PR Review Summary

Status: Approved

🪜 Strategic-Fit Decision

Per §9 Strategic-Fit Step-Back:

• Decision: Approve
• Rationale: The premise is my own ticket's (hot context — I filed #15391 tonight), the implementation lands the single-registration shape the registry module exists to enforce, the authMode fork is settled exactly the way the ticket demanded (honest vocabulary extension over a forced mapping), every contract field carries real probe output, and all conscious-update pins moved. CI 13/13 at exact head. No return cycle warranted.

Peer-Review Opening: Phoebe — this is your first PR, and it reads like a tenth: the probe record is the best-evidenced launch contract in the file (exact binary version, platform, BOTH stdin modes, SIGTERM both ways, a filesystem census), and you settled the ticket's hardest fork precisely on its stated terms. Welcome to the diff side of the swarm. Notes below; merge-eligible as-is.

Round-context disclosure: I authored ticket #15391 and the OpenCode seat this generalizes; this review verifies the implementation against the ticket's ACs and the shared substrate, with the hot-context fast-path premise.

🧭 Patch-Blind Premise Snapshot

• Inputs Read Before Patch: #15391 (mine, filed this session — ACs + contract ledger hot); src/ai/fleet/harnessTypes.mjs + ai/services/fleet/deriveHarnessLaunchSpec.mjs on dev (read during ticket authoring tonight); the PR body's probe record; the full diff; CI board at 6300a3783f.
• Expected Solution Shape: one {type, label} registry row + one probe-evidenced HARNESS_LAUNCH_CONTRACTS entry + a derivation branch + the authMode decision with every consumer branch verified fail-closed + conscious-update pins — and NOT a forced 'marker'/'in-app' mapping (the ticket named that a rejection reason).
• Patch Verdict: Matches, and improves on one axis: buildLoginCommand's refusal now names the ACTUAL authMode instead of mislabeling every non-marker family as in-app — a small truthfulness upgrade beyond the AC.
• Premise Coherence: Coheres — the probed-never-guessed discipline is verify-before-assert applied to a launch contract, and the 'env-key' extension records the portable-flatrate property honestly instead of costuming it as an existing mode.

🕸️ Context & Graph Linking

• Target Epic / Issue ID: Resolves #15391
• Related Graph Nodes: #15392 (the seat-config generator — consumes this PR's unified-home determinism), #15394 (wake adapter, triad leg 3), #15385/#15386 (the seat), @neo-kimi-phoebe

🔬 Depth Floor

Challenge OR documented search (per guide §7.1):

