Elnor Repo Reader

# E0 DOC80 Core Charter Draft — External Red-Team Review Prompt

**Repository:** github.com/wbrody/Elnor-Specs — branch `main`
**Date issued:** 2026-05-28
**You are:** an external red-team reviewer. Will Brody is the architect. He will save your findings to the repo himself; you do NOT need to write files. Your output is a single markdown document in your chat response.

**Calibration note (read this first):** the Stage 5R / 5R2 red-team synthesis at `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md` is the depth/tone benchmark for this review. That synthesis represented MANY DAYS of architectural work across multiple reviewers; it caught structural defects, named cross-cutting failure modes, proposed better patterns, and identified what Stage 6 / Stage 7 would discover. You are expected to match that depth. **Do not produce a one-paragraph "looks fine" verdict.** Independent skepticism is the entire point.

---

## 1. Mission

You are reviewing the **first draft of the foundational charter** for the DOC80 family — the Memory Control Plane (DOC80 core). This draft was produced by **Claude Code (Opus 4.x) in fast mode in ~15-20 minutes**. It passed a Claude Code self-audit (`Charter_Draft_Self_Audit.md` in the same folder) with minor fixes applied. **You are the first independent reviewer.** Stage 6's foundation cascades into every subsequent charter (E1–E10 + E_org), so errors here multiply.

**Your goal is excellence, not just verification.** Do NOT just confirm Claude Code did the job. Find:

- **Bugs** — contracts that are wrong, not just incomplete.
- **Inconsistencies** — claims that contradict the Skeletal baseline, Owner Map, ADQ ledger, OP-A V4, or themselves.
- **Phantom features** — fields, lints, fixtures, or contracts invented without grounding in ADQ / Skeletal / Owner Map / Pass 1.
- **Bad schema** — TypeScript interfaces that are plausible-looking but actually poorly designed (wrong discriminators, missing optionality, mis-typed fields, leaky abstractions, badly named constants).
- **Missing contracts** — capabilities the DOC80 family will need that the draft doesn't include.
- **Things that would make a coding agent guess** — every field, lifecycle state, and invariant should be specified densely enough that a Claude Code / Codex implementer cannot legitimately ask "what should X be here?". Find every place a coder would have to guess.
- **Cross-charter wiring failures** — contracts that look fine in isolation but won't compose with what E1/E2/E3/E4/E5/E6/E7/E8/E9/E10/E_org will need.
- **Better patterns** — even where the draft is "correct," there may be a better architectural pattern. **Propose them.**

**Critical context Will is worried about:** the Stage 5R / 5R2 / 5R2b build-plan work took MANY DAYS across multiple reviewers and produced 12 must-fixes + 14 fold-ins + 22 audit-gap items. Claude Code drafted this E0 in 15-20 minutes. **Spot-check aggressively whether all that substantive work has landing sites in the draft.** If anything from the synthesis-level decisions was missed, you must catch it.

---

## 2. Read order (files in the repo)

All paths are repo-relative. **If you have GitHub repo access, fetch directly.** **If you are Gemini (or another model without repo access), you have been provided uploaded copies — they are labeled `COPY_*` and are bit-identical to repo versions at the time of upload.**

### 2.1 The artifacts under review (read in this order)

1. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/DOC80_Core_Charter_Draft.md`** — **THE TARGET**. 1083 lines. This is what you are reviewing.
2. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Opening_Brief.md`** — scope, 20 draft targets, exit criteria. Your job is to verify the draft delivers against THIS brief.
3. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Input_Deck.md`** — the 8 ADQs + 17 Skeletal fold-ins the draft was supposed to consume.
4. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/E0_Drafting_Commission_Claude_Code.md`** — the commission prompt Claude Code was given. Knowing what was asked helps spot what was answered.
5. **`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Charter_Draft_Self_Audit.md`** — Claude Code's own self-audit. Spot-check whether the audit is honest or self-serving.

### 2.2 The ground truth (the architecture the draft must align with)

