Elnor Repo Reader

# Red-Team Review Request -- DOC23 Addenda B "Review Studio" (Human Review & Agent-Assisted Revision)

**Intended reviewers:** ChatGPT 5 Pro, Gemini 3.1, Codex. Run each in its own session. Be direct, no hedging; excellence and completeness over brevity.

You are an expert systems architect and red-teamer reviewing a DRAFT design-spec unit for ELNOR, a local-first AI orchestration platform (legal + general knowledge work). "Review Studio" is the human-review + agent-assisted in-place revision checkpoint in the DOC23 task system -- the interactive, collaborative form of the existing user-review gate, with the Document Viewer as the review surface and an agent-assist channel attached.

## Where the documents are (GitHub repo `wbrody/Elnor-Specs`, branch `main`)
PRIMARY (review this):
- `Active Working and Red Team/DOC23 Working/DOC23 Non Operative Proposals/DOC23 Add B Review Studo D1.md`

Operative context you will need:
- `Current Specs/DOC23/DOC23 Addenda B/DOC23_ADDB_OUTCOME_EVALUATOR_REVISOR_V3_3_1.md`  (the automated Evaluator/Reviser, the tiers, Feedback Interpreter Sec.14)
- `Current Specs/DOC23/DOC23 Addenda B/DOC23_EVALUATION_COMMON_CONTRACTS_V1_1_1.md`  (shared contracts / GovernanceEnvelope / finding model)
- `Current Specs/DOC23/DOC23 Addenda B/DOC23_ADDB_SUBSYS_FEEDBACK_DELIVERY_V1_0_1.md`
- `Current Specs/DOC23/DOC23 Addenda B/DOC23_ADDENDA_B_CORE_R0_7_1.md`
- `Active Working and Red Team/DOC23 Working/DOC23 Red Teaming/DOC23_ADDENDA_B_RT_ADJUDICATION_CARD_STAGED.md`  (the adjudication card -- for the shared finding model, the single-mutation chokepoint A-16, and the Document-Review/editing decisions; Review Studio shares these)
- DOC20 (Document Viewer / review surface) under `Current Specs/DOC20/`

If your tool cannot access the repo, the operator will attach these files.

## What I want -- please address each

1. **New ideas to make it better.** Net-new capabilities, sharper primitives, better designs -- anything that would make Review Studio more capable, reliable, inspectable, or pleasant to use. Do not limit yourself to fixing what is there.

2. **How others do it (research).** Research and report how comparable systems implement human-in-the-loop review plus agent-assisted revision of AI outputs: document review/redline tools, AI writing assistants with review/track-changes modes, agentic IDEs, legal doc-review platforms, etc. What patterns, primitives, or affordances should we steal or learn from? Cite sources.

3. **Missing wiring / phantom features / missing contracts or schema.** Identify (a) wiring implied but not actually connected end-to-end, (b) phantom features (referenced or assumed but not defined / not backed by a contract), and (c) contracts or schemas that are missing or underspecified. Type each finding; cite the section.

4. **End-to-end human-gate walkthrough.** Trace a regular human review gate end-to-end: an output arrives, passes through the human gate, the Evaluator, and the Reviser, across all the tiers, to a routed result. Confirm it actually works end-to-end. As you walk it, answer: **what buttons/controls does the human need that we do not currently have?** I am particularly concerned about the **Document Review and in-place editing functions**. State clearly (a) what has already been built / worked out, and (b) how hard it is to get Document Reviewing/editing back to where it is supposed to be -- the specific gaps and the effort to close them.

5. **Downstream context injection after a human review.** After a human review (and any co-authored revision), what do we need -- **substantively and technically** -- to ensure the receiving/downstream modules are injected with the context they need to understand what changed and why? Specify the mechanism: what context, in what form, carried how, so a downstream module is not blind to the human's edits and decisions.

6. **Straight from review into a Revisor.** How hard would it be to go directly from the human review (or Review Studio) into the automated Revisor? We suspect this may already be partially a capability. Assess: is it possible? feasible? worthwhile? What would it take, and what are the risks and benefits?

7. **UI advice.** Concrete UI/UX recommendations for the review surface and the agent-assist channel -- controls, states, layout, what to show/hide -- to mockup-ready depth.

## How to report
- Type every finding: BUG / GAP / SUGGESTION / BETTER_IDEA / CONFIRMED / ARCHITECT_STOP.
- Cite section numbers (and line numbers where possible) for every claim.
- No phantom features: every contract/field/lint/fixture you propose must trace to a cited section, or be flagged OPEN_FOR_ARCHITECT_REVIEW.
- Prefer comprehensive spec-level solutions over problem identification: write the TypeScript interfaces, lint names, and algorithm sketches, not "we should think about X."
- For item 2, include a short "how others do it" section with sources.
- Close with a value-tiered summary: Critical / Substantive / Minor / Considered-and-declined.

## Where to save your output
If your tool can write to the repo, save as:
`Active Working and Red Team/DOC23 Working/DOC23 Red Teaming/Review Studio Red Team Responses/<YourModelName>_review.md`
Otherwise return it in chat and the operator will save it there.