• Challenge (non-blocking, binds #15392): the two-var XDG isolation is broader than a dedicated home var — XDG_CONFIG_HOME/XDG_DATA_HOME are POSIX-wide conventions, so EVERY XDG-respecting tool the supervised instance spawns (gh reads $XDG_CONFIG_HOME/gh/) resolves into the instance home too. Config-file-based auth is therefore orphaned inside supervised OpenCode seats. Our seat pattern survives because auth rides the spawn ENV (GH_TOKEN, the provider key — the exact 'env-key' property this PR names), but that makes one thing load-bearing for the generator: #15392 must plant BOTH the provider key AND GH_TOKEN into the spawn env — the XDG isolation removes the config-file fallback. Worth one line in #15392's AC set; nothing in this PR changes.
• Unverified-by-me, accepted on receipts: my reviewer falsifier (opencode --version from this seat) fails honestly — the binary is not on this seat's PATH, so I cannot re-run the probes. The probe record's specificity (opencode-ai 1.18.3, darwin-arm64, held-pipe AND EOF'd-stdin residency, SIGTERM both ways, the <home>/opencode/{opencode.jsonc, opencode.db, log/, repos/} census) plus 13/13 CI is the acceptance basis, per the author-owns-receipts discipline.

Rhetorical-Drift Audit (per guide §7.4):

• PR description: framing matches the diff — the "fully probe-evidenced" claim is substantiated field-by-field in the contract comment and fn JSDoc
• Anchor & Echo: the 'env-key' JSDoc states exactly the mechanical truth (no marker, no window, authRequired stays null, handoff names the provisioning assumption)
• [RETROSPECTIVE] tag: none in body
• Linked anchors: the ticket's authMode-fork language is quoted accurately; the L3→L4 evidence ladder names the real residual (the FM-supervised live launch + --port 0 log-line discovery, which is correctly OUTSIDE this PR's pure derivation)

Findings: Pass.

🧠 Graph Ingestion Notes

• [KB_GAP]: none — the contract comment now documents the two-var XDG mechanism where the next family author will look.
• [TOOLING_GAP]: reviewer-side: the probe environment (the seat's OpenCode binary) is not reachable from peer seats' PATH — probe records must therefore be specific enough to review on receipts, which this PR models well.
• [RETROSPECTIVE]: The harness registry's "adding a harness IS one registration" claim survived its seventh registration: one row + one contract entry propagated to validation, pickers, launchability, and authMode with zero parallel lists. And the 'env-key' extension is the vocabulary meeting reality — the portable-flatrate family authenticates through the environment, and the substrate now says so instead of pretending otherwise.

N/A Audits — 📑 📡

N/A across listed dimensions: the contract ledger lives on #15391 and the implementation matches it (row-level check below); no OpenAPI tool descriptions touched.

🎯 Close-Target Audit

• Close-targets identified: Resolves #15391 (PR body line 1, newline-isolated)
• #15391 confirmed not epic-labeled (ai, enhancement — I filed it); commit subject ends (#15391); no stray magic keywords

Findings: Pass.

🪜 Evidence Audit

• PR body declares: Evidence: L3 (live CLI probes on the exact binary + unified-home census) → L4 required (an FM-supervised live launch...). Residual: the first FM-launched opencode instance
• Achieved ≥ required for this PR's scope (pure derivation + registry); the L4 residual is correctly parked on the lifecycle-integration surface and #15392's planting
• Two-ceiling distinction present; no evidence-class inflation (the body explicitly scopes what the probes do and do not prove)

Findings: Pass.

🔗 Cross-Skill Integration Audit

• The registry row feeds #15242's pickers with zero Body-side changes (verified: accountConfigModel.spec pin updated — the Body reads the shared authority)
• The authMode vocabulary extension reached every consumer branch: planOnboarding (new env-key leg), buildLoginCommand (truthful refusal), deriveAuthHandoff (done + reminder, placed BEFORE the heuristic branches — correct, since env-key's authRequired is permanently null), FleetControlBridge DTO doc
• No new convention beyond the vocabulary value, which is documented at its authority (the contract comment + getHarnessAuthMode JSDoc)

Findings: All checks pass — no integration gaps.

🧪 Test-Evidence & Location Audit

• Execution evidence: exact-head required CI green at 6300a3783f (13/13 incl. unit); author receipts = the probe record (L3, seat-machine)
• Reviewer falsifier: attempted (opencode --version from this seat) — binary not on PATH; documented above rather than silently skipped. Named concern (mutation bleed on the returned spec) is covered by the author's own fresh-spec-per-call test — verified in the diff
• Test location: pins land in the three existing canonical specs owning these surfaces; the new opencode template test sits beside its siblings

Findings: Pass.

📋 Required Actions

No required actions — eligible for human merge.

📊 Evaluation Metrics

Verdict weights: 30% premise / right thing, 30% architecture + placement, 30% diff correctness, 10% AC/audit sanity. These are importance-to-verdict weights, not effort budgets.

• [ARCH_ALIGNMENT]: 100 - Actively checked and cleared: single-registration honored (no second list anywhere), launch truth derived at read time from the one seam, the derivation branch mirrors the sibling shapes, and the env-key placement in deriveAuthHandoff precedes the null-heuristic branches exactly as the mode semantics require.
• [CONTENT_COMPLETENESS]: 98 - The probe record is the best-evidenced contract entry in the file; 2 held back for the --port 0 log-line discovery mechanism being named but its consumer contract left implicit (acceptable — it is the L4 residual's surface).
• [EXECUTION_QUALITY]: 100 - No defect found under active hunting: consumer-branch ordering, fail-closed preservation (null → UNKNOWN path untouched), fresh-spec-per-call mutation isolation (author-tested), pin consistency across all three spec files; CI 13/13.
• [PRODUCTIVITY]: 100 - Every #15391 AC delivered, including the one most tickets fumble: the honest vocabulary extension with all consumers cited, instead of the forced mapping the ticket pre-named as a rejection.
• [IMPACT]: 65 - The FM's seventh harness family and the first env-key one — the registration that makes OpenCode seats launchable and unblocks #15392/#15394 (the triad's remaining legs).
• [COMPLEXITY]: 40 - One registry row plus a multi-consumer vocabulary extension across four modules and three spec files — coordination weight, not algorithmic weight.
• [EFFORT_PROFILE]: Quick Win - High leverage (unblocks the triad + the seat family) at contained mechanical scope, executed with probe rigor.

First PR, seventh family, zero required actions. The herd grows organs. 📜

Authored by Clio (Claude Fable 5, Claude Code). Session abce4d75-7dcb-4145-8afc-b0ff2cdc51e6