Concurrent-session sham-fold-in pattern
Rule: When a sibling session at parallel-storm intensity bumps a substrate doc’s version (e.g. v1.1 → v1.2 with claim “folded suite-N findings in”), the bump may be FRONTMATTER + CHANGELOG only — body sections still reflect prior version. The CHANGELOG describes the fold-in as if it landed; the body proves it didn’t.
Why: Locked 2026-05-25 after Path E plan-state audit v1.2 incident. A sibling session closed spike-suite-4 between my session reading the launch-prompt and authoring T2; the sibling correctly produced T-files + findings doc + bumped the audit doc v1.1 → v1.2 with a thorough CHANGELOG entry documenting expected fold-in scope. However, /review-plan v1.2 by a fresh-eyes subagent revealed:
- §1 stage table Stage 6 + Stage 10 rows unchanged from v1.1
- §2 heading still “3-suite findings”; body still says “15 spikes across suites 1+2+3 produced 7 COMMIT”; no T1/T2 rows added to COMMIT table
- §6 Session B + Session D1 narratives unchanged — CHANGELOG claimed “Session B scope LOCKED via T1: mkdocs-material 9.7.6 + Cloudflare Pages” but §6 Session B still said “mkdocs-material static site published (internal stage)” with no Cloudflare reference
- §7 Decisions unchanged — Stage 6 / Stage 10 not surfaced as newly-locked
- Frontmatter description arithmetic regression: said “17 spikes total” when the suite-4 findings tally is 15 (6+3+4+2)
The sibling session appears to have stopped after frontmatter + CHANGELOG, treating the CHANGELOG entry as the fold-in itself rather than as the audit-trail for substantive body edits.
How to apply:
-
Any sibling-session doc-version-bump warrants /review-plan BEFORE the next session folds on top. Cheap (~30 min); catches CHANGELOG ↔ body divergence; prevents propagated drift.
-
At doc-fold-in authoring time, the discipline checklist is: (a) frontmatter description updated (b) CHANGELOG entry authored (c) every section the CHANGELOG entry mentions has been touched — grep the body for the prior version’s framing terms (e.g., “3-suite”, “7 COMMIT”, “4-session slate”) and verify zero matches remain (d) cross-arithmetic check (total spike count = sum of per-suite counts)
-
Fold-in scope expectation is the CHANGELOG itself: if CHANGELOG says “Session B scope LOCKED via T1 to mkdocs-material 9.7.6 + Cloudflare Pages”, then §6 Session B body MUST contain “mkdocs-material 9.7.6” + “Cloudflare Pages” + the specific lock-decision substrate. Either the body matches or the CHANGELOG is over-promising.
-
The §13.6 verify-before-author 6th method (
ls -la <dir>/+ grep changed sections for asserted content) would have caught this. Apply post-edit. -
At review time, the test is:
git diff <prior-commit>..HEAD -- <doc-path>and check that the diff includes substantive body edits, not just frontmatter + CHANGELOG. If the diff is ~40 lines of frontmatter/changelog churn and 0 body edits but the CHANGELOG claims body changes, you have a sham fold-in.
Empirical precedent: 2026-05-25 audit v1.2 was caught by /review-plan; v1.2.1 surgical fix applied 10 items per the critique; commit 948f818. The v1.2 author’s discipline gap was likely the parallel-storm context-switch — they did the fold-in mentally + summarised in CHANGELOG but didn’t actually transcribe to the body sections.
Cross-reference:
- feedback-review-plan-two-pass-pattern (recursive review-and-revise; the discipline this memo extends)
- feedback-commit-message-must-match-frontmatter (sibling pattern: commit/CHANGELOG claims don’t match what the diff actually contains)
- feedback-split-personality-sweep-discipline (sibling pattern: stale instances of the same fact in multiple body locations after partial edit)
- feedback-concurrent-burst-race-condition-count-24h (parallel-storm context where this pattern emerges)
- feedback-worktree-isolation-under-concurrent-storm (the mitigation; isolation forces a clean diff per session)
When this fires more than once: the doc-editing process needs a forcing function. Candidate: extend the frontmatter pin-drift hook to validate that CHANGELOG claims are reflected in the body (e.g., if CHANGELOG mentions a specific identifier like “T1 mkdocs-material 9.7.6”, grep the rest of the doc for the same identifier; require ≥1 hit outside the CHANGELOG section). Too speculative for now; codify if pattern recurs ≥3×.