Elnor Repo Reader

ELNOR REPO READER TEXT MIRROR
Original path: Memory Rebuild Docs/Flattening/Reviews/Red Team Ready/Stage_5_Skeletal_DOC80_Review_Prompt.md
Source repo: /Users/OpenClaw1/Elnor/Elnor Specs
Git branch: main
Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331
Generated: 2026-06-09T01:23:58.539Z

---

# Red-Team Review — DOC80 Memory Rebuild Stage 5 Skeletal Target Baseline

## Where to find the files

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`. Use exact paths (folders have spaces, capitalization matters).

If you have repo read access, fetch these paths directly. Otherwise Will will attach them.

**Primary review targets (the four skeletal Stage 5 artifacts):**

1. `Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md` — 454 lines. The main skeletal architecture: family member list (7 members: DOC80–DOC86), split rationale, per-schema ownership handoff, section maps, owner boundaries.
2. `Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md` — 154 lines. Intra-family + external-doc import graph; plan §18 import-graph proof conditions.
3. `Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md` — 191 lines. Per-schema ownership table (owns / consumes / stores / executes) across all DOC80 family + external owners.
4. `Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md` — 83 lines. Retired-name lint patterns + allowed historical context + alias expiry.

**Context files (read-only; do NOT re-review):**

- `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — **plan §18 (skeletal spec gate) is the governing rule** for this stage.
- `Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md` — 49 supersession rows; the canonical "old → new" mapping.
- `Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md` — 41 architect decisions (all resolved); the skeletal architecture consumes these decisions.
- `Memory Rebuild Docs/Flattening/Execution Ledger/OP-A Disposition/OP_A_Candidate_Disposition.md` — 24 cross-doc obligation candidates.
- `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/12_ABC_Consolidated_Structural_Patch_R0_2.md` — senior structural patch.
- `Memory Rebuild Docs/Memory Rebuild Review Packs/DOC80_Memory_Control_Plane_PreSpec_Review_Pack_v1_0_2026-05-25/13_Round_D_Policy_Scope_UI_Micro_Patch_R0_2.md` — senior policy/scope/UI patch.

## What you are reviewing

Stage 5 is a **skeletal architecture review**, not a full-spec review. The skeletal baseline is what plan §18 calls "the skeletal DOC80 target with: spec family membership, owner-doc imports, canonical object families, section map, retired-name table, cross-doc owner map, required lints, required fixtures, OP-A candidate table placeholder."

**Two pre-resolved architect decisions** are NOT under review (the runbook seeds them):

- **D-SEED-1:** DOC80 is a spec family.
- **D-SEED-2:** the DOC80 family is a real owner doc in the ELNOR hierarchy.

You may raise `architect_stop` ONLY if your review surfaces a genuine contradiction of D-SEED-1 or D-SEED-2 — for example, the owner-map analysis shows a memory schema cannot move into the family without breaking an existing owner boundary.

**The skeletal decisions that ARE under review:**

- The complete family member list (DOC80–DOC86, 7 members) — is this the right count and grouping?
- The split rationale (by owner boundary along plan §12 slices) — defensible?
- The per-schema ownership handoff from DOC72 / DOC24 / DOC73 — every load-bearing schema accounted for?
- The owner boundaries (what DOC80 family owns vs what stays at adjacent docs) — clean? Any phantom ownership?
- The import graph — does it prove the plan §18 conditions (no local redef, no dual-running type families, no retired-name leakage, every cross-doc import has owner, every target-freeze file path-resolvable)?
- The retired-name table — does it cover everything the Supersession Matrix retires, with appropriate lint patterns and allowed historical context?

## What we want you to check (RED-TEAM the architecture)

### A. Family member list

**A1.** Is **7 members** the right number? Could it be defensibly 5 or 9? Specifically:
- Is DOC83 (Extraction Spine + Temporal/Working-State) a coherent boundary, or should E5 (Extraction) and E6 (Temporal) be split into two members?
- Is DOC85 (Learning) substantial enough to warrant its own member, or should E9 be absorbed into DOC84 (Delivery)?
- Is DOC86 (UI / Inspector / Search) substantial enough to be its own member, or should it be folded into DOC84?

**A2.** Does the split respect every plan §12 lockstep pair?
- E1/E2 → DOC81 ✓
- E3/E4 → DOC82 ✓
- E7/E8 → DOC84 ✓
- Are there any non-lockstep slices that SHOULD have been kept together but were split?

**A3.** Is the "one core/contracts member" requirement correctly implemented? Does DOC80 own ONLY shared contracts (registries, vocabularies, proof spine), or has anything domain-specific leaked into the core? Look specifically at:
- Plan §6.4 crown-jewel families: are any DEFINED in DOC80 core that should live in a downstream member?
- ReasonCode registry, ContextProduct registry, PromptShellRegistry — these are correctly in core per ADQ-310 / ADQ-203 / ADQ-208 — confirm.

