83 lines
3.5 KiB
Markdown
83 lines
3.5 KiB
Markdown
---
|
|
id: PLN-0050
|
|
ticket: runtime-mode-separation-game-system
|
|
title: System Pipeline Evidence and Learning
|
|
status: open
|
|
created: 2026-05-14
|
|
completed:
|
|
ref_decisions: [DEC-0023]
|
|
tags: [runtime, firmware, hub, system-apps, validation, lessons]
|
|
---
|
|
|
|
## Briefing
|
|
|
|
This plan closes the implementation family by collecting evidence that `DEC-0023` was executed and preparing the required learning artifact after spec/code publication.
|
|
|
|
## Decisions de Origem
|
|
|
|
- `DEC-0023` - System Pipeline Separation.
|
|
|
|
## Alvo
|
|
|
|
Produce test evidence and a didactic lesson showing how to reason about profile-specific pipelines after the implementation plans are complete.
|
|
|
|
## Escopo
|
|
|
|
- Run the relevant firmware/system/host checks after `PLN-0046` through `PLN-0049`.
|
|
- Verify that no `System` path enters `GameRunningStep`.
|
|
- Verify that the game pipeline remains unchanged in behavior.
|
|
- Create an English lesson under `discussion/lessons/DSC-0031-runtime-mode-separation-game-system/`.
|
|
- Move the discussion lifecycle forward only after implementation evidence exists.
|
|
|
|
## Fora de Escopo
|
|
|
|
- No new architecture decisions.
|
|
- No code or spec changes except small documentation links required by housekeeping.
|
|
- No lesson before the execution result is published.
|
|
|
|
## Plano de Execucao
|
|
|
|
### Step 1 - Collect automated evidence
|
|
|
|
**What:** Run package-level checks covering firmware dispatch, system runtime gates, and host integration fallout.
|
|
**How:** Execute the test commands from the preceding plans and record the passing command set in the PR or execution notes.
|
|
**File(s):** Test output only.
|
|
|
|
### Step 2 - Collect routing evidence
|
|
|
|
**What:** Demonstrate that `AppMode::System` does not enter `GameRunningStep`.
|
|
**How:** Use tests, targeted logs, or debugger-visible state assertions to show `System` reaches the Runtime/Hub system path while `Game` reaches `GameRunning`.
|
|
**File(s):** Tests from `PLN-0047` and `PLN-0048`.
|
|
|
|
### Step 3 - Write the lesson
|
|
|
|
**What:** Explain the resulting mental model.
|
|
**How:** Create a lesson that distinguishes profile discriminator, pipeline routing, public ABI, syscall transport, and deferred WindowManager/filesystem contracts.
|
|
**File(s):** `discussion/lessons/DSC-0031-runtime-mode-separation-game-system/LSN-0040-system-pipeline-separation.md`.
|
|
|
|
### Step 4 - Housekeep the discussion state
|
|
|
|
**What:** Close the workflow once implementation and lesson are complete.
|
|
**How:** Use the discussion housekeeping flow to mark completed plans and discussion state after the lesson exists.
|
|
**File(s):** `discussion/index.ndjson`, lesson artifact.
|
|
|
|
## Criterios de Aceite
|
|
|
|
- [ ] Firmware and system runtime tests pass after the implementation family.
|
|
- [ ] Evidence shows `System` does not enter `GameRunningStep`.
|
|
- [ ] Evidence shows `Game` still enters and behaves through `GameRunningStep`.
|
|
- [ ] The lesson is in English and links back to `DEC-0023`.
|
|
- [ ] Housekeeping is run only after code/spec execution is complete.
|
|
|
|
## Tests / Validacao
|
|
|
|
- `cargo test -p prometeu-firmware`
|
|
- `cargo test -p prometeu-system`
|
|
- `cargo test -p prometeu-host-desktop-winit` if host-observable state changed.
|
|
- `discussion validate` after housekeeping, or document existing unrelated index validation debt if it still blocks.
|
|
|
|
## Riscos
|
|
|
|
- Existing discussion index path debt may block deterministic CLI housekeeping; if so, record it separately and avoid broad historical rewrites inside this implementation family.
|
|
- A lesson written before execution would become intent rather than learning; this plan explicitly sequences it after evidence.
|