===== 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") { 2958:if (doc.id === "card_contract_minimums" && state.categoryId === "architecture_engineering_core") { 3059:if (doc.id === "panel_data_contract" && state.categoryId === "architecture_engineering_core") { 3160:if (doc.id === "panel_component_contract" && state.categoryId === "architecture_engineering_core") { 3261:if (doc.id === "panel_sync_contract" && state.categoryId === "architecture_engineering_core") { 3362:if (doc.id === "panel_canonical_tree" && state.categoryId === "architecture_engineering_core") { 3463:if (doc.id === "panel_navigation_spec" && state.categoryId === "architecture_engineering_core") { 3564:if (doc.id === "panel_ui_blueprint" && state.categoryId === "architecture_engineering_core") { 3665:if (doc.id === "canonical_matrix_v1" && state.categoryId === "architecture_engineering_core") { 3766:if (doc.id === "cfc" && state.categoryId === "cognitive_flow") { 3867:if (doc.id === "ccc" && state.categoryId === "cognitive_flow") { 3968:if (doc.id === "cdms" && state.categoryId === "containerization") { 4070:if (doc.id === "lpc" && state.categoryId === "latency_performance") { 4172:if (doc.id === "nrc" && state.categoryId === "noise_reduction") { 4274:if (doc.id === "oac" && state.categoryId === "observability_audit") { 4376:if (doc.id === "panel_runtime_bridge" && state.categoryId === "observability_audit") { 4478:if (doc.id === "host_runtime_support" && state.categoryId === "observability_audit") { 4580:if (doc.id === "docker_runtime_support" && state.categoryId === "observability_audit") { 4682:if (doc.id === "runtime_status_support" && state.categoryId === "observability_audit") { 4784:if (doc.id === "runtime_row_semantics" && state.categoryId === "observability_audit") { 4886:if (doc.id === "sec" && state.categoryId === "security_governance") { 4988:if (doc.id === "host_security" && state.categoryId === "security_governance") { 5090:if (doc.id === "app_security" && state.categoryId === "security_governance") { 5192:if (doc.id === "module_security" && state.categoryId === "security_governance") { 5294:if (doc.id === "runtime_security" && state.categoryId === "security_governance") { 5396:if (doc.id === "delivery_security" && state.categoryId === "security_governance") { 5498:if (doc.id === "approval_policy" && state.categoryId === "security_governance") { 5600:if (doc.id === "memory_isolation" && state.categoryId === "security_governance") { 5702:if (doc.id === "security_monitoring" && state.categoryId === "security_governance") { 5804:if (doc.id === "ofc" && state.categoryId === "operational_flows") { 5906:if (doc.id === "subcategory_pipelines" && state.categoryId === "delivery_layer") { 6008:if (doc.id === "panel_content_index" && state.categoryId === "delivery_layer") { 6109:if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 6235:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 6446:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 6678:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 6795:- expected_binding: if (doc.id === "master_architecture_index" && state.categoryId === "overview_scope") { 7389:if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 7549:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 7785:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 8022:- expected_binding: if (doc.id === "project_scope" && state.categoryId === "overview_scope") { 8723:if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 8883:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 9119:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 9356:- expected_binding: if (doc.id === "deployment_order" && state.categoryId === "overview_scope") { 10125:if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 10285:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 10521:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 10758:- expected_binding: if (doc.id === "sandbox_environment" && state.categoryId === "overview_scope") { 11487:if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 11590:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 12092:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 12709:- expected_binding: if (doc.id === "panel_manifest" && state.categoryId === "overview_scope") { 12835:if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 12995:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 13231:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 13632:- expected_binding: if (doc.id === "server_registry" && state.categoryId === "overview_scope") { 14357:if (doc.id === "project_progress_canonical" && state.categoryId === "overview_scope") { 16393: if (doc.id === "master_architecture_index" && state.categoryId === "project_progress_model") { 16484: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") || (doc.id === "card_contract_minimums" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_data_contract" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_component_contract" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_sync_contract" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_canonical_tree" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_navigation_spec" && state.categoryId === "architecture_engineering_core") || (doc.id === "panel_ui_blueprint" && state.categoryId === "architecture_engineering_core") || (doc.id === "canonical_matrix_v1" && state.categoryId === "architecture_engineering_core") || (doc.id === "cfc" && state.categoryId === "cognitive_flow") || (doc.id === "ccc" && state.categoryId === "cognitive_flow") || (doc.id === "cdms" && state.categoryId === "containerization") || (doc.id === "lpc" && state.categoryId === "latency_performance") || (doc.id === "nrc" && state.categoryId === "noise_reduction") || (doc.id === "oac" && state.categoryId === "observability_audit") || (doc.id === "panel_runtime_bridge" && state.categoryId === "observability_audit") || (doc.id === "host_runtime_support" && state.categoryId === "observability_audit") || (doc.id === "docker_runtime_support" && state.categoryId === "observability_audit") || (doc.id === "runtime_status_support" && state.categoryId === "observability_audit") || (doc.id === "runtime_row_semantics" && state.categoryId === "observability_audit") || (doc.id === "sec" && state.categoryId === "security_governance") || (doc.id === "host_security" && state.categoryId === "security_governance") || (doc.id === "app_security" && state.categoryId === "security_governance") || (doc.id === "module_security" && state.categoryId === "security_governance") || (doc.id === "runtime_security" && state.categoryId === "security_governance") || (doc.id === "delivery_security" && state.categoryId === "security_governance") || (doc.id === "approval_policy" && state.categoryId === "security_governance") || (doc.id === "memory_isolation" && state.categoryId === "security_governance") || (doc.id === "security_monitoring" && state.categoryId === "security_governance") || (doc.id === "ofc" && state.categoryId === "operational_flows") || (doc.id === "subcategory_pipelines" && state.categoryId === "delivery_layer") || (doc.id === "panel_content_index" && state.categoryId === "delivery_layer"); ===== 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: CUSTOM_BRANCH - panel_data_contract: CUSTOM_BRANCH - panel_component_contract: CUSTOM_BRANCH - panel_sync_contract: CUSTOM_BRANCH - panel_canonical_tree: CUSTOM_BRANCH - panel_navigation_spec: CUSTOM_BRANCH - panel_ui_blueprint: CUSTOM_BRANCH - canonical_matrix_v1: CUSTOM_BRANCH ===== 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