===== CONTEXT DUMP ===== ===== CANON ===== ----- 03_RULES_OF_OPERATION.md ----- # RULES OF OPERATION ## PRINCÍPIO CENTRAL O sistema NÃO depende de memória do ChatGPT. Toda execução deve ser baseada em evidência real do servidor. --- ## REGRA 1 — EVIDÊNCIA OBRIGATÓRIA Todo novo chat deve iniciar com reconstrução de contexto via dump canônico. Comando obrigatório: /home/yeff/public_html/devon/context_dump.sh Sem dump inicial = MISSING. --- ## REGRA 2 — FLUXO FIXO 1. Evidência 2. Análise 3. Patch Proibido misturar etapas. --- ## REGRA 3 — SOURCE OF TRUTH A fonte de verdade é distribuída em duas raízes obrigatórias: - /home/yeff/public_html/devon/panel/data - /home/yeff/public_html/devon/canon Regra: - panel/data = estado do sistema - canon = governança do sistema --- ## REGRA 4 — PROIBIÇÕES - confiar em memória do ChatGPT - analisar sem dump - criar patch sem dump - inventar caminhos - alterar fora do escopo --- ## REGRA 5 — PATCH - sempre backup - sempre REPLACE no ponto canônico - APPEND só com autorização explícita --- ## REGRA 6 — STATUS PASS / FAIL / MISSING --- ## REGRA 7 — CONTEXTO Contexto é reconstruído via dump canônico. Somente evidência do servidor define o estado do sistema. --- ## REGRA 8 — OBRIGATORIEDADE Esta regra é não opcional e se aplica a todos os fluxos de execução. ----- 06_DECISIONS.md ----- # DECISIONS ## D-001 Decisão: usar diretório /canon Motivo: separar runtime de governança Impacto: organização estrutural Reversível: não ## D-002 Decisão: evidence-first obrigatório Motivo: eliminar erro de contexto Impacto: consistência operacional Reversível: não ## D-003 Decisão: context_dump.sh obrigatório no início de todo novo chat Motivo: reconstruir contexto canônico a partir de evidência real do servidor Impacto: elimina dependência de memória do ChatGPT e reduz drift operacional Reversível: não ## D-004 Decisão: manter separação formal entre panel/data e canon Motivo: distinguir estado do sistema de governança do sistema Impacto: arquitetura canônica com raízes complementares e sem mistura de responsabilidades Reversível: não ----- 07_SCOPE.md ----- # SCOPE ## IN - governança operacional - canon do projeto - regras e fluxo ## OUT - runtime - UI data - logs ----- 08_NEXT_ACTION.md ----- # NEXT ACTION ## Objetivo Operar todo novo chat do projeto com reconstrução obrigatória de contexto via dump canônico. ## Próximo passo Antes de qualquer análise ou patch em novo chat, executar: /home/yeff/public_html/devon/context_dump.sh ## Critério de pronto - dump executado no início do chat - contexto colado no chat - análise feita somente após evidência - patch gerado somente após análise ===== CORE ARCHITECTURE ===== # DEVON - MASTER ARCHITECTURE INDEX ## Checkpoint 2026-04-03 — Semantic Runtime Reading Canon ### Validated closure - `build_runtime_contracts.py` already emits canonical runtime contracts with explicit semantics. - `collect_runtime.py` was refactored so `runtime_status.json` now preserves semantic fields from the registry snapshot into final published runtime rows. - The Devon collector now emits semantically typed rows including: - `row_kind` - `semantic_scope` - `counts_toward_completion` - `display_in_cards` - `display_in_donuts` - `ui_group` - `source_contract` - `status_resolution` - `rollup_source` - `stage_rollup` is now a sovereign runtime row type and its `progress_pct` is the canonical source for stage completion in the UI. - `project_progress.json` remains the sovereign source for global project completion. - `export_panel_runtime.sh` was validated as the Devon → Waresite publication bridge for: - `runtime_snapshot.json` - `runtime_status.json` - `host_runtime.json` - `docker_runtime.json` - `project_progress.json` ### Mandatory semantic runtime rule Any runtime row that feeds UI completion or operational grouping must be published by Devon with explicit semantic boundaries. Minimum required fields: - `deployment_stage` - `subcategory` - `row_kind` - `semantic_scope` - `counts_toward_completion` - `display_in_cards` - `display_in_donuts` - `ui_group` - `source_contract` ### Mandatory UI reading rule - Waresite UI must read completion only from declared semantics emitted by Devon. - Global project completion must read from `project_progress.json`. - Stage completion must read from `stage_rollup.progress_pct`. - Subcategory cards must not render percentage donuts when `completionRows == 0`. - If a runtime row is visible but not eligible for completion, the UI must render `MISSING / not eligible`, never `0%`. - No semantic mixing between rollup rows and item rows in the same completion calculation. ### Canonical closure reached on 2026-04-03 The semantic runtime bottleneck is considered closed under the following validated path: 1. Devon server changes observable state 2. `collect_runtime.py` regenerates sovereign runtime artifacts 3. `export_panel_runtime.sh` synchronizes runtime artifacts to Waresite 4. Operator Panel reads published semantics without manual donut patching for new server-side evidence ### Operational implication - The UI is now render-only relative to runtime semantics. - Newly installed or configured Devon components must appear through collector + export, not through Waresite-side workaround patches. - Future work returns to Devon server configuration and host/runtime expansion. ### Material Devon runtime-contract artifacts now validated The following files already exist materially on the Devon server and must be treated as the current runtime-contract artifacts in force: - Canonical expected-runtime manifest: `/opt/devon/canon/runtime_expected_manifest.json` - Canonical probe registry: `/opt/devon/canon/runtime_probe_registry.json` - Contract builder/compiler: `/opt/devon/bin/build_runtime_contracts.py` These artifacts are the current material base for runtime expectation + probe execution mapping. They already exist and therefore must be referenced explicitly in continuity and master before any attempt to invent parallel contract files. version: v3.0 status: ACTIVE mode: CANONICAL_ROOT role: supreme_reference ## 1. SYSTEM IDENTITY Devon is a first-party cognitive development control plane. It is designed to: - architect - validate - generate - canonize - execute - benchmark - observe - promote All operations follow: - sandbox-first execution - evidence-based validation - PASS / FAIL / MISSING rules ## 1.1 OPERATIONAL CONTEXT RULE All Devon operations MUST start with canonical context reconstruction. Mandatory command: `/home/yeff/public_html/devon/context_dump.sh` Rules: - no analysis without dump - no patch without dump - no context = MISSING - ChatGPT memory is NOT a valid source of truth - only server evidence defines system state This rule is non-optional and applies to all execution flows. ## 2. GLOBAL STATUS MODEL PASS = observable evidence exists and validation passes FAIL = observable evidence exists and validation fails MISSING = no observable evidence PLANNED = formally defined but not yet materially present No inference allowed. ## 3. SUPREME REFERENCE LAW If a file is not registered in this master index, it does not exist for Devon canonical governance. This file is the highest human-readable reference for: - canonical file existence - file role - phase ownership - authority ownership - precedence and conflict resolution - structured canon registration ## 4. CANONICAL ROOT Devon canonical structure is composed of two distinct but complementary roots: ### 4.1 DATA ROOT (UI / Runtime / Contracts) `/home/yeff/public_html/devon/panel/data/` Purpose: - UI data source - runtime artifacts - contracts and schemas - documentation hub bridge ### 4.2 GOVERNANCE ROOT (Operational Canon) `/home/yeff/public_html/devon/canon/` Purpose: - operational rules - decision registry - execution flow - project scope and boundaries - continuity and next actions Rule: - panel/data = system state - canon = system governance Both roots are mandatory and must remain strictly separated. ## 5. DOCUMENTATION MODEL Devon canonical documentation is composed of: - authority documents - satellite documents - structured canonical JSON artifacts - runtime/support JSON artifacts - panel/documentation bridge artifacts Rule: one concept = one primary authority A concept may be referenced by multiple files, but only one file may define its sovereign canonical meaning. ## 6. DOCUMENT PRECEDENCE RULE If two files mention the same concept, precedence is: 1. this master index decides registration and ownership 2. the designated authority file defines the sovereign meaning 3. structured canonical JSON defines machine-readable enforcement 4. satellite files may contextualize but may not redefine 5. runtime/support files may operationalize but may not redefine canon ## 7. CANONICAL ORGANIZATION MODEL This master index is organized by four mandatory structural axes: 1. phase 2. category 3. subcategory 4. installation / configuration order Structural rule: - `Phase` is the primary operational axis and preserves real installation / configuration sequence - `Category` is the primary documentary authority grouping inside a phase - `Subcategory` is the internal workflow / context grouping inside a category - `Bucket` and `Item` remain the implementation-detail layers inside each category workflow - `Layer` remains a macro canonical classification axis, but may not replace `Category` as the primary documentary grouping in the Documentation Hub or downstream panel structures Reading rule: - left navigation must prioritize `Phase -> Category` - center workflow must render `Subcategory -> Bucket -> Item` - canonical layers such as `Strategy Layer`, `Architecture Layer`, `Runtime Layer`, `Trust Layer`, `Memory Layer` and `Monitoring Layer` are cross-cutting classification contexts - layers may organize registration semantics, but may not flatten or replace phase/category ownership Authority grouping rule: - within a phase, categories should be bound to sovereign authority documents or explicitly bounded documentary groups - examples: - Phase 02 categories are documentary authorities such as `CAS`, `CGS`, `ACS`, `CSS`, `NCS`, `STS`, `CDMS` - Phase 03 categories are sovereign or bounded contextual documents such as `CFC`, `CCC`, `LPC`, `NRC`, `OAC` - no layer name may be used as a substitute for a documentary category when a more specific authority grouping exists materially in the master Operational dependency rule: - no layer may break deployment order - no categorization may override operational dependency - no documentary grouping may collapse a phase into a generic layer heading System flow: Strategy → Architecture → Delivery → Runtime → Trust → Memory → Monitoring Cross-layer mandatory controls: - release artifact hygiene must be defined before unrestricted promotion - distribution and packaging observability must exist before runtime evidence is treated as operationally complete - environment-specific exposure policy must exist before memory-bearing runtime is treated as trusted ## 8. LAYERED CANONICAL INDEX Interpretation rule for this section: - the `8.x` layers below are macro canonical classification layers - they are not the primary documentary category tree for DH navigation - documentary navigation and ownership must be read through the structural rule: `Phase -> Category -> Subcategory -> Bucket -> Item` - whenever a layer contains multiple registered authority documents, those authorities remain the correct category-level units for DH and downstream structural projection ### 8.1 STRATEGY LAYER Purpose: defines what is being built, why it exists, under which scope, rules and environment constraints. Installation/configuration order: this layer comes first. Phase origin: - Phase 01 - Overview & Scope Authority and registered files: #### 8.1.1 System Root and Registration Authority: - master_architecture_index.md Purpose: define the sovereign root conditions that must exist before any downstream phase, category, runtime contract, Documentation Hub rendering or Operator Panel projection can be treated as structurally valid. Why this prerequisite exists: - the project requires one supreme human-readable reference for canonical existence, role, ownership, precedence and dependency mapping - no downstream artifact may define authority without being bounded by the root registration model - no DH or Panel projection may be treated as truth if the root registration logic is ambiguous Prerequisite rule: before Devon can be expanded safely, the following prerequisite classes must be materially bounded and readable from the canonical roots. #### Prerequisite Class 01 — Canon Prerequisites Definition: these prerequisites determine whether the project is canonically governable. Required conditions: - a sovereign architectural root exists - canonical root separation is explicit - documentary precedence is explicit - one concept maps to one primary authority - structural organization is governed by `Phase -> Category -> Subcategory -> Bucket -> Item` - deployment and reading order are materially defined What exists: - `master_architecture_index.md` is the sovereign root reference - `panel/data` is the canonical state root for UI data, runtime artifacts, contracts and DH bridge artifacts - `canon` is the governance root for operational rules, decisions, scope and continuity - documentary precedence is explicitly bounded in the master - phase/category/subcategory order is explicitly bounded in the master Why it exists: - to prevent authority drift - to prevent layer-only grouping from replacing documentary ownership - to keep DH and Panel downstream projections aligned with the real canonical tree Authority artifacts: - `master_architecture_index.md` Support artifacts: - `project_scope_canonical.json` - `deployment_order_canonical.json` - `devon_continuity.md` - `03_RULES_OF_OPERATION.md` - `06_DECISIONS.md` Unlocks: - phase registration - category ownership - DH structural navigation - downstream artifact legitimacy #### Prerequisite Class 02 — Operational Prerequisites Definition: these prerequisites determine whether work on Devon is allowed to proceed under the operating law of the project. Required conditions: - every new chat starts from canonical context reconstruction - no analysis is allowed without dump - no patch is allowed without dump - no status may be inferred from memory - all validation must resolve through `PASS`, `FAIL`, `MISSING` or `PLANNED` What exists: - `/home/yeff/public_html/devon/context_dump.sh` is the mandatory operational entrypoint - the evidence-first workflow is materially defined - the allowed status model is materially defined - chat memory is explicitly rejected as a source of truth Why it exists: - to eliminate architectural drift - to block speculative patches - to force evidence-backed continuity between chats Authority artifacts: - `03_RULES_OF_OPERATION.md` - `master_architecture_index.md` Support artifacts: - `08_NEXT_ACTION.md` - `06_DECISIONS.md` - `devon_continuity.md` Unlocks: - valid diagnostics - valid patch generation - continuity-safe project evolution #### Prerequisite Class 03 — Infrastructure Prerequisites Definition: these prerequisites determine whether the Devon host baseline exists materially enough to support downstream runtime, service and publication work. Required conditions: - the host baseline must be observable - security and network boundaries must be explicitly bounded - missing infrastructure components must remain visible as `MISSING` - tooling presence must be stated materially, never assumed What exists: - Devon host baseline is observable - host operating system, kernel, architecture, CPU, memory and disk baseline are observed - security baseline is partially bounded through active firewall policy and restricted inbound exposure - Python3, Git and Curl are present What remains missing: - reverse proxy - TLS baseline - Docker - Docker Compose - Nginx Why it exists: - infrastructure maturity cannot be faked by UI or documentation progress - runtime publication and service exposure depend on real host conditions - downstream phases must inherit observable substrate, not assumed substrate Authority artifacts: - `master_architecture_index.md` Support artifacts: - `host_runtime.json` - `host_security_canonical.json` - `server_registry_canonical.json` Unlocks: - runtime deployment feasibility - service exposure hardening - trust-layer expansion - future container runtime adoption #### Prerequisite Class 04 — Publication Prerequisites Definition: these prerequisites determine whether Devon can publish machine-readable truth to Waresite safely and repeatably. Required conditions: - runtime contract artifacts must exist materially on Devon - publication must flow through a declared bridge - exported artifacts must remain contract-bounded - UI must consume published truth rather than invent runtime meaning locally What exists: - canonical expected-runtime manifest exists on Devon - canonical runtime probe registry exists on Devon - runtime contract builder/compiler exists on Devon - runtime row semantic publication is materially recognized - `export_panel_runtime.sh` is the validated Devon -> Waresite publication bridge Published artifact set: - `runtime_snapshot.json` - `runtime_status.json` - `host_runtime.json` - `docker_runtime.json` - `project_progress.json` Why it exists: - DH and Panel can only be trusted if publication is contract-backed - runtime truth must originate on Devon and be projected downstream - Waresite must remain consumer-side, not source-side, for runtime state Authority artifacts: - `master_architecture_index.md` - runtime contract base on Devon Support artifacts: - `runtime_row_semantics_canonical.json` - `project_progress_canonical.json` - `project_progress_model.json` - `panel_runtime_bridge.json` - `panel_sync_contract.json` Unlocks: - trustworthy runtime visibility - project and stage progress projection - downstream synchronization integrity #### Prerequisite Class 05 — Projection Prerequisites Definition: these prerequisites determine whether Documentation Hub and Operator Panel are allowed to project the canon without corrupting ownership or semantics. Required conditions: - DH must preserve documentary authority - left navigation must prioritize `Phase -> Category` - center workflow must render `Subcategory -> Bucket -> Item` - Panel must remain render-only relative to published runtime truth - no layer abstraction may replace category ownership - no completion metric may be shown without semantic boundary control What exists: - Documentation Hub baseline is established - Operational UI baseline is established - DH and Panel projection already depend on canonical JSON and runtime artifacts - semantic runtime reading rules are materially defined Why it exists: - projection layers must expose canon, not redefine it - visual completion without semantic control produces false maturity - downstream consumers must remain structurally subordinate to the canonical roots Authority artifacts: - `master_architecture_index.md` Support artifacts: - `hub_index.json` - `panel_manifest.json` - `panel_canonical_tree.json` - `panel_content_index.json` - `panel_navigation_spec.json` - `panel_component_contract.json` - `panel_data_contract.json` - `panel_ui_blueprint.json` - `panel_runtime_bridge.json` Unlocks: - structurally correct DH rendering - semantically safe Panel completion logic - stable downstream documentation and operational projection #### Program-wide prerequisite reading rule These prerequisite classes are cumulative. Interpretation: - no later phase may be treated as mature if upstream prerequisite classes remain unresolved - no UI completion may conceal unresolved prerequisites - open prerequisites must remain explicitly visible where material evidence is still absent - prerequisite maturity must be read as a program-wide dependency system, not as isolated checklists Program-wide open prerequisites currently visible in evidence: - reverse proxy - TLS baseline - Docker - Docker Compose - Nginx - full SSE bridge maturity - full runtime publication maturity across all downstream views Exit condition for this prerequisite block: this block is considered structurally complete only when it can answer, for each major project dependency group: - what exists - why it exists - where it enters the phase model - who governs it - what supports it - what it depends on - what it unlocks next - how DH and Panel must project it downstream #### 8.1.2 Project Scope Authority: - project_scope_canonical.json Supporting context: - devon_panel_chat_checkpoint.md #### 8.1.3 Deployment Order Authority: - deployment_order_canonical.json #### 8.1.4 Sandbox Environment Authority: - sandbox_environment_canonical.json #### 8.1.5 Server Registry Authority: - server_registry_canonical.json --- ### 8.2 ARCHITECTURE LAYER Purpose: defines the software structure, domains, contracts, state legitimacy, naming, governance and system topology. Installation/configuration order: this layer is defined after strategy and before execution. Phase origin: - Phase 02 - Architecture & Engineering Canon - Phase 03 - Cognitive Flow Canon Authority and registered files: #### 8.2.1 Cognitive Architecture Authority: - cas.md Satellite references allowed in: - cfc.md - ris.md - ccc.md #### 8.2.2 Governance Model Authority: - cgs.md #### 8.2.3 Artifact Canon and Structure Authority: - acs.md #### 8.2.4 Contracts and Schemas Authority: - css.md Structured support: - card_contract_minimums.json - panel_data_contract.json - panel_component_contract.json - panel_sync_contract.json #### 8.2.5 Naming Authority: - ncs.md #### 8.2.6 State Legitimacy and Transitions Authority: - sts.md Satellite references allowed in: - cfc.md - ofc.md #### 8.2.7 Deployment Structure Authority: - cdms.md #### 8.2.8 Deterministic Orchestration and Cognitive Flow Authority: - cfc.md Satellite references allowed in: - cas.md - ris.md - ofc.md - lpc.md #### 8.2.9 Role Interaction Context Authority: - ris.md Rule: RIS is contextual and may not redefine sovereign authority. #### 8.2.10 Operational Flow Mapping Authority: - ofms.md Rule: OFMS is contextual and may not redefine canonical flow. #### 8.2.11 Panel Canonical Tree Authority: - panel_canonical_tree.json #### 8.2.12 Panel Navigation Authority: - panel_navigation_spec.json #### 8.2.13 Panel UI Blueprint Authority: - panel_ui_blueprint.json #### 8.2.14 Canonical Matrix Authority: - canonical_matrix_v1.json --- ### 8.3 DELIVERY LAYER Purpose: defines build progression, release logic, operational flows, canonization and project execution mapping. Installation/configuration order: this layer starts after architecture is materially defined. Phase origin: - Phase 09 - Operational Flows Canon - build/release references from Phase 02 Authority and registered files: #### 8.3.1 Build, Release and Promotion Authority: - brps.md #### 8.3.2 Release Artifact Hygiene and Supply-Chain Evidence Authority: - brps.md Structured enforcement: - delivery_security_canonical.json - subcategory_pipelines.json Canonical scope: - sourcemap blocking in production artifacts - debug artifact exclusion from production delivery - packaging audit before promotion - SBOM generation and traceability for releaseable artifacts Rule: delivery promotion is not canonically safe if release artifacts expose debug-sensitive material or lack auditable packaging evidence. #### 8.3.3 Operational Flows Canon Authority: - ofc.md #### 8.3.4 Subcategory Pipelines Authority: - subcategory_pipelines.json #### 8.3.5 Panel Content Index Authority: - panel_content_index.json #### 8.3.6 Panel Manifest Authority: - panel_manifest.json --- ### 8.4 RUNTIME LAYER Purpose: defines live system state, runtime bridge, containers, observability and operational support artifacts. Installation/configuration order: this layer becomes valid only after delivery/configuration begins materializing runtime. Phase origin: - Phase 04 - Containerization Canon - Phase 05 - Latency & Performance Canon - Phase 06 - Noise Reduction Canon - Phase 07 - Observability & Audit Canon Authority and registered files: #### 8.4.1 Container Topology and Isolation Authority: - cdms.md Rule: cdms.md is the sovereign authority for Phase 04 containerization, deployment topology and isolation boundaries. ccc.md remains a Phase 03 contextual component reference and may not redefine containerization authority. #### 8.4.2 Latency and Performance Authority: - lpc.md #### 8.4.3 Noise Reduction Authority: - nrc.md #### 8.4.4 Observability and Audit Authority: - oac.md #### 8.4.5 Distribution and Packaging Observability Authority: - oac.md Support artifacts: - panel_runtime_bridge.json - runtime_status.json - host_runtime.json - docker_runtime.json Canonical scope: - distribution failure visibility - packaging anomaly visibility - promotion-to-runtime traceability - runtime-visible evidence of what artifact was actually delivered Rule: runtime observability is incomplete if Devon can observe execution failure but cannot expose distribution or packaging failure. #### 8.4.6 Panel Runtime Bridge Authority: - panel_runtime_bridge.json #### 8.4.7 Runtime Status and Host/Docker Runtime Records Registered support artifacts: - runtime_status.json - host_runtime.json - docker_runtime.json Rule: These are runtime/support records and do not override canonical authority. --- ### 8.5 TRUST LAYER Purpose: defines security governance, approval control, protection boundaries and enforcement priority. Installation/configuration order: trust rules govern all layers, but are materially formalized before unrestricted runtime operation. Phase origin: - Phase 08 - Security Canon Authority and registered files: #### 8.5.1 Security Governance Authority: - sec.md Structured implementation authorities: - host_security_canonical.json - app_security_canonical.json - module_security_canonical.json - runtime_security_canonical.json - delivery_security_canonical.json - approval_canonization_policy.json - memory_isolation_canonical.json - security_monitoring_canonical.json Canonical scope: - policy for memory exposure by environment - policy for data exposure by environment - separation between operator-facing, runtime-facing and debug-facing visibility - prohibition of unrestricted cross-environment exposure - protection against runtime-sensitive artifact exposure outside declared trust boundaries Rule: no environment may expose memory, payload, secrets, debug output or runtime-sensitive artifacts outside its declared boundary. --- ### 8.6 MEMORY LAYER Purpose: defines historical cognition, memory boundaries, learning governance, planning and knowledge continuity. Installation/configuration order: memory becomes operational after trust boundaries and architecture rules are defined. Phase origin: - Phase 08 - Security Canon (trust-bound activation point) - post-core canonical expansion registered in this master index Rule: memory-layer authorities become canonically activatable only after trust boundaries are defined. Operationally, their trust-bound phase origin is Phase 08. Authority and registered files: #### 8.6.1 Memory Architecture Authority: - memory_canonical_architecture.json #### 8.6.2 Memory Isolation and Partitioning Authority: - memory_isolation_canonical.json Narrative governance: - sec.md Flow enforcement reference: - cfc.md #### 8.6.3 Memory Lifecycle and Consolidation Authority: - memory_lifecycle_canonical.json #### 8.6.4 Learning Governance Authority: - learning_governance_canonical.json #### 8.6.5 Planning and Reasoning Authority: - planning_reasoning_canonical.json #### 8.6.6 Tool Execution and Permission Model Authority: - tool_execution_canonical.json #### 8.6.7 Knowledge Ingestion and Indexing Authority: - knowledge_ingestion_canonical.json --- ### 8.7 MONITORING LAYER Purpose: defines real-time operational monitoring of the Devon host, containers and services. Monitoring is a first-class operational layer and feeds the Operator Panel monitoring section. Installation/configuration order: this layer becomes active after core_runtime is operational. It must be installed before SSE bridge is activated. Phase origin: - Phase 10 - Monitoring & Real-time Observability Authority and registered files: #### 8.7.1 Monitoring Authority Authority: - monitoring_canonical.json Canonical scope: - CPU, memory, disk, network and uptime monitoring - Docker container health per container with CPU, memory and restart count - Nginx, UFW, Fail2ban service status - Process count and file descriptor monitoring - Latency monitoring for API and network paths - Alert thresholds per metric - Refresh intervals per target Rule: Devon has no GPU. CPU is the primary compute resource. CPU monitoring is mandatory and must be continuous. #### 8.7.2 SSE Bridge Authority: - sse_bridge_canonical.json Canonical scope: - Defines the SSE permanent channel that replaces export_panel_runtime.sh - Devon emits SSE events on /monitoring/stream - Waresite Operator Panel consumes via EventSource - Fallback to 5-second polling if SSE disconnects - Migration gate: SSE only replaces push_snapshot after monitoring is fully operational ## 9. PHASE REGISTRY This registry is preserved as the operational installation and configuration sequence reference. ### Phase 01 - Overview & Scope #### Phase 01 Process-Spec Purpose: canonize the sovereign overview and scope baseline that defines Devon identity, project framing, canonical source of truth and continuity reference before downstream architecture, runtime and monitoring layers. ##### P01-01 Master Architecture Index - authority_owner: master_architecture_index.md - canonical_role: sovereign root architecture index - why_this_item_exists: define the full canonical architecture map, document hierarchy, phase structure, category structure, subcategory workflow model and completeness rules before any downstream canon is interpreted - required_before: - all downstream phase materialization - Documentation Hub structural rendering - Operator Panel canonical alignment - hard_dependencies: - project_scope_canonical.json - feeds_operational_ui: - left navigation - center workflow - dependency mapping - evidence contracts - phase registry view ###### Subcategory: Prerequisites **Bucket: Canonical root registration** - Item: register `master_architecture_index.md` as sovereign source in the canonical root - Item: confirm the file is located under `/panel/data` - Item: confirm downstream documents reference the master without redefining its authority ###### Subcategory: Installation **Bucket: Source-of-truth exposure** - Item: expose `master_architecture_index.md` to Documentation Hub - Item: expose master references to DH relation mapping - Item: make the master selectable as a category-level authority artifact ###### Subcategory: Configuration **Bucket: Structural definition** - Item: define macro phase hierarchy - Item: define category ownership inside each phase - Item: define canonical navigation hierarchy as `Phase -> Category -> Subcategory -> Bucket -> Item` - Item: define rendering contract as `left navigation = Phase -> Category` and `center workflow = Subcategory -> Bucket -> Item` ###### Subcategory: Validation **Bucket: Hierarchy integrity** - Item: verify the master explicitly defines `Phase` - Item: verify the master explicitly defines `Category` - Item: verify the master explicitly defines `Subcategory` - Item: verify the master explicitly defines `Bucket` - Item: verify the master explicitly defines `Item` **Bucket: Alignment integrity** - Item: verify `Master Architecture Index` is treated as a category, not as the phase itself - Item: verify subcategories are declared as internal category workflow layers - Item: verify left navigation rules do not promote subcategories to primary navigation ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `/panel/data/master_architecture_index.md` exists - Item: Documentation Hub renders `Master Architecture Index` under `Overview & Scope` - Item: hierarchy and rendering contract are readable from the master - Item: downstream categories reference the master as the sovereign structural authority ###### Subcategory: Failure Modes & Recovery **Bucket: Canonical failure modes** - Item: missing master file - Item: phase/category hierarchy undefined - Item: subcategories omitted from category workflow - Item: DH rendering hierarchy diverges from master contract - Item: a category is treated as equivalent to a phase **Bucket: Recovery actions** - Item: restore the sovereign hierarchy in the master - Item: rebind categories to the correct phase - Item: rematerialize category internals as `Subcategory -> Bucket -> Item` - Item: revalidate DH against the master before touching the Panel ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: `Master Architecture Index` is materially registered as the sovereign category authority under `Overview & Scope` - Item: hierarchy `Phase -> Category -> Subcategory -> Bucket -> Item` is explicit and readable - Item: DH can mirror the category center workflow without inventing structure - Item: downstream phase/category materialization can proceed using the master as structural source of truth ##### P01-02 Project Scope Canonical - authority_owner: project_scope_canonical.json - canonical_role: project scope authority - why_this_item_exists: define mission, scope boundaries, principles and explicit project framing that constrain every downstream architectural and operational decision - required_before: - architecture canon expansion - runtime implementation - UI projection - hard_dependencies: - master_architecture_index.md - feeds_operational_ui: - scope cards - project framing - dependency context - evidence mapping ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `project_scope_canonical.json` in the canonical root - Item: bind the file to `Phase 01` - Item: confirm scope authority is referenced by the master ###### Subcategory: Installation **Bucket: Scope exposure** - Item: expose `project_scope_canonical.json` to Documentation Hub - Item: expose project scope references to relation mapping - Item: make scope authority available for downstream cross-document validation ###### Subcategory: Configuration **Bucket: Scope definition** - Item: define mission - Item: define non-negotiable principles - Item: define scope boundaries - Item: define file index expectations - Item: define what downstream systems may not override ###### Subcategory: Validation **Bucket: Scope integrity** - Item: verify file exists in `/panel/data` - Item: verify file is registered in the master - Item: verify scope constraints are readable and unambiguous - Item: verify downstream artifacts do not violate declared project scope ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `/panel/data/project_scope_canonical.json` exists - Item: Documentation Hub renders `Project Scope Canonical` under `Overview & Scope` - Item: DH relation mapping shows scope authority linked to the master ###### Subcategory: Failure Modes & Recovery **Bucket: Scope failure modes** - Item: missing scope file - Item: undefined mission - Item: scope boundaries omitted - Item: downstream artifact contradicts declared scope **Bucket: Recovery actions** - Item: restore the project scope file - Item: rematerialize mission, principles and scope boundaries - Item: rebind scope authority to `Phase 01` - Item: revalidate DH against declared scope constraints ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: `Project Scope Canonical` is materially registered, readable and bound to `Phase 01` - Item: scope constraints are explicit enough to govern downstream architecture - Item: DH can render scope context without inference ##### P01-03 Devon Panel Chat Checkpoint - authority_owner: devon_panel_chat_checkpoint.md - canonical_role: supporting continuity context - why_this_item_exists: preserve operational continuity, checkpoint memory and handoff context without redefining sovereign architecture or scope meaning - required_before: - continuity recovery - context restoration after interrupted work - hard_dependencies: - master_architecture_index.md - project_scope_canonical.json - feeds_operational_ui: - continuity links - checkpoint context - restoration support ###### Subcategory: Prerequisites **Bucket: Context binding** - Item: register `devon_panel_chat_checkpoint.md` as supporting context, not sovereign authority - Item: bind the file to `Phase 01` - Item: confirm it does not override the master or project scope ###### Subcategory: Installation **Bucket: Continuity exposure** - Item: expose checkpoint context to Documentation Hub as supporting material - Item: maintain traceability from DH to checkpoint context - Item: preserve checkpoint discoverability for interrupted execution recovery ###### Subcategory: Configuration **Bucket: Context boundaries** - Item: define checkpoint as continuity aid - Item: define checkpoint as non-sovereign - Item: define allowed use as restoration and handoff support only ###### Subcategory: Validation **Bucket: Continuity integrity** - Item: verify file exists in `/panel/data` - Item: verify file is referenced as supporting context - Item: verify no checkpoint content overrides sovereign canon ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `/panel/data/devon_panel_chat_checkpoint.md` exists - Item: DH exposes continuity/checkpoint context under `Overview & Scope` - Item: checkpoint remains linked as support, not authority ###### Subcategory: Failure Modes & Recovery **Bucket: Continuity failure modes** - Item: missing checkpoint file - Item: checkpoint treated as sovereign authority - Item: continuity unavailable after interruption **Bucket: Recovery actions** - Item: restore checkpoint file - Item: rebind checkpoint as supporting context only - Item: revalidate authority boundaries against the master ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: checkpoint context is available as supporting continuity layer - Item: authority boundaries remain intact - Item: Phase 01 overview package is complete enough to support downstream canon handoff ### Phase 02 - Architecture & Engineering Canon Authority files: - cas.md - cgs.md - acs.md - css.md - ncs.md - sts.md - brps.md - cdms.md Satellite files: - ris.md - ofms.md #### Phase 02 Process-Spec Purpose: canonize the architecture and engineering foundation that governs structure, contracts, naming, state legitimacy, deployment structure and contextual boundaries. ##### Category: CAS · Cognitive Architecture Spec - authority_owner: cas.md - canonical_role: sovereign architecture definition - why_this_item_exists: define the cognitive architecture baseline before downstream orchestration, runtime and monitoring exist - required_before: - cfc.md - ofms.md - operator/runtime implementation - hard_dependencies: - master_architecture_index.md - project_scope_canonical.json - feeds_operational_ui: - category cards - evidence drawer - dependency drawer - phase registry view ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `cas.md` in the canonical root - Item: bind the file to `Phase 02` - Item: confirm the category is treated as documentary authority, not as a generic layer heading ###### Subcategory: Installation **Bucket: DH exposure** - Item: expose `cas.md` to the Documentation Hub - Item: make `CAS` discoverable under `Architecture & Engineering Canon` - Item: preserve category binding at the documentary-authority level ###### Subcategory: Configuration **Bucket: Architecture definition** - Item: define architecture scope - Item: define core domains and structural boundaries - Item: define sovereignty versus allowed satellite references ###### Subcategory: Validation **Bucket: Category integrity** - Item: verify file exists in `/panel/data` - Item: verify file is registered in the master - Item: verify category binding is correct - Item: verify DH loads the file without error ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `/panel/data/cas.md` exists - Item: DH renders `CAS` under `Architecture & Engineering Canon` ###### Subcategory: Failure Modes & Recovery **Bucket: Architecture failure modes** - Item: missing file - Item: wrong phase binding - Item: satellite redefining sovereign meaning **Bucket: Recovery actions** - Item: restore `cas.md` - Item: rebind `CAS` to `Phase 02` - Item: revalidate sovereign versus satellite boundaries ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: `CAS` is registered, readable, categorized and treated as sovereign authority ##### Category: CGS · Governance Model - authority_owner: cgs.md - canonical_role: governance authority - why_this_item_exists: define governance rules for architecture, engineering and canonical control - required_before: - structured contracts - runtime enforcement - hard_dependencies: - cas.md - master_architecture_index.md - feeds_operational_ui: - contract drawer - dependency drawer - evidence drawer ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `cgs.md` in the canonical root - Item: bind the file to `Phase 02` - Item: confirm governance authority is bounded to documentary category ownership ###### Subcategory: Installation **Bucket: Governance exposure** - Item: expose governance authority in DH - Item: preserve discoverability of governance role in relation mapping - Item: keep governance as category-level authority ###### Subcategory: Configuration **Bucket: Governance scope** - Item: define governance scope - Item: define rule ownership - Item: define what satellites may not override ###### Subcategory: Validation **Bucket: Governance integrity** - Item: verify file exists - Item: verify file is registered - Item: verify file is mapped to `Phase 02` ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `/panel/data/cgs.md` exists - Item: DH relation map shows governance role ###### Subcategory: Failure Modes & Recovery **Bucket: Governance failure modes** - Item: governance file missing - Item: duplicated authority - Item: governance scope undefined **Bucket: Recovery actions** - Item: restore `cgs.md` - Item: rebind governance authority to `Phase 02` - Item: revalidate governance scope boundaries ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: governance authority is materialized and bound to `Phase 02` ##### Category: ACS · Artifact Canon and Structure - authority_owner: acs.md - canonical_role: artifact structure authority - why_this_item_exists: define how canonical artifacts are shaped, separated and registered - required_before: - structured json artifacts - DH/UI artifact mapping - hard_dependencies: - cgs.md - master_architecture_index.md - feeds_operational_ui: - artifact view - contract view - validation timeline ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `acs.md` - Item: bind artifact structure to `Phase 02` - Item: preserve `ACS` as category-level authority ###### Subcategory: Configuration **Bucket: Artifact structure** - Item: define artifact classes - Item: define authority versus satellite separation - Item: define structural expectations ###### Subcategory: Validation **Bucket: Structural integrity** - Item: verify file exists - Item: verify file is registered - Item: verify structure rules are referenced by dependent artifacts ###### Subcategory: Observable Evidence **Bucket: Observable files and coherence** - Item: `/panel/data/acs.md` exists - Item: dependent docs and jsons remain structurally coherent ###### Subcategory: Failure Modes & Recovery **Bucket: Structure failure modes** - Item: structure undefined - Item: mixed authority boundaries - Item: artifact overlap **Bucket: Recovery actions** - Item: restore `acs.md` - Item: rebind structure authority to `Phase 02` - Item: revalidate dependent artifact coherence ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: artifact structure is explicit and enforceable ##### Category: CSS · Contracts and Schemas - authority_owner: css.md - canonical_role: contracts and schemas authority - why_this_item_exists: define machine-readable interfaces and operational schema boundaries - required_before: - panel_data_contract.json - panel_component_contract.json - panel_sync_contract.json - card_contract_minimums.json - hard_dependencies: - acs.md - cgs.md - feeds_operational_ui: - contract drawer - card shell rendering - evidence rules - status resolution ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `css.md` - Item: register declared contract JSON artifacts - Item: bind the contract authority package to `Phase 02` ###### Subcategory: Configuration **Bucket: Schema definition** - Item: define required fields - Item: define join rules - Item: define status/data resolution rules ###### Subcategory: Validation **Bucket: Contract integrity** - Item: verify all declared contract artifacts exist - Item: verify each contract artifact loads correctly - Item: verify no fake status derivation rule is preserved ###### Subcategory: Observable Evidence **Bucket: Observable files and rendering** - Item: `css.md` exists - Item: contract JSON files exist and load - Item: DH exposes them under the correct category ###### Subcategory: Failure Modes & Recovery **Bucket: Contract failure modes** - Item: missing contract artifact - Item: incomplete schema - Item: conflicting field authority **Bucket: Recovery actions** - Item: restore missing contract artifact - Item: rematerialize incomplete schema fields - Item: revalidate contract authority boundaries ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: contract layer is materialized and readable end to end ##### Category: NCS + STS · Naming and State Legitimacy - authority_owner: - ncs.md - sts.md - canonical_role: naming authority plus state legitimacy authority - why_this_item_exists: prevent naming drift and invalid state transitions during implementation - required_before: - runtime status handling - operator counters - dependency logic - hard_dependencies: - css.md - cgs.md - feeds_operational_ui: - status badges - state rendering - evidence/status reconciliation ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `ncs.md` and `sts.md` - Item: bind both files to `Phase 02` - Item: preserve the paired authority boundary between naming and state legitimacy ###### Subcategory: Configuration **Bucket: Naming and state rules** - Item: define naming patterns - Item: define legal states - Item: define forbidden transitions ###### Subcategory: Validation **Bucket: Legitimacy integrity** - Item: verify both files exist - Item: verify naming is referenced consistently - Item: verify state legitimacy is not contradicted downstream ###### Subcategory: Observable Evidence **Bucket: Observable files** - Item: `/panel/data/ncs.md` exists - Item: `/panel/data/sts.md` exists ###### Subcategory: Failure Modes & Recovery **Bucket: Naming/state failure modes** - Item: naming drift - Item: invalid state labels - Item: impossible transitions in runtime/UI **Bucket: Recovery actions** - Item: restore `ncs.md` and `sts.md` - Item: rebind both authorities to `Phase 02` - Item: revalidate downstream state usage ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: naming and state legitimacy are explicit and reusable ##### Category: CDMS + RIS + OFMS + BRPS · Deployment Structure and Contextual Boundaries - authority_owner: - cdms.md - ris.md - ofms.md - brps.md - canonical_role: deployment structure plus contextual boundary support - why_this_item_exists: bind architecture to deployment structure, delivery promotion and role/context references without allowing contextual files to redefine sovereign canon - required_before: - delivery layer - runtime materialization - hard_dependencies: - cas.md - cgs.md - acs.md - css.md - feeds_operational_ui: - dependency drawer - timeline drawer - promotion/timeline views ###### Subcategory: Prerequisites **Bucket: Canonical registration** - Item: register `cdms.md`, `ris.md`, `ofms.md` and `brps.md` - Item: bind all files to `Phase 02` - Item: preserve sovereign versus contextual boundaries ###### Subcategory: Installation **Bucket: DH dependency exposure** - Item: expose dependencies in DH - Item: preserve relation mapping for deployment and contextual references - Item: keep documentary grouping bounded within `Phase 02` ###### Subcategory: Configuration **Bucket: Deployment and context definition** - Item: define deployment model - Item: define contextual interaction boundaries - Item: define operational flow mapping references - Item: define build/release/promotion references ###### Subcategory: Validation **Bucket: Boundary integrity** - Item: verify all support files exist - Item: verify no contextual file overrides sovereign authority - Item: verify dependencies are declared ###### Subcategory: Observable Evidence **Bucket: Observable files and relations** - Item: files exist in `/panel/data` - Item: DH relation map shows their role and dependencies ###### Subcategory: Failure Modes & Recovery **Bucket: Boundary failure modes** - Item: contextual override - Item: undeclared dependency - Item: deployment structure ambiguity **Bucket: Recovery actions** - Item: restore missing support file - Item: rebind contextual references without granting sovereign override - Item: revalidate deployment structure boundaries ###### Subcategory: Completion & Promotion **Bucket: Done-when gates** - Item: deployment structure and contextual support are explicitly registered and bounded ##### Phase 02 Category Completion ###### Subcategory: Failure Modes & Recovery **Bucket: Not-done conditions** - Item: any authority file is missing - Item: any required contract artifact is missing - Item: phase binding is absent - Item: sovereign versus satellite separation is ambiguous - Item: DH cannot load the registered source ###### Subcategory: Completion & Promotion **Bucket: Canonization gate** - Item: `Phase 02` is canonized only when all Phase 02 categories satisfy done-when gates and expose observable evidence **Bucket: Promotion gate** - Item: downstream runtime, trust and memory layers may not be treated as canonically safe until `Phase 02` is materially valid ### Phase 03 - Cognitive Flow Canon Authority file: - cfc.md #### Phase 03 Process-Spec Purpose: canonize deterministic orchestration, cognitive flow routing, execution sequence, context handling and operational flow references before runtime implementation is treated as valid. Mandatory implementation items: ##### P03-01 Deterministic Orchestration and Cognitive Flow - authority_owner: cfc.md - canonical_role: sovereign cognitive flow authority - why_this_item_exists: define how interpretation, orchestration and deterministic execution are sequenced without allowing probabilistic components to control the system - required_before: - runtime layer materialization - observability logic - tool execution and planning integration - hard_dependencies: - cas.md - cgs.md - sts.md - master_architecture_index.md - install_steps: 1. register cfc.md in the canonical root 2. bind the file to Phase 03 and architecture layer 3. expose the file in the Documentation Hub under Cognitive Flow Canon - config_steps: 1. define orchestration stages 2. define deterministic control boundaries 3. define allowed interaction with interpretation layers 4. define downstream runtime implications - validation_gates: - file exists in /panel/data - file is registered in the master - file is mapped to Phase 03 - DH loads the file without error - observable_evidence: - /panel/data/cfc.md exists - DH renders CFC under Cognitive Flow Canon - failure_modes: - missing file - orchestration undefined - probabilistic layer overriding deterministic flow - done_when: - CFC is registered, readable and treated as sovereign authority for cognitive flow - feeds_operational_ui: - category cards - contract drawer - dependency drawer - phase registry view ##### P03-02 Cognitive Component Context - authority_owner: ccc.md - canonical_role: contextual component reference - why_this_item_exists: describe cognitive components and contextual relationships used by the flow authority without redefining sovereign flow - required_before: - downstream runtime mapping - operator flow visualization - hard_dependencies: - cfc.md - cas.md - install_steps: 1. register ccc.md 2. bind the file to Phase 03 3. expose the file in DH as contextual support - config_steps: 1. define component roles 2. define contextual relationship boundaries 3. preserve sovereign authority ownership in cfc.md - validation_gates: - file exists - file is registered - file is presented as contextual, not sovereign - observable_evidence: - /panel/data/ccc.md exists - DH relation map shows contextual role - failure_modes: - contextual file missing - contextual file redefining sovereign flow - component role ambiguity - done_when: - contextual component reference is registered and bounded by CFC sovereignty - feeds_operational_ui: - relation map - dependency drawer - artifact view ##### P03-03 Latency and Performance Context - authority_owner: lpc.md - canonical_role: latency/performance contextual reference - why_this_item_exists: define performance-sensitive flow expectations that must be respected before runtime optimization phases are implemented - required_before: - latency monitoring - noise reduction - runtime optimization cards - hard_dependencies: - cfc.md - cas.md - cdms.md - install_steps: 1. register lpc.md 2. bind the file to Phase 03 3. expose latency/performance context in DH - config_steps: 1. define latency-sensitive path segments 2. define expected performance boundaries 3. define what later runtime phases must preserve - validation_gates: - file exists - file is registered - DH loads the file correctly - observable_evidence: - /panel/data/lpc.md exists - DH shows latency/performance context under Phase 03 - failure_modes: - performance context absent - runtime optimization later contradicting flow expectations - latency path ambiguity - done_when: - latency/performance context is explicitly registered and traceable to Phase 03 - feeds_operational_ui: - dependency drawer - timeline drawer - performance-related views downstream ##### P03-04 Noise and Runtime Context References - authority_owner: - nrc.md - oac.md - canonical_role: contextual runtime/noise references - why_this_item_exists: preserve upstream cognitive flow constraints when runtime noise and observability concerns are later materialized - required_before: - Phase 06 - Noise Reduction Canon - Phase 07 - Observability & Audit Canon - hard_dependencies: - cfc.md - lpc.md - ofms.md - install_steps: 1. register nrc.md and oac.md 2. bind both files to Phase 03 as contextual references 3. expose dependencies in DH - config_steps: 1. define noise-sensitive execution boundaries 2. define observability-sensitive checkpoints 3. preserve contextual status only - validation_gates: - both files exist - both files are registered - neither file overrides sovereign authority - observable_evidence: - /panel/data/nrc.md exists - /panel/data/oac.md exists - DH shows both as contextual references - failure_modes: - missing runtime-context files - contextual override - observability path undefined - done_when: - runtime/noise context references are registered and bounded - feeds_operational_ui: - dependency drawer - timeline drawer - observability-related downstream views ##### Phase 03 Category Completion - not_done_when: - cfc.md is missing - contextual support files are missing where declared - sovereign versus contextual separation is ambiguous - DH cannot load the registered source - deterministic flow boundaries remain undefined - canonization_gate: - Phase 03 is canonized only when sovereign flow authority and all declared contextual references satisfy done_when and expose observable evidence - promotion_gate: - downstream containerization, runtime optimization, observability and tool execution monitoring may not be treated as canonically safe until Phase 03 is materially valid ### Phase 04 - Containerization Canon Authority file: - cdms.md #### Phase 04 Process-Spec Purpose: canonize containerization, service isolation, networking, persistent state mounting and deployment topology so runtime execution starts from an explicit and monitorable infrastructure baseline. Mandatory implementation items: ##### P04-01 Container Topology Definition - authority_owner: cdms.md - canonical_role: deployment structure authority for container topology - why_this_item_exists: define which services must exist, how they are isolated and how they compose the canonical runtime baseline - required_before: - docker compose materialization - runtime status collection - observability wiring - hard_dependencies: - cas.md - cgs.md - acs.md - cfc.md - server_registry_canonical.json - install_steps: 1. register container topology authority under Phase 04 2. bind topology definition to architecture and runtime preparation 3. expose the file in the Documentation Hub - config_steps: 1. define required services 2. define service roles 3. define isolation boundaries 4. define which services are mandatory versus contextual - validation_gates: - topology authority exists - topology is registered in master - topology is mapped to Phase 04 - DH loads the source without error - observable_evidence: - deployment structure file exists in /panel/data - DH renders containerization references under Phase 04 - failure_modes: - topology undefined - missing service role definition - isolation boundary ambiguity - done_when: - container topology is explicit, registered and readable as canonical authority - feeds_operational_ui: - category cards - dependency drawer - contract drawer - phase registry view ##### P04-02 Service Networking and Reverse Proxy Boundaries - authority_owner: cdms.md - canonical_role: network and routing boundary authority - why_this_item_exists: define service communication paths, ingress/egress rules and reverse proxy expectations before runtime traffic exists - required_before: - exposed endpoints - runtime bridge - host/docker telemetry - hard_dependencies: - P04-01 Container Topology Definition - server_registry_canonical.json - sandbox_environment_canonical.json - install_steps: 1. bind network/routing expectations to Phase 04 2. register reverse proxy and networking references 3. expose them in DH - config_steps: 1. define internal networks 2. define ingress path 3. define reverse proxy scope 4. define allowed service-to-service communication - validation_gates: - network scope is documented - reverse proxy boundary is documented - service communication path is explicit - observable_evidence: - deployment/network references exist in canonical docs - DH shows network-related dependencies under Phase 04 - failure_modes: - routing ambiguity - unbounded service communication - reverse proxy undefined - done_when: - networking and routing boundaries are explicit and traceable - feeds_operational_ui: - dependency drawer - evidence drawer - server scope drawer ##### P04-03 Volumes, Persistent State and Artifact Storage - authority_owner: - cdms.md - acs.md - canonical_role: state persistence and artifact storage authority - why_this_item_exists: define what must persist across runs and where structured state, cache, vectors and artifacts are allowed to live - required_before: - runtime snapshots - memory lifecycle downstream - artifact generation and storage - hard_dependencies: - Artifact Canon and Structure - server_registry_canonical.json - sandbox_environment_canonical.json - install_steps: 1. register persistent-state expectations in Phase 04 2. bind volumes and storage classes to deployment structure 3. expose storage/state references in DH - config_steps: 1. define structured state locations 2. define cache locations 3. define vector/state locations 4. define artifact storage locations - validation_gates: - persistence rules are documented - storage classes are separated - storage paths remain consistent with canon - observable_evidence: - Phase 04 docs reference storage/state classes - DH relation map shows storage/state relevance - failure_modes: - state mixed without boundary - artifact storage undefined - persistence scope ambiguous - done_when: - persistent state and artifact storage rules are explicit and enforceable - feeds_operational_ui: - artifact view - evidence drawer - dependency drawer - memory/server scope downstream ##### P04-04 Runtime Bootstrap Readiness - authority_owner: - panel_runtime_bridge.json - host_runtime.json - docker_runtime.json - runtime_status.json - canonical_role: observable runtime bootstrap readiness reference - why_this_item_exists: connect containerization canon to observable runtime evidence without allowing runtime artifacts to redefine sovereign canon - required_before: - runtime layer monitoring - Operator Panel telemetry - host/docker/pipeline runtime views - hard_dependencies: - P04-01 Container Topology Definition - panel_data_contract.json - panel_sync_contract.json - panel_runtime_bridge.json - install_steps: 1. register runtime bridge/support artifacts in the master 2. bind them to Phase 04/Runtime preparation 3. expose them in DH as observable support, not sovereign canon - config_steps: 1. define bridge relationship between canon and runtime snapshots 2. define expected runtime entities 3. define monitoring source paths - validation_gates: - runtime bridge artifact exists - support runtime json artifacts exist - panel can read them as support evidence - no runtime artifact overrides sovereign canon - observable_evidence: - /panel/data/panel_runtime_bridge.json exists - /panel/data/host_runtime.json exists - /panel/data/docker_runtime.json exists - /panel/data/runtime_status.json exists - failure_modes: - missing runtime bridge - runtime support file missing - support artifact treated as sovereign canon - done_when: - runtime bootstrap evidence is wired and clearly bounded as support state - feeds_operational_ui: - host runtime view - docker runtime view - pipeline runtime view - evidence drawer - timeline drawer ##### Phase 04 Category Completion - not_done_when: - topology authority is missing - network/routing boundaries are undefined - persistence/state rules are undefined - runtime bridge/support artifacts are missing where declared - runtime support is being used to redefine canon - canonization_gate: - Phase 04 is canonized only when topology, networking, persistence and runtime-bootstrap references satisfy done_when and expose observable evidence - promotion_gate: - latency, noise reduction, observability and security monitoring may not be treated as canonically reliable until Phase 04 is materially valid ### Phase 05 - Latency & Performance Canon Authority file: - lpc.md ### Phase 06 - Noise Reduction Canon Authority file: - nrc.md ### Phase 07 - Observability & Audit Canon Authority file: - oac.md ### Phase 08 - Security Canon Authority file: - sec.md Structured implementation canon: - host_security_canonical.json - app_security_canonical.json - module_security_canonical.json - runtime_security_canonical.json - delivery_security_canonical.json - approval_canonization_policy.json - memory_isolation_canonical.json - security_monitoring_canonical.json Trust-bound memory expansion attached to Phase 08: - memory_canonical_architecture.json - memory_lifecycle_canonical.json - learning_governance_canonical.json - planning_reasoning_canonical.json - tool_execution_canonical.json - knowledge_ingestion_canonical.json ### Phase 09 - Operational Flows Canon Authority file: - ofc.md ### Phase 10 - Monitoring & Real-time Observability Authority files: - monitoring_canonical.json - sse_bridge_canonical.json Installation order: 85-86 Depends on: core_runtime (order 70), observability_audit_base (order 80) Purpose: real-time host, container and service monitoring with SSE transport to the Operator Panel. This phase must be complete before SSE bridge replaces the push_snapshot model. ## 10. CROSS-DOCUMENT RULES 1. A file not registered here does not exist canonically. 2. A satellite file may reference a concept, but may not redefine it. 3. A phase authority file may define a concept only if ownership is assigned here. 4. If a concept needs both narrative governance and structured enforcement: - narrative governance belongs to the authority document - machine-readable enforcement belongs to the structured canonical JSON 5. If state and flow conflict: - STS wins on state legitimacy 6. If security conflicts with flow, latency or convenience: - SEC wins 7. If naming conflicts with content: - NCS wins on naming 8. If latency conflicts with optional processing: - LPC wins on latency budget 9. If memory access scope is ambiguous: - deny by default 10. If retrieval scope exceeds memory boundary: - memory isolation canon wins 11. Memory lifecycle must respect memory isolation and security boundaries. 12. Learning cannot bypass validation layer. 13. Planning cannot override deterministic control. 14. Tool execution must respect security and scope boundaries. 15. Knowledge ingestion must be versioned and auditable. 16. Runtime/support JSON artifacts may report state, but may not redefine canon. 17. Panel artifacts may represent canon, but may not create sovereign canon by themselves. ## 11. COMPLETE CANONICAL FILE REGISTRY ### 11.1 Authority and Satellite Markdown Files - acs.md - brps.md - cas.md - ccc.md - cdms.md - cfc.md - cgs.md - css.md - devon_panel_chat_checkpoint.md - lpc.md - master_architecture_index.md - ncs.md - nrc.md - oac.md - ofc.md - ofms.md - ris.md - sec.md - sts.md ### 11.2 Structured Canonical JSON Files - app_security_canonical.json - approval_canonization_policy.json - canonical_matrix_v1.json - card_contract_minimums.json - delivery_security_canonical.json - deployment_order_canonical.json - host_security_canonical.json - knowledge_ingestion_canonical.json - learning_governance_canonical.json - memory_canonical_architecture.json - memory_isolation_canonical.json - memory_lifecycle_canonical.json - module_security_canonical.json - panel_canonical_tree.json - panel_component_contract.json - panel_content_index.json - panel_data_contract.json - panel_manifest.json - panel_navigation_spec.json - panel_runtime_bridge.json - panel_sync_contract.json - panel_ui_blueprint.json - planning_reasoning_canonical.json - project_scope_canonical.json - runtime_row_semantics_canonical.json - runtime_security_canonical.json - sandbox_environment_canonical.json - security_monitoring_canonical.json - server_registry_canonical.json - subcategory_pipelines.json - tool_execution_canonical.json - project_progress_canonical.json - project_progress_model.json - runtime_row_semantics_canonical.json ### 11.3 Runtime and Support JSON Files - docker_runtime.json - host_runtime.json - monitoring_runtime.json - project_progress.json - runtime_snapshot.json - runtime_status.json ## 12. CANONICAL DEPENDENCY MATRIX This section defines explicit dependencies between canonical domains. No domain operates in isolation. ### 12.1 Memory Domain - memory_lifecycle_canonical.json depends on: - memory_canonical_architecture.json - memory_isolation_canonical.json - learning_governance_canonical.json ### 12.2 Learning Domain - learning_governance_canonical.json depends on: - validation layer (implicit) - memory_lifecycle_canonical.json - security_monitoring_canonical.json ### 12.3 Planning / Reasoning Domain - planning_reasoning_canonical.json depends on: - deterministic control layer - tool_execution_canonical.json - project_scope_canonical.json ### 12.4 Tool Execution Domain - tool_execution_canonical.json depends on: - runtime_security_canonical.json - module_security_canonical.json - project_scope_canonical.json ### 12.5 Knowledge Ingestion Domain - knowledge_ingestion_canonical.json depends on: - memory_canonical_architecture.json - memory_lifecycle_canonical.json - canonical_matrix_v1.json ## 13. CANONICAL PROCESS SPEC MODEL This section defines the mandatory process model that every canonical category, section, card and implementation item must follow. Purpose: turn canonical documentation into an executable process reference for the Documentation Hub, Operator Panel and future real-time build monitoring. Rule: a category is not sufficiently documented if it only declares files, layers, phase origin or dependencies. A category becomes operationally valid only when its process is explicitly documented step by step. ### 13.0 Canonical execution hierarchy The canonical execution hierarchy for Devon documentation, Documentation Hub and Operator Panel is: 1. Phase 2. Category 3. Process bucket 4. Item Definitions: ### Canonical Navigation and Execution Hierarchy The canonical hierarchy for Devon documentation, execution mapping and panel rendering is: 1. Phase 2. Category 3. Subcategory 4. Bucket 5. Item #### Subcategory A Subcategory is the process-oriented subdivision inside a Category. Subcategories are additive organizational layers and do not replace Phase or Category sovereignty. Canonical subcategories are: - Prerequisites - Installation - Configuration - Validation - Observable Evidence - Failure Modes & Recovery - Completion & Promotion #### Bucket A Bucket is a grouped execution container inside a Subcategory. Buckets belong to a Subcategory and may not be attached directly to a Phase. #### Item An Item is the smallest executable process unit inside a Bucket. Items belong to a Bucket and represent the lowest executable unit in the canonical workflow model. #### Structural Adaptation Rule The existing sovereign structure remains valid: - Phase remains the primary macro execution layer - Category remains the second-level sovereign document grouping The hierarchy is extended, not replaced: - Phase - Category - Subcategory - Bucket - Item Rendering contract: - left navigation = Phase -> Category - center workflow = Subcategory -> Bucket -> Item Subcategories must not be promoted to primary left navigation unless a future canonical navigation contract explicitly changes that rule. #### Phase A Phase is the macro execution stage shown in left navigation. It preserves installation/configuration order and canonical progression. Examples: - Overview & Scope - Architecture & Engineering Canon - Cognitive Flow Canon - Containerization Canon #### Category A Category is a sovereign or supporting document group inside a selected Phase. Examples inside a phase: - Master Architecture Index - Panel Manifest - Project Scope Canonical - Contracts and Schemas - Governance Model Rule: a category is not the phase itself. A phase contains categories. #### Process bucket A Process bucket is the ordered operational subdivision inside a category. Mandatory canonical buckets are: 1. prerequisites 2. installation 3. configuration 4. validation 5. observable_evidence 6. failure_modes_recovery 7. completion_promotion Rule: process buckets must appear in execution order. The Documentation Hub and Operator Panel may summarize them visually, but may not change their order. #### Item An Item is the smallest executable process unit inside a process bucket. An item must describe: - what must be done - in which order - what input is required - what output is expected - how to validate it - what evidence proves it - what failure can occur - what recovery action is allowed Example hierarchy: Phase: - Overview & Scope Category: - Project Scope Canonical Process buckets: - prerequisites - installation - configuration - validation - observable_evidence - failure_modes_recovery - completion_promotion Items: - register file - bind file to phase - expose file in DH - validate source load - confirm category ownership Canonical rule: left navigation = phase registry. center workflow = categories inside the selected phase. category body = ordered process buckets. bucket body = executable items. ### 13.1 Mandatory process-spec fields Every canonical implementation item must define, at minimum: 1. identity - canonical_layer - phase_origin - category_id - section_id - card_id - item_id - authority_owner 2. process purpose - objective - canonical_role - why_this_item_exists 3. prerequisites - required_before - blockers - hard_dependencies - allowed_preconditions 4. installation process - install_steps - installation_order - installation_commands_or_actions - expected_install_result 5. configuration process - config_steps - configuration_inputs - configuration_outputs - expected_configuration_result 6. validation process - validation_gates - checks - pass_criteria - fail_criteria - missing_criteria 7. evidence model - observable_evidence - evidence_source - evidence_path_or_endpoint - evidence_frequency - last_validation_pointer 8. failure model - failure_modes - probable_root_causes - recovery_actions - rollback_or_safe_state 9. completion model - done_when - not_done_when - promotion_gate - canonization_gate 10. operational monitoring contract - feeds_operational_ui - runtime_monitoring_hooks - timeline_events - status_counter_impact - dependency_impact ### 13.2 Canonical process rules 1. No implementation item may be treated as complete without explicit done_when criteria. 2. No step may be considered valid without observable evidence. 3. Installation and configuration must remain separated when they are materially different actions. 4. Validation must be explicit and may not be inferred from file existence alone unless the item contract says so. 5. Runtime monitoring may report process state, but may not redefine the canonical process contract. 6. The Documentation Hub may summarize the process, but the master index remains the supreme authority. 7. The Operator Panel may visualize process execution, but may not invent missing steps. 8. If a process field is absent, its status is MISSING. 9. If an item cannot expose evidence, it cannot produce PASS. 10. If a category has files but no process spec, the category is documentation-incomplete. ### 13.3 Required DH and UI alignment Audit split rule: Documentation Hub responsibilities: - canonical/document audit - coverage against this master index - authority ownership visibility - phase binding visibility - layer binding visibility - depends_on / used_by visibility - sovereign versus satellite separation visibility - documentation completion gap visibility - PASS / FAIL / MISSING only for documentary and canonical evidence Operator Panel responsibilities: - operational/runtime audit - real implementation state - real server/runtime evidence - health, containers and process telemetry - pipeline execution evidence - sync/export/runtime bridge evidence - PASS / FAIL / MISSING only for materially observable execution evidence Boundary rule: - Documentation Hub may summarize canonical structure, but may not claim runtime implementation as complete unless runtime evidence is exposed through the operational side. - Operator Panel may summarize runtime state, but may not redefine canonical ownership, precedence, phase order or documentary authority. - A runtime-relevant concept is only fully auditable when its canonical definition exists in the master/documentation side and its material evidence exists in the operational side. The Documentation Hub must eventually expose, per category: - required_before - install_steps - config_steps - validation_gates - observable_evidence - failure_modes - done_when - feeds_operational_ui The Operator Panel must eventually consume the same process model for: - monitoring sequence - timeline events - evidence drawers - contract drawers - dependency drawers - status counters - real-time runtime tracking ### 13.4 Process-spec priority If there is conflict between: - file listing and process contract - visual convenience and validation rule - runtime report and canonical process definition then the canonical process definition wins. ## 14. CANONICAL INTEGRITY RULES 1. No canonical file can operate without declared dependencies. 2. Cross-domain interaction must follow declared dependency paths. 3. Violations = FAIL (even if implementation exists). 4. Missing dependency = MISSING (system incomplete). 5. Circular dependencies are forbidden unless explicitly declared. ## 15. FAILURE MODES The system must explicitly recognize invalid states: - orphan canonical file → FAIL - dependency missing → MISSING - dependency violated → FAIL - execution bypassing canonical rule → FAIL - undocumented canonical file → FAIL ## 16. ARCHITECTURAL COMPLETENESS CRITERIA The system is considered COMPLETE only if: - all canonical files are referenced in this document - all dependencies are declared - all rules are enforceable - all domains are isolated and governed - validation layer is respected globally ## 17. COMPLETENESS RULE A Documentation Hub update is complete only if: - the canonical/document audit scope is materially reflected in the Hub - the Hub makes clear what belongs to documentary authority versus operational/runtime verification - no Documentation Hub element implies that runtime implementation is complete without operational evidence - the file exists materially in `/panel/data` - the file is registered in this master index - the file has a defined role - the file does not violate precedence rules ## 18. MASTER RULE FOR FUTURE EXPANSION No new file may be introduced into the canonical root without: - unique responsibility - explicit registration in this master index - non-overlap with existing authority - observable justification ===== CONTINUITY ===== # DEVON CONTINUITY ## Checkpoint 2026-04-09 — Canon Cleanup + Monitoring Layer ### O que foi feito - Limpeza completa de arquivos órfãos no Waresite /panel/data - Limpeza de baks no Devon /opt/devon/bin e /opt/devon/canon - runtime_row_semantics_canonical.json criado no disco e registrado no master - monitoring_canonical.json criado — define CPU, memory, disk, network, containers, nginx, security - sse_bridge_canonical.json criado — transport SSE PLANNED, push_snapshot ainda ACTIVE - master_architecture_index.md atualizado: seção 8.7, Phase 10, 11.2, 11.3 - hub_index.json atualizado: 10 phases, 12 categories, monitoring_observability adicionado - project_progress_canonical.json e project_progress_model.json registrados em overview_scope - runtime_row_semantics_canonical registrado em observability_audit - Export script Devon corrigido para sincronizar canon completo (panel_export/current) - DH funcionando e refletindo tudo corretamente ### Próximo passo - Refatorar Operator Panel (UI) — novo chat - Após UI: implementar SSE bridge Devon → Waresite - Após SSE: remover export_panel_runtime.sh ## Checkpoint 2026-04-03 — Semantic Runtime Reading Canon ### Real state validated - Devon is already emitting real runtime for host, docker, pipeline and project progress. - Waresite is already consuming published runtime rows from Devon. - The UI numbers are not being filled manually. - The current problem is semantic, not cosmetic and not “manual digit editing”. ### Structural diagnosis - The Operator Panel is still grouping runtime rows with insufficient semantic separation. - Some visual groups are mixing rollup rows, matrix-derived rows and item-level runtime rows. - This makes some donuts mathematically calculated but semantically invalid. - The correct correction is not another ad hoc UI patch. - The correct correction is explicit semantic typing in the runtime publication contract. ### Sovereign rule now in force - Devon must publish runtime truth with explicit row semantics. - Waresite UI must only consume published runtime truth and declared row meaning. - Canon stays canonical. - Runtime stays operational. - UI stays render-only. - No manual UI recognition workflow is allowed as normal operating mode. - No ambiguous row grouping is allowed for completion semantics. ### Mandatory next correction - Canonize the runtime row semantics model. - Keep the probe-registry model as mandatory architecture. - Bind every emitted row to an explicit `row_kind` and `semantic_scope`. - Refactor `collect_runtime.py` and export artifacts to publish semantically typed rows. - Keep `Canon -> DH -> UI` intact, but eliminate semantic ambiguity in runtime consumption. ### Material Devon runtime-contract artifacts now validated The following files already exist materially on the Devon server and are the current runtime-contract base in force: - `/opt/devon/canon/runtime_expected_manifest.json` - `/opt/devon/canon/runtime_probe_registry.json` - `/opt/devon/bin/build_runtime_contracts.py` Operational reading: - `runtime_expected_manifest.json` is the expected-runtime manifest. - `runtime_probe_registry.json` is the probe registry. - `build_runtime_contracts.py` is the builder/compiler that generates these contracts. Rule now fixed: - Do not invent a parallel canonical file when the contract base already exists materially in Devon. - Any semantic/runtime correction must start from these files first. ## 1. MEMORY ### 1.1 Project Identity - Devon is the cognitive development control plane of the YEFF architecture. - Waresite server hosts the canonical documentation, Documentation Hub, and Operational UI. - Devon server is the origin of real runtime, host, container, and execution data. - The Operational UI does not define truth. It validates and exposes canonical truth. ### 1.2 Canonical References - Canonical root: `/home/yeff/public_html/devon/panel/data/master_architecture_index.md` - Canonical child-files: markdown and JSON artifacts referenced by the canonical root - Canonical contracts: JSON/YAML files consumed by the Documentation Hub and Operational UI - Canonical continuity file: `/home/yeff/public_html/devon/panel/data/devon_continuity.md` ### 1.3 Fixed Rules - Evidence first, patch after. - No guessing. - No fake status or fake progress. - Allowed status model is evidence-based and boolean. - If something does not exist observably, the only allowed status is `MISSING`. - Operational UI validates canonical contracts. It does not invent architecture. - Waresite hosts canonical documentation and UI. - Devon hosts real runtime and operational execution. - Any new operational discovery must follow canonical expansion order. - Canonical expansion order is mandatory: `Canon -> DH -> UI`. ### 1.4 Canonized Decisions - The project truth is defined by canonical documentation, not by chat memory. - `master_architecture_index.md` remains the canonical root. - `devon_continuity.md` is the canonical continuity layer between chats. - The continuity model is divided into two macrosections: `MEMORY` and `TODO`. - The Operational UI is the operational validation layer, not the source of truth. - Any new item discovered during server installation/configuration must be canonized before entering DH or UI. ### 1.5 Completed Milestones - Documentation Hub baseline is already established. - Operational UI baseline has been finalized as current operational reference. - The continuity strategy between chats has been defined. - Canonical expansion flow has been defined. - Waresite has been defined as the canonical documentation host. - Devon has been defined as the real runtime source. ### 1.6 Stable Context - There are two distinct servers in this architecture: - Waresite: canonical documentation, DH, Operational UI - Devon: runtime origin, host state, containers, execution - Server work must converge to canon already defined in Waresite. - Canon must always lead implementation. ## 2. TODO ### 2.1 Current Focus - Replace ambiguous UI/runtime reading with a sovereign Devon-side semantic publication model. - Canonize the runtime probe-registry pattern as mandatory architecture. - Canonize the runtime row semantics contract as mandatory architecture. - Prepare the collector refactor from hardcoded runtime logic to registry-driven, semantically typed publication. - Preserve existing `/opt/devon` runtime, export and bridge assets during the redesign. ### 2.2 Open Operational Fronts - Define the canonical runtime probe registry artifact and its schema. - Define the canonical runtime row semantics artifact and its schema. - Bind every observable stage/subcategory/item to a deterministic probe rule. - Bind every emitted runtime row to explicit semantic type and counting boundary. - Refactor `collect_runtime.py` to execute the registry instead of per-case hardcoded logic. - Stop any workflow where Waresite UI must be patched just to recognize an already-installed Devon component. - Stop any workflow where Waresite UI must guess row meaning from loose grouping. - Keep sync/export bridge stable while the collector model is upgraded. ### 2.3 Active Blockers - Runtime publication is still partially hardcoded in `collect_runtime.py`. - UI/runtime alignment still depends on case-specific downstream adjustments. - There is no sovereign registry-driven runtime publication contract yet. - There is no sovereign runtime row semantics contract yet. - Current runtime granularity is incomplete for several stage/subcategory views. - Current row grouping still allows semantic mixing between rollup rows and item rows. - This creates operational drag and wastes time/energy during Devon server setup. ### 2.4 Next Operational Step - The next technical deliverable is not another UI patch. - The next technical deliverable is to evolve the existing Devon contract base, not invent a parallel contract base. - Start from `/opt/devon/canon/runtime_expected_manifest.json`. - Start from `/opt/devon/canon/runtime_probe_registry.json`. - Start from `/opt/devon/bin/build_runtime_contracts.py`. - The next chat must start from the runtime publication architecture problem, not from another installation micro-fix. - Waresite UI must remain consumer-only while Devon becomes the complete runtime publisher. - UI completion semantics must only be computed from semantically typed rows emitted by Devon. ### 2.5 Deferred Items - Any DH/UI reflection not yet required for immediate continuity use. - Any runtime/service component not yet evidenced on the Devon server. - Any UI expansion for components that are not yet canonized. ### 2.6 Devon Host Real Status #### 2.6.1 Observed Host Baseline - Hostname observed: `Devon` / `vmi2858754` - OS observed: Ubuntu 22.04.5 LTS - Kernel observed: Linux 5.15.0-170-generic - Architecture observed: x86-64 - CPU observed: 6 vCPU - Memory observed: 11 GiB RAM - Disk observed: 100 GB total with approximately 94 GB available - Current exposed listening service observed: SSH on port 22 only #### 2.6.2 Observed Security/Network Status - Firewall status observed: `active` - UFW policy observed: `deny (incoming), allow (outgoing), disabled (routed)` - Allowed inbound rule observed: `22/tcp` - iptables default policy observed: `INPUT DROP`, `FORWARD DROP`, `OUTPUT ACCEPT` - Reverse proxy observed: `MISSING` - TLS baseline observed: `MISSING` #### 2.6.3 Observed Tooling Status - Python3: `PRESENT` - Git: `PRESENT` - Curl: `PRESENT` - Docker: `MISSING` - Docker Compose: `MISSING` by consequence of Docker absence - Nginx: `MISSING` #### 2.6.4 Observed Devon Paths and Assets - `/opt/devon`: `PRESENT` - `/opt/devon/bin`: `PRESENT` - `/opt/devon/runtime`: `PRESENT` - `/opt/devon/canon`: `PRESENT` - `/srv`: `PRESENT` - `/app`: `MISSING` #### 2.6.5 Observed Reusable Devon Runtime Assets - `/opt/devon/bin/collect_runtime.py` - `/opt/devon/bin/export_panel_runtime.sh` - `/opt/devon/runtime/host_runtime.json` - `/opt/devon/runtime/docker_runtime.json` - `/opt/devon/runtime/runtime_status.json` - `/opt/devon/runtime/panel_export/current` - `/opt/devon/canon/*.yaml` #### 2.6.6 Canonical Reading of Current Host - The Devon host already contains canonical/runtime/export structure under `/opt/devon`. - The Devon host does not yet contain container runtime baseline. - The Devon host does not yet contain reverse proxy/TLS baseline. - The Devon host must be expanded without breaking existing `/opt/devon` assets or the Waresite bridge. ### 2.7 Canonical Installation Plan #### 2.7.1 Installation Principle - Installation must follow evidence and canonical order. - Existing `/opt/devon` structure is treated as reusable operational base, not as disposable scaffold. - No component enters DH or UI before canon alignment if new architectural surface appears. #### 2.7.2 Layered Execution Order 1. Host baseline classification 2. Security baseline classification and hardening plan 3. Docker runtime installation plan 4. Container path and persistence plan 5. Reverse proxy/TLS plan 6. Preservation/alignment of current Devon runtime bridge 7. Only after that: service/container materialization #### 2.7.3 Initial Layer Matrix - Host OS baseline: `PASS` - CPU/RAM/Disk baseline: `PASS` - Network baseline: `PASS` - SSH access baseline: `PASS` - Python/Git/Curl baseline: `PASS` - Firewall baseline: `PASS` - Fail2ban baseline: `PASS` - Docker runtime baseline: `MISSING` - Docker Compose baseline: `MISSING` - Reverse proxy baseline: `MISSING` - TLS baseline: `MISSING` - Canon/runtime path baseline: `PASS` - `/app` runtime path baseline: `MISSING` #### 2.7.4 Operational Rule for Next Chat - The semantic runtime publication path is now validated end-to-end. - Do not reopen the old donut problem as an unresolved backend/UI ambiguity. - `collect_runtime.py` is now the canonical place that materializes semantically typed runtime rows. - `export_panel_runtime.sh` is now the validated publication bridge from Devon runtime to Waresite panel data. - `project_progress.json` remains sovereign for the global project donut. - `stage_rollup.progress_pct` remains sovereign for stage completion in the UI. - Subcategory cards must treat `0 eligible` as `not eligible`, never as `0%`. - Any future Devon installation/configuration must be reflected by: 1. observable server evidence 2. collector regeneration 3. export to Waresite 4. UI refresh ### 2.8 Bootstrap for New Chat Use the following block to resume work in a new chat: - Canonical root: `/home/yeff/public_html/devon/panel/data/master_architecture_index.md` - Continuity file: `/home/yeff/public_html/devon/panel/data/devon_continuity.md` - Waresite server: canonical docs, Documentation Hub, Operator Panel UI - Devon server: runtime origin, collector, exporter and operational truth - Semantic runtime closure status: `PASS` - Validated result: - `runtime_status.json` now preserves row semantics end-to-end - `project_progress.json` drives the global project donut - `stage_rollup.progress_pct` drives stage completion - subcards with `0 eligible` now render `MISSING / not eligible` - Operational rule: - after any Devon installation/configuration change, run: - `python3 /opt/devon/bin/collect_runtime.py` - `bash /opt/devon/bin/export_panel_runtime.sh` - only then validate the Waresite Operator Panel - Next mission: - return to Devon server configuration - continue host/runtime baseline expansion in canonical order - prioritize missing layers still blocking real Devon materialization: 1. Docker runtime baseline 2. Docker Compose baseline 3. reverse proxy baseline 4. TLS baseline 5. `/app` runtime path baseline ## 3. CANON EXPANSION RULE ### 3.1 Mandatory Order Whenever a new item appears during Devon server installation, configuration, runtime validation, or host discovery, the following order is mandatory: 1. Canon 2. Documentation Hub 3. Operational UI ### 3.2 Canon First Before anything enters DH or UI, it must be classified and canonized through: - `master_architecture_index.md` - child-files if deeper detailing is required - explicit definition of purpose, dependency, observable evidence, and operational impact ### 3.3 DH Second After canonization, the item must be reflected in the Documentation Hub for navigable architectural/documental visibility. ### 3.4 UI Last Only after canon and DH alignment may the item be reflected in the Operational UI. ### 3.5 Governance Rule If an item exists operationally but is not yet canonized: - it is not a final operational reference - it must not be treated as fully integrated architecture - it must not go directly into UI ## 4. DISCOVERY INTAKE TEMPLATE Use this template whenever a new operational item is discovered during Devon host work: ### 4.1 Discovery Record - Item name: - Category: - Why it appeared: - Dependencies: - Evidence of presence: - Evidence of functionality: - Canon impact: - Needs child-file? `YES|NO` - Needs DH reflection? `YES|NO` - Needs UI reflection? `YES|NO` - Current status: `PASS|FAIL|MISSING` ===== DH EXECUTION LAW ===== # DOCUMENTATION HUB EXECUTION LAW Core law: Documentation Hub is simultaneously: 1. canonical documentation 2. execution system 3. contract base for the future operational panel DH structural transition law: Textual validation is transitional only. The future operational panel must consume structural contract, not textual inference. Strategic rule: Documentation Hub is canonical execution guidance, not decorative documentation. ===== DH JSON MIRROR LAW ===== # DOCUMENTATION HUB JSON MIRROR LAW Core law: A category that is already structurally mature in Documentation Hub may be materialized as a JSON mirror. Current meaning: - DH remains the canonical human-readable reference - category JSON is the machine-readable mirror of the current DH execution contract - this JSON is not yet the final sovereign engine contract Status rule: When a category JSON is still a DH mirror, its status must communicate transition rather than final sovereignty. Current valid transition status: - ACTIVE_DH_MIRROR Boundary rule: Do not redesign category macrostructure once the DH category architecture is stable. After macrostructure is stable, the next step is hardening, not redesign. Hardening law: The correct next step after category JSON materialization is: - strengthen weak evidence - replace semantic/textual validation where possible - migrate toward structural evidence, fixed bindings, key paths and schema-backed validation - do not reopen the category architecture unless there is a real canonical error Bucket-boundary law: The following bucket roles must remain rigidly separated: Validation: - test conformity against the declared contract Observable Evidence: - prove material evidence exists Completion & Promotion: - decide whether category status may be promoted Invalid state: If these three buckets begin to overlap semantically, the category loses execution clarity and future panel consumption becomes weaker. Parser-readiness law: Classification must obey real technical properties, not conservative guessing. engine_grade_final = true only when: - evidence is structural - validation is parseable - fail state is deterministic - no human semantic reading is required parser_readiness = high only when: - the engine can resolve the check without textual interpretation validation_mode = semantic_transitional only when: - the check depends on language interpretation instead of structural keys, bindings or machine-readable contracts Recalibration rule: Strong structural checks must not be underclassified merely because the category still contains transitional fields elsewhere. Item classification must reflect the real strength of that item's own evidence and validation path. Transition rule: Current category JSON may be: - strong for governance - strong for DH mirroring - strong for operational contract intent - partial for parser determinism This is valid during transition. It only becomes invalid if DH mirror status is falsely presented as final engine-grade sovereignty. Strategic direction: Final architecture target is: - DH = canonical human-readable execution reference - category JSON = machine-readable execution mirror - future operational panel = consumer of hardened structural category contracts ===== DOCUMENTATION HUB SNAPSHOT ===== PHASE COUNT: 10 - phase-01 | Overview & Scope - phase-02 | Architecture & Engineering Canon - phase-03 | Cognitive Flow Canon - phase-04 | Containerization Canon - phase-05 | Latency & Performance Canon - phase-06 | Noise Reduction Canon - phase-07 | Observability & Audit Canon - phase-08 | Security Canon - phase-09 | Operational Flows Canon - phase-10 | Monitoring & Real-time Observability CATEGORY COUNT: 12 CATEGORY: overview_scope | LABEL: Overview & Scope | PHASE: phase-01 | DOCS: 8 DOC: master_architecture_index | LABEL: Master Architecture Index | TYPE: text DOC: panel_manifest | LABEL: Panel Manifest | TYPE: json DOC: project_scope | LABEL: Project Scope Canonical | TYPE: json DOC: deployment_order | LABEL: Deployment Order Canonical | TYPE: json DOC: sandbox_environment | LABEL: Sandbox Environment Canonical | TYPE: json DOC: server_registry | LABEL: Server Registry Canonical | TYPE: json DOC: project_progress_canonical | LABEL: Project Progress Canonical | TYPE: json DOC: project_progress_model | LABEL: Project Progress Model | TYPE: json CATEGORY: architecture_engineering_core | LABEL: Architecture & Engineering Canon | PHASE: phase-02 | DOCS: 18 DOC: cas | LABEL: CAS · Cognitive Architecture Spec | TYPE: text DOC: cgs | LABEL: CGS · Canonical Governance Spec | TYPE: text DOC: acs | LABEL: ACS · Artifact Canon Structure | TYPE: text DOC: css | LABEL: CSS · Contracts & Schemas Spec | TYPE: text DOC: ncs | LABEL: NCS · Naming Canon Spec | TYPE: text DOC: sts | LABEL: STS · State Transition Spec | TYPE: text DOC: brps | LABEL: BRPS · Build Release Promotion Spec | TYPE: text DOC: cdms | LABEL: CDMS · Canonical Deployment Model Spec | TYPE: text DOC: ris | LABEL: RIS · Role Interaction Spec | TYPE: text DOC: ofms | LABEL: OFMS · Operational Flow Mapping Spec | TYPE: text DOC: card_contract_minimums | LABEL: Card Contract Minimums | TYPE: json DOC: panel_data_contract | LABEL: Panel Data Contract | TYPE: json DOC: panel_component_contract | LABEL: Panel Component Contract | TYPE: json DOC: panel_sync_contract | LABEL: Panel Sync Contract | TYPE: json DOC: panel_canonical_tree | LABEL: Panel Canonical Tree | TYPE: json DOC: panel_navigation_spec | LABEL: Panel Navigation Spec | TYPE: json DOC: panel_ui_blueprint | LABEL: Panel UI Blueprint | TYPE: json DOC: canonical_matrix_v1 | LABEL: Canonical Matrix v1 | TYPE: json CATEGORY: cognitive_flow | LABEL: Cognitive Flow Canon | PHASE: phase-03 | DOCS: 2 DOC: cfc | LABEL: CFC · Cognitive Flow Canon | TYPE: text DOC: ccc | LABEL: CCC · Cognitive Component Context | TYPE: text CATEGORY: containerization | LABEL: Containerization Canon | PHASE: phase-04 | DOCS: 1 DOC: cdms | LABEL: CDMS · Canonical Deployment Model Spec | TYPE: text CATEGORY: latency_performance | LABEL: Latency & Performance Canon | PHASE: phase-05 | DOCS: 1 DOC: lpc | LABEL: LPC · Latency & Performance Canon | TYPE: text CATEGORY: noise_reduction | LABEL: Noise Reduction Canon | PHASE: phase-06 | DOCS: 1 DOC: nrc | LABEL: NRC · Noise Reduction Canon | TYPE: text CATEGORY: observability_audit | LABEL: Observability & Audit Canon | PHASE: phase-07 | DOCS: 6 DOC: oac | LABEL: OAC · Observability & Audit Canon | TYPE: text DOC: panel_runtime_bridge | LABEL: Panel Runtime Bridge | TYPE: json DOC: host_runtime_support | LABEL: Host Runtime Support | TYPE: json DOC: docker_runtime_support | LABEL: Docker Runtime Support | TYPE: json DOC: runtime_status_support | LABEL: Runtime Status Support | TYPE: json DOC: runtime_row_semantics | LABEL: Runtime Row Semantics Canonical | TYPE: json CATEGORY: security_governance | LABEL: Security Canon | PHASE: phase-08 | DOCS: 9 DOC: sec | LABEL: SEC · Security Canon | TYPE: text DOC: host_security | LABEL: Host Security Canonical | TYPE: json DOC: app_security | LABEL: App Security Canonical | TYPE: json DOC: module_security | LABEL: Module Security Canonical | TYPE: json DOC: runtime_security | LABEL: Runtime Security Canonical | TYPE: json DOC: delivery_security | LABEL: Delivery Security Canonical | TYPE: json DOC: approval_policy | LABEL: Approval Canonization Policy | TYPE: json DOC: memory_isolation | LABEL: Memory Isolation Canonical | TYPE: json DOC: security_monitoring | LABEL: Security Monitoring Canonical | TYPE: json CATEGORY: operational_flows | LABEL: Operational Flows Canon | PHASE: phase-09 | DOCS: 1 DOC: ofc | LABEL: OFC · Operational Flows Canon | TYPE: text CATEGORY: delivery_layer | LABEL: Delivery Layer | PHASE: phase-09 | DOCS: 2 DOC: subcategory_pipelines | LABEL: Subcategory Pipelines | TYPE: json DOC: panel_content_index | LABEL: Panel Content Index | TYPE: json CATEGORY: memory_learning_reasoning | LABEL: Memory, Learning & Reasoning Governance | PHASE: phase-08 | DOCS: 6 DOC: memory_arch | LABEL: Memory Canonical Architecture | TYPE: json DOC: memory_lifecycle | LABEL: Memory Lifecycle Canonical | TYPE: json DOC: learning_gov | LABEL: Learning Governance Canonical | TYPE: json DOC: planning_reasoning | LABEL: Planning Reasoning Canonical | TYPE: json DOC: tool_execution | LABEL: Tool Execution Canonical | TYPE: json DOC: knowledge_ingestion | LABEL: Knowledge Ingestion Canonical | TYPE: json CATEGORY: monitoring_observability | LABEL: Monitoring & Real-time Observability | PHASE: phase-10 | DOCS: 2 DOC: monitoring_canonical | LABEL: Monitoring Canonical | TYPE: json DOC: sse_bridge_canonical | LABEL: SSE Bridge Canonical | TYPE: json ===== PHASE 01 + PHASE 02 DOC MAP ===== [phase-01] overview_scope => Overview & Scope - master_architecture_index => Master Architecture Index - panel_manifest => Panel Manifest - project_scope => Project Scope Canonical - deployment_order => Deployment Order Canonical - sandbox_environment => Sandbox Environment Canonical - server_registry => Server Registry Canonical - project_progress_canonical => Project Progress Canonical - project_progress_model => Project Progress Model [phase-02] architecture_engineering_core => Architecture & Engineering Canon - cas => CAS · Cognitive Architecture Spec - cgs => CGS · Canonical Governance Spec - acs => ACS · Artifact Canon Structure - css => CSS · Contracts & Schemas Spec - ncs => NCS · Naming Canon Spec - sts => STS · State Transition Spec - brps => BRPS · Build Release Promotion Spec - cdms => CDMS · Canonical Deployment Model Spec - ris => RIS · Role Interaction Spec - ofms => OFMS · Operational Flow Mapping Spec - card_contract_minimums => Card Contract Minimums - panel_data_contract => Panel Data Contract - panel_component_contract => Panel Component Contract - panel_sync_contract => Panel Sync Contract - panel_canonical_tree => Panel Canonical Tree - panel_navigation_spec => Panel Navigation Spec - panel_ui_blueprint => Panel UI Blueprint - canonical_matrix_v1 => Canonical Matrix v1 ===== DOCS INDEX CUSTOM BRANCHES ===== 1967: if (doc.id === "cas" && state.categoryId === "architecture_engineering_core") { 2066: if (doc.id === "cgs" && state.categoryId === "architecture_engineering_core") { 2165: if (doc.id === "acs" && state.categoryId === "architecture_engineering_core") { 2264: if (doc.id === "css" && state.categoryId === "architecture_engineering_core") { 2363: if (doc.id === "ncs" && state.categoryId === "architecture_engineering_core") { 2462: if (doc.id === "sts" && state.categoryId === "architecture_engineering_core") { 2561: if (doc.id === "brps" && state.categoryId === "architecture_engineering_core") { 2660: if (doc.id === "cdms" && state.categoryId === "architecture_engineering_core") { 2759: if (doc.id === "ris" && state.categoryId === "architecture_engineering_core") { 2858: if (doc.id === "ofms" && state.categoryId === "architecture_engineering_core") { 2957: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 3083:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 3294:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 3526:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 3643:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 4237:if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 4397:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 4633:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 4870:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 5571:if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 5731:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 5967:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 6204:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 6973:if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 7133:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 7369:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 7606:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 8335:if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 8438:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 8940:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 9557:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 9683:if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 9843:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 10079:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 10480:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 11205:if (doc.id === "project_progress_canonical" && state.categoryId === "overview_scope") { 13241: if (doc.id === "master_architecture_index" && state.categoryId === "project_progress_model") { 13332:if (doc.id === "project_progress_model" && state.categoryId === "overview_scope") { ===== DOCS INDEX forceDirectArchitectureRender ===== const forceDirectArchitectureRender = (doc.id === "panel_manifest" && state.categoryId === "overview_scope") || (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") || (doc.id === "project_scope" && state.categoryId === "overview_scope") || (doc.id === "deployment_order" && state.categoryId === "overview_scope") || (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") || (doc.id === "server_registry" && state.categoryId === "overview_scope") || (doc.id === "project_progress_canonical" && state.categoryId === "overview_scope") || (doc.id === "project_progress_model" && state.categoryId === "overview_scope") || (doc.id === "cas" && state.categoryId === "architecture_engineering_core") || (doc.id === "cgs" && state.categoryId === "architecture_engineering_core") || (doc.id === "acs" && state.categoryId === "architecture_engineering_core") || (doc.id === "css" && state.categoryId === "architecture_engineering_core") || (doc.id === "ncs" && state.categoryId === "architecture_engineering_core") || (doc.id === "sts" && state.categoryId === "architecture_engineering_core") || (doc.id === "brps" && state.categoryId === "architecture_engineering_core") || (doc.id === "cdms" && state.categoryId === "architecture_engineering_core") || (doc.id === "ris" && state.categoryId === "architecture_engineering_core") || (doc.id === "ofms" && state.categoryId === "architecture_engineering_core"); ===== DOCS INDEX PHASE STATUS SNAPSHOT ===== PHASE-01: CATEGORY: overview_scope | Overview & Scope - master_architecture_index: CUSTOM_BRANCH - panel_manifest: CUSTOM_BRANCH - project_scope: CUSTOM_BRANCH - deployment_order: CUSTOM_BRANCH - sandbox_environment: CUSTOM_BRANCH - server_registry: CUSTOM_BRANCH - project_progress_canonical: CUSTOM_BRANCH - project_progress_model: CUSTOM_BRANCH PHASE-02: CATEGORY: architecture_engineering_core | Architecture & Engineering Canon - cas: CUSTOM_BRANCH - cgs: CUSTOM_BRANCH - acs: CUSTOM_BRANCH - css: CUSTOM_BRANCH - ncs: CUSTOM_BRANCH - sts: CUSTOM_BRANCH - brps: CUSTOM_BRANCH - cdms: CUSTOM_BRANCH - ris: CUSTOM_BRANCH - ofms: CUSTOM_BRANCH - card_contract_minimums: GENERIC_RENDER - panel_data_contract: GENERIC_RENDER - panel_component_contract: GENERIC_RENDER - panel_sync_contract: GENERIC_RENDER - panel_canonical_tree: GENERIC_RENDER - panel_navigation_spec: GENERIC_RENDER - panel_ui_blueprint: GENERIC_RENDER - canonical_matrix_v1: GENERIC_RENDER ===== DOCS INDEX SYNTAX ===== No syntax errors detected in /home/yeff/public_html/devon/docs/index.php ===== DUMP STATUS ===== PASS: canonical + docs + hub context reconstructed from server evidence ===== SYNTAX ===== No syntax errors detected in /home/yeff/public_html/devon/docs/index.php No syntax errors detected in /home/yeff/public_html/devon/docs/index.html ===== MINIMUS VS MINIMUMS MAP ===== ===== CURRENT CATEGORY SOURCE TEXT SHOWN IN UI ===== ===== STRUCTURED RENDERER ROUTE ===== 1729- !/^#####\s+P\d\d-/.test(line) && 1730- !/^####\s+Phase /.test(line) && 1731- !/^Authority files:/.test(line) && 1732- !/^Satellite files:/.test(line) && 1733- !/^- authority_owner:/.test(line) && 1734- !/^- canonical_role:/.test(line) && 1735- !/^- why_this_item_exists:/.test(line) && 1736- !/^- required_before:/.test(line) && 1737- !/^- hard_dependencies:/.test(line) && 1738- !/^- feeds_operational_ui:/.test(line) 1739- ) { 1740- out.overview.push(line); 1741- } 1742- } 1743- } 1744- 1745- out.overview = out.overview.slice(0, 8); 1746- return out.subcategories.length ? out : null; 1747- } 1748- 1749: function renderStructuredCategoryView(doc, sourceMeta){ 1750- const parsed = parseStructuredCategoryView(sourceMeta.sourceText, doc); 1751- if (!parsed) return null; 1752- 1753- const renderBucketCard = (bucket) => ` 1754-
1755-
${escapeHtml(bucket.title)}
1756- ${ 1757- bucket.items.length 1758- ? `` 1759- : `
No items declared.
` 1760- } 1761-
1762- `; 1763- 1764- const renderSubBlock = (title, buckets) => ` 1765-
1766- 1772-
1773- ${buckets.map(renderBucketCard).join("")} 1774-
1775-
1776- `; 1777- 1778- const overviewHtml = ` 1779-
1780-

