PASS_2_WILL_REVIEW_PACKET.md
Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_2_WILL_REVIEW_PACKET.md
# Pass 2 — Will Review Packet **Stage 5R3 Pass 2** · mechanical retarget of OP-A V3.18 §6 onto the post-flatten DOC80 family · generated 2026-05-28. --- ## STATE Pass 2 is **complete and ready for your review.** All 7 required deliverables (+ the recommended self-audit) are written into `Stage_5R3/`. Pass 2 applied the 13 resolved Pass-1 architect decisions **mechanically** — it changed only the **owner (target-doc) assignment** of each §6 active obligation, not obligation bodies. The 511 true §6-active rows were classified into three buckets: **512 Bucket A** (high-confidence single retargets, including 7 new ADD rows), **3 Bucket B** (splits into 7 owner-clean child rows), and **2 Bucket C** (genuine architect calls, held RESERVED). One duplicate pair was merged (D10). The 17 §8-deferred (V17/V18) rows were left untouched. **One pivot from the Pass-1 plan:** the "≈342 likely-splits" estimate was a keyword overcount — in practice almost every split-section row resolved cleanly into Bucket A or B, leaving only **2** rows that need your judgment. No new architecture was invented; the two open questions are surfaced as proposed ADQs, not decided. ## WHAT YOU MUST DECIDE Two items (both Bucket C). Each is held as a RESERVED placeholder in the V4 candidate (target unchanged until you rule). Full detail in `BUCKET_C_ARCHITECT_DECISIONS.md`. 1. **PBE cluster-detection schema home — graph store or extraction owner?** - *Question:* Does `PBEClusterDetectionResult` live in **DOC72** (graph store, as the superset read-model) or **DOC73** (as the owner, with DOC72 holding a projection)? - *Recommended default:* **DOC72** (graph store owns the superset; DOC73 consumes a minimum projection) — unless DOC73 needs write-authority over cluster membership. - *Impact:* blocks the **E3 knowledge** cluster-detection read-model and the **DOC72 graph-schema freeze**. Proposed **ADQ-PASS2-01**. 2. **Corpus / "library" identity authority — who owns the canonical mapping?** - *Question:* Who owns the canonical corpus↔"library" identity mapping — **DOC24** (search/onboarding), **DOC87** (organization/membership identity), or **DOC25** (ingestion)? And is `OBL-D24-CORPUS-LIB-MAP-01` the **same** obligation as `OBL-D7-NEW-LIBRARY-NAMING-01` (merge) or **distinct** (keep both)? - *Recommended default:* **DOC24** (the R3.1 gate row originates there) — but **DOC87** if the term is primarily a membership/organization concept. Keep both rows unless you confirm the dup. - *Impact:* blocks the **E1 scope** corpus/library vocabulary and the **E_org (DOC87) membership identity**. Ties to SM-040 + the OPA-032 Topic-identity seam. Proposed **ADQ-PASS2-02**. ## SAFE TO BULK-APPROVE **512 Bucket A + 3 Bucket B (= 7 child rows) = the entire rest of the deck** is mechanically derived and needs no architect judgment. Every Bucket A row is a one-to-one mapping from the Pass-1-resolved section→owner model (113 rows move into the DOC80 family DOC81–DOC87; 399 keep their current owner because they sit outside the memory-flatten boundary). Every Bucket B split falls on a Pass-1-resolved boundary (schema-vs-executor for the Extraction Failure State Machine; extraction-vs-ingestion for the DOC73/DOC25 adapter; UI-vs-onboarding-vs-corpus-org for the DOC73 UI bundle), so each carries `architect_review_required = no`. The 7 ADD rows (6 DOC24 R3.1.1 per D3a + 1 DOC25 degraded-state per D13a) and the 1 D10 merge are likewise direct applications of resolved decisions. These are in `BUCKET_A.md` and `BUCKET_B_SPLITS.md`. ## BLOCKED-MISSING Nothing blocked Pass 2 from completing. Three **external-write actions are reserved for you** because Pass 2 is forbidden (HARD CONSTRAINTS §5.1 / §5.5) from touching files outside `Stage_5R3/`: 1. **33 DOC23 Addenda B deferral rows (D3b)** — deferred entirely (correctly; out of scope until flatten complete). Their tracking rows belong in `DOC73_V1_6_DEFERRAL_INVENTORY_R1.1.md` (outside `Stage_5R3/`). **You add them at ratification.** No Bucket A/B/C rows were created for these. 2. **RecentActivityRollup deferral tracking (D6)** — the consumer/orchestration deferral note also belongs in that same external inventory. **You add it.** 3. **2 new ADQ rows (ADQ-PASS2-01, ADQ-PASS2-02)** — must be opened in `Architect Decision Queue/Architect_Decision_Queue.md` (outside `Stage_5R3/`). Pass 2 surfaced the question text + recommended default (above and in `BUCKET_C_ARCHITECT_DECISIONS.md`) but **you open the rows.** No sha256 mismatch was found in `baseline_snapshot/` (the frozen retarget substrate) or in the live `OPA_V3_18.md` input — both verify bit-exact, so **no HALT condition was triggered.** Two *cross-reference* trackers did drift since the Pass-0 pin — the **ADQ ledger** (`dcf1f25f15c1` → `5f136300ab5b`) and the **Supersession Matrix** (`5c58e08c276f` → `89311929c416`). This is expected drift on files you actively edit, not a defect: every anchor Pass 2 cited from them was re-verified present (all 11 ADQ anchors; `SM-040`; no `ADQ-PASS2` collision). **Before ratifying, confirm those post-pin edits don't change the cited anchors' meaning, then re-pin both files in the Source Package.** Full detail in `Stage_5R3_Pass_2_Self_Audit.md` §1b. ## KEY NUMBERS | Quantity | Count | |---|---:| | V3.18 total OBL rows | **528** (511 §6-active + 17 §8-deferred) | | — note | V3.18's "528 §6-active" figure conflated the 17 deferred rows; true §6 = 511 | | Bucket A (incl 7 new ADD) | **512** | | — of which move into DOC80 family (DOC81–87) | 113 | | — of which keep current owner (outside boundary) | 399 | | Bucket B splits (3 parents → 7 children, net +4) | **3 → 7** | | Bucket C reserved (architect review) | **2** | | D10 merge (loser folded into winner) | −1 | | New ADD rows (6 D3a + 1 D13a) | +7 | | **V4-candidate §6 active rows** | **521** | | §8 deferred (untouched) | 17 | | **V4-candidate total OBL rows** | **538** | | New ADQ rows proposed | **2** (ADQ-PASS2-01, -02) | | New OPA-* seam rows minted | 0 (existing OPA-024/032/034/035 reused) | **Charter inputs (OPA V4 rows per DOC80-family charter):** DOC80/E0 = 0 (ADQ-driven core); DOC81/E1+E2 = 10; DOC82/E3+E4 = 9; DOC83/E5+E6 = 7; DOC84/E7+E8 = 34; DOC85/E9 = 45; DOC86/E10 = 3; DOC87/E_org = 9. **Total family-owned = 117.** Per-charter ADQ / Conflict-Register / seam / `minimum_completion_for_v5` assignments are in `STAGE_6_CHARTER_INPUT_INDEX.md`. ## NEXT ACTION 1. **Decide the 2 Bucket C items** above (PBE cluster home; corpus/library identity owner + dup question). 2. **Ratify Bucket A + B** (bulk-approve — no judgment needed). 3. **Apply the 3 external writes** (33 + 1 deferral-inventory rows; open the 2 ADQ rows). 4. Update the Conflict Register / Supersession Matrix / Owner Map as needed (your step, not Pass 2's). 5. **Publish** the ratified candidate as the live `OPA_V4.md`. 6. **Open the Stage 6 charters** using `STAGE_6_CHARTER_INPUT_INDEX.md` as each author's first read. ## SUPPORTING FILES All in `Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/`: 1. `BUCKET_A.md` — 512 high-confidence retargets. 2. `BUCKET_B_SPLITS.md` — 3 splits → 7 owner-clean child rows. 3. `BUCKET_C_ARCHITECT_DECISIONS.md` — the 2 items above (full detail + proposed ADQ text). 4. `OPA_V4_CANDIDATE.md` — the full V4 row deck (Bucket A + B applied; C held RESERVED; §9 D-decision closures). 5. `STAGE_6_CHARTER_INPUT_INDEX.md` — per-charter input deck (OPA rows + ADQ + conflicts + seams + AC minimums). 6. `SECTION_15A_REWRITE_PREVIEW.md` — V4 conventions/discipline prose preview. 7. `PASS_2_WILL_REVIEW_PACKET.md` — this file. 8. `Stage_5R3_Pass_2_Self_Audit.md` — *(recommended 8th)* residual limitations, input sha256 verification, no-external-write confirmation.