6. **`Memory Rebuild Docs/DOC80 Target Baseline/Skeletal Spec/DOC80_Skeletal_Target_Baseline.md`** — DOC80 family skeletal architecture. **§10 (Stage 5R2 fold-ins) and §11 (Stage 5R2b additions) are the load-bearing input material.** Every contract in the draft should trace back here.
7. **`Memory Rebuild Docs/DOC80 Target Baseline/Owner Map/DOC80_Owner_Map.md`** — schema/object ownership truth.
8. **`Memory Rebuild Docs/DOC80 Target Baseline/Import Graph/DOC80_Import_Graph.md`** — 4-edge-kind dependency graph.
9. **`Memory Rebuild Docs/DOC80 Target Baseline/Retired Names/DOC80_Retired_Names.md`** — retired schemas; draft must not reintroduce these.

### 2.3 The decision authority

10. **`Memory Rebuild Docs/Flattening/Execution Ledger/Architect Decision Queue/Architect_Decision_Queue.md`** — 46 resolved ADQs + 1 open (ADQ-222, V5 networking, does not block Stage 6). The 8 ADQs pinned to E0 + cross-cutting ADQs are your verification anchors.
11. **`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R3/PASS_1_ARCHITECT_DECISIONS_RESOLVED.md`** — Will's 13 Stage 5R3 Pass 1 resolutions.

### 2.4 The substantive build-plan content (CRITICAL — this is what Will doesn't want lost)

12. **`Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md`** — **the multi-day, multi-reviewer synthesis.** 12 must-fixes + 14 fold-ins + 22 audit-gap items. **Every architectural decision in here must land somewhere in the E0 draft, OR be explicitly deferred to a downstream charter with a citation. Verify exhaustively.** This is THE single most important read for catching missed work.
13. **`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2_Patch_Summary.md`** — how Stage 5R2 actually applied the synthesis (record of what landed in skeletal §10).
14. **`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2_Self_Audit.md`** — Stage 5R2 self-audit (the source of the 22 audit-gap items folded into §11).
15. **`Memory Rebuild Docs/Flattening/Execution Ledger/Stage_5R2c_Patch_Summary.md`** — the cleanup patch that closed Stage 5R2c residuals.

### 2.5 Operational state (read for cross-references)

16. **`OP-A and Operations and Trackers/OPA_V4.md`** — operative cross-doc obligation tracker. DOC80 core has 0 direct OPA rows but the contracts you're reviewing must support obligations across DOC81/82/83/84/85/86/87.
17. **`Memory Rebuild Docs/Flattening/Supersession Matrix/Supersession_Matrix.md`** — 49 SM rows. SM-050 (MemoryFlowCertificate), SM-051 (ContextPacketProof + RenderSafetyProof split), SM-060 (ContextProduct 14-kind registry), SM-100 (MemoryCoordinationTrace), SM-203 (PromptShell), SM-213 (ReasonCode) are direct E0 input.
18. **`Memory Rebuild Docs/Flattening/Execution Ledger/Conflict Register/Conflict_Disagreement_Register.md`** — 8 resolved conflicts.

### 2.6 Background reference (read only if disoriented)

19. **`CLAUDE.md`** at repo root — project orientation + Will's standards.
20. **`Memory Rebuild Docs/Flattening/Current Flattening Plan/Flatten_and_Unify_Plan_V2_1c.md`** — the governing plan; §12 slice list; §18 golden-scenario E2E test.

---

## 3. What ELNOR is (background — 90 seconds)

ELNOR is a **local-first AI orchestration platform** built on OpenClaw (Node.js), running on a single M4 Pro MacBook. The architect is Will Brody, a securities litigator who built ELNOR as a domain-agnostic personal-OS platform with legal-litigation as one profile. ELNOR is in **spec completion / red-team / design-hardening phase** — nothing is implemented yet.

