## Summary
Reviewed immutable `stage-40-revision.md` at SHA-256 `d88cada5457c027da90bfbad59a82060c9953f2dff06c75c42532a595bda798e`, as recorded by the RALPLAN index. Revision 40 closes the named revision-39 concerns around dual-profile/schema parity, correction-aware discovery, sealed non-recovering reconciliation, and exact journal deltas, but it retains a high-severity contradiction between compatible skips and the fixed 29-root retraction membership contract.

## Claims
- `index.jsonl` records stage 40 at the assigned path and SHA-256.
- §4.2 requires both profile `models.py` files and the shared schema to move atomically, with cross-profile golden vectors.
- §4.3 discovers the correction only as the expected synthetic root's child, while allowing `skipped_compatible` for a compatible terminal at any candidate day.
- §4.5 replaces the execution path with a sealed reconciliation entrypoint that never invokes recovery, initialization, or operational reconciliation, and specifies exactly one mapping plus prepared/committed intent rows per mapped root.
- §§4.7–8 retain test-first, fail-closed, no-live, immutable-prefix, and additive-only rollback constraints.

## Analysis
The revised boundary is materially stronger: the importer remains sealed to one registered customer, model/schema compatibility is specified across both packages, root resolution is shared, and reconciliation is isolated from all known creating/recovering paths. The root-digest preimage and set-equality validation make retraction membership auditable.

However, the membership algebra is not closed under the plan's allowed compatible-overlap path. A skipped compatible root is not a synthetic generation member, so it cannot appear in a retraction tuple without retracting foreign evidence. In particular, when offset 23 is skipped, no synthetic root exists for the mandatory correction to supersede. The classifier nevertheless requires the correction and the retraction requires an exact 29-root tuple. That makes a valid allowed overlap impossible to complete/retract, contrary to the stated `[0,30]` delta range.

## Root Cause
The plan treats the static 29-root recipe as the retraction target even though its overlap rule permits a runtime subset of those roots to be omitted from the synthetic ledger.

## Findings
- HIGH — `stage-40-revision.md:153-166`: define retraction/completeness from the exact effective appended-root set; condition the offset-23 correction on its synthetic root being appended; test all-skipped and offset-23-compatible collision/replay/resume/retract cases. Alternatively reject all compatible overlaps, but that would remove the stated skip/delta behavior.

## Recommendations
1. Persist or deterministically revalidate the effective per-offset member set under the same lock; use its sorted root-digest tuple for COMPLETE, resolver retraction validation, and retraction construction.
2. Treat the correction as required only when its root belongs to that effective set; classify a foreign/forged correction as conflict.
3. Add collision coverage for offset 23, partial/replay after those collisions, and a generation with zero appended members.

## Architectural Status
BLOCK

## Code Review Recommendation
REQUEST CHANGES

## Tradeoffs
- Variable effective member set: preserves permitted compatible skips and allows safe retraction; requires explicit classifier/test coverage.
- Reject compatible overlaps: simpler fixed 29-root target, but contradicts the existing skip semantics and allowed zero-to-30 delta range.