I read this as an advisory recovery-architecture task - I’ll trace the authority, status, journal, and observer flows end to end, compare the required migration options, then write only the requested evidence JSON if the repository permits it.


I read this as the same advisory recovery design - a concurrent codemap artifact appeared during verification, so I’m checking it against the completed recommendation before finalizing the decision.


I read this as an advisory recovery-architecture task - I traced the authority, persistence, runtime, observer, and control-plane flows and produced the requested design evidence without live or source changes.

## Decision

Recommend a **fresh one-use, network-isolated canonical reissue** of the sole authenticated r70 row into the empty current r71 sidecar.

- Parse and validate the r70 row through the installed weekly-operations contracts.
- Verify its customer identity and sequence-zero canonical pin against current r71.
- Reconstruct `WeeklyOperationInput` preserving every semantic, reminder, source, and KST field.
- Append through `WeeklyOperationsStore`, not filesystem copy.
- Store cross-root provenance in the fresh execution root, since authority-root inventory forbids extra receipt files.
- Migrate only `2026-08-31`; the resulting 792-byte row and digest should exactly equal r70 because rows are not candidate-bound.

## Options

1. **One-use canonical reissue — recommended**
   - Smallest blast radius.
   - No gateway deployment, config change, authority rotation, or row-schema change.
   - Reuses production validation, locking, conflict, and fsync behavior.

2. **Generic authority-rotation migrator — viable but deferred**
   - Prevents recurrence by importing retained history before future authority switches.
   - Requires product source, packaging, upgrade, rollback, and multi-customer changes disproportionate to this one-row repair.

3. **Raw copy — rejected**
   - Although the bytes happen to validate in the empty r71 history, copying bypasses typed reconstruction, authority verification, lock ordering, canonical-pin checks, replay handling, and authenticated provenance.

4. **Observer fallback to r70 — rejected**
   - Makes only the observer appear healthy while leaving current r71 semantically incomplete.
   - Introduces permanent dual-root behavior and stale-root retention coupling.

## Transaction contract

Fresh namespaces:

- `live-authorization-v15/nutricoach-v150-day-status-continuity-r71-r1`
- `live-executions-v15/nutricoach-v150-day-status-continuity-r71-r1`

The sealed package binds:

- r70/r71 root identities, markers, registries, sidecars, and row digests;
- current config, candidate credential, committed phase, and consumed authorization;
- current canonical registration and sequence-zero pin;
- installed wheel/RECORD and controller closure;
- observer source/unit/timer hashes;
- protected delivery/customer hashes and a zero-send oracle.

Phases:

`RESERVED -> OBSERVER_TIMER_FENCED -> INPUTS_LOCKED_AND_VERIFIED -> APPEND_INTENT_DURABLE -> ROW_DURABLE -> PROVENANCE_DURABLE -> MANUAL_PASS_DURABLE -> TIMER_WATCH_ARMED -> TIMER_PASS_DURABLE -> COMMITTING -> COMMITTED`

A second launch is always refused. A recovery-only entry point may resume the same pending reservation without accepting approval again.

## Crash and replay behavior

- Empty before durable intent: no-mutation rollback, restore timer, consume `FAILED`.
- Empty after intent: resume the same attempt.
- Exact strict prefix of the expected row: append only the missing suffix under locks; never truncate or replace.
- Exact complete row: roll forward receipts and observation phases without another append.
- Any divergent bytes, extra row, inode replacement, or unexpected path: leave evidence untouched, fail closed, consume `FAILED`, and prohibit retry of that namespace.

Once any valid row bytes exist, rollback is forbidden because it would rewrite append-only truth.

## Filesystem requirements

- Private control directories: `0700`; immutable receipts: `0400`; locks: `0600`.
- Authority roots remain `0700`; authority files remain existing `0600` inodes.
- Component-by-component `O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC`.
- Files require exact uid/gid, regular type, `nlink=1`, named/open inode equality.
- Full-write/EINTR handling, file fsync, directory fsync, and no-follow readback.
- No rename, replacement, truncation, chmod, or unlink of authority data.

## Observer completion

Fence the existing timer and capture its validated failed-chain head. After the row and provenance receipt are durable:

1. Start the observer service exactly once and require a manual `PASS` linked to the captured head.
2. Subscribe to the exact observation event before restoring the timer.
3. Await a naturally timer-triggered `PASS` whose predecessor is the manual row.

The prior FAIL rows remain an immutable prefix. This proves recovery health but does **not** relabel the original seven-day chain as all-PASS.

## Evidence

Written and validated:

`/home/cube/projects/richard/traning coach/.omo/evidence/nutricoach-telegram-checkin-stepper/task-11-day-status-migration-design.json`

SHA-256:

`a79b50d143d4959f78442ba0db1456a72a8d7e51ca7cb75a1371bacaad956e42`

Validation: JSON parsed successfully; LSP reported no diagnostics. No live profile, source, service, timer, authority, observer, provider, customer, or network mutation was performed.