I read this as read-only evidence adjudication - I’ll trace the governing clauses, candidate identity/lineage, live receipts, and ledger end to end, then return one literal-plan outcome with the minimal compliant next action.


I read this as a read-only release-evidence adjudication - I will apply the plan literally, trace candidate/product lineage, and return one binding outcome.

# Decision: `NEW_LIVE_REQUIRED`

**Task26’s objective and F4 cannot PASS for candidate `2e0894…` by transferring Tasks22–25 evidence. Under the unamended plan, one new complete live Telegram rehearsal against the exact fixed candidate is mandatory.**

An amendment is an alternative governance choice, but it would change or waive the present standard; it would not constitute PASS under the unamended plan. No files, services, profiles, or external systems were modified.

## Controlling clauses

1. The objective requires **one reproducible release candidate** completing the entire lifecycle through real Telegram surfaces without the listed shortcuts (`dualcoach-production-readiness.md:24-38`).
2. Invariant 10 requires production evidence from **“the exact immutable candidate being reviewed”** (`:114-115`).
3. Evidence reuse is allowed only when **its exact candidate and covered behavior remain unchanged**; affected gates are rerun after a digest change (`:221-223`).
4. Task26 reviewers must receive the candidate digest and live rehearsal evidence; missing or inconclusive lanes fail, and findings require affected gates to be rerun (`:802-814`).
5. Every final verifier judges the **exact fixed candidate** (`:1069-1071`).
6. F4 requires one real happy path over the intended customer and owner/operator Telegram surfaces, with exactly one delivery after explicit send (`:1083-1085`).
7. Completion additionally requires that **no normal-path step used a recovery shortcut**; anything less remains NO-GO (`:1091-1102`).

These clauses independently block silent retargeting.

## Identity layers

| Identity layer | Meaning | `653cc2…` | Current `2e0894…` |
|---|---|---|---|
| Full candidate | Authoritative release-review identity calculated from the candidate manifest | `653cc2f0…c7a723` | `2e0894ea…da925` |
| Core candidate | Canonical manifest-core hash; despite its name, it includes evidence/archive bindings, not just product code | `a03f84f7…f5ef` | `a8d099d5…e88e` |
| Envelope | Immutable filesystem bundle containing wheel, bindings, history, status and verifier | Manifest `23b72148…ca26` | Manifest `7b6d0d6e…52d`; 43 files; tree `d5213d1b…c75b4` |
| Executable closure | Product/source-equivalence evidence | 2,374 entries, `7d7fb32d…986dd` | Identical |
| Product wheel | Deployable product bytes | `af4a9d0a…f141b` | Byte-identical `af4a9d0a…f141b` |

Therefore:

- `653cc2…` and `2e0894…` are **product-equivalent**, but not the same full/core/envelope candidate.
- The existing supersession receipt permits only **source-bound evidence transfer** between them.
- It explicitly records `historical_execution_retargeted_to_successor: false`.
- `2e0894…` is sealed only as `NOT_TASK26_PASS`; its effective state says `task26_pass: false`.

Most importantly, product parity exists only between `653cc2…` and `2e0894…`. Neither candidate was exercised through Tasks22–25 live.

## Live lineage

| Phase | Identity actually evidenced | Live status and consequence |
|---|---|---|
| Task22 | Full/code candidate `3ce5b956…`; manifest `e456cfc6…`; wheel `f592abef…` | Authenticated Telegram terminal evidence, but Task22 expressly limits PASS to its own acceptance. |
| Task23 expiry stage | Candidate `70da304a…`; wheel `fbcef69d…` | Superseded Task22 product. |
| Task23 successful generation | Hardened wheel `3d1bc0a7…` plus five source hashes | The successful event occurred after the `70da…` seal; no complete immutable full-candidate digest covers that execution. A separately authorized one-use recovery child created the draft. |
| Task24 live | Repository/`.venv` service; deployed `telegram.py` pin `774df448…` | No complete immutable candidate digest or wheel is bound to the live sequence. Normal Regenerate produced an unparented draft and was blocked. |
| Task24 recovery | Existing authenticated Edit path | Completed forward via recovery. The Regenerate repair wheel `231015fa…` was explicitly **not deployed**. |
| Task25 | Cleanup plus `rehearsal_reset.py` pin `7dcb0b1e…` | No complete executable candidate digest. |
| Task24/25 archive | `9b102fde…` | Hash of control files, historical receipts and four selected gateway files. It is an archive/evidence-scope digest, not proof that a full product candidate ran live. |
| Task26 launch | `5e6f2f2a…`; wheel `6a3f5f04…` | Service connected, but no recoverable owner-review prerequisite existed; candidate invalidated. Not a happy path. |
| Repaired successor | `3b42723d…`; wheel `36719371…` | Controller repaired; no complete live rehearsal. |
| PID successor | `653cc2f0…`; wheel `af4a9d0a…` | Task26 objective lane returned `FAIL/NO-GO`; Tasks22–25 classified historical-only. |
| Current | `2e0894ea…`; same `af4a9d0a…` wheel | Envelope-only successor; no historical live execution retargeted and no Task26 PASS. |

