# Todo 4 canonical-authority registration decision

## Decision

Persist the first canonical customer authority binding in a fixed,
profile-owned append-only registry under the already pinned weekly-operations
authority root.

- Registry rows use only the opaque customer identity digest.
- Each row binds the full canonical authority binding digest and its
  root/events/sequence/lock identities.
- The first registration appends exactly one hash-chained row.
- Any later registration for that customer returns typed already-registered;
  it never issues a new binding.
- Every correlation and expected-bound reopen requires the registry row to
  match the caller-held canonical binding.
- Corrupt, missing-after-registration, duplicated, or disagreeing registry
  history fails closed before canonical snapshot or sidecar mutation.

The fixed registry is provisioned during the Todo 3 authority bootstrap, before
the authority marker is committed. Its inode identity is sealed into both the
marker and `WeeklyOperationsAuthorityBinding`. It is never lazily recreated.
Mode is 0600; it is locked on its own descriptor, append-fsynced, and globally
validated. It contains no raw customer identity or health payload.

Each canonical registration row also binds the profile authority identity,
marker digest, and registry inode. The caller-held registered canonical binding
includes the exact registration row digest. A recomputed replacement history,
missing/replaced registry, or cross-authority registry therefore cannot satisfy
an existing caller binding.

Registration uses the same explicit binding-handoff transaction pattern as
authority initialization. A committed row always yields either an acknowledged
caller-held binding or a typed committed outcome carrying that binding.

## Cleanup boundary

The worktree-root `.venv` observed by the r4 verifier was born on
2026-08-23, before the Todo 4 executor-created profile `.venv`, and was present
at verifier start. It is protected inherited workspace state and must not be
deleted. Cleanup gates cover only task-generated caches, bytecode, virtual
environments, temporary roots, and processes. The protected baseline inventory
must be retained and byte-checked instead of being silently removed.