# DEVON CONTINUITY

<!-- CHECKPOINT_2026_04_03_SEMANTIC_RUNTIME_UI -->

## 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.

<!-- /CHECKPOINT_2026_04_03_SEMANTIC_RUNTIME_UI -->


### 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`