prometeu-runtime/discussion/workflow/plans/PLN-0039-incremental-runtime-domain-suite-split-and-baselines.md

id	ticket	title	status	created	completed	tags
PLN-0039	runtime-edge-test-plan	Plan - Incremental Runtime Domain Suite Split and Baselines	done	2026-04-20	2026-04-20	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.