There is consequently **no “live candidate used in Tasks22–25” as a single immutable identity**.

## Executable deltas

An exhaustive live-candidate-to-current delta chain cannot be produced because Tasks23–25 did not seal the complete execution closure actually used. That missing lineage is itself fatal to transfer. The authenticated deltas are:

| Boundary | Executable delta |
|---|---|
| Task22 → Task23 | Wheel changed `f592abef… → fbcef69d… → 3d1bc0a7…`; onboarding runtime, authority, callbacks, Telegram routing/bootstrap and generation/coaching sources changed. |
| Task23 successful pins → current | `nutrition_coaching.py` `3f8943b5… → 07f868ad…`; `nutrition_coaching_proposal.py` `d36c39e2… → 055d5798…`; `telegram.py` `6a393a58… → b41060de…`. Two other pinned judgment files remain equal. |
| Task24 live → current | Deployed `telegram.py` `774df448… → b41060de…`. |
| Task24 failed-Regenerate repair → current | Undeployed `nutrition_coaching.py` `2d10de01… → 07f868ad…`; later changes therefore occurred after the repair receipt. |
| Task24/25 archive snapshot → current | `nutrition_coaching.py` `8ea601b4… → 07f868ad…`; `telegram.py` `e51d6676… → b41060de…`; `rehearsal_reset.py` `7dcb0b1e…` is absent from the current closure; proposal source remained `055d5798…`. |
| `5e6f2… → 3b427…` | `dualcoach_tasks21_25_controller.py` repaired to `b3036345…`; wheel `6a3f5f04… → 36719371…`. |
| `3b427… → 653cc2…` | Exactly one executable delta: `gateway/status.py`, 60,499 bytes / `7a04d81f…` → 60,653 bytes / `8641bae4…`; wheel `36719371… → af4a9d0a…`. |
| `653cc2… → 2e0894…` | **Zero product-source deltas**, identical closure and wheel. Only envelope/binding content changed. |

A direct comparison of the Task22 sealed manifest with the current closure finds 24 changed shared non-test paths, including coaching, proposal/validation, check-in, Telegram onboarding/runtime/publication, operator-console, `gateway/status.py`, and `pyproject.toml`. Thus there is no cryptographic product-equivalence bridge from Task22—or the later live executions—to `653cc2…`/`2e0894…`.

## No-recovery-shortcut criterion

This cannot be closed retroactively:

- Task22 explicitly records `global_no_recovery_shortcut_criterion: not_claimed` and says the plan remains NO-GO until independently satisfied (`dualcoach-task-22.md:8-10`).
- Task23 says a separately authorized one-use recovery child generated the accepted draft (`dualcoach-task-23.md:9-10`).
- Task24’s normal Regenerate failed; completion used the Edit recovery path while the Regenerate repair remained undeployed (`dualcoach-task-24-regenerate-lineage-repair.json:55-62`).

This does not necessarily prove a prohibited mutation occurred. It proves the required absence-of-shortcut fact is missing and that the recorded lifecycle was segmented by recovery. Under Task26’s fail-closed rule, later automated tests, cleanup, or product parity cannot convert that run into an uninterrupted no-recovery happy path.

## Why `653cc2… → 2e0894…` parity is insufficient

Even the broadest reasonable interpretation fails:

- If “exact candidate” means full/core identity, `653cc2…` and `2e0894…` differ.
- If it means product wheel plus closure, those two are equivalent—but neither has Tasks22–25 live evidence.
- Earlier live candidates are not product-equivalent to `af4a9d0a…`.
- The current transfer record expressly limits reuse to source-bound evidence and disclaims historical execution retargeting.
- The current Golden Path and Recovery Runbook still name candidate `19ed0e92…`, not `2e0894…`; they must be re-bound before a current-candidate rehearsal.

## Options

1. **New exact-candidate rehearsal — required under the current plan.**
   Preserves every objective and completion clause.

2. **Amend the plan.**
   To avoid a new rehearsal, the amendment would need to:
   - redefine candidate identity around product equivalence;
   - authorize live-evidence transfer across full/core/envelope changes and intervening source deltas;
   - permit segmented task evidence to count as one happy path; and
   - redefine or waive the no-recovery-shortcut criterion.

   A narrow amendment allowing byte-identical transfer from `653cc2…` to `2e0894…` is insufficient because no live rehearsal exists on `653cc2…`.

3. **Transfer without amendment.**
   Invalid: it conflicts with the plan, the Task26 objective FAIL receipt, and the candidates’ own anti-retargeting declarations.

## Minimal next action

Re-bind the unchanged Golden Path and Recovery Runbook to `2e0894…`, then run one isolated complete Tasks22–25 lifecycle using wheel `af4a9d0a…`/closure `7d7fb32d…`:

- prove those exact bytes are loaded;
- use only the intended customer DM and owner/operator Telegram surfaces;
- use no recovery path;
- observe exactly one delivery after explicit send;
- complete truthful disable/cleanup;
- bind all receipts externally to full digest `2e0894…`; and
- rerun the affected Task26 objective, hands-on/provenance lanes and F4.

If that rehearsal exposes a product defect, reseal a new candidate digest and rerun the affected gates against that successor.