6.0 KiB
Registry Gate 7 reconciliation — working record
Source pin: commit 50d2a2eba9.
Draft registry plan 5f010ef6ad2b7c68ee0b7d29bdd3868ea23662bc996e4adfb2e48da5598d60b2.
Foundation plan ce58408289fceea4b99d8a77c69523a1c04e683f5084f31c7c4199ae0b9934f3.
Registry review alignment only; no implementation authorized. This record is analysis, not plan approval.
Gate 7 as written (registry draft)
Determine pi's supported host-side noninteractive OAuth refresh trigger; implementation must prove refresh without exposing or duplicating tokens. Paused by the foundation plan until seat-global selection and generated per-seat files are reconciled with concurrent workspace sessions.
Later owner decisions that constrain the answer
From the foundation plan, owner ruling D10/R16-R17 and Q5: workspace missions have exactly one parent project; each workspace belongs to one project. Session scope is immutable and workspace-scoped (Q16 connection model; #53 record table: session records carry agent/project/workspace IDs and creation mode; execution records carry launch/configuration hash references and resolved-context manifests). Resume keeps one session ID and mints a new execution ID. Registration-based access: workspace registration may narrow but never widen project registration.
Reconciliation findings so far
F1. The draft's seat-global settings-selection.json is incompatible with immutable, workspace-scoped sessions: two concurrent workspace sessions of one seat could require different accounts at the same time, while one mutable file can only express one choice. Verdict: the draft's seat-global single-selection model must be revised toward per-execution materialization inputs before any implementation.
F2. Materialization must become an explicit input to execution records. The #53 execution record already reserves launch/configuration hash references and a resolved-context manifest; placing the selected settings profile/account set and generated-file manifest identity there preserves audit lineage without adding a second system configuration. The draft's activation-log receipts remain compatible as host-side evidence.
F3. Session-vs-relaunch semantics. The draft already says selection normally applies at relaunch/new session and defers in-session identity swapping. Under #53, resume mints a new execution ID, so an account change can occur between executions of one session only if immutable session metadata pins the original account for forks (draft gate 6). If the session record pins account identity, forked sessions inherit that pin; unpinned ad-hoc relaunch materializes the current profile default. This keeps gate 6 and gate 7 consistent rather than conflicting.
F4. Unchanged by this reconciliation: gate 7's core requirement remains. Noninteractive refresh is host-side only, agents never authenticate, tokens are never exposed or duplicated, and launch-time ensure is the final fail-closed gate. Workspace scoping changes where a selection is recorded (execution record), not who may refresh.
F5. Out-of-scope interactions explicitly rejected here: no per-workspace credential forks (one central registry per canon; a workspace may not mint its own credentials); no mission/task grant widening (later policy phase keeps task narrowing only); registry stays a single authority under dataRoot, not a second config.
O1 result: interview-record search (2026-09-10)
Searched the four interview-bearing plan files for launch profiles, account pinning, settings profiles, and session identity rulings. No later owner ruling decides named launch profiles or session account pinning; both remain open as the draft's gates 5/6 state. Relevant confirmations found:
O1a. R17 (Q20/Q21) extends the launch fingerprint to harness/model settings, explicitly excluding credentials, chat, and task progress. This supports F2: account identity belongs in execution inputs and fingerprints, while credential material never does. Consistent with F4's no-token-exposure rule.
O1b. R16 ruling pattern (SOUL current-revision loading per execution, running conversations not silently reloaded) is the precedent for materialization: each execution resolves current registry state, records what it used, and does not mutate a running session's identity. This resolves F3's relaunch semantics in the same shape the owner already chose for instructions.
O1c. R14/R33 keep actor/scope/session plus invocation evidence in records and forbid credentials in them. Activation receipts and manifests must therefore stay secret-free, matching the draft's existing secret-non-disclosure suites.
O1d. R21/R24 (one controlling connection; no duplicate launch) and R23 (membership revocation stops affected executions) do not change refresh mechanics but reinforce that materialization regeneration must not disturb running sessions: regenerate beside, swap on next execution, never mid-session.
O1 is closed: no contradiction found; reconciliation F1-F5 stands. Remaining open items are O2 (independent review) and the O3 owner decisions.
O1. CLOSED 2026-09-10: interview search found no contradicting ruling; R16/R17 precedents support the reconciliation. Details in the O1 section above. O2. CLOSED 2026-09-10: independent REGISTRY-GATE7-FILBERT-1 verdict SUPPORTED all six checks against real bytes at pin 50d2a2eb; snapshot unchanged; verdict at docs/plans/reviews/2026-09-10_registry-gate7-verdict.md. Both non-blocking notes accepted as framing caveats. O3. Owner decisions — RESOLVED 2026-09-10: Jason answered yes to all three. Forked sessions pin the original account; unpinned relaunches use the current profile default; named launch profiles are deferred. Recorded in the draft's gates 5/6 as owner rulings and reflected in the revised runtime-selection section.
Status: complete through independent review and owner rulings. R1 verdict SUPPORTED; O3 resolved by Jason 2026-09-10; draft revised accordingly. Remaining open items are the still-unresolved draft gates 2/3/4/7/8/9/10, which belong to the owner. Registry implementation remains unauthorized until those are decided and a revision is approved.