mosaicstack/stack
25
0
Fork 1
Code Issues 344 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

Record owner account-selection rulings and registry draft revision

Browse Source
This commit is contained in:
jason.woltje
2026-09-10 14:27:47 -05:00
parent 50d2a2eba9
commit b8008eda5d
7 changed files with 177 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/plans/2026-09-03_auth-provider-harness-registry.md
+25 -7
View File
@@ -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
(e.g. `work`, `personal`) as a first-class layer.
6. Confirm whether a seat may switch same-provider account on relaunch only, or
whether forked sessions must pin the original account in immutable session
metadata.
5. **RESOLVED (owner, 2026-09-10):** named launch profiles are deferred. Per-execution
selection recorded in execution records/context manifests (per the Gate 7
reconciliation and #53 model) covers the need; a named-profile layer would be
a separate future decision if a use case emerges.
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