Document Authority Hierarchy

The live reference codebase at E:/repos/arc is the single source of truth for ARC requirements. Its source code (views, API routes, data models, agent logic) defines what ARC IS. All Nexus documentation about ARC (Tier 4 specs, use case docs, pipeline definitions) must be derived from and traceable to specific files in this repository.

Conflict resolution rule: If any Nexus document (including Tier 1 ACTION_PLAN) contradicts what actually exists in the ARC repository source code, the repository is correct. Requirements that cannot cite a source file path and line range from E:/repos/arc are unverified claims, not requirements.

Evidence format: Every requirement derived from this source MUST cite: [file_path]#L[start]-L[end] (e.g. frontend/src/app/page.tsx#L45-L90). Requirements without source citations are Tier 6 quality (unverified self-reports).

What is true about the build state of this project. Section 03 of NEXUS_ACTION_PLAN.html is the explicit lie register: it documents every milestone that was falsely claimed complete. Any status marked LIE there is false regardless of what any other document says.

Conflict resolution rule: If SESSION_REVIVAL.md says a feature is complete and NEXUS_ACTION_PLAN.html section 03 says it does not exist, the ACTION_PLAN is correct. SESSION_REVIVAL.md is wrong.

NEXUS_COMPONENT_STATUS.html is the implementation status matrix. It is the only document that lists every component, its line count, test coverage, and current status (Production / Implemented / Scaffold / Declared). Read this before making any plan that involves existing capabilities — status here overrides SESSION_REVIVAL claims. A one-line description in this doc does not mean the component is simple.

P-01 through P-12 in NEXUS_DOC_POLICY.html govern all documentation and implementation decisions. No ASCII diagrams. No emojis. Accurate status pills only. Sanctioned diagram types only. Dropdown nav pattern mandatory. overflow: visible required on .site-nav-inner.

validate_doc_policy.py enforces P-11 and P-12 programmatically. Must exit 0 before any doc work is considered done.

NEXUS_PRODUCT_PLAN.html defines the four-scale canvas model (MACRO / MICRO / NANO / PICO), the component roles (ChameleonV2 = form layer, Nexus = rule engine, deltaPrism = store), and the milestone roadmap. Note: currently contains false COMPLETE pills — action item A-04 in Tier 1 mandates correction.

NEXUS_HLD.html defines the high-level design, four-scale interaction model, and component boundaries. ChameleonV2 is the production form renderer. Plain-JS demo panels are only authorised as demo simulation (Tier 4 scope) — they do not replace ChameleonV2 in the production architecture.

NEXUS_CAPABILITY_GAP_ANALYSIS.md cross-references use-case requirements against NEXUS_COMPONENT_STATUS. Read this before declaring a capability missing — it distinguishes engine-layer gaps from UI-layer gaps. NEXUS_LLD.html documents screen data flows, method signatures, database schema changes, and multi-tenancy architecture. It also contains the hardcoded-data elimination checklist (Section 13) — read before touching any SPA that uses hardcoded arrays. NEXUS_AWS_DEPLOYMENT_PLAN.html (ADP-1.0) is the authoritative specification for the AWS deployment target, the NX-S18/NX-S19/NX-S20 sprint plan, and the app-owner self-service capability model. Read before making any changes to sprint scope, AWS infrastructure decisions, or the RBAC + tenancy implementation plan.

NEXUS_DEMO_SPEC.html is the implementation spec for the Nesto autonomous demo mode. REM-01 through REM-08 define the remedy: plain HTML/CSS/JS panels inside WORMWOOD_APP.html that simulate ChameleonV2 forms for demo purposes. This is an authorised scoped exception to Tier 3 architecture — the demo is not the production form layer.

Use case docs (NEXUS_USECASE_NESTO, ENDO, ARC) define pipeline node sequences, field schemas, and integration points. These are the specification source for what the autonomous demo mode must show.

NEXUS_BACKLOG.html lists BL01–BL16 node implementations with milestone tags, priorities, and dependencies. Authoritative for what node executor work exists and what it depends on.

Status badges in NEXUS_BACKLOG.html are subject to the same accuracy rule as all docs (P-04 / Tier 2). DONE means: backend built, tested, demo-able. API ONLY means backend exists but no UI.

SESSION_REVIVAL.md is written by agents between sessions. It contains progress summaries, next actions, and milestone statuses. It is not verified. An agent that lies about completing a milestone will write that lie into SESSION_REVIVAL.md.

Read SESSION_REVIVAL.md last. Accept its status claims only where they do not contradict Tier 1. When in doubt: run the relevant test command and check the exit code. Do not accept a claimed status without evidence.

Verified conflict example: SESSION_REVIVAL.md states M-NEXUS-D1 complete and demo runner done. NEXUS_ACTION_PLAN.html section 03 states auto-demo mode NOT STARTED and interactive demo NOT STARTED, both marked LIE. Tier 1 is correct. SESSION_REVIVAL.md entry is false.