**The three-system architecture:**
- **Knowledge** (brain): DOC72 (graph store), DOC73 (PBE), DOC25 (source ingestion), DOC1 (write gate), DOC8 (legacy learning — capability-mining only).
- **Operations** (nervous system): DOC24 (packet assembly), DOC15 (CIL), DOC10/DOC11 (final runtime), DOC4.
- **Body** (muscles): DOC23 (tasks), DOC12/16/18/20 (UI), DOC14 (CANDOR), DOC17 (Q dashboard).

**The DOC80 family being flattened (where this charter sits):**
- DOC80 (core — **YOU ARE REVIEWING THIS**)
- DOC81 (scope/policy)
- DOC82 (knowledge/source/evidence)
- DOC83 (extraction/temporal)
- DOC84 (delivery/prompt/proof — contains DAMS substrate)
- DOC85 (learning architecture)
- DOC86 (UI/Inspector/Search)
- DOC87 (organization/membership)

**EC** = Elnor Core (sole durable writer; `dependency_status = partial / moving` per ECSeamContract). **Q** = Q Dashboard (Electron UI). **OpenClaw** = native runtime. **PBE** = Positronic Brain Enhancement (DOC73). **DAMS** = substrate inside DOC84, not an independent doc (ADQ-210).

**Will's standards (binding for your review):**
- Direct, no hedging.
- Excellence + completeness over brevity.
- Cite section/line numbers.
- Type findings as **BUG / GAP / SUGGESTION / CONFIRMED / BETTER_IDEA / ARCHITECT_STOP**.
- Think simultaneously as **Coder + Product Designer + Integration Architect**.

**Will's failure modes (search for these in the draft):**
phantom buttons · phantom memories · over-aggressive ingestion · silent auto-promotion of weak signals · missing empty/degraded/error states · under-specified schemas · cross-doc seams that sound good but aren't wired · magical context behavior · version sprawl · unregistered content types · unregistered UI surfaces · injected knowledge that shouldn't be / missing when needed · system feeling like a search engine instead of a personal OS · DOC73/DOC1 boundary erosion · living memory eroding static facts · silent PBE-lite degradation.

---

## 4. What to check — General areas (the 10 lenses)

Walk the draft through these 10 lenses. Each gets its own section in your output (§4.A through §4.J).

### 4.A — Completeness against the build-plan substance

**Critical lens.** The Stage 5R / 5R2 / 5R2b synthesis (file 12 above) represents many days of work and many specific decisions. Verify EVERY decision in that synthesis has either:
- A landing site in the E0 draft (cited with section pointer), OR
- An explicit deferral with citation to which charter it lands at, OR
- An explicit "out-of-scope for E0" justification.

If anything was silently dropped, **flag it as BUG** (high severity — losing the build-plan work is the worst possible outcome).

Specifically walk:
- Synthesis §4 (12 must-fixes) — every one must land somewhere.
- Synthesis §5 (14 fold-ins) — every one must land somewhere.
- Skeletal §11.1 through §11.22 (22 Stage 5R2b additions) — every one must land somewhere.

### 4.B — Architectural soundness

Do the contracts hang together as a cross-cutting foundation? Specifically:
- Will `ContextProduct` + `MemoryContextPlan` + `MemoryFlowCertificate` + the proof spine actually compose into a coherent delivery pipeline for DOC84 to consume?
- Is the three-plan model (`ExtractionContextPlan` / `MemoryContextPlan` / `UserContextSurfacePlan`) cleanly separated, or do the boundaries blur?
- Does the `ReasonCode` namespace-prefixing scheme scale? Will it survive 50 producer docs?
- Does the `ECSeamContract` (partial/moving) actually cover the cases EC will need? Anything missing?
- Are the proof spine contracts (`ContextPacketProof`, `RenderSafetyProof`, `MemoryFlowCertificate`) composable, or do they double-cover or leave gaps?

### 4.C — Phantom features

Re-read the draft as a skeptical reader looking for fabricated capabilities. For EVERY field, lint, fixture, and contract, ask: "Is this grounded in a citation, or did the drafter just think it 'would be useful'?" If the latter, **flag as GAP** (or BUG if it conflicts with an actual citation).

