Operator ownership and recovery
Document class: operator contract; branch-local intended post-program behavior until reviewed promotion to develop. Project Constitution remains target authority. This contract does not introduce enterprise IAM or change deployment configuration ownership.
A password login creates a finite execution root with a persisted, unique server principal. Bearer refresh preserves that root and principal through the existing credential CAS. Logout, idle or absolute expiry, identity revocation, and workspace restore revoke execution authority. Historical record IDs, original owner pairs, effects, and receipts remain immutable.
Use Operator ownership and recovery in the authenticated cockpit to enroll the current proved scope before logout. Enrollment creates private continuity proof in a HttpOnly, SameSite Strict cookie (Secure follows deployment configuration), bounded to one year. The cookie never authenticates by itself. Password plus valid cookie rotates its hash atomically and binds the newly created execution root to the enrolled identity. A password-only independent scope cannot claim earlier records or replace another identity's recovery code.
Download the one-time recovery code and keep it private. On another device, use the code with the operator password. Redemption consumes it atomically; the authenticated, continuity-bound scope can explicitly replace it. Codes are never put in URLs, journals, browser persistence, or displayed record metadata. The code response is deliberate, one-time, and uncached. Forgetting a device revokes that browser's continuity proof while leaving its current finite session and other devices intact. Revoking the identity invalidates all its proofs and bound sessions; connected sockets lose authority at their bounded recheck.
Review private inventory, select exact records, preview, and acknowledge read-only recovery. Confirmation binds the preview digest and exact immutable principal/root pairs to an idempotent journal in canonical SQLite. Repeated submission returns the same journal; conflicting payloads are rejected. Recovery exposes original IDs in canonical goal/tree/dashboard, task/detail, reviewed memory, input artifact metadata, and routine reads. Recovered rows show recovered_read_only and current_scope_review_required; they cannot be mutated, dispatched, dragged into work, or used as standing permission. Deleted/redacted/unproved/foreign records remain blocked.
Create fresh intent creates current-owned goal/task triage records with explicit original lineage. It copies no admitted inputs, approvals, credentials, budgets, standing grants, queued jobs, or capability authority. A past attempted task or uncertain effect/cost history blocks this action pending reconciliation. The bounded exception is a single verified Done local workflow.goal-snapshot-to-file attempt whose explicitly selected output passes the shared canonical dispatcher parent/child/readback/fence/file proof. It creates empty triage intent, never replays the attempt; other successful capabilities and multiple-attempt histories remain blocked. Fresh task A can cite only explicitly reviewed sources from its exact historical goal/task lineage, even when its journal also selects project B. Private-source content checks and model-egress/source-purpose consent remain separate. Input artifact recovery exposes metadata; output artifacts require the integrated #913 receipt/file proof resolver and otherwise visibly block.
Recovery requests and selected records are bounded. Storage failure returns a neutral retry/read-journal reason; the UI preserves confirmed inventory and bounds requests to 15 seconds. An uncertain confirmation is retried with the same key and checked through journal readback. Rollback removes selected reads; after fresh intent exists, recovery rollback requires current-scope review and never deletes or rewrites those new records.
Migration and restore
Before installing the principal migration, stop managed services and take a verified canonical workspace backup using the existing production lifecycle. The migration is transactional and forward-only: it gives historical roots unique persisted principals, retains a former role label solely as exact read-pair metadata, revokes all pre-migration bearer authority, and installs a principal-required SQLite issuance fence. A missing, malformed, or duplicate principal blocks startup. Managed local launch checks schema compatibility before starting the backend. Old browser auth code cannot issue a session with missing principal or authenticate a pre-migration bearer on this database. Exact pre-migration paired-edge and Telegram token generations are revoked, retaining IDs/metadata while making their ciphertext unusable to pinned old readers; provider/configuration credentials and unrelated key names remain intact. Old device binaries remain unsupported and must not open the migrated workspace: this issuance guard proves the browser path, not universal compatibility of arbitrary old readers with newly issued device state.
Do not roll back code alone against the migrated workspace. Stop services and use a verified pre-migration backup together with the compatible older code. Restore/rollback invalidate bearer, continuity/recovery-code, and exact paired-edge/Telegram token authority; restoring an old snapshot cannot revive consumed or revoked proof. Original identity/root/data rows remain stored, but their ownership proof may no longer be usable. Re-establishing ownership then requires a separately reviewed recovery/reset; the shared bootstrap password alone is insufficient. No host workspace restore is performed by the implementation tests.
Ambiguous principal-only legacy conversations, devices, vault records, and existing ownerless conversation placeholders are never attributed to the first new login. Legacy pairing authority stays blocked. A foreign or ambiguous pairing cannot be overwritten from the cockpit's Pair action: it requires an explicit host-local administrative reset/new pairing, outside this recovery flow. Own current pairings retain revision-fenced replacement/rotation. New sessions, grants, and records use only the new unique principal.
Store boundaries
| Store | Data/authority boundary | Legacy behavior |
|---|---|---|
| Conversations and linked messages/todos | Exact persisted unique principal; existing ownerless rows fail HTTP and WebSocket ingress | Shared-role/ownerless rows remain private and unclaimed |
| Goals, board tasks/input artifacts, routines | Current principal/root, or exact privately proved selected original pair for reads | Historical IDs/owners preserved; mutations/execution blocked |
| Reviewed canonical memory | Exact immutable source root, confirmation/deletion fences and selected read proof; fresh citations require exact accepted project/task provenance | Unproved roots and deleted records blocked |
| Jobs, approvals, consents, effects | Current finite root, owner pair, normal dispatch/review/egress fences | No grant transfer or replay; retired root fails at authority boundary |
| Paired devices, audio and Telegram | Exact unique owner and live persisted root at ingress/effect boundary | Reconnect/review required; old pairing cannot be adopted |
| Browser/tool vault | Exact current unique principal; raw values never browser metadata | Null-owner secrets remain system-only; no guessed-key adoption |
| Profile/soul, runtime/provider settings, capability registry | Deployment operator configuration, intentionally singleton | Not private execution history or identity proof; onboarding task/result authority remains separately scoped |
Provider configuration credentials remain deployment settings; this contract does not duplicate or transfer them. Singleton profile completion is not evidence that a new root owns an earlier setup task/result.
The managed keyless browser/API/file receipt on 2026-10-02 verifies actual enrollment, queued local starter execution, verified artifact opening, logout and a new root under the same private identity, exact goal/task/output selection, empty fresh intent and local source-span inspection. Historical task access was denied before selection and read-only afterward. The actual 147-byte snapshot SHA256 matched its durable readback. The integrated test_899_identity_snapshot_evidence.py additionally covers expiry, exact cross-project lineage and authority/tampering negatives. These receipts establish local mechanics; production restore, external-account behavior, provider usefulness and promotion to develop remain unverified.