[hhff]

Components in other repos (PR 2 of 2). Stacked on #100; spec rev 2.4 §5, §6.2, §8, §9 (measure.link), §10, §12.

(What / Why / Migration: see pr2-release-notes.md.)

One-way doors

None. Every new field is optional (gate.repo, act.repo, goal.measure.link, entry_hash on an approved link act); a project with no repo links writes none of them.

G1: why a single-repo project runs what it ran before

The goldens in test/fixtures/g1 are untouched (git log multi-repo..HEAD -- test/fixtures/g1 is empty). Hunk by hunk:

• git/gitOrDie/gitRun/gitBlob default cwd is HOME_CWD, which is undefined in a home checkout: every existing call runs where it ran.
• The location constants. In a home checkout commonDir from the script equals the cwd's, devteamDir, projectDir and runDir keep their formulas, and projectRoot is repoRoot, so projectRel and kitRel are unchanged. The DEVTEAM_HOME checks run only when DEVTEAM_HOME is set. Without it, a kit whose project folder has no settings.md (no initialised home lacks one) runs only init and help, unless --project/DEVTEAM_PROJECT names the project; in the kit's own repo (a remote is sanctuarycomputer/devteam) its read-only status, whoami, validate and links run too, as before.
• HEAD readers (cwdGit): in a home checkout process.cwd() is the same checkout the old no-cwd call read.
• repo('home') is homeFacts plus today's functions and caches (mainRef, resolveCommit, homeMergeShaFor = the old mergeShaFor body via findMergeSha, homeReleasedIn = v*).
• The routers. With no repo links every component's link is home, so factsRepo, repoOfTicket(Id), repoOfTicketLink return home and repoReadable('home') is true; releaseOf gives no pattern (v*).
• checkTicket/checkPr/verdictHolds/coverageFails/registryFails/logRule/reviewRule take repo('home'), whose git, mainRef, changedFiles are today's; headIn reads the same HEAD in a home checkout.
• gateEnv adds DEVTEAM_HOME only; DEVTEAM_MAIN is mainRoot. seedWorktree/detachedWorktree use home's settings and root. missingPins/pinsHint default to mainRoot.
• makeSession: home's worktree commands are today's (R.git = git, R.root = mainRoot); the prompt is PROMPTS[role] unchanged for home; the pane's env line gains DEVTEAM_HOME (typed into the pane, printed by no golden).
• sessionOf adds repoName, readable and a repo getter; the handoff path for home is projectRel's as before; handoffFor/handoffCommit/sessionSettled read through repo('home').
• merge: R = repo('home') for a home ticket, a plan or a chore; texts gain " in " only for another repo; the gate and act lines gain repo only for another repo; home resets exactly the caches it reset before.
• repo('home').gh: home's gh calls are exactly today's (no -R, so gh repo set-default still applies). Only a sibling's calls carry -R <its repo>.
• fleet status: no repos key, no repo/readable on a row, no new text line, no extra fetch or PR listing without repo links; the checklist gains lines only for repo links or an existing run/links.local.json.
• validate: D4 compares tickets in the same repo (all of them, without repo links); the story rule needs two repos; the per-repo coverage loop and the project-folder check run only over repo links.
• metrics: unowned-files/line-empty loop over home plus repo links (just home).
• whoami prints home= inside its # comment line (no golden).
• runMeasureCheck: home's fetch, cache reset, sha and worktree are today's; the check's env gains DEVTEAM_HOME.
• fetchMain: home's half is PR 1's (the no-origin skip, refusing a failed fetch); fetchLinkMain runs only for another repo. makeSession fetches home's main as before; fleet status's blockers start from the sibling fetch failures, an empty list without repo links.
• The file drawer's peek file: home's git log call is the same (same cwd, the --ref it was given, else none); repo is passed only for a sibling file.

Two single-repo behaviour changes are on purpose:

• merge and check-pr refuse a ticket whose depends_on hasn't merged, home's tickets included: "depends on , which is not merged yet: merge it first". Before, a dependency only kept a ticket out of ready.
• Two merge findings count only merges after the upgrade: merged-out-of-order (a ticket on main before its dependency) and merged-without-merge (a merge no merge act made). Each reads merges at or after the commit on home's main whose kit first names it, so an existing project's history raises nothing.

