prometeu-runtime/discussion/workflow/plans/PLN-0086-end-to-end-render-boundary-validation.md

id	ticket	title	status	created	ref_decisions	tags
PLN-0086	render-frame-packet-boundary	End-to-End Render Boundary Validation	open	2026-05-25	DEC-0030	gfx renderer runtime frame-composer architecture ui pipeline

Briefing

Source decision: DEC-0030.

Add end-to-end validation proving the new boundary works across Game and Shell modes after the granular implementation plans land.

Target

Integration coverage demonstrates typed submissions, app-mode capability gates, immutable closed submissions, render-surface publication, fade removal, and visible output preservation.

Scope

• Add Game end-to-end tests from PBS/syscall production to Game2DFramePacket and final pixels.
• Add Shell end-to-end tests from UI production to ShellUiFramePacket and final pixels.
• Test wrong-domain capability failures.
• Test closed-submission immutability.
• Test latest-complete-submission-wins behavior.
• Test absence of fade and host debug overlay from canonical paths.

Out of Scope

• Implementing missing production code.
• New rendering features.
• Performance tuning.
• Dirty regions.

Execution Sequence

1. Define representative Game and Shell scenarios that cover composer, gfx2d, and gfxui.
2. Add integration harness access to inspect closed submissions where appropriate.
3. Assert Game produces RenderSubmission::Game2D and Shell produces RenderSubmission::ShellUi.
4. Assert wrong-domain syscalls fail before mutating buffers.
5. Assert closed submissions remain unchanged after producers continue mutating the next frame.
6. Assert final pixels match existing expected output for unchanged scenarios.
7. Add searches or tests proving fade and host debug overlay are absent from the active render path.

Acceptance Criteria

• Game and Shell each have end-to-end typed submission tests.
• Capability gates reject gfxui in Game and composer/gfx2d in Shell.
• Closed submissions are immutable snapshots.
• Latest complete submission replaces older unpublished submissions without queue growth.
• Unchanged Game and Shell scenarios remain visually equivalent.

Tests / Validation

• Run full affected Rust test suites.
• Run PBS compile/runtime integration tests.
• Run pixel-equivalence tests for representative Game and Shell output.
• Run discussion validate once execution discussion artifacts are updated.

Risks

• End-to-end tests may become brittle if they assert host details; assert the logical contract and final pixels, not internal host implementation names.
• Pixel-equivalence fixtures must account for intentional removals such as host debug overlay.

Affected Artifacts

• Integration tests under crates/
• PBS tests
• Render fixtures