### B. Per-schema ownership handoff (the real Stage 5 decision)

**B1.** For each schema in `DOC80_Skeletal_Target_Baseline.md` §4 (per-schema ownership handoff from DOC72 / DOC24 / DOC73):
- Does every load-bearing schema have an explicit new owner?
- Are any schemas missing (e.g., a DOC72 schema we forgot to hand off)?
- Are any handoffs wrong (e.g., a schema that should stay at original owner but we moved it)?

**B2.** Three specific handoffs to red-team hard:
- **Assertion → DOC82** (was at DOC72): does this break DOC72's role as the knowledge graph owner? DOC72 retains graph topology and stores Assertion payload, but DOC82 defines the schema and EC executes writes. Is this clean, or does it create a 3-way coordination problem (DOC82 schema / DOC72 storage / EC writer)?
- **ConsolidatedUnderstanding → DOC73 (retained)** (per ADQ-219): is the conditional `SourceBoundSynthesisProjection` wrapper architecturally clean, or does it risk becoming a permanent compatibility shim?
- **MemoryContextPlan + ContextProduct → DOC80 core** (per ADQ-211 / ADQ-203): are these really cross-cutting enough to belong in core, or do they belong in DOC84 (delivery)?

**B3.** Are there schemas in DOC72 / DOC73 / DOC24 that the table forgot? Use these as anchors to check:
- DOC72: WorkSession, EpisodeSegment, scope linking, entity graph
- DOC73: VersionedClaim (currently mapped via lineage table — is that enough?), RecentActivityRollup variants
- DOC24: PriorDeliveryLedger, CarryoverCapsule, DynamicHeaderLedger, MemoryContextPlanDeterminismInputs — these are in DOC84; confirm DOC24 doesn't claim ownership of any

### C. Import graph (plan §18 proof)

**C1.** The Import Graph asserts five plan §18 conditions. For each, red-team whether the skeletal architecture actually satisfies it:
- §4.1 No local redefinition of owner-doc schemas — any cases where DOC80 family member effectively redefines an external doc's schema?
- §4.2 No dual-running type families — any retired name that could re-emerge under the architecture as proposed?
- §4.3 No retired names outside allowed historical context — any leaks?
- §4.4 Every cross-doc import has an owner — any orphaned imports?
- §4.5 Every required target-freeze file is path-resolvable — confirmed at Stage 2, still true?

**C2.** The intra-family import graph has DOC80 at the top and the slice members flowing through E0→E1/E2→E3/E4→E5/E6→E7/E8→E9→E10. Are there any **necessary lateral imports** between non-core members that I've missed? The §1 table lists DOC82→DOC83, DOC83→DOC84, DOC81→{82/83/84}, DOC84→DOC85, DOC84→DOC86, DOC86→DOC81. Are any wrong direction, missing, or causing a cycle?

### D. Owner boundaries (what DOC80 owns vs doesn't)

**D1.** Plan §1.2 lists what flattening must NOT absorb wholesale: DOC23 task graph mechanics, DOC20 non-memory UI, DOC11/OpenClaw runtime truth, DOC3 executable skill lifecycle, DOC9 self-repair, code implementation planning. Does the skeletal architecture preserve those boundaries, or has it absorbed something it shouldn't?

**D2.** §3.2 lists what DOC80 family explicitly does NOT own (DOC72 graph, DOC73 CU, DOC25 SourceArtifact, DOC24 packet assembly, KDA rendering, BDSM computation, EC writes, PropA rules, DOC1 Write Gate, DOC11 final truth, DOC3 procedural, DOC15 CIL, DOC20 UI impl, DOC23 task graph, DOC26 UnifiedWorkspaceLibrary). Are any of these implicitly absorbed somewhere in the family member sections?

### E. Retired names

**E1.** The retired-name table has 22 entries. Compare against the Supersession Matrix (49 rows). The matrix has rows with `disposition` ∈ {retire_as_superseded, split_into_multiple_targets, semantic_compression, merge_into_target, replace_*}. Are any of those retire/split/compression/merge rows NOT in the retired-name table?

