aware app install can later discover and run a sibling manifest

[pawellisowski]

Summary

On CLI v0.134.0, aware app install <folder> can select and install one top-level .flo/.app manifest while later discovery and by-id verbs select a different sibling manifest from the copied folder. PR #499 makes the selection deterministic but demonstrates that the install has no durable record of which manifest was authoritative.

Observed (verified in source / at runtime)

1. On main, install_app_from_path takes the first .flo/.app returned by read_dir, loads that app, and copies the entire source directory to apps/<app-id> (cli/src/install/local.rs:66-93). The chosen manifest path is not persisted.
2. Later discovery independently calls find_app_manifest for the installed directory (cli/src/manifest/loader.rs:65-90). That selector prefers <dir-name>.flo, then the first .flo, then the first .app (cli/src/manifest/loader.rs:181-196). After installation renames the directory to the selected manifest's app: id, this can be a different question from the install-time selection.
3. Reproduced on rebased PR refactor: share artifact writing and PATH binary lookup #499 with bundle/bundle.flo declaring app: alpha beside bundle/alpha.flo declaring app: decoy:

$ aware app install bundle
✓ installed alpha (lockfile written)

$ aware app list
warning: app "decoy" is in directory "alpha" — name and `app:` field disagree
ID     VERSION  NODES  CONNS  LAYOUT
decoy  0.1.0    1      0      linear

$ aware app show alpha
app:           decoy
description:   sibling decoy manifest

The install-time lockfile.yaml says app: alpha, while discovery and show load decoy.

Repro

Create a source directory bundle/ containing these two valid apps:

# bundle/bundle.flo
app: alpha
version: 0.1.0
description: selected manifest
nodes:
  - id: gate
    inline: { kind: predicate, description: always pass, code: "true" }
requires: []

# bundle/alpha.flo
app: decoy
version: 0.1.0
description: sibling decoy manifest
nodes:
  - id: gate
    inline: { kind: predicate, description: always pass, code: "true" }
requires: []

Then run with an empty temporary AWARE_HOME:

aware app install bundle
aware app list
aware app show alpha

On main, which file install chooses depends on filesystem enumeration order. With PR #499's canonical selector, install consistently chooses bundle.flo, then later discovery consistently chooses alpha.flo after the directory becomes apps/alpha/.

Expected / proposal

An installed app must have exactly one durable authoritative manifest, and every later surface (list, show, run, explain, export, compile/update paths) must load the same manifest that install validated.

Choose and specify one contract before implementation:

• persist the selected relative manifest path as installed metadata and make installed-app resolution honor it; or
• reject ambiguous source folders containing multiple top-level app manifests before copying.

Keep this separate from PR #499's independent artifact-writer and PATH-lookup deduplications.

Why it matters

The CLI can report a successful install and write a lock for app A, then list and run app B from the same installed directory. That is silent wrong-app execution, not merely a naming warning.

References

• Split from PR refactor: share artifact writing and PATH binary lookup #499 after Codex reproduced the lock/discovery disagreement.
• Builds on app: no first-class rename/duplicate verb, and verbs resolve an app inconsistently (app: field vs dir name) #226, which made app verbs agree on directory/id resolution but did not define manifest identity inside a directory.
• cli/src/install/local.rs:66-93
• cli/src/manifest/loader.rs:65-90
• cli/src/manifest/loader.rs:181-196

[pawellisowski]

Claimed by the cloud issue-fixer routine.

---

Generated by Claude Code

[pawellisowski]

Fixed and merged as d255293 (#515). Left open and labelled qa-ready: the fix is ready to test, not verified.

Contract chosen — the second of the two this issue offered. A source folder must hold exactly one top-level .flo/.app, and aware app install refuses one holding more, naming every candidate, before anything is copied. Persisting the selected path was rejected: it is a second source of truth that goes stale the moment someone edits the directory, it still needs the ambiguous fallback for every app installed before it and every directory placed under apps/ by hand, and it records an arbitrary pick — read_dir order, so the same folder can install as a different app on a different machine — as though it were a decision. The rationale is in require_single_app_manifest's doc comment, and the contract is written into 10-core/app-spec.md § Installation and distribution.

Root cause was four selectors, not one bad one. app install chose a manifest three times (pre-validation, inside install_app_from_path, and again in the installed directory to write lockfile.yaml) and discovery chose a fourth time under different rules. All of them now share one tiered lookup — <dir-name>.<first ext>, then each extension in precedence order — resolved over a sorted candidate list, so no answer depends on filesystem enumeration order. Install returns the manifest it validated, so the lock is written from that rather than from a re-scan.

To verify: the repro in this issue should now fail at install with an error naming both bundle.flo and alpha.flo, and nothing should appear under apps/. The single-manifest shape it protects (bundle.flo declaring app: alpha) should install as alpha with list, show and the lock all agreeing. Both are pinned as tests; the ambiguous one was confirmed red on the parent commit, where the install succeeded.

Two things this deliberately did not do, both stated in the PR:

• aware app install 30-apps/_examples now refuses instead of installing an arbitrary one of the eight loose .app files. That path never had a correct answer; installing a chosen example means copying it into its own directory.
• A directory already holding two manifests — installed before this gate, or placed by hand — cannot be fixed retroactively, so it warns instead.

Codex reviewed three times and found two P2 defects, both fixed at the root; its pass on the final commit is clean. One of them exposed a separate pre-existing bug: dst.exists() is a check rather than a reservation, so two concurrent installs of the same id merge into one directory. Filed as #516 rather than widened into this PR.

Claim released.

---

Generated by Claude Code