RLCR loop: 7 methodology gaps for re-acceptance / inherited-delta sessions

[Leopold-Fitz-AI]

Summary

A recent RLCR session opened on a tree that already contained the substantive work — landed by a prior session that hit the stagnation circuit breaker plus an off-loop plan-amendment commit between the two sessions. The new session executed a single review-only round, the reviewer returned COMPLETE, and the finalize phase ran a cleanup pass that produced zero edits.

The methodology produced the right outcome (single-round COMPLETE, clean finalize) for the wrong structural reason: it ran an implementation-grade round shape over a thin re-acceptance task and the artifacts happened to fit. The session worked because the reviewer was diligent and the prior session's exit was actually clean, not because the methodology has machinery to handle re-acceptance correctly.

The analysis suggests 7 narrow improvements that add cheap re-acceptance machinery, make inherited-delta sessions legible to both reviewer and audit, and reframe the finalize no-op as positive evidence rather than ambient noise. None require breaking changes to existing implementation-mode sessions.

Suggestions

1. Re-acceptance round mode: reduced contract template stating (a) which prior-session changes are being re-presented, (b) what off-loop edits occurred between sessions, (c) what the implementer re-verified locally, (d) skip BitLesson selector unless a new lesson surfaced.

2. First-class re-acceptance state: when base_commit differs from start_branch HEAD at session start, classify the session as inherited-delta and require the round-0 contract to declare prior session ID + off-loop commits + verification scope (full vs delta-only). Persist as re-acceptance: { source_session, inherited_commits, off_loop_commits } in state. (partially landed in feat(methodology): pre-stall reviewer awareness + re-acceptance signals (4 commits) #145 commit 3 — inherited_delta: bool + auto-generated session-lineage.md; the richer state-block extension is open)

3. Dual byte-lock semantics: differentiate lock-as-spec (implementation, plan is the contract being executed) vs lock-as-attestation (re-acceptance, plan is being attested as unchanged-during-this-session). Same stop-hook check; contract template references the relevant semantic.

4. Dual-reading-mode reviewer prompt for inherited-delta sessions: explicit two-question format — (Q1) does inherited work, read fresh, satisfy the original goal contract? (Q2) does the off-loop amendment plus this session's work introduce any regression against Q1? Both must be answered separately; a single verdict against the combined diff is insufficient.

5. Finalize outcome classification: emit a single-line top-of-summary classification — no-op (already-minimal) / cosmetic (formatting only) / substantive (logic edits). In re-acceptance sessions, no-op (already-minimal) is the expected outcome; a substantive outcome should require justification. (landed in feat(methodology): pre-stall reviewer awareness + re-acceptance signals (4 commits) #145 commit 1)

6. Session lineage artifact: in inherited-delta mode, generate a one-screen session-lineage.md at session open containing prior session ID + exit verdict + commit range + one-paragraph statement of why a new session is needed. Prior session's circuit-breaker exit pre-populates a stub so the next session inherits a partially filled record. (landed in feat(methodology): pre-stall reviewer awareness + re-acceptance signals (4 commits) #145 commit 3)

7. Three session archetypes: explicitly define and document implementation (current default), re-acceptance (reduced shape, inherited-delta state, finalize expected to no-op), attestation (no implementer round at all; reviewer reads the tree and emits a verdict; finalize skipped). Session-open command takes a --mode flag; archetype is recorded in state and gates which hooks run.

Pairs With

This issue is a companion to #146 (stagnation-class methodology gaps from the prior session that hit the round-4 circuit breaker). The two issues describe complementary methodology gaps: handling stalled sessions that need cancel/amend/restart, and handling clean re-acceptance sessions that follow them.

PR #145 lands #5, #6, and the v1 of #2 from this issue (plus #3 v1 + #4 from the stagnation companion #146). Suggestions #1, #3, #4, #7 from this issue and the v2 extension of #2 remain open.

Notes

• All content is sanitized: no file paths, function names, branch names, business domain terms, or project identifiers.
• The full sanitized analysis report (~1100 words) was generated by an Opus-class model from the loop's state metadata + the user-supplied session-shape narrative.