Outside a home checkout, two things change on purpose: with no DEVTEAM_HOME and a cwd in no git repo, home is the repo that holds the running kit (before, commonDir was null and git-backed commands refused); with a cwd inside an unrelated git repo, home is the running kit's repo too (before, that unrelated repo was treated as home). Git reads go to home (HOME_CWD); only HEAD readers (cwdGit) see the cwd's checkout.

No forge workflow

In line with #102 (the kit installs no forge workflow; merge runs the checks), this PR adds none for a sibling repo either: an earlier draft's init --github --repo and its two-checkout template are gone, and so is fleet status's missing-workflow warning. check-pr --repo <link> [--path <checkout>] stays as a command.

Testing

Targeted tests only, per the speed rule; CI runs the full matrix. Every task's test was run red, then green, with G1 after each. Home regressions run locally: devteam kit (43 subtests, before the last merge of #100), fleet park, fleet drain, the PR 1 merge/check-pr/registry/link tests. After merging #100's base again (upstream #98, #99, #101): G1, every PR 2 test and the touched PR 1 tests, 27/27.

Cold review fixes

Fable and Opus reviewed this independently and cold. There were no blockers. They found seven majors, each reproduced and each fixed with a test that failed first:

• Dependency order at merge: merge (dry runs too) refuses a ticket while any depends_on ticket, in any repo, is unmerged. An unreadable dependency fails closed. A new merged-out-of-order finding (severity 3) catches a merge done in the forge UI.
• Sibling fetches each tick: observe-metrics fetches every readable repo link's main, four at a time inside the tick budget. A failed fetch becomes repo-unreachable, with the remote redacted.
• Sibling worktree removal: worker <id> --remove [--force] removes a session worktree through its own repo and prunes that repo's worktree list. supervisor.md points to it.
• Gates in a sibling worktree: gate --all and gate <name> run in a sibling worktree under that repo's gates and env, and log its repo.
• Dashboard cache: the file drawer's cache key includes the repo and the ref.
• Home's gh calls: they carry no -R, as before this change.
• Phantom home refused: a kit copy with no settings.md and no DEVTEAM_HOME refuses everything but init and help, so it can't run as a phantom home. The kit's own repo still runs its read-only views (see below).

The reviews' minors are tracked for a follow-up PR.

Upstream review fixes

devteam-ae's review (at 187eb78) found two blockers and four should-fixes. Blocker 1 (an owner's "no" approving a link) is fixed on main by #113 and comes in with that merge. The rest, each with a regression test:

• One answer lands only what its question showed. A repo link question carries the full settings diff it approves (every repo link change waiting to land, as "main has / would be"). --approved logs an act per entry with its entry_hash and main's prior_hash. merge --approved binds every changed repo link entry to such an act of that answer and refuses any other by name.
• Workers can't push to their own repo's main. The deny rules are per session and also name the session's repo's main branch (trunk for a sibling). A new merged-without-merge finding catches a merge on any repo's main that no merge act made.
• Sibling gates run outside home's tree. Merge's throwaway checkouts of another repo go in the OS temp folder, so a gate can't pass on home's node_modules or configs. Worker and review worktrees stay under .worktrees/; README and spec state the risk.
• Single-repo changes, stated above. merged-out-of-order counts only merges after the upgrade.
• The kit's own repo. The dead kitsOwnRepo() is gone, and status, whoami, validate and links run there again.

The review's nits (7–13) are tracked for the follow-up PR.

🤖 Generated with Claude Code

[hhff]

Adversarial review (upstream loop), at 187eb78: CHANGES

The reviewer ran every finding on Node 18.20.4 against throwaway fixtures (home plus two siblings, local bare origins, forge git). Six of the PR's targeted multi-repo tests and five home-regression tests pass.

Blockers