Overview

1781-

${ 1782- parsed.overview.length 1783- ? escapeHtml(parsed.overview.join(" ")) 1784- : escapeHtml(sourceMeta.summary || "Structured category view loaded.") 1785- }

1786-
1787- `; 1788- 1789- const category = getCategory(state.categoryId); 1790- 1791- if (category && Array.isArray(category.subcategories)) { 1792- const category = getCategory("overview_scope"); 1793- const getHubSub = (id) => 1794- category.subcategories.find(sub => sub.id === id); 1795- 1796- const cloneBuckets = (sourceSub) => { 1797- const buckets = Array.isArray(sourceSub && sourceSub.buckets) ? sourceSub.buckets : []; 1798- return buckets.map(bucket => ({ 1799- title: bucket.title || "Untitled", 1800- items: Array.isArray(bucket.items) ? bucket.items.slice() : [] 1801- })); 1802- }; 1803- 1804- const parsedMap = {}; 1805- (parsed.subcategories || []).forEach(sub => { 1806- parsedMap[String(sub.title || "").trim().toLowerCase()] = { 1807- title: sub.title || "Untitled", 1808- buckets: Array.isArray(sub.buckets) 1809- ? sub.buckets.map(bucket => ({ 1810- title: bucket.title || "Untitled", 1811- items: Array.isArray(bucket.items) ? bucket.items.slice() : [] 1812- })) 1813- : [] 1814- }; 1815- }); 1816- 1817- const scaffold = [ 1818- { title: "Prerequisites", id: "prerequisites", side: "left" }, 1819- { title: "Installation", id: "installation", side: "right" }, 1820- { title: "Configuration", id: "configuration", side: "left" }, 1821- { title: "Validation", id: "validation", side: "right" }, 1822- { title: "Observable Evidence", id: "observable_evidence", side: "left" }, 1823- { title: "Failure Modes & Recovery", id: "failure_modes_recovery", side: "right" }, 1824- { title: "Completion & Promotion", id: "completion_promotion", side: "left" } 1825- ]; 1826- 1827- const leftBlocks = []; 1828- const rightBlocks = []; 1829- 1830- scaffold.forEach(def => { 1831- const hubHit = getHubSub(def.id); 1832- const parsedHit = parsedMap[String(def.title || "").trim().toLowerCase()]; 1833- 1834- let buckets = []; 1835- if (hubHit && Array.isArray(hubHit.buckets) && hubHit.buckets.length) { 1836- buckets = cloneBuckets(hubHit); 1837- } else if (parsedHit && Array.isArray(parsedHit.buckets) && parsedHit.buckets.length) { 1838- buckets = parsedHit.buckets; 1839- } else { 1840- buckets = [{ title: "Pending content", items: [] }]; 1841- } 1842- 1843- const html = renderSubBlock(def.title, buckets); 1844- if (def.side === "left") leftBlocks.push(html); 1845- else rightBlocks.push(html); 1846- }); 1847- 1848- const leftHtml = leftBlocks.join(""); 1849- const rightHtml = rightBlocks.join(""); 1850- 1851- return overviewHtml + ` 1852-
1853-
${leftHtml}
1854-
${rightHtml}
1855-
1856- `; 1857- } 1858- 1859- const preferredOrder = [ 1860- "Prerequisites", 1861- "Installation", 1862- "Configuration", 1863- "Observable Evidence", 1864- "Validation", 1865- "Failure Modes & Recovery", 1866- "Completion & Promotion" 1867- ]; 1868- 1869- const orderedSubs = [...parsed.subcategories].sort((a, b) => { 1729- !/^#####\s+P\d\d-/.test(line) && 1730- !/^####\s+Phase /.test(line) && 1731- !/^Authority files:/.test(line) && 1732- !/^Satellite files:/.test(line) && 1733- !/^- authority_owner:/.test(line) && 1734- !/^- canonical_role:/.test(line) && 1735- !/^- why_this_item_exists:/.test(line) && 1736- !/^- required_before:/.test(line) && 1737- !/^- hard_dependencies:/.test(line) && 1738- !/^- feeds_operational_ui:/.test(line) 1739- ) { 1740- out.overview.push(line); 1741- } 1742- } 1743- } 1744- 1745- out.overview = out.overview.slice(0, 8); 1746- return out.subcategories.length ? out : null; 1747- } 1748- 1749: function renderStructuredCategoryView(doc, sourceMeta){ 1750- const parsed = parseStructuredCategoryView(sourceMeta.sourceText, doc); 1751- if (!parsed) return null; 1752- 1753- const renderBucketCard = (bucket) => ` 1754-
1755-
${escapeHtml(bucket.title)}
1756- ${ 1757- bucket.items.length 1758- ? `` 1759- : `
No items declared.
` 1760- } 1761-
1762- `; 1763- 1764- const renderSubBlock = (title, buckets) => ` 1765-
1766- 1772-
1773- ${buckets.map(renderBucketCard).join("")} 1774-
1775-
1776- `; 1777- 1778- const overviewHtml = ` 1779-
1780-

