Record owner account-selection rulings and registry draft revision

2026-09-10 14:27:47 -05:00
parent 50d2a2eba9
commit b8008eda5d
7 changed files with 177 additions and 10 deletions
@@ -279,6 +279,12 @@ selection.
 ## Runtime seat selection
 Owner rulings 2026-09-10 supersede the earlier seat-global single-selection
 model: selection is per-execution, not one mutable seat-global file. The file
 below remains the host-side record of the seat's current default choices, but
 it is an input to the next materialization, not a live switch that rewrites a
 running session's identity.
 At-will changes are mutable state, not repo edits:
 ```text
@@ -302,11 +308,20 @@ Rules:
 - Selection can choose only accounts allowed by the seat's referenced profile.
 - Omitted provider selections use profile defaults.
- Changing selection is append-only-audited and triggers regeneration.
+- Changing selection is append-only-audited and triggers regeneration for the
  next execution; concurrent workspace sessions of one seat materialize
  independently from their own execution records, so one file never rewrites
  another running session's identity.
 - Forked sessions pin the original account in immutable session metadata
  (owner ruling 2026-09-10, gate 6). Unpinned relaunches materialize the
  current profile default.
 - No account choice silently falls back to another account.
- In-session identity swapping is deferred. Selection normally applies on
+- In-session identity swapping is deferred. Selection applies on
  relaunch/new session; changing identity inside a session risks ambiguous
  billing, provider state, and audit lineage.
 - Each execution record references the selected settings profile, account
  set, and generated-file manifest identity, per the #53 execution/context
  manifest records. Credentials never enter records or fingerprints (R17).
 ## Mechanical per-seat materialization
@@ -465,11 +480,14 @@ No named accounts currently exist, so migration is state-free:
   `credential.json` secret) versus one encrypted/combined file.
 4. Decide encryption-at-rest requirement. Filesystem 0600 is specified now;
   external keyring/envelope encryption would change login/refresh design.
-5. Confirm selection scope: seat-global only initially, or named launch profiles
+5. **RESOLVED (owner, 2026-09-10):** named launch profiles are deferred. Per-execution
-   (e.g. `work`, `personal`) as a first-class layer.
+   selection recorded in execution records/context manifests (per the Gate 7
-6. Confirm whether a seat may switch same-provider account on relaunch only, or
+   reconciliation and #53 model) covers the need; a named-profile layer would be
-   whether forked sessions must pin the original account in immutable session
+   a separate future decision if a use case emerges.
-   metadata.
+6. **RESOLVED (owner, 2026-09-10):** forked sessions pin the original account in
   immutable session metadata. Ordinary relaunches of an unpinned session
   materialize the current profile default. Selection changes apply between
   executions, never mid-session.
 7. Determine pi's supported host-side noninteractive OAuth refresh trigger;
   implementation must prove refresh without exposing or duplicating tokens.
 8. Confirm local Ollama container routing (`host-gateway`) and remote Ollama
@@ -7,9 +7,16 @@ update this file to the next action). No ambiguity, no re-planning.
 ## Next action
-Review `docs/plans/2026-09-03_auth-provider-harness-registry.md` and reconcile
+Registry review alignment is complete through independent review:
-Gate 7 with later owner decisions and #53's workspace/session model. This is
+REGISTRY-GATE7-FILBERT-1 SUPPORTED the Gate 7 reconciliation. Record:
-registry review alignment only; no registry implementation is authorized.
+`docs/plans/reviews/2026-09-10_registry-gate7-reconciliation.md`; verdict:
 `docs/plans/reviews/2026-09-10_registry-gate7-verdict.md`.
 Jason resolved all three O3 decisions on 2026-09-10 (fork pins account;
 unpinned relaunch uses default; named launch profiles deferred); draft gates 5/6
 now record those rulings and the runtime-selection section uses per-execution
 semantics. Next action: complete the focused r2 review of the revised draft,
 then commit exactly the approved bytes. Remaining draft gates 2/3/4/7/8/9/10 are
 still owner decisions; no registry implementation is authorized.
 Owner goal #1498 completed: independently approved skill/launcher repair published
 at f3dce3208877626043c521c6ef5076f9559309b0; fresh remote identity verified and
@@ -190,6 +197,8 @@ and unfinished-fixture status.
 ## Completed log
 - 2026-09-08 — Owner-corrected Sage setup: `agents/sage/` now owns the DYOR business/strategy persona, context, launcher, and working records. Native cwd is this checkout, private history is `.pi/state/sage/sessions/`, and the prior brain command forwards here. Six offline launcher tests and both real configuration checks pass; current registry alignment queue unchanged.
 - 2026-09-08 — Owner-requested development team: Rocko launches Claude Code with Fable; Filbert launches Pi with `openai-codex/gpt-6-astra:low`; Darkwing is the development team lead and Dewey remains frontend/UX owner. Five offline launcher tests and both new agents’ local configuration checks pass. No model session started; inspector acceptance queue unchanged.
 - 2026-09-08 — Owner-requested Dewey frontend/UX agent: `agents/dewey/launch.sh` uses the shared native launcher with its own persona, context and session history. Offline launcher checks pass for both agents and real Dewey `--check` passes; no model session started. Current inspector acceptance queue unchanged.
@@ -0,0 +1,9 @@
 # REGISTRY-GATE7-FILBERT-R2
 Focused follow-up review. Owner Jason answered yes to all three O3 decisions on 2026-09-10: forked sessions pin the original account; unpinned relaunches use the current profile default; named launch profiles are deferred.
 Darkwing revised only the registry draft's gates 5/6 (marked RESOLVED with the rulings) and the runtime-seat-selection section (per-execution semantics, independent materialization for concurrent workspace sessions, fork pin, execution-record references, credential exclusion). The reconciliation/verdict/request files and CURRENT.md carry the matching status text; no other draft sections changed.
 Verify frozen five-file snapshot /tmp/registry-gate7-r2-3xacrwga at SHA256SUMS 510a448e18fc5753e2f6a97b2e42680c8f0510efd71824eb51458ed274042b0b. Confirm against baseline commit 50d2a2eb that draft deltas are confined to the two stated areas, rulings are recorded as owner decisions (not reviewer or coordinator authority), remaining gates 2/3/4/7/8/9/10 stay untouched and unresolved, and the revision contradicts neither your R1 verdict nor any cited owner ruling. Read-only; no implementation, no credential access, no shared-log edits.
 Write ONLY docs/plans/reviews/2026-09-10_registry-gate7-r2-verdict.md and reply to Darkwing/default. APPROVED permits committing exactly these reviewed bytes; REQUEST CHANGES names the fix. This review still authorizes no implementation; gates 2/3/4/7/8/9/10 remain owner decisions.
@@ -0,0 +1,46 @@
 # REGISTRY-GATE7-FILBERT-R2 — verdict
 Reviewer: Filbert (independent). Author of the revision: Darkwing. Baseline `50d2a2eb…`; frozen snapshot `/tmp/registry-gate7-r2-3xacrwga` at manifest SHA-256 `510a448e18fc5753e2f6a97b2e42680c8f0510efd71824eb51458ed274042b0b` (all five hashes verified; snapshot unchanged after review).
 ## Verdict: REQUEST CHANGES
 The registry draft revision itself is correct, confined, and owner-attributed. The blocking defect is status currency in two of the five frozen files: the set is internally inconsistent about whether the O3 decisions have been made, and committing it exactly as frozen would put the contradiction into the durable record, including CURRENT.md's single-source next action.
 ## What verifies
 - **Draft confinement:** against baseline `50d2a2eb…`, the registry draft changes only the runtime-seat-selection section and gates 5/6. No other section, including gates 1–4 and 7–10, changed. Gates 2/3/4/7/8/9/10 remain unresolved and untouched.
 - **Owner attribution:** both resolved gates read "RESOLVED (owner, 2026-09-10)" and the selection section says "Owner rulings 2026-09-10 supersede…" — authority is recorded as the owner's, not the reviewer's or coordinator's.
 - **Substance:** per-execution selection semantics, independent materialization for concurrent workspace sessions, fork pin in immutable session metadata, unpinned relaunch at current profile default, execution-record references with R17 credential exclusion. Each element matches what my R1 verdict verified as source-consistent (F1/F2/F3, O1a) and what O3 recommended; the owner's yes-rulings adopt exactly those branches. No contradiction with the R1 verdict or any cited ruling.
 - **Unrelated drift excluded:** my R1 verdict file in the snapshot is byte-identical to my live original; the request file is identical; the reconciliation's only content changes are the accurate O2-closed line and the status line.
 ## Blocking finding R2-F1: stale O3 status contradicts the draft's recorded rulings
 - `docs/plans/CURRENT.md` next-action block still says "present the three remaining O3 owner decisions to Jason and record his rulings," but the draft in this same frozen set records those rulings as decided on 2026-09-10. CURRENT.md is the single-source next-action file; committed as-is, it would direct a future session to re-ask decided questions.
 - `docs/plans/reviews/2026-09-10_registry-gate7-reconciliation.md` status still says "The three O3 decisions are now the only open items and belong to Jason," and its O3 list still frames all three as "genuinely open." Same contradiction.
 The review request's own composition claim ("carry the matching status text") is not met on these two files.
 ## Required fix (small, no draft change)
 1. Update the snapshot's CURRENT.md registry block to record the owner's 2026-09-10 yes-rulings on all three O3 decisions and set the true next action (record rulings, then the remaining owner gates; still no implementation).
 2. Append or amend the reconciliation's status/O3 lines to record the rulings as closed by owner decision on 2026-09-10, keeping the R1 analysis text intact.
 3. Re-freeze and resend; I will re-verify hashes and the two status locations only. The registry draft bytes need no change.
 This review authorizes nothing: no implementation, no credential access, and gates 2/3/4/7/8/9/10 remain owner decisions.
 ---
 # Follow-up verdict (re-frozen candidate, appended 2026-09-10)
 Re-frozen snapshot `/tmp/registry-gate7-r3-6qxzgx95` at manifest SHA-256 `2ec6634f5adcf3909fe0abdd830008c95bdab73b1a90befb2ee41fdba61acd1c`; all five hashes verified; snapshot unchanged after review.
 ## Verdict: APPROVED
 R2-F1 is resolved exactly as specified above, and nothing else moved.
 - **Registry draft:** byte-identical to the r2 snapshot's verified bytes; all r2 findings on the draft carry over unchanged.
 - **Reconciliation:** only the O3 item and Status line changed. O3 now records "RESOLVED 2026-09-10: Jason answered yes to all three" with the rulings and their recording locations; Status names the remaining open items as draft gates 2/3/4/7/8/9/10, owned by the owner, implementation unauthorized. The R1 analysis text is intact.
 - **CURRENT.md:** the registry block records Jason's three resolutions, states where the rulings live, and sets the next action to completing this review and committing exactly the approved bytes, with gates 2/3/4/7/8/9/10 still owner decisions. The stale "present the decisions" instruction is gone.
 - **Untouched:** my R1 verdict file and the r2 request file are byte-identical to the r2 snapshot.
 Committing exactly these five reviewed files at manifest `2ec6634f…` is approved. This authorizes the documentation commit only: no implementation, no credential access, and gates 2/3/4/7/8/9/10 remain owner decisions.
@@ -0,0 +1,46 @@
 # Registry Gate 7 reconciliation — working record
 Source pin: commit 50d2a2eba9c93d3f801017ea6fd53a30308d9ab1.
 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.
@@ -0,0 +1,11 @@
 # REGISTRY-GATE7-FILBERT-1
 Independent review request. Author Darkwing; reviewer Filbert (no authorship of this analysis). Declare conflicts before acting.
 Frozen snapshot /tmp/registry-gate7-review-vewu5_2t, SHA256SUMS 61f284fd7647e380c1f0672a8d4c10a8e6f1b94c8a0576c8366ff96e9500b586, at source pin 50d2a2eba9c93d3f801017ea6fd53a30308d9ab1. Reconciliation draft 957f7e6b plus four source plans.
 Task: verify the Gate 7 reconciliation analysis is faithful to its cited sources. Specifically: (1) F1's incompatibility verdict between the draft's seat-global settings-selection and #53 immutable workspace-scoped sessions under concurrent executions; (2) F2's placement of selection/materialization identity in execution records and context manifests consistent with the #53 record table; (3) F3's relaunch-vs-fork semantics consistent with draft gate 6 and the resume-new-execution rule; (4) F4 preserves gate 7's no-token-exposure, host-side-only refresh core; (5) O1's claim that R16/R17/R14/R33/R21/R23/R24 support, not contradict, the reconciliation; (6) F5's exclusions do not silently decide open gates 5, 6, 8-10 or authorize implementation.
 Constraints: read-only analysis of the frozen snapshot; no implementation, no credential access, no live operations, no edits to the reconciliation or shared logs. Flag any overstatement, missed contradiction with any owner ruling in those files, or any place the analysis drifts from review into unauthorized design approval. The O3 recommendations are marked as recommendations, not decisions.
 Write ONLY docs/plans/reviews/2026-09-10_registry-gate7-verdict.md with SUPPORTED / REQUEST CHANGES, findings, and exact citations. Reply via agent-send.sh to Darkwing/default. This review authorizes nothing; owner decisions remain with Jason.
@@ -0,0 +1,28 @@
 # REGISTRY-GATE7-FILBERT-1 — verdict
 Reviewer: Filbert (independent). Author of the reconciliation: Darkwing. Conflict: none; I authored none of the reconciliation or its cited plans.
 ## Verdict: SUPPORTED
 The Gate 7 reconciliation at `/tmp/registry-gate7-review-vewu5_2t` (manifest SHA-256 `61f284fd7647e380c1f0672a8d4c10a8e6f1b94c8a0576c8366ff96e9500b586`, all five hashes verified; snapshot unchanged after review) is faithful to its cited sources. Every premise I checked traces to real bytes at source pin `50d2a2eb…`: the four source plans in the snapshot are byte-identical to the pin, and the reconciliation's own SHA-256 citations (`5f010ef6…` registry draft, `ce584082…` foundation plan) match those bytes exactly.
 ## Findings by assigned check
 1. **F1 incompatibility — SUPPORTED.** The draft's seat-global `<dataRoot>/agents/<seat>/settings-selection.json` (one mutable file, "exactly one account per provider is active for a materialization") is verified in the registry draft's runtime-seat-selection section. The #53 side is verified in the record table: Session records are "workspace-scoped… Scope is immutable"; R3 (owner Q5) gives each workspace exactly one parent project and per-workspace agent registration. No owner ruling imposes one-running-session-per-seat (R24 limits connections per session, not sessions per seat), so two concurrent workspace sessions of one seat needing different accounts is a real case the single mutable file cannot express. The incompatibility verdict follows from the sources.
 2. **F2 placement — SUPPORTED.** The Execution record already carries "resolved-context reference" and "launch/configuration hash references," and the Context manifest record exists to capture "exactly which approved inputs were supplied." Recording the selected settings profile/account set and generated-file manifest identity there adds audit lineage without a second system configuration, consistent with the record table and with R17's boundary (harness/model settings in fingerprints; credentials excluded).
 3. **F3 relaunch-vs-fork — SUPPORTED.** The draft's "selection normally applies on relaunch/new session; in-session identity swapping is deferred" is verified in its own text. The #53 rule "Resume retains session ID but creates a new execution ID" is verified in the record table, and session records carry creation mode and predecessor reference. F3 states the conditional fork/relaunch semantics without deciding draft gate 6; the pin-representation and unpinned-relaunch questions stay in O3 as recommendations.
 4. **F4 core preserved — SUPPORTED.** Gate 7 as written ("host-side noninteractive OAuth refresh… prove refresh without exposing or duplicating tokens") is quoted accurately; the draft's launch/ensure refresh step ("refusal leaves prior generated files untouched") keeps refresh host-side and fail-closed. F4's claim that workspace scoping changes where a selection is recorded, not who may refresh, is consistent with both sources.
 5. **O1 ruling survey — SUPPORTED.** R14 ("no credentials in either"), R16 (current revision per execution, running conversations not silently reloaded), R17 (fingerprint extension excluding credentials), R21 (no duplicate launch), R23 (revocation stops affected executions), R24 (one controlling connection), and R33 (invocation-level evidence with credential protection mandatory) all exist verbatim with the content O1a–O1d claims. O1b and O1d are framed as precedent and reinforcement, which is honest: they are analogies, not registry rulings. My own search of the four files found no owner decision on named launch profiles or session account pinning; D10 explicitly leaves credential-sharing and configuration lifecycle open. "No contradiction found" holds.
 6. **F5 exclusions — SUPPORTED.** F5 decides nothing in draft gates 5, 6, or 8–10; O3's three items are labeled recommendations, and the record's header and status repeat "analysis, not plan approval" and "no implementation authorized." The central-registry exclusions (no per-workspace credential forks, no grant widening, single registry authority) match the draft's central design and repository canon.
 ## Notes (non-blocking)
 - F1's "must be revised toward per-execution materialization inputs" reads as a direction, but it is grounded in the demonstrated incompatibility and explicitly leaves the shape of the profile layer (gate 5) to the owner via O3. That stays on the analysis side of the line.
 - The pause framing ("reconciled with concurrent workspace sessions before implementation; this plan does not approve it") is quoted faithfully from the foundation plan's authorization section.
 This review authorizes nothing. Owner decisions remain with Jason; the reconciliation's O2 is hereby satisfied for the analysis, and O3 remains open as owner decisions.