1. The owner's "no" lands the repo link (linkByOwner :8619, ownerAnswer :3392).
   • Reproduced: the owner answers "no, do not add it", then the kit's own printed flow (--approved qid, then link land registry, then merge --chore registry --approved qid) merges the link.
   • Root cause on main: ownerAnswer checks only that the question was answered, not what the owner said. Fixed on main via Decisions: an owner's answer approves one call, about what it was asked about #113 (d427e62): a merge approval must be the question's recommendation. Merge main in once Decisions: an owner's answer approves one call, about what it was asked about #113 lands. linkByOwner should apply the same rule (matched) when it records the act.
2. One answer approves link changes the question never named (:3484-3497, ownerApproved :8490).
   • Reproduced: approving "add the docs repo link" also landed hand-edits to links.console.gates, links.console.ignored_checks and links.companion.remote in the same chore.
   • The owner has decided that one owner-only answer may approve a whole bundle. So the rule isn't changing; the owner must see exactly what they approve.
   • Required:
     • (a) merge binds each changed owner-kind link entry to an act with approved_by === --approved and the same entry_hash, so the entries the question was asked about are exactly the ones that land, and any others need their own approval;
     • (b) the approval question carries the full settings diff it covers.

Should-fix

3. Workers can push straight to a sibling's main. The worker deny list is home's literal git push*main*, so a sibling on trunk isn't covered. findMergeSha then treats that ticket as merged with no gates or reviews. Fix: a per-session deny list built from that repo's main branch, plus a finding for a merge on any repo's main with no merge-word act.

4. Sibling gates can pass only because the worktree sits inside home's tree: home's node_modules, .tool-versions and lint/ts configs are found by walking up the directories. Put sibling worktrees outside home's tree, or at least merge's throwaway ones, or document the risk.

5. Single-repo behaviour changes the G1 section doesn't mention.

   • depsFails now refuses a home ticket whose dependency hasn't merged.
   • merged-out-of-order scans all history, so existing projects get high-severity findings for old merges.

   Say so in G1, and limit the finding to merges after the upgrade.

6. Every non-adopted checkout now refuses everything but init and help. kitsOwnRepo() is dead, and status in the kit's own repo is refused. The PR body's description of the guard is out of date.

Nits

7. DEVTEAM_HOME leaks into every gate's environment and every worker pane; the PR's own test file had to delete it.
8. DEVTEAM_OWN_KIT=1, or a set DEVTEAM_PROJECT, gets past the guards. Refuse DEVTEAM_OWN_KIT when the running kit isn't home's.
9. remoteKeyAt misses non-GitHub scp-style remotes and keeps https userinfo.
10. A bare clone at a link's path resolves to its parent directory, and components check then fails open. Refuse bare repos; use --show-toplevel.
11. A sibling checkout's pushurl or insteadOf redirects fetch and push while the identity check, which reads only remote.origin.url, still passes.
12. isHandoffFile accepts handoff paths under every repo's project folder name.
13. ownerApproved has no time window, unlike linkActs.

What held

• A sibling PR can't touch its settings.md, its log or another ticket's folder.
• Home's check-pr on a sibling branch is refused.
• Sibling gates come from home's settings.
• The DEVTEAM_HOME guards hold as claimed.
• Worker log lines go to home's live log.
• tmux behaviour is unchanged.
• Remote URLs are redacted.
• No test covers merge binding an approval to an entry, a "no" answer, or the per-repo deny list.

Merging is the upstream loop's call: it needs 1 (by merging main in) and 2 fixed, CI green, and our local runs.

[hhff]

Merging for v0.20.1 (upstream loop).

• Local release candidate (main with Tests never reach the machine's default tmux server #117, plus An owner's answer binds to the question as the owner saw it #116, Tickets in other repos: one fleet, one log and one graph across sibling repos #108, Lessons: keep one with an owner's note that refines it #114 and gate-change can be settled by the owner's own standing rule #115): Node 24.14.1 passed 122/123. The one failure is the hub test's "both instances listed with counts" timeout under load; it passed in the previous candidate's run and on CI.
• CI: 18/20/22/24 green on this head, with main merged in.
• Next: main's own CI checks the combined result before the tag.