## Summary
Revision 39 is not approvable. Its sealed importer and canonical-lock direction are sound, but four unresolved P1 contracts prevent a generation from completing/replaying safely, permit reconciliation recovery writes outside the sealed target, break the declared shared Event/schema contract, and leave retraction membership uncomputable.

## Claims
- The immutable RALPLAN index records the requested revision and SHA-256 `38f567e819d7ac5fc2d361de53e6e846607844ebecfa07cdc862dbe135df94ab` (`index.jsonl`, stage 39).
- The plan explicitly declares a 29-root-plus-one-correction expected generation, while discovery is only by root `import_manifest.generation_digest` (`stage-39-revision.md:151-154`).
- The plan prohibits a manifest on correction terminals (`:135`) and requires offset 23's correction to have no manifest (`:188`).
- The current reconciler has additional write/recovery paths beyond canonical `recover()`: `profile_authority_lock` can create/chmod its lock (`customer_admin.py:128-158`), `_recover_activation_journal` can restore registry/audit state (`:1220-1409`), reconciliation calls it and `initialize_adaptive_customer` (`:3635-3758`), and adaptive source-day/intent appends call `_recover_locked`, which truncates torn tails (`adaptive_nutrition.py:4217-4229,4272-4274,4438-4439`).
- Both current profile Event models are strict and neither declares the fields or retraction enum proposed by the shared schema update (`dualcoachtest/.../models.py:759-863`; `physique-coach/.../models.py:759-863`).
- Current reconciliation creates a source-day mapping, then both a prepared and committed source-day intent (`customer_admin.py:3813-3816`), consistent with the plan's 44 mappings/88 intent rows baseline (`stage-39-revision.md:12`).

## Analysis
### Spec compliance
The plan closes several prior issues materially: the target seal is concrete, manifest/adherence fields are typed, the importer uses the canonical pair lock, duplicate payload equality is specified, and projection/reconciliation are intended to share a root resolver. Those choices are preferable to raw JSONL patching or a generic importer.

However, the proposed lifecycle cannot meet its own COMPLETE/replay acceptance. A correction is in the expected set but is unobservable by the only declared membership scan. A complete ledger therefore remains PARTIAL/quarantined, defeating the importer-to-projection and zero-delta replay contract.

The typed retraction also lacks the digest preimage that connects a hex `root_digests` member to the root held by the resolver. Since the resolver receives Event objects rather than sequence rows, it has neither a specified hash calculation nor a defined set-equality/membership rule. Retraction cannot be proved to affect exactly its generation.

### Architecture and failure safety
The strongest antithesis is that removing the one canonical `recover()` call is sufficient because reconciliation only needs to append derivatives. The source disproves that: the retained entrypoint performs activation recovery/initialization and adaptive writers auto-recover by truncating their own journals. That conflicts with the plan's absolute no-recover/no-truncation/no-outside-sealed-mutation boundary and hides a real defect instead of failing closed.

The shared contract boundary is also incomplete. Updating the shared JSON schema while only dualcoachtest's strict Pydantic model gains the new fields makes valid shared-contract events unparseable in physique-coach. The proposed model/schema parity test locations do not cover that independent consumer.

### Constructive synthesis
1. Treat a generation as a closed graph: roots are selected by manifest digest; the only correction is selected by its expected root, `supersedes` edge, deterministic correction identity, and byte-equal expected payload. Count/replay/quarantine must use that same graph.
2. Define `root_event_digest` with one stable, named canonical serialization and require a retraction set to equal the generation's complete synthetic root set exactly. Builder, store validation, and resolver must share the function.
3. Split a sealed synthetic reconciliation path from ordinary lifecycle reconciliation. It must validate a pre-existing safe lock without create/chmod, reject pending activation state rather than recover it, require initialized artifacts, use strict non-recovering source-day/journal append methods, and confine writes to the two allowed derived journals.
4. Update the parallel physique-coach Event model/enums/discriminator with the shared schema, or do not make the schema shared. Cross-profile golden validation must cover legacy plus new event shapes.
5. Pin physical derived row deltas: one mapping plus one prepared and one committed source-day intent row per newly mapped root, unless a fully specified compatible journal transition change is selected.

## Root Cause
The plan specifies the canonical happy path precisely but assumes adjacent lifecycle/reconciliation machinery shares its invariants. It does not: correction membership is not explicitly propagated, retraction has no canonical root-digest identity, and the retained reconciliation entrypoint owns autonomous recovery and initialization behaviors outside the importer contract.

## Findings
1. HIGH — `stage-39-revision.md:151-154`: correction membership is absent from the generation scan; COMPLETE/quarantine/replay cannot work. Reported as P1.
2. HIGH — `stage-39-revision.md:215`: retaining the ordinary reconciler leaves registry/profile/derived-journal recovery writes and truncation despite the no-live boundary. Reported as P1.
3. HIGH — `stage-39-revision.md:91-93`: the shared schema changes only one of two strict Event models, breaking cross-profile model/schema compatibility. Reported as P1.
4. HIGH — `stage-39-revision.md:124-141`: `root_digests` has no deterministic preimage, set rule, or resolver-compatible evidence source. Reported as P1.
5. MEDIUM — `stage-39-revision.md:255`: source-day intent delta is ambiguous against the existing prepared/committed two-row protocol. Reported as P2.

## Recommendations
1. Resolve all four P1 findings before execution or approval.
2. Add graph-completion and retraction-digest golden vectors to the crash/replay matrix, including forged/missing/duplicate roots and corrections.
3. Add full-tree no-mutation assertions for registry/profile locks/activation artifacts and all non-allowed journals on success and every failure path.
4. Add a cross-profile schema/model validation suite and pin source-day mapping plus prepared/committed intent row deltas.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
- **Closed generation graph plus deterministic correction linkage (recommended):** permits crash-safe completion and replay; adds explicit graph validation.
- **Root-manifest-only scan:** simpler but permanently hides the mandated correction; reject.
- **Ordinary reconciliation with recovery:** reuses APIs but can truncate/restore outside scope; reject.
- **Dedicated sealed strict reconciliation:** larger local seam but preserves no-repair containment; recommend.
- **Shared schema with one updated model:** smaller diff but invalidates the other strict consumer; reject.