Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/BUCKET_B_SPLITS.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# Stage 5R3 Pass 2 — BUCKET B (mid-confidence splits)

**Generated:** 2026-05-28 · Pass 2 mechanical retarget of OP-A V3.18 §6 against the DOC80 family.
**Confidence:** medium for every row (each is one OP-A row that resolves into **multiple** V4 rows under different owners). High-confidence single retargets are in `BUCKET_A.md`; genuine architect calls are in `BUCKET_C_ARCHITECT_DECISIONS.md`.

**Count:** 3 rows. Each splits one OP-A obligation into 2–3 V4 obligations. `architect_review_required = no` for all three — the split lines fall on a Pass-1-resolved boundary (schema-vs-executor, or extraction-vs-ingestion-vs-UI), so no new architecture decision is needed; the split is mechanical.

**What "split" means here:** the single OP-A row covers concerns that, post-flatten, belong to two or more different one-owner schemas (B3). Rather than force-fit it to one owner, the row is decomposed so each child V4 row has a single clean owner. Child IDs below are **proposed**; final IDs are confirmed when the owning DOC charters are drafted in Stage 6.

## Field key
`opa_row_id` · `current_target_doc` · `split_kind` · `proposed_v4_rows` · `confidence` · `mapping_basis` · `architect_review_required`

---

### OBL-EXT-FSM-01 — Extraction Failure State Machine
- **current_target_doc:** GroupA (EC + DOC73) — V1.6 cross-cutting
- **split_kind:** `executor_split` (schema owner ≠ the kernel that drives it)
- **confidence:** medium
- **architect_review_required:** no
- **proposed_v4_rows:**

| proposed_v4_id | owner | scope of this child row |
|---|---|---|
| `OBL-EXT-FSM-01` | **DOC83** | Extraction Failure State Machine **schema + state semantics** — states, legal transitions, terminal/recovery conditions. The normative definition of the FSM lives with extraction (E5). |
| `OBL-EXT-FSM-EXEC-01` *(new child)* | **EC Core** | Kernel **records** FSM transitions as `extraction_state_change` operations. EC executes/journals transitions but does **not** own the state semantics. |

- **mapping_basis:** The OP-A row bundles the state-machine definition with the kernel's duty to record transitions. Post-flatten these are two owners: extraction (DOC83) owns the schema and the legal-transition table; the executor kernel (EC Core) owns only the operation that journals a transition. Source-row note already states "DOC73 + DOC25 own state semantics; EC kernel records transitions … (does not own state semantics)" — Pass 2 routes the state-semantics half to DOC83 (the E5 extraction owner that absorbs DOC73's extraction surface) and keeps the recording half in EC Core. Clean schema/executor boundary; no judgment call.

---

### OBL-D73-NEW-10 — Extraction + DOC25 adapter bundle
- **current_target_doc:** DOC73
- **split_kind:** `owner_split` (two co-equal schema owners)
- **confidence:** medium
- **architect_review_required:** no
- **proposed_v4_rows:**

| proposed_v4_id | owner | scope of this child row |
|---|---|---|
| `OBL-D73-NEW-10` | **DOC83** | Extraction surface — the extraction-side contract (E5). |
| `OBL-D25-NEW-10-INGEST-ADAPTER-01` *(new child)* | **DOC25** | DOC25 ingestion-adapter surface — the ingest/connector half that DOC25 retains (outside the memory-flatten boundary). |

- **mapping_basis:** Row covers both the extraction contract and the DOC25 ingestion adapter that feeds it. Extraction → DOC83 (E5 owner, absorbs DOC73 extraction). The ingestion-adapter half stays with DOC25, which is a STAYS doc (outside the flatten boundary). Two distinct owners, split on the extraction-vs-ingestion line that Pass 1 already drew for the DOC25/DOC73 sections.

---

### OBL-D73-NEW-12 — UI / onboarding / corpus-UX bundle
- **current_target_doc:** DOC73
- **split_kind:** `owner_split` (three owners)
- **confidence:** medium
- **architect_review_required:** no
- **proposed_v4_rows:**

| proposed_v4_id | owner | scope of this child row |
|---|---|---|
| `OBL-D73-NEW-12` | **DOC86** | Corpus UX / inspector UI surface (E10). |
| `OBL-D24-NEW-12-ONBOARDING-01` *(new child)* | **DOC24** | Corpus onboarding flow — stays with DOC24 (search/onboarding, outside flatten boundary). |
| `OBL-D87-NEW-12-CORPUS-ORG-01` *(new child)* | **DOC87** | Corpus organization / membership surfaces (E_org). |

- **mapping_basis:** Row spans three post-flatten owners: the inspector/search UI (DOC86, E10), the onboarding flow (DOC24, a STAYS doc), and corpus organization/membership (DOC87, E_org). Each maps cleanly onto a Pass-1-resolved owner; the only work is decomposing the one row into three. UI → DOC86, onboarding → DOC24, corpus-org → DOC87 follow the same section-model used for the rest of the DOC73 peel.

---

## Note for Stage 6 charter drafting
All `*(new child)*` IDs above are **proposed splits**, not yet-existing OP-A rows. When the owning DOC charter is drafted, confirm the child ID and add a `split_parent: OBL-…` provenance pointer back to the OP-A parent so the lineage is traceable. The parent OP-A row is considered fully discharged once all child rows are placed.