**E2.** Allowed historical contexts — any too broad ("lineage only" without further qualification is correct for some, but should `Premise` (as memory object) really be allowed in "DOC72 / DOC73 legacy citation contexts" indefinitely, or should this have an expiry?

**E3.** The 11→7 enum supersession (`AssertionCandidateDisposition`) is specifically listed (the four discontinued values: `retain_as_cu_component`, `create_directive_candidate`, `create_procedure_candidate`, `evaluation_only`). Are these the RIGHT four, or did the absorption rule keep some of them?

### F. New canonical object families (red-team for completeness)

The skeletal baseline introduces these as DOC80-core-owned (and a few are NEW canonical families per plan §11.3 — "new canonical object family is introduced" is an architect_stop condition normally; but the runbook seeds D-SEED-1 and D-SEED-2 to authorize the family creation, so families introduced as part of the skeletal split are pre-authorized):

- `SourceBoundSynthesisProjection` (DOC82 wrapper if DOC73 CU diverges, per ADQ-219)
- `PolicyDisambiguationRequest` (replaces ask_user, per SM-102)
- `PolicyCappedDAMSInput` (per SM-107)
- `EpisodePolicyEpoch` (restored, per SM-101)
- `MemoryCoordinationTrace` (restored, per SM-100)
- `ReviewQueueBatch` (per SM-210)
- `DynamicHeaderLedger` (per SM-209)
- `TopicCollectionDirectiveBudget` (per SM-211)
- `ProjectAutoLinkState` (per SM-212)
- `NullResultMemory` (with freshness fields per SM-205)
- `IncidentObservation` / `FrictionEvent` / `FrictionPattern` (per SM-206)
- `AssertionMergeOperation` family (per SM-204)
- `AssertionDedupeOutcome` (per ABC §7.8)
- `ExtractionRouteContext` / `ExtractionRoutePolicyEnvelope` / `ExtractionOutputKind` / `ExtractionSidecarKind`
- `SourceParseQualitySidecar` (per SM-207)
- `CascadingSourceInvalidation` (per SM-208)
- `RenderSafetyProof` / `MemoryFlowCertificate` / `ContextPacketProof` (proof spine)

**F1.** Are any of these NOT actually authorized by the matrix or the seeded decisions? Architect_stop if found.

**F2.** Are there obviously missing canonical objects that the skeletal architecture omits and that Stage 6 will then have to scramble to add?

### G. Round D / ABC R0.2 absorption

**G1.** Round D R0.2 had substantial UI / Inspector / SearchAffordance / Round-D UI surface content (review queue, policy restamp panel, blocked-item explanation, privacy banner, Project quarantine chip, cross-project search chip, task handoff scope-envelope, Topic/Library/Search More notices). All of these are in DOC86 §4. Did anything from Round D get dropped or mis-assigned?

**G2.** ABC R0.2 was the senior structural patch — the SM-202 lesson (DR-001 in the Conflict Register) says ABC + Round D are senior to Concept Model + DAMS V5 Outline. Are there places in the skeletal baseline where Concept Model wording would be inferred but ABC R0.2 actually superseded it? Spot-check `AssertionCandidateDisposition`, `EvidenceSupportEdge`, the warrant ladder, the merge operations, and §7 of ABC (extraction triage stages).

## Return your findings in THIS exact format

```
# DOC80 Stage 5 Skeletal Target Baseline — Red-Team Review Findings

## Summary
<one or two sentences — is the skeletal architecture sound enough for Stage 6 charters to begin?>

## A. Family member list findings
- [A1 or A2 or A3] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] <description>
  - affected family member(s) / section(s): <name>
  - recommended action: <what>

## B. Per-schema ownership handoff findings
- [B1 or B2 or B3] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] <description>
  - schema(s) affected: <name>
  - recommended handoff change: <what>

## C. Import graph findings
- [C1 or C2] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] <description>
  - plan §18 condition affected: <number>
  - recommended action: <what>

## D. Owner boundaries findings
- [D1 or D2] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] <description>

## E. Retired names findings
- [E1 or E2 or E3] [BUG | GAP | SUGGESTION | CONFIRMED] <description>

## F. New canonical object families findings
- [F1 or F2] [BUG | GAP | SUGGESTION | CONFIRMED | ARCHITECT_STOP] <description>

## G. Round D / ABC absorption findings
- [G1 or G2] [BUG | GAP | SUGGESTION | CONFIRMED] <description>

## Overall assessment
<one paragraph: is the skeletal DOC80 architecture sound enough that Stage 6 (charters) can begin, or does it need to be patched first? If any ARCHITECT_STOP findings, name them explicitly.>
```

## Boundaries — do not do these

- This is a **skeletal architecture** review, not a slice-draft review. Do NOT draft individual schemas or sections (that is Stage 7).
- Do NOT propose Supersession Matrix changes here (that was Stage 4; new findings against the matrix should go into the Conflict / Disagreement Register, not into this review).
- Do NOT re-litigate the four seeded decisions (D-SEED-1 through D-SEED-4) — they are settled. Only raise `architect_stop` if the skeletal architecture surfaces a genuine substantive contradiction of them.
- Do NOT re-litigate the 41 Architect Decision Queue items — they are resolved. If a resolved decision now appears wrong in light of the skeletal architecture, flag it explicitly as a finding ("ADQ-XXX may need re-opening because <reason>"), but do not assume it can simply be changed.

## Where Will saves your reply

`Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5_Skeletal_DOC80_Review_Response.md`

If multiple reviewers, use the per-stage folder: `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/Stage_5/<reviewer_name>.md`.