ELNOR REPO READER TEXT MIRROR Original path: Memory Rebuild Docs/Flattening/Reviews/Codex Ready/Stage_3_Review_Prompt.md Source repo: /Users/OpenClaw1/Elnor/Elnor Specs Git branch: main Git commit: dbaa25962edc11ab30e8d4ca1715f9ae5bf77331 Generated: 2026-06-09T01:23:58.539Z --- # Codex Review — DOC80 Memory Rebuild Stage 3 Capability Inventory ## Where to find the files **Repository:** github.com/wbrody/Elnor-Specs — branch `main`. Use exact paths (folders have spaces and capitalization, both significant). If you have repo read access, fetch these paths directly. Otherwise, Will will attach them. **Primary review target (the thing you are reviewing):** - `Memory Rebuild Docs/Flattening/Capability Inventory/Capability_Inventory.md` — 110 capability rows (95 file-level + 15 plan §6.4 seeded crown-jewel families). This is the file we want you to audit. **Companion file (flag here if you spot issues in passing, but do not deep-review):** - `Memory Rebuild Docs/Flattening/Source Section Disposition/Source_Section_Disposition.md` — 3,068 section disposition rows. **Context / source-of-truth files (read-only, do NOT re-review these):** - `Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md` — plan §§6.1, 6.2, 6.3, 6.4 are the controlling vocabularies for this inventory. - `Memory Rebuild Docs/Flattening/Source Freeze/Source_Freeze.md` — 124 active source files (after D-SEED-3 archive exclusion and D-SEED-4 operations/meta exclusion). - `Memory Rebuild Docs/Flattening/Source Registry/Source_Registry.md` — full inventory including the explicit lists of which files were excluded as archive or operations/meta (so you can confirm we're not missing anything). ## What the inventory is Per plan §6.3, each row is a `CurrentSpecCapabilityRecord` representing one memory-relevant capability. Two kinds of rows: 1. **File-level capabilities (95 rows):** one per active `direct`/`adjacent`-relevance file. `capability_name` is the file's H1 title (the document's own declared name; not a subsection heading). 2. **Plan §6.4 seeded crown-jewel families (15 rows):** named load-bearing/crown-jewel families from plan §6.4, seeded as explicit capabilities so the named families have identity at this stage. Their `source_file` is `(plan §6.4 seed)`. Tier assignment follows plan §6.2: - `crown_jewel_must_showcase` — file or seed matches a plan §6.4 named family. - `load_bearing` — safe default for `direct`-relevance files (plan §6.2 rule: untiered touched capability = `load_bearing`). - `important` — default for `adjacent`-relevance files (memory seam, not memory core). - `supporting` / `minor` / `lineage_only` / `unknown_untiered` — not used in this first pass. `capability_status` (plan §6.1) is `operative_capability` for every row because the active source set is `operative_current`. ## What we want you to check ### A. Completeness **A1.** Are there active source files in `Source_Freeze.md` that have NO capability row in `Capability_Inventory.md` and that SHOULD have one because they describe a memory capability? (The 29 source files without a capability row are intentionally those classified `process` or `low` — e.g., connector specs, DOC5 account build, DOC13 costs, master spec list, manifests, cross-doc delta trackers, punch lists. Confirm those are correctly omitted, OR flag any that actually hold memory capability.) **A2.** Are there capability families listed in plan §6.4 that are missing from the 15 seeded rows? Plan §6.4 explicitly names: - DOC72 six-dimensional knowledge + graph shape - DOC72 procedural taxonomy + standing-procedure / skill / task escalation - DOC73 CU / VersionedClaim / RecentActivityRollup / source-bound synthesis discipline - DOC25 parse quality / materialization / SourceArtifact / ArtifactSegment / prompt-injection isolation - DOC24 packet lifecycle / manifests / context assembly / injection slots / Packet Inspector / final-prompt proof - KDA reference-only-vs-excluded distinction / deterministic rendering / KdaManifestPatch / render safety metadata - BDSM-DOC8 final-prompt-proof-gated utility / partitioned learning / no second confidence system - PropA / EC source policy / dimensional policy / command closure / one compiled policy evaluator - DOC20 Project / Library / Inspector / visible-control command closure - DOC23 task outputs / Claim Extractor interfaces / task-output-to-memory seams - DOC3 procedural memory / skill lifecycle seams - TopicLens and TopicCollectionDirective - Library / corpus source collection and deep ingestion - Assertion / CU / Evidence / Directive / Procedure / IssueFrame / NullResult distinctions - MemoryCoordinationTrace and final proof chain **A3.** Are there ADDENDA files (e.g., DOC23 Addenda B subsystem files, DOC24 Addendum A BDSM, DOC3 Addenda A, EC Core Addendum A, DOC20 Addendum B MS Word Viewer, DOC2 Freshness Manager Addendum) present in `Source_Freeze.md` but missing from the inventory? ### B. Correctness **B1.** For each capability row, is the `capability_name` field a reasonable name for the document/capability? (`capability_name` is set to the file's H1 title; if a file's H1 is misleading or unhelpful — e.g., a generic "Spec Pinning" or a banner header — flag it and suggest a better name.) **B2.** For each row, is the `capability_tier` assignment defensible per plan §6.2 and §6.4? Specifically: - Are there `important`-tier rows that should be `load_bearing` because DOC80 actually depends on that seam being correct? - Are there `load_bearing` rows that should be `crown_jewel_must_showcase` because they match a plan §6.4 named family? - Are there `crown_jewel_must_showcase` rows that should actually be `load_bearing` (rare)? - Are there rows tiered too low — e.g., `important` for a memory-direct file? **B3.** Is the `owner_doc` field correct? File-level rows for `direct` files say "DOC80 (target)" (they will be flattened INTO DOC80). `adjacent` files say e.g. "DOC10", "DOC11", "DOC15" (they remain owned by their named doc). Are any owners mis-assigned? **B4.** Is the `target_disposition` defensible? File-level capabilities have: - `absorbed_with_redesign` for `direct`-relevance files (memory-core: absorbed into DOC80 with redesign). - `external_owner_preserved` for `adjacent`-relevance files (memory seam stays at its owner). - `federated_reference` for some `adjacent`-relevance files whose H1 / first section is a memory seam (e.g., DOC11 sections about EC policy). ### C. Aspirational valuable **C1.** Per plan §6.1, capabilities that are "aspirational but valuable" should be `aspirational_valuable` rather than `operative_capability`. All 110 rows are currently `operative_capability`. Are there source files that should actually be `aspirational_valuable` (incomplete, accepted-in-principle, not yet operative)? Candidates to consider: - DOC23 Addenda B subsystem files (FEEDBACK_DELIVERY, SOURCE_WORKSPACE, TASK_FORUM_RUN_BOARD) - DOC73 positronic-brain enhancement concept files (if any current ones exist) - Any file with "Proposal" / "Draft" in the name - DOC2 ELNOR_FRESHNESS_MANAGER_ADDENDUM (was an addendum proposal — confirm whether it's now operative or aspirational) ### D. Crown-jewel coverage gaps **D1.** Plan §6.4 includes "TopicLens and TopicCollectionDirective" as a crown-jewel family. Is this surfaced by a real source file? If yes, that file should also be tiered `crown_jewel_must_showcase`. If no, the seeded row alone is sufficient but flag where it should live (which DOC owns it). **D2.** Plan §6.4 includes "MemoryCoordinationTrace and final proof chain" as a crown-jewel family. Where in the source does this live? Identify the file (likely DOC24 territory) and confirm whether the seeded row is sufficient or a per-file capability row is also needed. **D3.** Are there capabilities the plan §6.4 list omits that should be added based on what's actually in the source set? Candidates to consider: IssueFrame lifecycle, NullResultMemory, FrictionEvent / FrictionPattern, SearchAffordance, IncidentObservation, prompt shell registry, the Knowledge Delivery Shared Contracts (KDA addendum), Q_BROWSER intake architecture. ## Return your findings in THIS exact format ``` # DOC80 Stage 3 Capability Inventory — Codex Review Findings ## Summary ## A. Completeness findings - [A1 or A2 or A3] [BUG | GAP | SUGGESTION | CONFIRMED] - row(s) affected: - source_file(s): - recommended action: (repeat one bullet per finding; "CONFIRMED" with no issue is fine — say "A1 CONFIRMED — no missing files" if A1 looks good) ## B. Correctness findings - [B1 or B2 or B3 or B4] [BUG | GAP | SUGGESTION | CONFIRMED] - row(s) affected: - recommended change: ## C. Aspirational valuable findings - [C1] [BUG | GAP | SUGGESTION | CONFIRMED] - row(s) affected: - recommended change: ## D. Crown-jewel coverage findings - [D1 or D2 or D3] [BUG | GAP | SUGGESTION | CONFIRMED] - recommended action: ## Overall assessment ``` ## Boundaries — do not do these - This is a Stage 3 **classification** review. Do NOT make Supersession Matrix decisions (that is Stage 4) and do NOT write target DOC80 sections (Stage 5/6/7). - Per architect directions D-SEED-3 (archives out of source) and D-SEED-4 (operations/meta out of source), files in `Archived and Subsumed Specs and Lineage/`, `Parked and Abandoned Specs/`, archived subfolders, the flattening plan, the runbook, the One-Shot Start Prompt, the review-pack process files (00_README, 01_Adjudication, 06_R2R_Matrix, 07_*, 09A–F reviewer prompts, 11_Current_Instructions), README.md, and REPO_FILE_MANIFEST.md are intentionally NOT in this inventory. Do not flag their absence. The Source Registry lists them explicitly under "D-SEED-4 — Operations/meta files". - Do NOT propose tier DOWN-grades unless the row is clearly mistakenly tiered too high. ## Where Will saves your reply `Memory Rebuild Docs/Flattening/Reviews/Codex Responses/Stage_3_Review_Response.md`