Overview

1781-

${ 1782- parsed.overview.length 1783- ? escapeHtml(parsed.overview.join(" ")) 1784- : escapeHtml(sourceMeta.summary || "Structured category view loaded.") 1785- }

1786-
1787- `; 1788- 1789- const category = getCategory(state.categoryId); 1790- 1791- if (category && Array.isArray(category.subcategories)) { 1792- const category = getCategory("overview_scope"); 1793- const getHubSub = (id) => 1794- category.subcategories.find(sub => sub.id === id); 1795- 1796- const cloneBuckets = (sourceSub) => { 1797- const buckets = Array.isArray(sourceSub && sourceSub.buckets) ? sourceSub.buckets : []; 1798- return buckets.map(bucket => ({ 1799- title: bucket.title || "Untitled", 1800- items: Array.isArray(bucket.items) ? bucket.items.slice() : [] 1801- })); 1802- }; 1803- 1804- const parsedMap = {}; 1805- (parsed.subcategories || []).forEach(sub => { 1806- parsedMap[String(sub.title || "").trim().toLowerCase()] = { 1807- title: sub.title || "Untitled", 1808- buckets: Array.isArray(sub.buckets) 1809- ? sub.buckets.map(bucket => ({ 1810- title: bucket.title || "Untitled", 1811- items: Array.isArray(bucket.items) ? bucket.items.slice() : [] 1812- })) 1813- : [] 1814- }; 1815- }); 1816- 1817- const scaffold = [ 1818- { title: "Prerequisites", id: "prerequisites", side: "left" }, 1819- { title: "Installation", id: "installation", side: "right" }, 1820- { title: "Configuration", id: "configuration", side: "left" }, 1821- { title: "Validation", id: "validation", side: "right" }, 1822- { title: "Observable Evidence", id: "observable_evidence", side: "left" }, 1823- { title: "Failure Modes & Recovery", id: "failure_modes_recovery", side: "right" }, 1824- { title: "Completion & Promotion", id: "completion_promotion", side: "left" } 1825- ]; 1826- 1827- const leftBlocks = []; 1828- const rightBlocks = []; 1829- 1830- scaffold.forEach(def => { 1831- const hubHit = getHubSub(def.id); 1832- const parsedHit = parsedMap[String(def.title || "").trim().toLowerCase()]; 1833- 1834- let buckets = []; 1835- if (hubHit && Array.isArray(hubHit.buckets) && hubHit.buckets.length) { 1836- buckets = cloneBuckets(hubHit); 1837- } else if (parsedHit && Array.isArray(parsedHit.buckets) && parsedHit.buckets.length) { 1838- buckets = parsedHit.buckets; 1839- } else { 1840- buckets = [{ title: "Pending content", items: [] }]; 1841- } 1842- 1843- const html = renderSubBlock(def.title, buckets); 1844- if (def.side === "left") leftBlocks.push(html); 1845- else rightBlocks.push(html); 1846- }); 1847- 1848- const leftHtml = leftBlocks.join(""); 1849- const rightHtml = rightBlocks.join(""); 1850- 1851- return overviewHtml + ` 1852-
1853-
${leftHtml}
1854-
${rightHtml}
1855-
1856- `; 1857- } 1858- 1859- const preferredOrder = [ 1860- "Prerequisites", 1861- "Installation", 1862- "Configuration", 1863- "Observable Evidence", 1864- "Validation", 1865- "Failure Modes & Recovery", 1866- "Completion & Promotion" 1867- ]; 1868- 1869- const orderedSubs = [...parsed.subcategories].sort((a, b) => { 3579- 3580-EVIDENCE: 3581-- aggregate result of all previous failure recovery checks 3582- 3583-VALIDATION: 3584-- PASS if all previous recovery checks are PASS 3585-- FAIL if any previous recovery check is FAIL 3586-- MISSING if any previous recovery check cannot be executed 3587- 3588-FAIL: 3589-- FAIL if root file recovery is false 3590-- FAIL if Overview & Scope binding recovery is false 3591-- FAIL if downstream placement recovery is false 3592- 3593-IMPACT: 3594-If this gate is bypassed, Devon may look operational while its master architecture spine remains broken at the source, category or hierarchy level.` 3595- ] 3596- } 3597- ]; 3598- const leftHtml = [ 3599: renderStructuredCard("Prerequisites", prerequisitesBuckets), 3600- renderStructuredCard("Configuration", configurationBuckets), 3601- renderStructuredCard("Observable Evidence", observableEvidenceBuckets), 3602- renderStructuredCard("Completion & Promotion", completionPromotionBuckets) 3603- ].join(""); 3604- 3605- const installationBuckets = [ 3606- { 3607- title: "Mount The Master Index As Devon's Consultable Structural Spine", 3608- items: [ 3609-`WHAT: 3610-Installation for Master Architecture Index means mounting the sovereign index as the consultable spine of Devon inside the Documentation Hub. At this point, the index stops being only a source file and becomes the live structural reference used to orient the project. 3611- 3612-WHY: 3613-This category is the system's master coordinate layer. Installation must prove that the architecture index is available where operators read the project, because every later canon, registry, deployment rule and progress document depends on a stable place inside the master topology. 3614- 3615-EVIDENCE: 3616-- file_path: /home/yeff/public_html/devon/panel/data/master_architecture_index.md 3617-- file: /home/yeff/public_html/devon/docs/index.php 3618-- expected_binding: doc.id === "master_architecture_index" && state.categoryId === "overview_scope" 3619-- expected_scope: Master Architecture Index mounted as the root readable architecture reference 3620- 3621-VALIDATION: 3622-- The Documentation Hub must expose Master Architecture Index through its Overview & Scope binding as the first structural reference for Devon 3623- 3624-FAIL: 3625-- If the index is not mounted as the readable structural spine, Installation cannot pass 3626- 3627-IMPACT: 3628-Devon loses the operational point from which every documented authority can be located, interpreted and subordinated to the master architecture.` 3629- ] 3630- }, 3631- { 3632- title: "Activate The Root Topology Without Reducing It To Generic Documentation", 3633- items: [ 3634-`WHAT: 3635-Installation must activate Master Architecture Index as a category-specific authority, not as generic documentation content. The bucket exists to confirm that Devon's root topology is presented through the branch that preserves its sovereign role. 3636- 3637-WHY: 3638-The master index cannot be treated like a reusable text block. Its job is to define the architecture order that other documents depend on. If it is installed through a generic path, the system may render content, but it fails to preserve the distinction between root authority and ordinary documentation. 3639- 3640-EVIDENCE: 3641-- file_path: /home/yeff/public_html/devon/docs/index.php 3642-- file: /home/yeff/public_html/devon/docs/index.php 3643-- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 3644- 3645-VALIDATION: 3646-- docs/index.php must route Master Architecture Index through the custom Overview & Scope branch before this Installation bucket is valid 3647- 3648-FAIL: 3649-- If Master Architecture Index falls back to generic rendering, the root topology loses its exclusive authority surface 3650- 3651-IMPACT: 3652-The project would flatten its highest architecture authority into the same treatment as ordinary documents, making category sovereignty unenforceable at the root.` 3653- ] 3654- }, 3655- { 3656- title: "Install The Index As The Parent Locator For Downstream Authorities", 3657- items: [ 3658-`WHAT: 3659-This Installation bucket must establish the Master Architecture Index as the parent locator for downstream authorities. The installed index has to make it possible to understand where scope, manifest, deployment order, sandbox environment, server registry and progress documents sit under the Devon architecture. 3660- 3661-WHY: 3662-The real installation value is not that a card appears. The value is that Devon gains a readable parent map that turns scattered canons into positioned authorities. The master index must therefore operate as the placement mechanism for the rest of the documentation system. 3663- 3664-EVIDENCE: 3665-- file_path: /home/yeff/public_html/devon/panel/data/master_architecture_index.md 3666-- file: /home/yeff/public_html/devon/docs/index.php 3667-- expected_scope: downstream authorities must remain interpretable from the root architecture index 3668- 3669-VALIDATION: 3670-- The installed category must preserve Master Architecture Index as the reference used to locate downstream documentation authorities 3671- 3672-FAIL: 3673-- If downstream authorities cannot be related back to the installed master index, the bucket remains incomplete 3674- 3675-IMPACT: 3676-Devon would keep individual authority files, but lose the parent structure that explains why each one exists where it does inside the project.` 3677- ] 3678- }, 3679- { 3680- title: "Installation Exit Gate For The Operational Master Index", 3681- items: [ 3682-`WHAT: 3683-Installation closes only when the Master Architecture Index is mounted as a live, category-bound and structurally consultable authority inside the Documentation Hub. 3684- 3685-WHY: 3686-This bucket is the point where the root index becomes operational. Passing Installation means the project can use the master index as the visible architecture spine, not merely store it as a source file or render it as a card. 3687- 3688-EVIDENCE: 3689-- aggregate result of all previous installation checks 3690- 3691-VALIDATION: 3692-- The Installation card must render from installationBuckets inside the Master Architecture Index branch bound to overview_scope 3693- 3694-FAIL: 3695-- If the index is present but not operationally mounted as Devon's structural spine, Installation must remain non-promotable 3696- 3697-IMPACT: 3698-If this gate is bypassed, Devon can claim the master index is installed while the project still lacks a reliable operating surface for reading and subordinating its architecture.` 3699- ] 3700- } 3701- ]; 3702- 3703- const validationBuckets = [ 3704- { 3705- title: "Validate The Master Index As The Only Root Topology Source", 3706- items: [ 3707-`WHAT: 3708-Validation for Master Architecture Index proves that Devon's root topology is being read from the sovereign master index and not from inferred structure, duplicated UI state or downstream category order. 3709- 3710-WHY: 3711-This category is the project spine. Validation must confirm that the system has one authoritative architecture root before any later document can claim position, dependency or governance lineage under Devon. 3712- 3713-EVIDENCE: 3714-- file_path: /home/yeff/public_html/devon/panel/data/master_architecture_index.md 3715-- file: /home/yeff/public_html/devon/docs/index.php 3716-- expected_binding: doc.id === "master_architecture_index" && state.categoryId === "overview_scope" 3717-- expected_scope: single root topology source for Devon architecture 3718- 3719-VALIDATION: -- 4076-- downstream categories can drift into false completion states 4077-- sequencing becomes easier to overstate without root dependency recovery 4078-- DH and future panel would lose dependable program-level dependency governance 4079- 4080-TRANSITION_NOTE: 4081-- this remains transitional because dependency-law recovery still targets text-declared semantics rather than machine-readable dependency contracts` 4082- ] 4083- }, 4084- { 4085- title: "Stage-regression failure", 4086- items: [ 4087-`WHAT: 4088-Failure Modes & Recovery must define what happens when already-completed Master Architecture Index stages regress back to pending placeholders or lose structured bindings 4089- 4090-WHY: 4091-the sovereign root must preserve stage maturity cumulatively, because regression at baseline level distorts the whole project's execution reading 4092- 4093-EVIDENCE: 4094-- file: /home/yeff/public_html/devon/docs/index.php 4095-- expected_structured_bindings: 4096: - renderStructuredCard("Prerequisites", prerequisitesBuckets) 4097- - renderStructuredCard("Installation", installationBuckets) 4098- - renderStructuredCard("Configuration", configurationBuckets) 4099- - renderStructuredCard("Validation", validationBuckets) 4100- - renderStructuredCard("Observable Evidence", observableEvidenceBuckets) 4101- - renderStructuredCard("Failure Modes & Recovery", failureModesRecoveryBuckets) 4102- 4103-VALIDATION: 4104-- prerequisites_structured_binding == true 4105-- installation_structured_binding == true 4106-- configuration_structured_binding == true 4107-- validation_structured_binding == true 4108-- observable_evidence_structured_binding == true 4109-- failure_recovery_structured_binding == true 4110- 4111-FAIL: 4112-- any expected structured binding missing -> FAIL 4113- 4114-RECOVERY: 4115-- restore the missing structured binding in docs/index.php 4116-- replace any accidental pending-card regression with the correct structured renderer call 4117-- reopen DH and verify stage continuity is restored visually and semantically 4118- 4119-IMPACT: 4120-- DH underreports real maturity of the sovereign root 4121-- operators lose a trustworthy stage view of baseline progress 4122-- later buckets would build on a regressed root category state` 4123- ] 4124- }, 4125- { 4126- title: "Render-path breakage", 4127- items: [ 4128-`WHAT: 4129-Failure Modes & Recovery must define how to recover when the Master Architecture Index category becomes unreadable or unstable in DH after root-bucket evolution 4130- 4131-WHY: 4132-the sovereign root cannot remain the project baseline if the consultation surface itself breaks under runtime or renderer changes 4133- 4134-EVIDENCE: 4135-- file: /home/yeff/public_html/devon/docs/index.php 4136-- validation_commands: 4137- - php -l /home/yeff/public_html/devon/docs/index.php 4138-- renderer_helpers: 4139- - renderExecutionItem 4140- - renderStructuredCard 4141- 4142-VALIDATION: 4143-- php_lint_pass == true 4144-- render_execution_item_exists == true 4145-- render_structured_card_exists == true 4146-- category_open_runtime_breakage == false 4147- 4148-FAIL: 4149-- php_lint_pass == false -> FAIL 4150-- render_execution_item_exists == false -> FAIL 4151-- render_structured_card_exists == false -> FAIL 4152-- category_open_runtime_breakage == true -> FAIL 4153- 4154-RECOVERY: 4155-- restore the last stable renderer helpers and category branch state from backup 4156-- run php lint and reopen the category in DH 4157-- only continue bucket work after the sovereign root is readable and stable again 4158- 4159-IMPACT: 4160-- the project loses the live consultation surface for its baseline category 4161-- DH trust collapses exactly where governance should be clearest 4162-- later execution work would continue on an unstable root render path` 4163- ] 4164- }, 4165- { 4166- title: "Failure-and-recovery exit gate", 4167- items: [ 4168-`WHAT: 4169-Failure Modes & Recovery is complete only when Master Architecture Index can identify, classify and restore failure across root artifact presence, DH reachability, direct rendering, two-root governance, hierarchy law, precedence law, dependency law, stage continuity and render stability 4170- 4171-WHY: 4172-the sovereign root must be recoverable across all major baseline failure domains before Completion & Promotion can legitimately claim the project root is resilient 4173- 4174-EVIDENCE: 4175-- aggregate result of all previous failure and recovery checks 4176- 4177-VALIDATION: 4178-- all_previous_checks == true 4179- 4180-FAIL: 4181-- any previous check false -> NOT COMPLETE 4182- 4183-IMPACT: 4184-- Completion & Promotion cannot be treated as legitimate 4185-- the whole Devon program remains under-recovered at its sovereign root 4186-- every downstream category would continue depending on a baseline that still cannot restore itself reliably` 4187- ] 4188- } 4189- ]; 4190- 4191- const rightHtml = [ 4192- renderStructuredCard("Installation", installationBuckets), 4193- renderStructuredCard("Validation", validationBuckets), 4194- renderStructuredCard("Failure Modes & Recovery", failureModesBuckets) 4195- ].join(""); 4196- 4197- queueMicrotask(() => { 4198- const btn = document.getElementById("master-architecture-index-overview-toggle"); 4199- const more = document.getElementById("master-architecture-index-overview-more"); 4200- if (!btn || !more) return; 4201- 4202- const toggle = () => { 4203- const expanded = btn.getAttribute("aria-expanded") === "true"; 4204- btn.setAttribute("aria-expanded", expanded ? "false" : "true"); 4205- more.hidden = expanded; 4206- more.style.display = expanded ? "none" : "grid"; 4207- btn.textContent = expanded ? "mais..." : "menos"; 4208- }; 4209- 4210- if (btn.dataset.bound !== "true") { 4211- btn.dataset.bound = "true"; 4212- btn.addEventListener("click", toggle); 4213- btn.addEventListener("keydown", (event) => { 4214- if (event.key === "Enter" || event.key === " ") { 4215- event.preventDefault(); 4216- toggle(); -- 4924- 4925-EVIDENCE: 4926-- aggregate result of all previous failure recovery checks 4927- 4928-VALIDATION: 4929-- PASS: all previous recovery checks are PASS 4930-- FAIL: at least one previous recovery check is FAIL 4931-- MISSING: at least one previous recovery check cannot be executed 4932- 4933-FAIL: 4934-- FAIL: scope source recovery false 4935-- FAIL: Overview & Scope binding recovery false 4936-- FAIL: execution admission recovery false 4937- 4938-IMPACT: 4939-If this closure is bypassed, Devon can continue operating with a project perimeter that is restored in appearance but not proven as an enforceable scope boundary.` 4940- ] 4941- } 4942- ]; 4943- const leftHtml = [ 4944: renderStructuredCard("Prerequisites", prerequisitesBuckets), 4945- renderStructuredCard("Configuration", configurationBuckets), 4946- renderStructuredCard("Observable Evidence", observableEvidenceBuckets), 4947- renderStructuredCard("Completion & Promotion", completionPromotionBuckets) 4948- ].join(""); 4949- 4950- const installationBuckets = [ 4951- { 4952- title: "Scope Boundary Mounted As Devon's Execution Perimeter", 4953- items: [ 4954-`WHAT: 4955-Installation for Project Scope Canonical is the point where Devon's declared project perimeter becomes an operative boundary for documentation and execution. The scope canon stops being only a boundary file and becomes the installed rule that decides what work belongs inside the project. 4956- 4957-WHY: 4958-This category protects Devon from execution drift. Installation must prove that the project boundary is not merely described, but mounted where later buckets, patches and documentation decisions can be judged against the authorized scope. 4959- 4960-EVIDENCE: 4961-- file_path: /home/yeff/public_html/devon/panel/data/project_scope_canonical.json 4962-- file: /home/yeff/public_html/devon/docs/index.php 4963-- expected_binding: doc.id === "project_scope" && state.categoryId === "overview_scope" 4964-- expected_scope: Project Scope Canonical mounted as Devon's execution perimeter 4965- 4966-VALIDATION: 4967-- PASS: test -f /home/yeff/public_html/devon/panel/data/project_scope_canonical.json 4968-- PASS: grep -q 'doc.id === "project_scope" && state.categoryId === "overview_scope"' /home/yeff/public_html/devon/docs/index.php 4969-- FAIL: project_scope_canonical.json absent 4970-- FAIL: project_scope + overview_scope binding absent 4971-- MISSING: required path unreadable 4972- 4973-FAIL: 4974-- FAIL: scope source condition false 4975-- FAIL: branch binding condition false 4976-- FAIL: installed scope cannot be tied to project_scope_canonical.json 4977- 4978-IMPACT: 4979-If this installation fails, Devon can keep moving operationally while lacking a mounted perimeter that separates authorized project work from uncontrolled expansion.` 4980- ] 4981- }, 4982- { 4983- title: "Authorized Scope Becomes Available Before Downstream Work Claims Legitimacy", 4984- items: [ 4985-`WHAT: 4986-This installation bucket makes the scope boundary available before downstream categories claim implementation, deployment, registry or progress legitimacy. The installed scope canon must stand in front of execution, not behind it as post-facto documentation. 4987- 4988-WHY: 4989-Project Scope Canonical exists to stop the project from validating work only because it was already performed. Installation must put scope in the decision path first, so downstream activity is measured against the canonical boundary before it is treated as Devon work. 4990- 4991-EVIDENCE: 4992-- file_path: /home/yeff/public_html/devon/panel/data/project_scope_canonical.json 4993-- file: /home/yeff/public_html/devon/docs/index.php 4994-- expected_scope: downstream execution must remain subordinate to installed project scope 4995- 4996-VALIDATION: 4997-- PASS: project_scope_canonical.json exists and Project Scope branch exists 4998-- PASS: renderStructuredCard("Installation", installationBuckets) exists inside the target branch 4999-- FAIL: Installation remains renderPendingCard("Installation") 5000-- FAIL: downstream scope relation cannot be traced to project_scope_canonical.json 5001-- MISSING: target branch cannot be isolated 5002- 5003-FAIL: 5004-- FAIL: Installation card pending 5005-- FAIL: installationBuckets array missing 5006-- FAIL: structured render call outside project_scope + overview_scope 5007- 5008-IMPACT: 5009-If this installation path fails, Devon can document execution without proving that execution was first admitted by the canonical project perimeter.` 5010- ] 5011- }, 5012- { 5013- title: "Scope Canon Installed As The Control Line Against Project Drift", 5014- items: [ 5015-`WHAT: 5016-Installation must establish Project Scope Canonical as the control line that detects when documentation, patches or operational decisions attempt to exceed the declared project frame. This bucket installs scope as a containment mechanism, not as descriptive background. 5017- 5018-WHY: 5019-The real risk this category governs is not missing text; it is scope creep entering the system as normal work. Project Scope Canonical must be installed as the authority that blocks undocumented expansion before later categories normalize it. 5020- 5021-EVIDENCE: 5022-- file_path: /home/yeff/public_html/devon/panel/data/project_scope_canonical.json 5023-- file: /home/yeff/public_html/devon/docs/index.php 5024-- expected_scope: scope canon must remain the control line for project admission and exclusion 5025- 5026-VALIDATION: 5027-- PASS: scope source exists 5028-- PASS: project_scope + overview_scope branch exists 5029-- FAIL: scope source missing 5030-- FAIL: branch missing 5031-- FAIL: execution or documentation cannot be checked against scope authority 5032-- MISSING: source state cannot be evaluated 5033- 5034-FAIL: 5035-- FAIL: project work admitted without scope source 5036-- FAIL: renderer bypasses project_scope + overview_scope 5037-- FAIL: project boundary cannot be observed before execution interpretation 5038- 5039-IMPACT: 5040-If this control line is not installed, Devon loses the mechanism that prevents unauthorized growth from becoming part of the documented project baseline.` 5041- ] 5042- }, 5043- { 5044- title: "Installation Closure For The Canonical Project Perimeter", 5045- items: [ 5046-`WHAT: 5047-Installation closes only when the scope source exists, the Overview & Scope branch is correct, and the Installation bucket is active inside the Project Scope category path. 5048- 5049-WHY: 5050-This bucket confirms that the project perimeter is operationally mounted. A PASS means Devon can use Project Scope Canonical as an installed boundary for what enters documentation, execution and promotion. 5051- 5052-EVIDENCE: 5053-- aggregate result of all previous installation checks 5054- 5055-VALIDATION: 5056-- PASS: all previous installation checks are PASS 5057-- FAIL: at least one previous installation check is FAIL 5058-- MISSING: at least one previous installation check cannot be executed 5059- 5060-FAIL: 5061-- FAIL: scope source installation false 5062-- FAIL: branch installation false 5063-- FAIL: active Installation render false 5064- -- 5439-- scope drift can spread without obvious contradiction 5440-- downstream categories may treat excluded or deferred work as committed delivery 5441-- DH and future panel lose a dependable evidence trail for project-perimeter logic 5442- 5443-TRANSITION_NOTE: 5444-- this remains transitional because inclusion-exclusion recovery still targets declared content rather than machine-readable scope boundaries` 5445- ] 5446- }, 5447- { 5448- title: "Stage-regression failure", 5449- items: [ 5450-`WHAT: 5451-Failure Modes & Recovery must define what happens when already-completed Project Scope Canonical stages regress back to pending placeholders or lose structured bindings 5452- 5453-WHY: 5454-the perimeter category must preserve maturity cumulatively, because regression at baseline scope level distorts the whole program's execution reading 5455- 5456-EVIDENCE: 5457-- file: /home/yeff/public_html/devon/docs/index.php 5458-- expected_structured_bindings: 5459: - renderStructuredCard("Prerequisites", prerequisitesBuckets) 5460- - renderStructuredCard("Installation", installationBuckets) 5461- - renderStructuredCard("Configuration", configurationBuckets) 5462- - renderStructuredCard("Validation", validationBuckets) 5463- - renderStructuredCard("Observable Evidence", observableEvidenceBuckets) 5464- - renderStructuredCard("Failure Modes & Recovery", failureModesRecoveryBuckets) 5465- 5466-VALIDATION: 5467-- prerequisites_structured_binding == true 5468-- installation_structured_binding == true 5469-- configuration_structured_binding == true 5470-- validation_structured_binding == true 5471-- observable_evidence_structured_binding == true 5472-- failure_recovery_structured_binding == true 5473- 5474-FAIL: 5475-- any expected structured binding missing -> FAIL 5476- 5477-RECOVERY: 5478-- restore the missing structured binding in docs/index.php 5479-- replace any accidental pending-card regression with the correct structured renderer call 5480-- reopen DH and verify stage continuity is restored visually and semantically 5481- 5482-IMPACT: 5483-- DH underreports real maturity of the scope baseline 5484-- operators lose a trustworthy stage view of project-perimeter progress 5485-- later buckets would build on a regressed scope category state` 5486- ] 5487- }, 5488- { 5489- title: "Render-path breakage", 5490- items: [ 5491-`WHAT: 5492-Failure Modes & Recovery must define how to recover when the Project Scope Canonical category becomes unreadable or unstable in DH after scope-bucket evolution 5493- 5494-WHY: 5495-the perimeter baseline cannot remain authoritative if the consultation surface itself breaks under renderer or runtime changes 5496- 5497-EVIDENCE: 5498-- file: /home/yeff/public_html/devon/docs/index.php 5499-- validation_commands: 5500- - php -l /home/yeff/public_html/devon/docs/index.php 5501-- renderer_helpers: 5502- - renderExecutionItem 5503- - renderStructuredCard 5504- 5505-VALIDATION: 5506-- php_lint_pass == true 5507-- render_execution_item_exists == true 5508-- render_structured_card_exists == true 5509-- category_open_runtime_breakage == false 5510- 5511-FAIL: 5512-- php_lint_pass == false -> FAIL 5513-- render_execution_item_exists == false -> FAIL 5514-- render_structured_card_exists == false -> FAIL 5515-- category_open_runtime_breakage == true -> FAIL 5516- 5517-RECOVERY: 5518-- restore the last stable renderer helpers and project_scope branch state from backup 5519-- run php lint and reopen the category in DH 5520-- only continue scope-bucket work after the perimeter surface is readable and stable again 5521- 5522-IMPACT: 5523-- the project loses the live consultation surface for official scope 5524-- DH trust collapses exactly where mission-boundary control should be clearest 5525-- later execution work would continue on an unstable scope render path` 5526- ] 5527- }, 5528- { 5529- title: "Failure-and-recovery exit gate", 5530- items: [ 5531-`WHAT: 5532-Failure Modes & Recovery is complete only when Project Scope Canonical can identify, classify and restore failure across scope artifact presence, master registration, Phase 01 placement, DH reachability, direct rendering, outcome-boundary integrity, inclusion-exclusion integrity, stage continuity and render stability 5533- 5534-WHY: 5535-the official project perimeter must be recoverable across all major baseline scope failure domains before Completion & Promotion can legitimately claim that mission control is resilient 5536- 5537-EVIDENCE: 5538-- aggregate result of all previous failure and recovery checks 5539- 5540-VALIDATION: 5541-- all_previous_checks == true 5542- 5543-FAIL: 5544-- any previous check false -> NOT COMPLETE 5545- 5546-IMPACT: 5547-- Completion & Promotion cannot be treated as legitimate 5548-- the whole Devon program remains under-recovered at perimeter-governance level 5549-- every downstream category would continue depending on a scope baseline that still cannot restore itself reliably` 5550- ] 5551- } 5552- ]; 5553- 5554- const rightHtml = [ 5555- renderStructuredCard("Installation", installationBuckets), 5556- renderStructuredCard("Validation", validationBuckets), 5557- renderStructuredCard("Failure Modes & Recovery", failureModesBuckets) 5558- ].join(""); 5559- 5560- return { 5561- kind: "html", 5562- content: overviewHtml + ` 5563-
5564-
${leftHtml}
5565-
${rightHtml}
5566-
5567- ` 5568- }; 5569- } 5570- 5571-if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 5572- const renderPendingCard = (title) => ` 5573-