I read this as a security-and-authority audit of frozen V13 - I will inspect the specified evidence and run only non-mutating or copy-based tamper checks.


I read this as an investigation of the disabled-draft blocker and a security-safe remediation design - verify the live shape and trace builder/startup authority handling without changing anything.


I read this as a root-cause and release-blocker audit - preserve disabled drafts only through a new sealed package, not a V13 mutation.

**Verdict: V13 remains FAIL / do not approve.**

Confirmed live registry: 2 customers, 1 enabled, registry SHA-256 `bd61...60b29` and secure `0600` mode.

The immediate failure is real:

- `build_weekly_authority_postimage()` creates `customer_keys` from enabled customers, then rejects whenever that count differs from all registry customers.
- Removing only that check is insufficient. Startup independently requires the full registry key set to equal `enabled_customer_keys` in `nutrition_weekly_reminder_bootstrap_customers.py`, and `WeeklyReminderAuthorityOwner.verify_registry()` repeats the full-set equality.

### Security-safe root fix (new V14 candidate)

Define the authority scope as **exactly the current enabled registry customers**:

1. Builder: retain the existing `enabled` selection, capacity, consent, registry-identity, and receipt generation. Remove the all-customers equality rejection.
2. Bootstrap: replace the full-registry equality with an exact ordered comparison between:
   - `receipt.enabled_customer_keys`, and
   - the current registry's enabled customer keys.
3. Owner factory and refresh fence: require the constructed sidecar customers to equal that same enabled set. A disabled customer must have:
   - no canonical authority registration,
   - no reminder ledger/store capability,
   - no entry in the receipt,
   - no possible `tick_snapshot()` / `bound_customer()` path.
4. Preserve full registry identity binding for startup. A changed registry before startup fails closed; disabled drafts are retained but never authorized.

This safely preserves the disabled draft without silently widening scope. A disabled-to-enabled change after startup must invalidate the authority owner because the enabled set changes.

Add regressions for one enabled plus one disabled customer: successful startup, receipt/sidecars only for the enabled customer, disabled-customer denial, and failure when the draft is enabled or the active customer is disabled.

### Additional blockers

1. **V13 controller cannot import its authority dependencies in its declared sandbox.**
   A read-only exact `bwrap --clearenv` import of `scripts.nutricoach_v150_weekly_authority` fails with `ModuleNotFoundError: checkin_cli`. The test injects `dualcoach/profile` into `sys.path`, but the live bootstrap does not. An approval would reserve/consume authority and roll back during migration.

2. **Capacity-five is not presently supportable for distinct consents.**
   The receipt has one `consent_digest`; the builder requires every enabled customer to have that same digest. Real multi-customer consent records will normally differ. Either scope V14 explicitly to one enabled customer or evolve the receipt to bind `{customer_key: consent_digest}`.

3. **Service/network/startup fencing is not adequate.**
   `--unshare-net` protects only the controller. `systemctl --user start` launches the gateway in the host network namespace; the live unit has no `PrivateNetwork`, `IPAddressDeny`, or equivalent restriction. The post-fence checks only in-process event lists and service liveness, not actual host egress.

   Worse, `service_state()` replaces systemd's observed `ExecStart` with the unit-file text before validation. A running stale or overridden process can therefore satisfy the successor-runtime text check.

   V14 needs an offline, successor-runtime startup gate before the main service is allowed to communicate: load the complete authority, verify the enabled-only sidecars and receipt, then verify the actual systemd-reported command/PID rather than rewritten unit text. Monitor the service cgroup for egress during the fence and rollback on any event.

4. **Authority artifact trust remains weak.**
   Preseal files are `0664`, source and dependency roots are `0775`, and the bootstrap runs before it verifies its own closure. Package manifests are self-excluding; inventory verification accepted a same-content external symlink on a copy. The ledger class also accepts symlinked roots and is only global per supplied root. A new package needs an immutable or separately trusted launcher, signed/root-owned manifest, no-follow descriptor traversal, and ledger-root identity checks.

5. **Supersession governance is inconsistent.**
   The V13 preseal ledger names V13 active, while the runtime global supersession file still names V12 active; the live controller does not enforce that global document.

The static V13 verifier passes, but it does not cover these runtime and trust-boundary failures. No live or source files were changed.