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