# INITKOA CONTEXT PACK repository: Rejean-McCormick/LevelUpDiag-Koa-Linux source_commit: bfdb935861ab83bb4f4bf6d210c81db93acee888 source_mode: git working_tree_markdown: clean working_tree_selected: clean selection_mode: markdown wiki_source_commit: none wiki_working_tree_markdown: none policy_version: 2026-09-10.13 repo_files: 8 wiki_files: 0 source_files: 8 included_files: 8 excluded_files: 0 duplicate_files: 0 content_bytes: 20309 authority_counts: {"reference":8} content_role_counts: {"knowledge":8} generated_at: 2026-09-10T13:04:20-04:00 files: 8 content_sha256: 3f08f2acdbb292bfd016a25d8c1a26eb1ae8020f2fee1567c27615a9a03cb0b5 ================================================================================================ FILE INDEX ================================================================================================ 1. [reference] [knowledge] docs/ARCHITECTURE.md | bytes=2201 | sha256=f27974dcaa1d83065f1e3e528ea626a91ad4051207b7f70bd9b16d6461903a22 2. [reference] [knowledge] docs/KOALI_SEQUENCE.md | bytes=1860 | sha256=5250504654d0e3f25bd6e2295cfd353ec2db095b205a90ab3bec2f9baa12967a 3. [reference] [knowledge] docs/MIGRATION_FROM_V1.md | bytes=939 | sha256=f322541d47fea81a45bb2b11fc1371d289f7dbc129adf130c6f7c44ad575365c 4. [reference] [knowledge] docs/README.md | bytes=505 | sha256=b398a84dc066940915d535c8e2d9ee1925c2c69431ca9b06e29ec11ffecde331 5. [reference] [knowledge] docs/RESULT_MODEL.md | bytes=1641 | sha256=9b4497138697abd4c398361e4f7a6f9f94bc975f585f5b465c58981c2d813de7 6. [reference] [knowledge] docs/SECURITY_MODEL.md | bytes=797 | sha256=b8cf498f59c451104f4d8bdc5dba9524477b95100313ce214bca861732f806a3 7. [reference] [knowledge] docs/UI_MODULARITY.md | bytes=2668 | sha256=0ef0d3068065a42f96b6383ec9182a0cb2ff211553eea07aa23642baaf04910b 8. [reference] [knowledge] README.md | bytes=9698 | sha256=c511f8fbb9d5799ab14aea2c53f791f36b13ca943ff09d5d5801dbf7363a80c1 ================================================================================================ FILE: docs/ARCHITECTURE.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f27974dcaa1d83065f1e3e528ea626a91ad4051207b7f70bd9b16d6461903a22 CONTENT_BYTES: 2201 ================================================================================================ # Architecture — Debug-first policy LevelUpDiag-Koali separates **observation**, **conformance**, and **release provenance**. The tool code lives in this directory and generated evidence lives under `.levelupdiag/` in the target. Commands execute with `shell=false`, bounded/redacted output, explicit timeouts, and process isolation. ## DEBUG DEBUG is the default execution policy. It does not snapshot or compare Git state globally. Dependency verdicts do not suppress downstream diagnostic levels. A local `BLOCKED`, `FAIL`, `CONFIG_ERROR`, or repository formality remains evidence for that level while independent diagnostics continue. The default `debug` campaign excludes N02 Repository/Structure, N03 Documentation, and N11 Delivery. ## VALIDATION VALIDATION includes formal conformance levels. Hard prerequisite states (`BLOCKED`, `ERROR`, `INFRA_ERROR`, `CONFIG_ERROR`) can block declared dependants. Git cleanliness is still not a global prerequisite. ## RELEASE RELEASE enables tracked Git-state protection and strict dependency semantics. This is the only default mode where before/after Git tracked-state comparison is part of campaign integrity. ## Dependency topology Repository conformance is no longer a functional prerequisite. N04 depends on N01 rather than N02; N05 depends on N01/N04; runtime gates depend on N01/N04/N05. This prevents repository formalities from entering a functional debug selection through transitive dependencies. ## Modular product UI boundary LevelUpDiag is an observer of Koali product-UI modularity, not the owner of that architecture. N06 can consume an explicit local `ui_modularity` policy and test product availability, product-owned standalone markers, public integrated-contribution markers, and explicitly forbidden private cross-product UI dependency tokens. The check is intentionally configuration-driven so LevelUpDiag does not hard-code product frameworks or manifest names. Optional product absence is a valid state and reports `PASS` for the removal observation; required product absence can report `BLOCKED`. The core `stabilization` campaign does not select N06, so UI-product lifecycle remains outside core stabilization. ================================================================================================ FILE: docs/KOALI_SEQUENCE.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 5250504654d0e3f25bd6e2295cfd353ec2db095b205a90ab3bec2f9baa12967a CONTENT_BYTES: 1860 ================================================================================================ # Koali sequence — LevelUpDiag 2.2 ## Phase 1: stabilize Koali core Run `stabilization` first. It validates diagnostic integrity, the complete host/build environment, canonical contracts, and native component validations. Independent subsystems are intentionally deferred and must not be marked pinned or activable unless their real source authority has been integrated and verified. ```text PREPARE DEVELOPMENT ENVIRONMENT → LevelUpDiag stabilization → build/verify native Koali components → repeat until the environment is stable ``` Deferred during this phase: - Konnaxion: placeholder until real integration. - Ariane: integrate and test next. - Orgo: draft/not admitted. - Semantik Architect: deferred/not admitted. ## Phase 2: core runtime When a bootable image exists, run `stabilization-runtime`. N08/N09/N10 remain diagnostic in DEBUG; final-profile blockers remain visible but do not redefine the core-stabilization scope. ## Phase 3: subsystem integration Integrate each independent subsystem with real source pins, digests, license/documentation evidence, adapter tests, and activation evidence. For products that expose a UI, preserve the Koali modularity boundary during this phase: - standalone product operation remains product-owned; - integrated UI contributions are declared explicitly rather than copied into another product; - optional product removal is a supported state; - private cross-product UI imports are not used as a substitute for shared Koali UI primitives or public integration contracts. N06 can diagnose these properties only when their concrete markers and dependency scan inputs are configured locally. It does not define the UI contract itself. ## Phase 4: final target Use `validation` and `release` against the unchanged canonical `sovereign-linux-node` target. No partial conformance is claimed. ================================================================================================ FILE: docs/MIGRATION_FROM_V1.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: f322541d47fea81a45bb2b11fc1371d289f7dbc129adf130c6f7c44ad575365c CONTENT_BYTES: 939 ================================================================================================ # Migration notes — v2.1 debug-first policy Version 2.1 retains N00-N11 and the existing Koali validators but changes orchestration semantics. Key changes: 1. `debug` is the default campaign and mode. 2. N02 Repository/Structure and N03 Documentation are removed from the primary debug campaign. 3. N04-N10 no longer depend transitively on N02. 4. DEBUG has no dependency-blocking verdict set: independent evidence continues to be collected. 5. DEBUG does not snapshot or compare tracked Git state. 6. VALIDATION keeps conformance checks and strict dependency semantics without global Git cleanliness enforcement. 7. RELEASE keeps strict tracked-state protection and delivery/finalization checks. 8. Campaign summaries separate diagnostic execution, testability, and conformance. Historical campaign names remain available for compatibility, but new automation should use `debug`, `structure`, `validation`, or `release` explicitly. ================================================================================================ FILE: docs/README.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: b398a84dc066940915d535c8e2d9ee1925c2c69431ca9b06e29ec11ffecde331 CONTENT_BYTES: 505 ================================================================================================ # LevelUpDiag-Koali documentation - `ARCHITECTURE.md` — DEBUG / VALIDATION / RELEASE separation and dependency topology. - `KOALI_SEQUENCE.md` — N00-N11 roles and DEBUG principal selection. - `RESULT_MODEL.md` — local verdicts and campaign aggregation. - `SECURITY_MODEL.md` — bounded execution and mode-scoped Git protection. - `MIGRATION_FROM_V1.md` — migration to the v2.1 debug-first model. - `UI_MODULARITY.md` — optional N06 diagnostics for standalone/integrated product UI boundaries. ================================================================================================ FILE: docs/RESULT_MODEL.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 9b4497138697abd4c398361e4f7a6f9f94bc975f585f5b465c58981c2d813de7 CONTENT_BYTES: 1641 ================================================================================================ # Result model Level verdicts remain: `PASS`, `WARN`, `FAIL`, `SKIP`, `BLOCKED`, `PARTIAL`, `ERROR`, `INFRA_ERROR`, `CONFIG_ERROR`. Their meaning is local to a level. `BLOCKED` means that level could not establish its intended evidence because a prerequisite was unavailable. It does not mean every independent diagnostic must stop. Campaign summaries add: - `diagnostic_mode`: `debug`, `validation`, or `release`; - `execution_verdict`: whether the diagnostic machinery completed without `ERROR`/`INFRA_ERROR`; - `testability`: `COMPLETE` or `PARTIAL`; - `conformance_verdict`: `NOT_EVALUATED` in DEBUG, otherwise the strict campaign verdict. ## DEBUG aggregation - any `ERROR`/`INFRA_ERROR` -> campaign `ERROR`; - any other non-PASS local verdict -> campaign `WARN`; - otherwise -> `PASS`. Thus target failures and missing prerequisites remain visible without turning routine development diagnosis into a global `BLOCKED` state. ## VALIDATION / RELEASE aggregation Strict evidence semantics are preserved. `FAIL` remains failure, required unavailable evidence can block completion, and configuration/diagnostic errors are not accepted as success. ## Optional product removal evidence An explicitly configured UI product with `required: false` can be absent and still produce a local `PASS` observation in the N06 UI-modularity diagnostic. This represents the intended independent-removal property, not a claim that the product was tested. A configured required product that is absent reports `BLOCKED`; missing configured markers on an available product report `FAIL`; invalid diagnostic configuration reports `CONFIG_ERROR`. ================================================================================================ FILE: docs/SECURITY_MODEL.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: b8cf498f59c451104f4d8bdc5dba9524477b95100313ce214bca861732f806a3 CONTENT_BYTES: 797 ================================================================================================ # Security model LevelUpDiag-Koali remains read-oriented and bounded: - commands execute as argument arrays with `shell=false`; - stdout/stderr capture is bounded and redacted; - target mutation is disabled by default; - network use is disabled unless explicitly enabled; - referenced gate reports are accepted only from bounded paths inside the target repository; - worker timeouts remain explicit. Git tracked-state protection is now **mode-scoped**: - DEBUG: disabled; Git provenance is not a prerequisite for diagnosis; - VALIDATION: disabled globally; N02 can still observe repository state when selected; - RELEASE: enabled and tracked-state mutation during diagnostics is an error. This keeps release provenance strict without making Git formalities part of ordinary system debugging. ================================================================================================ FILE: docs/UI_MODULARITY.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: 0ef0d3068065a42f96b6383ec9182a0cb2ff211553eea07aa23642baaf04910b CONTENT_BYTES: 2668 ================================================================================================ # Modular product UI diagnostics LevelUpDiag-Koali treats modular product UI behavior as an **integration diagnostic**, not as a definition of Koali user-interface architecture. ## Authority boundary Koali canonical documentation and each product's admitted public contract define what counts as its standalone entry point, integrated contribution, commands, routes, surfaces, inspector declarations, or other UI assets. LevelUpDiag only evaluates explicit diagnostic configuration. It MUST NOT: - make kOA Spaces a mandatory runtime for a product UI; - make Konnaxion, Orgo, Kristal, or another product a mandatory UI dependency of another product; - invent a universal product-manifest filename; - copy product business semantics into diagnostic code; - treat an intentionally removed optional product as a Koali core failure. ## Configuration The optional `ui_modularity` object is read from the normal LevelUpDiag configuration merge. ```json { "ui_modularity": { "enabled": true, "base_root": "..", "products": [ { "id": "product-id", "root": "product-repository", "required": false, "standalone_markers": ["path/declared/by/product"], "integration_markers": ["path/declared/by/integration-contract"], "scan_files": ["package-or-source-file"], "forbidden_private_ui_tokens": ["private-import-token"] } ] } } ``` `base_root` is resolved relative to the LevelUpDiag tool root. Product roots can be absolute or relative to that base. Marker and scan paths are product-relative and cannot escape the configured product repository. ## Verdicts - optional product absent: `PASS` — removal is accepted; - required product absent: `BLOCKED`; - available product with configured markers present: `PASS`; - configured marker missing: `FAIL`; - configured forbidden private UI token found: `FAIL`; - invalid paths or malformed configuration: `CONFIG_ERROR`; - unreadable configured scan input: `INFRA_ERROR`. A `PASS` for an absent optional product means only that the removal state is permitted. It is not positive functional evidence for that product. ## Campaign placement The check runs from N06 Integrations. The default `stabilization` campaign remains N00/N01/N04/N05 and therefore does not depend on UI products. Broader `debug`, `validation`, and `release` selections can include N06 according to their existing policies. ## Security and boundedness The check is read-only. It reads only explicit marker paths and explicit scan files. Each scan file is bounded to 512 KiB of text and only reports configured token/path metadata, not arbitrary source content. ================================================================================================ FILE: README.md AUTHORITY: reference CONTENT_ROLE: knowledge CONTENT_SHA256: c511f8fbb9d5799ab14aea2c53f791f36b13ca943ff09d5d5801dbf7363a80c1 CONTENT_BYTES: 9698 ================================================================================================ # LevelUpDiag-Koali v2.3 LevelUpDiag-Koali 2.3 is a **core-stabilization-first** diagnostic suite for kOA-Linux. The primary development objective is to stabilize the Koali environment and native core before independent subsystems are integrated. Its primary rules are: > If a formality does not materially prevent observation or execution of the system, it must not block DEBUG. > > Missing independent subsystems must not be falsified as admitted dependencies merely to advance core stabilization. Repository cleanliness, frozen architecture conformance, documentation conformance, delivery residue, signatures, and release provenance remain available as validation/finalization evidence, but they are no longer prerequisites for the main debug path. ## Koali core stabilization scope The default campaign is now `stabilization`: ```text N00 Diagnostic Integrity N01 Environment N04 Contracts N05 Components ``` This scope deliberately defers independent subsystems while the Koali host/build/runtime environment is being stabilized: ```text Konnaxion placeholder_until_integration Ariane deferred_until_koali_integration_test Orgo draft_not_admitted Semantik Architect deferred_not_admitted ``` This does **not** weaken or rewrite the canonical `sovereign-linux-node` profile. Full-target VALIDATION and RELEASE remain strict and can still report those subsystem authorities as unresolved. The `stabilization-runtime` campaign adds N08/N09/N10 when a bootable image/runtime context becomes available, while retaining DEBUG non-blocking campaign semantics. ## Repository layout The specialization remains a sibling of the kOA-Linux repository: ```text C:\mycode\kOA-Linux\ ├── koa-linux\ └── LevelUpDiag-Koali\ ``` The default target is `../koa-linux`. Local developer utilities such as `GitSink.bat` are not a DEBUG gate. If an underlying kOA conformance validator reports a local utility or generated build residue, that individual level may report `FAIL/WARN`, but DEBUG continues collecting independent functional/runtime evidence. ## Modes ### DEBUG — default Use while developing, loading, testing, or diagnosing kOA-Linux. - no tracked-Git-state protection; - no dependency verdict blocks another level; - repository/documentation/release formalities are excluded from the default campaign; - `FAIL`, `BLOCKED`, `CONFIG_ERROR`, `SKIP`, and `PARTIAL` remain visible at their local level but make the campaign `WARN`, not globally `BLOCKED`; - `ERROR`/`INFRA_ERROR` still mean the diagnostic execution itself had a problem. ### VALIDATION Use to check repository/documentation/conformance in addition to functional gates. Dependencies can be blocked by `BLOCKED`, `ERROR`, `INFRA_ERROR`, or `CONFIG_ERROR`, but a clean Git worktree is not imposed globally. ### RELEASE Use for strict finalization. Tracked Git state is snapshotted before and after the campaign; mutation by diagnostics is an error. ## Normal execution ```bash python levelupdiag.py doctor python levelupdiag.py list python levelupdiag.py run stabilization ``` Explicit modes are supported: ```bash python levelupdiag.py run N08,N09,N10 --mode debug python levelupdiag.py run validation --mode validation python levelupdiag.py run release --mode release ``` Windows launcher default: ```bat RUN_LEVELUPDIAG.bat ``` Linux/macOS launcher default: ```bash ./RUN_LEVELUPDIAG.sh ``` Both now default to the `stabilization` campaign. ## Console `LEVELUPDIAG_CONSOLE.pyw` exposes three policies: - **DEBUG — non bloquant** - **VALIDATION — conformité** - **RELEASE — strict** Presets: - **STABILISATION KOALI**: N00, N01, N04, N05 - **RUNTIME CORE**: N00, N01, N04, N05, N08, N09, N10 - **DEBUG COMPLET**: N00, N01, N04-N10 - **STRUCTURE**: N00-N03 - **VALIDATION**: N00-N10 - **RELEASE**: N00-N11 N02 Repository and N03 Documentation are intentionally absent from DEBUG PRINCIPAL. ## Level sequence ```text N00 Diagnostic Integrity N01 Environment N02 Repository / Structure N03 Documentation N04 Contracts N05 Components N06 Integrations N07 Profiles N08 Security Runtime N09 Offline Runtime N10 System Runtime N11 Delivery ``` All levels remain serial for stable evidence ordering. Functional levels no longer depend transitively on N02. Selecting `N08,N09,N10` adds functional prerequisites N00, N01, N04 and N05, but not repository/documentation formalities. ## Campaigns - `stabilization` — primary pre-subsystem Koali core stabilization, mode DEBUG. - `stabilization-runtime` — core runtime qualification when image/QEMU context exists, mode DEBUG. - `debug` — broader development diagnosis including integration/profile/runtime levels, mode DEBUG. - `structure` — repository/documentation checks, mode VALIDATION. - `validation` — N00-N10, mode VALIDATION. - `release` — N00-N11, mode RELEASE. Compatibility aliases remain: `preflight`, `core`, `standard`, `delivery`, `full`. ## Modular product UI diagnostics LevelUpDiag does **not** define the Koali UX, shell implementation, product manifest filename, or product framework. Those remain owned by Koali documentation and the individual products. N06 can optionally diagnose consequences of the Koali modular-UI contract when `ui_modularity.enabled` is set in local configuration. The diagnostic is read-only and configuration-driven: - an optional product repository may be absent and that absence is accepted as an independent-removal state; - a required product repository that is unavailable reports `BLOCKED`; - configured standalone markers can verify that a product retains its own runnable UI entry point or equivalent product-owned surface; - configured integration markers can verify that the product exposes its declared integrated contribution; - configured dependency scan files can reject explicit private cross-product UI dependency tokens; - LevelUpDiag does not invent or hard-code Orgo, Konnaxion, Kristal, Spaces, or other product UI file names. Example local policy: ```json { "ui_modularity": { "enabled": true, "base_root": "..", "products": [ { "id": "example-product", "root": "example-product", "required": false, "standalone_markers": [""], "integration_markers": [""], "scan_files": [""], "forbidden_private_ui_tokens": [""] } ] } } ``` The example deliberately uses placeholders: concrete marker paths belong to each product's admitted contract, not to LevelUpDiag. This check is outside the `stabilization` campaign and therefore cannot turn a missing optional UI product into a Koali core-stabilization prerequisite. ## Result model A campaign summary now separates: ```text verdict execution_verdict system testability conformance_verdict ``` In DEBUG, conformance is reported as `NOT_EVALUATED` by the campaign summary. Local level findings are still preserved exactly. Example: ```text LevelUpDiag debug [DEBUG] - WARN Diagnostic execution: PASS System testability: PARTIAL Conformance: NOT_EVALUATED ``` That means the diagnostic completed and found unavailable/failed local checks; it does **not** mean the whole debug session is blocked. ## Git policy DEBUG does not inspect Git globally before/after a run. N02 performs Git observations only when N02 is explicitly selected. A dirty worktree in N02 is advisory in DEBUG. RELEASE retains tracked-state mutation protection because release/finalization provenance is a separate concern. ## kOA-specific validation commands Default commands are still the canonical public kOA-Linux vectors: ```text Documentation uv run --frozen python docs/tools/validate_docs.py Contracts uv run --frozen python ci/scripts/run-contracts.py Components uv run --frozen python ci/scripts/run-components.py Profiles uv run --frozen pytest -q tests/profiles Security uv run --frozen python ci/scripts/run-security.py Offline uv run --frozen python ci/scripts/run-offline.py System uv run --frozen python ci/scripts/run-system-tests.py ``` Koali gate markers such as `security: blocked`, `offline: blocked`, and `system: blocked` remain local level verdicts. In DEBUG they do not prevent independent levels from running. ## Evidence Evidence remains under the target repository: ```text .levelupdiag/ ├── runs// │ ├── effective_config.json │ ├── summary.json │ ├── summary.txt │ └── levels/Nxx/result.json └── latest/ ``` Commands use `shell=false`; output is bounded and redacted; target mutation remains disabled by configuration. ## Version 2.3.0 2.3.0 keeps the 2.2 core-stabilization policy and adds opt-in N06 diagnostics for modular product user interfaces. The new check validates only explicitly configured product roots, standalone/integration markers, and private-dependency tokens; it does not define the Koali UI architecture itself. Optional product absence is accepted as a valid independent-removal state. It also fixes the desktop console's **DEBUG COMPLET** preset so it selects the `debug` campaign rather than `stabilization`. ## Version 2.2.0 2.2.0 changed the default workflow from broad debug to explicit **Koali core stabilization before subsystem integration**. It also requires the core Rust/native toolchain in N01 (`git`, `cargo`, `rustc`, `cc`), adds qualification-scope metadata to campaign summaries, and provides compatibility aliases plus `scripts/run_level.py` for older Koali Control Panel integrations.