Particular sniff tests:
- Lint names that don't correspond to any concrete invariant.
- Fixture names that can't actually be implemented.
- Fields in TypeScript interfaces that have no producer or no consumer.
- Lifecycle states that no transition actually leads to or from.

### 4.D — Coding-agent test

Imagine a Claude Code / Codex implementer is told "implement DOC80." For every contract in the draft, ask: **"Where would the implementer have to guess?"** Flag every guess-point.

Specifically:
- Are field types specified (`string` vs `string literal union` vs `branded type`)?
- Are optional fields explicitly marked optional?
- Are enum values exhaustively listed?
- Are field-validation rules (length, format, allowed characters) specified or punted?
- Are default values specified?
- Are constructor / factory patterns specified?
- Are inter-field invariants stated (e.g., "if field X is non-null, field Y must also be non-null")?

### 4.E — Schema quality

The 15 TypeScript schemas in the draft — are they actually well-designed, or just plausible-looking? Audit each schema for:
- **Discriminated unions** where they belong (and not where they don't).
- **Branded types** for IDs vs free-form strings.
- **Field naming consistency** (snake_case vs camelCase — pick one; the draft should be one).
- **Generic parameterization** opportunities missed (e.g., should `ContextProduct` be generic over its payload type?).
- **Leaky abstractions** (private state exposed; public state hidden).
- **Mis-typed primitives** (`string` where `Date` would be better; `number` where `bigint` is needed for counts).
- **Encoding conventions** for timestamps (ISO 8601? Unix epoch? Both?).

For each schema, give it a quality grade: **A (production-grade) / B (good first attempt; needs polish) / C (plausible but needs significant rework) / D (architecturally wrong)**.

### 4.F — Missing contracts

What does DOC80 family need that the draft doesn't include? Particular candidates to consider:
- **Telemetry / tracing contract** beyond `MemoryCoordinationTrace` — does DOC80 own anything cross-cutting for distributed-tracing semantics, even in single-node V5?
- **Versioning / migration contract** — when schemas evolve, how do durable instances migrate? Does DOC80 own a versioning protocol or punt to each member?
- **Concurrency primitive vocabulary** — beyond EC serialization and `dedupe_basis_generation_id`, are there other concurrency primitives DOC80 should own?
- **Schema evolution contract** — what happens when DOC82 adds a field to `Assertion`? Does DOC80 own the family-wide migration discipline?
- **Test/fixture taxonomy contract** — does DOC80 name the kinds of fixtures the family needs (unit / integration / E2E / property-based)?
- **Debug / dev-mode contract** — is there a development-mode toggle that exposes additional state, owned by DOC80?

If any of these (or others you think of) are warranted but absent, flag as GAP.

### 4.G — Cross-charter wiring

For every contract DOC80 owns, ask: **"Will the consumer charter (E1/E2/E3/E4/E5/E6/E7/E8/E9/E10/E_org) actually be able to bind to this?"**

Spot-check by reading the Charter_Input_Deck for one downstream charter (pick E7+E8 since they consume the most from DOC80) and verify the contracts E0 produces actually deliver what E7+E8 will need.

Critical examination points:
- Does `ContextProduct` cover all 14 product kinds that DOC84 needs?
- Does `MemoryContextPlan` carry everything DOC24 packet assembly needs?
- Does `MemoryFlowCertificate` cover every flow DOC85 learning attribution needs?
- Does the proof spine compose with DOC11's final-prompt-truth role?

### 4.H — Better patterns (BETTER_IDEA findings)

Even where the draft is "correct," there may be a better architectural pattern. Propose them aggressively. Look at:
- Are there patterns from elsewhere in the ELNOR architecture (PBE bitemporality, event-sourcing, monotonic ledgers) that DOC80 should adopt that it doesn't?
- Are there industry-standard patterns (CQRS, EventStore, OpenTelemetry, Protocol Buffers, JSON Schema) that DOC80 could borrow for any contract?
- Are there naming conventions that would be clearer (e.g., should `ContextProduct` be renamed to `ContextArtifact` since "Product" overloads with delivery semantics)?
- Are there contracts that should be split or combined?

### 4.I — Failure modes / unhappy paths

For every contract, verify the draft specifies:
- **Empty state** — initial / unpopulated state.
- **Degraded state** — partial data / quality below threshold.
- **Error state** — operation failed.
- **Blocked state** — policy denied.
- **Suppressed state** — visible but content withheld.
- **Revoked state** — source was clawed back.

Flag any contract that's specified only for the happy path. This is one of Will's stated failure modes — "missing empty / degraded / error states."

### 4.J — Lints / fixtures coverage

The draft names 60+ lints and a handful of fixtures (§16.3). Audit:
- Are there critical invariants without a corresponding lint?
- Are there lints whose invariant is unclear from the name alone?
- Are the lints organized at the right scope (per-section vs cross-cutting)?
- Are the fixtures actually testable?
- Is the **end-to-end golden scenario** (Skeletal §18; F-struct #2) adequately reflected in the fixture inventory?

---

## 5. Specific questions — answer each directly

Beyond the 10 general lenses, answer each of these specific questions. **Each gets a numbered section in your output (§5.1 through §5.20).** Give your reasoning; cite section/line numbers.

1. **The 2 open items**: `IngestionCostBudget` (DOC25 vs DOC82) and `WarrantConsequenceRegistry` (DOC82 vs DOC80) — for each, which placement is correct? Show your reasoning from the Owner Map and ABC §21 if you have access to it.

2. **ContextProduct kinds**: the draft references "14 product kinds" (per SM-060). Are the 14 kinds enumerated in §3.1 correct? Any kinds missing that DOC84 will need? Any redundant or mis-named?

3. **MemoryFlowCertificate invocation points**: per ADQ-207, MFC is mandatory for durable write, render, export, carryover, delegation, learning attribution. Are all 6 invocation points covered by the draft? Are there flows that need MFC but don't have it? Any over-coverage where MFC is required but unnecessary?

4. **ReasonCode namespace scheme**: the draft specifies producer-prefixed namespaces. Walk through the scheme — will it actually prevent collisions across 50 producer docs? Are deprecation / migration semantics specified? Is there a registry-of-registries problem lurking?

5. **DomainProfile `conservative` fallback**: is "conservative" the right name? What does "highest restrictiveness" actually mean operationally? Could two DomainProfiles tie for "most conservative" — if so, who breaks the tie?

6. **PromptShellVariant stable-vs-volatile (ADQ-305)**: the draft must carry through the rule "stable headers ONLY if hash-pinned AND policy-invariant." Is this rule correctly enforced in the contract? Are there scenarios where a shell would be misclassified?

7. **Proof spine composition**: `ContextPacketProof` + `RenderSafetyProof` + `MemoryFlowCertificate` — do they actually compose? Walk an example flow (e.g., a durable Assertion write triggered by user input) and verify each proof artifact threads through correctly. Are there gaps?

8. **MemoryMutationEnvelope scoping**: this is NAMED-only (schema body deferred to Stage 7). Is the scope tight enough that Stage 7 can write the body? What's missing from the scope that Stage 7 would have to guess?

9. **MemoryProvenanceGraph scoping**: same question. Particularly: is the distinction from `MemoryCoordinationTrace` crisp?

10. **Bitemporal carrier choice**: §8.2 puts bitemporal axes on `MemoryMutationEnvelope`. Is this the right carrier, or should bitemporal live on Assertion directly (DOC82)?

11. **ECSeamContract coverage**: per Skeletal §10.9, the ECSeamContract includes 12 items (durable write execution, command execution, policy/scope execution, membership write execution, learning write-back execution, source-revocation execution, audit/replay, transaction ordering, compare-and-swap, read-model refresh, no non-EC durable writer). Are all 12 covered? Are there EC responsibilities the draft missed?

12. **MemoryOperationQuota completeness**: §10 lists ~8 quota fields. Are these exhaustive of what V5 needs? Any operation that can blow up at scale that lacks a quota?

13. **Recovery / replay testability**: §11 specifies a replay-completeness invariant. Is this invariant testable? Walk through how a fixture would prove it.

14. **Invariant enforcement-point naming (§12)**: per Skeletal §11.4, each invariant must have a runtime gate AND a Stage 9 lint. Are all load-bearing invariants in the §12 table? Any missing? Any with only a lint but no runtime gate?

15. **ABC §21 dispositions**: §13 places 7 normalization objects (4→DOC82, 2→DOC84, 1→DOC25). Are these dispositions correct? You will likely have to look up ABC §21 (in `Current Specs/DOC72/...` or via the source-doc references in the synthesis); if you can't access ABC §21, flag that the dispositions are unverified.

16. **AC-004 minimum_completion_for_v5**: `schema_plus_lints_and_fixtures` — is this the right bar for the Memory Intake & At-Use Disciplines obligation? Could it be downgraded to `schema_plus_owner_boundary`?

17. **AC-005 ADQ-202 dependency**: AC-005 (EC Core Addendum A intake-routing) depends on ADQ-202 (Corpus hierarchy at E4). Is this dependency correctly noted? Are there other AC-005 dependencies missed?

18. **§13.2 deferral to E3/E4**: the draft defers 7 Owner Map row additions to E3/E4/E7-E8 charters. Is the deferral honest (the member charters will actually do this work), or is it a punt? Anything that should land in E0 but got deferred?

19. **The 17 §10/§11 fold-ins vs the brief's "14" headline**: Claude Code noted the discrepancy and reconciled (14 headline topics → 17 enumerated rows). Verify the reconciliation is correct. Are 17 actually distinct, or are some duplicates?

20. **Schema field-naming consistency**: walk all 15 schemas. Are they consistently camelCase or snake_case? Mixed? Should they be one or the other? Justify your preferred convention.

---

## 6. Brutal questions — answer these last

Don't soften. If the answer makes the draft look bad, say so.

1. **Is this draft "production-grade" or "good first attempt"?** Why?
2. **What's the single biggest weakness?**
3. **What's the single biggest improvement opportunity?**
4. **Was 15-20 minutes enough time, or does the output reflect rushing?** Cite specific evidence either way.
5. **Did Claude Code miss substantive build-plan work from Stage 5R / 5R2 / 5R2b?** If yes, list what.
6. **If you had drafted this from the same inputs, what would you have done DIFFERENTLY (not just better)?**
7. **What would a skeptical Stage 7 schema-body author say is missing?**
8. **What would a skeptical Stage 8 fixture author say is missing?**
9. **What would a skeptical Stage 9 lint author say is missing?**
10. **Should Stage 6 charters open against this draft, or does E0 need a revision round first?**

---

## 7. How to produce your response

A single markdown document. Will saves it as:
`Memory Rebuild Docs/Stage_6_Charters/E0_DOC80_Core/Reviews/Stage_6_E0_Red_Team_Review_<your_model_name>.md`

Structure:

```
# E0 DOC80 Core Charter Draft — External Red-Team Review (<your model>)

## Summary
[Verdict + one paragraph stating bottom line.]

## §4.A Completeness against build-plan substance
[Per-decision walk-through. Cite which synthesis must-fixes / fold-ins 
have landing sites in the draft and which were dropped.]

## §4.B Architectural soundness
[Composition check + cross-contract integrity.]

## §4.C Phantom features
[Per-finding: cite the location, state why it's phantom.]

## §4.D Coding-agent test
[Per-guess-point: cite location, state what an implementer would have 
to guess about.]

## §4.E Schema quality
[Grade each of the 15 schemas A/B/C/D + reasoning.]

## §4.F Missing contracts
[Per gap: cite why DOC80 should own this.]

## §4.G Cross-charter wiring
[Spot-check E7+E8 binding + any other charter you think is at risk.]

## §4.H Better patterns (BETTER_IDEA)
[Per proposal: cite the existing draft text + your alternative.]

## §4.I Failure modes / unhappy paths
[Per contract: list missing states.]

## §4.J Lints / fixtures coverage
[Per gap: cite the invariant that needs a lint and isn't lint-named.]

## §5. Specific questions 1-20
[One subsection per question, numbered.]

## §6. Brutal questions 1-10
[One subsection per question, numbered.]

## Overall assessment
[One of: STAGE_6_CAN_OPEN | E0_NEEDS_REVISION_BEFORE_RED_TEAM_CLOSES | ARCHITECT_STOP.
If revision needed: minimum patch list (which sections of DOC80_Core_Charter_Draft.md to revise).
Bonus: rank the top 5 most important changes from your review.]
```

Use **BUG / GAP / SUGGESTION / CONFIRMED / BETTER_IDEA / ARCHITECT_STOP** tags inline on each finding. Cite section numbers and line numbers in the draft for every finding.

---

## 8. How to be useful (and not waste Will's time)

- **Be specific.** "The proof spine is weak" is useless. "§4.2 line 487 specifies `RenderSafetyProof.use_limit_survived: boolean`, but per Skeletal §10.7 the use-limit check should produce a `UseLimitOutcome` discriminated union with at least `passed`, `degraded`, and `blocked` cases — flag as BUG" is useful.

- **Distinguish defect from preference.** This is the E0 first draft. If you disagree with an architect decision (an ADQ resolution, a Pass 1 decision), that's preference (out of scope — flag as OOS-advisory). If the draft fails to implement an architect decision faithfully, that's a defect.

- **Don't propose new architecture casually.** Architect decisions are pre-resolved. Propose BETTER_IDEA where you see a clearer pattern; flag GAP where you see missing scope; flag ARCHITECT_STOP only if you think the family-level architecture is actually wrong (which it shouldn't be — that was settled at Stage 5R2c).

- **Don't soften.** If 30% of the schemas are grade C, say so. If you find a phantom feature, say so. The whole point is independent skepticism.

- **Cite section/line numbers.** Every finding should be locatable.

- **You can be wrong.** If you flag something and you're not sure, say so ("I think this is a BUG but I'd want to verify against ABC §21 which I don't have access to"). Honesty about uncertainty is valuable.

---

## 9. What is OUT of scope for this review

- The architect decisions themselves (ADQ resolutions, Pass 1 decisions) — flag as OOS-advisory if you have feedback.
- The DOC80 family member count (8) and member boundaries — settled at Stage 5R2.
- The OPA V4 retarget decisions — those got their own external review at Pass 2c.
- Stage 7 schema bodies for NAMED-only concepts — out of scope by design.
- Stage 8 fixture implementations — out of scope by design.
- Stage 9 lint implementations — out of scope by design.

If you have findings in these areas anyway, mark as `OUT_OF_SCOPE_ADVISORY` rather than as E0 defects.

---

## 10. Calibration note (re-emphasized)

The Stage 5R / 5R2 synthesis at `Memory Rebuild Docs/Flattening/Reviews/Red Team Responses/DOC80_Stage_5R_Red_Team_Reviews_and_Synthesis.md` is the depth/tone benchmark. That synthesis was thousands of lines, multi-reviewer, multi-day. Your output for E0 review may be shorter (E0 is more bounded than the family-level architecture), but should match the depth-per-finding standard.

The Stage 5R2c regression review responses at `Memory Rebuild Docs/Flattening/Reviews/Stage_5R2_Regression_Review_Responses.md` are also a useful reference — they show what found-issues look like vs missed-issues.

If your output is shorter than 500 lines, you probably didn't dig deep enough. If it's shorter than 200 lines, you definitely didn't. The 10 general lenses + 20 specific questions + 10 brutal questions should produce substantial content.

---

**Begin by reading file 1 (`DOC80_Core_Charter_Draft.md`) for orientation. Then file 12 (the Stage 5R / 5R2 synthesis) to ground yourself in the build-plan substance Will wants preserved. Then proceed through §2.1-§2.4 in order. Begin findings only after you've completed at least §2.1 + §2.4 reads.**

**You are the first independent reviewer of the foundation of the DOC80 family. Make it count.**