prometeu-runtime/discussion/workflow/plans/PLN-0039-incremental-runtime-domain-suite-split-and-baselines.md
2026-04-20 18:08:10 +01:00

133 lines
4.4 KiB
Markdown

---
id: PLN-0039
ticket: runtime-edge-test-plan
title: Plan - Incremental Runtime Domain Suite Split and Baselines
status: done
created: 2026-04-20
completed: 2026-04-20
tags: [tests, runtime, fs, asset, organization]
---
## Briefing
This plan turns the current monolithic runtime-edge suite into clearer domain-owned test surfaces over time, while preserving the existing breadth of coverage already present in `prometeu-system`.
## Decisions de Origem
- `DEC-0020`
## Alvo
Establish clearer test ownership and baseline evidence for:
- `system/runtime`
- `fs`
- `asset/bank`
Do this incrementally, without a one-shot refactor of the whole runtime test tree.
## Escopo
- Split the current runtime-edge suite along canonical domain lines as work touches those areas.
- Preserve or improve current behavioral coverage while improving maintainability.
- Establish explicit baseline evidence for the non-priority domains, starting from `0` if needed.
## Fora de Escopo
- Rewriting all tests in one pass.
- Large behavioral refactors unrelated to test structure.
- Introducing strict non-zero domain thresholds immediately.
## Plano de Execucao
### Step 1 - Define the split targets for the existing monolithic suite
**What:**
Map the current `virtual_machine_runtime/tests.rs` coverage into the canonical runtime domains.
**How:**
Create a target decomposition for the current file, separating at least:
- `system/runtime` lifecycle and tick behavior;
- `asset/bank` status-first and preload behavior;
- `fs` and memcard-adjacent runtime cases when they belong to runtime orchestration rather than `VirtualFS` internals.
Do not move files blindly. First define the intended ownership map.
**File(s):**
- `crates/console/prometeu-system/src/virtual_machine_runtime/tests.rs`
- `crates/console/prometeu-system/src/virtual_machine_runtime/`
### Step 2 - Split the runtime suite incrementally
**What:**
Reduce the monolithic test concentration without destabilizing current coverage.
**How:**
As each domain is touched, move or extract tests into smaller modules with domain ownership.
Prefer incremental Rust module splits such as domain-focused test modules over an all-at-once rewrite.
**File(s):**
- `crates/console/prometeu-system/src/virtual_machine_runtime/tests.rs`
- new sibling test modules under `crates/console/prometeu-system/src/virtual_machine_runtime/`
### Step 3 - Preserve and expose `fs` and `asset/bank` baselines
**What:**
Make existing stronger areas explicitly visible in the new governance model.
**How:**
Use:
- `crates/console/prometeu-system/src/services/fs/virtual_fs.rs` for filesystem contract evidence;
- runtime and loader tests for `asset/bank` scenario evidence.
Capture baseline evidence even if the numeric threshold remains `0` initially.
**File(s):**
- `crates/console/prometeu-system/src/services/fs/virtual_fs.rs`
- `crates/console/prometeu-system/src/virtual_machine_runtime/tests.rs`
- `crates/console/prometeu-hal/src/cartridge_loader.rs`
- `crates/console/prometeu-drivers/src/asset.rs`
### Step 4 - Align future review with the new runtime-domain ownership
**What:**
Ensure later PRs can tell which runtime-domain tests should move with the code.
**How:**
Document or encode enough structure that maintainers can tell where to add tests for:
- lifecycle/tick behavior;
- filesystem normalization and runtime cleanup;
- asset/bootstrap/status-first flows.
**File(s):**
- runtime test modules
- repository guidance introduced by `PLN-0037`
## Criterios de Aceite
- [ ] The current monolithic runtime suite has an explicit decomposition into canonical domains.
- [ ] New or moved runtime tests follow domain ownership rather than returning to a single catch-all file.
- [ ] `fs` and `asset/bank` have baseline evidence captured under the governance model.
- [ ] The split is incremental and does not require a one-shot rewrite to start delivering value.
## Tests / Validacao
### Automated
- Run `cargo test -p prometeu-system`.
- Run any focused tests for `prometeu-hal` and `prometeu-drivers` touched during the split.
### Evidence
- Show that the domain-oriented split preserves existing runtime behaviors.
- Produce baseline coverage evidence for `system/runtime`, `fs`, and `asset/bank`.
## Riscos
- Moving tests mechanically without improving domain clarity.
- Creating fragmented helpers that are harder to reuse than the current monolith.
- Treating structural cleanup as more important than preserving behavioral coverage.