rendering-design-compat-check

name	rendering-design-compat-check
description	After a rendering design is approved and before writing the implementation plan, run a structured compatibility check against the realtime-rendering skill's technique-compatibility.md, interactions.md, and the project's existing rendering architecture. Report PASS/GAP findings; fix gaps before proceeding.
source	auto-skill
extracted_at	2026-06-15T05:51:47.835Z

Rendering design compatibility check

After a rendering design is approved (brainstorming step 5 complete) and before writing the implementation plan, run this structured compatibility pass. The check surfaces integration issues the skill references can catch but which are easy to miss when focused on the new subsystem in isolation.

When to invoke

• A new rendering pass or technique is being added to Titan's existing pipeline
• The design touches two or more existing subsystems (shadows × denoiser, shadows × shading, TLAS × scene representation)
• The design composes techniques across the tier ladder (e.g. High gets VSM, Mid gets CSM)
• The design inserts into the existing frame-graph ordering

The compatibility check (4 passes)

Pass 1: Technique composition

Read C:\Users\emper\.qwen\skills\realtime-rendering\references\technique-compatibility.md and check the design against the relevant decision slot:

• Is each technique in the correct slot? (e.g. RT shadows + VSM + SDF are all in the Shadows slot — they must compose as primary/fallback, not duplicate)
• Does the composition rule match? (additive layers compose via min(), never multiply; filters attach to shadow-map members; alternatives are mutually exclusive)
• Are there redundancy conflicts? (two techniques claiming the same role without a documented composition rule)

Why: The skill's technique-compatibility audit explicitly classifies every technique as complementary, mutually exclusive, or redundant. A design that violates these classifications will produce conflicting outputs or wasted work.

Pass 2: Cross-system interactions

Read C:\Users\emper\.qwen\skills\realtime-rendering\references\interactions.md and check:

• Pipeline ordering: Does the new pass slot into the right place in the dependency chain? (e.g. shadows must run before shading, TLAS must build before ray queries fire)
• Required-by relationships: Does the new technique need data from an existing pass that the design doesn't list as a dependency? (e.g. VSM needs depth pre-pass, HZB)
• Format & precision: Do the new resource formats match the skill's recommendations? (e.g. VSM page pool as D32F, page table as R32Uint)
• "If you change X, also check Y": Does the design touch any of the listed change → check pairs? (e.g. "Add a stochastic system that needs per-pixel motion-vec + history-validity")
• Shared cross-system passes: If the new technique reprojects per-pixel history, does it need to integrate with the shared tile classification pass? (Titan doesn't have this yet — note as future work)

Pass 3: Existing architecture fit

Check the design against Titan's actual codebase:

• Crate boundaries: Does the design place new types in the right crate? (RT infra → titan-rendering-rt, shadow/VSM logic → titan-stratum-lighting)
• Existing pass chain: Where does the new pass insert in the existing stratum pipeline? (check render_hook.rs for the actual dispatch order)
• Resource aliasing: Do new transient resources conflict with existing frame-graph transient allocations?
• Denoiser contract: If the design changes the visibility source, does the denoiser consume it in the same format as before? (source-agnostic → check the per-slot bit layout)
• Existing shadow system: Does the new system conflict with or duplicate the existing SDF cell_shadow_probe and screen-space shadow_screen?

Pass 4: Internal consistency

Read the design doc end-to-end and check:

• Data flow gaps: Does every resource have a producer listed before its first consumer? (e.g. TLAS must be built before stratum shading reads it)
• Milestone sequencing: If the design has multiple milestones, are the sequential code path migrations explicit? (m54-b → m54-c changes the shading dispatch from RT-only to VSM-primary + RT-fallback)
• Tier coverage: Does every tier in the design's scope have a complete path? (Mid tier with RT shadows but no VSM — what shadow technique fills the gap?)
• Default/initial state: Are ambiguous choices resolved? (VSM static caching: on or off for initial ship?)

Output format

Report each finding as:

✅ PASS — <category>: <one-line summary>
⚠️ GAP — <category>: <what's missing> → Fix: <concrete fix>

Fix gaps directly in the design doc. Do not defer them — they are the compatibility check's deliverable, not TODO items.

Example (from m54 RT shadows + VSM)

✅ PASS — Technique: RT + VSM + SDF compose correctly via min() per light class
✅ PASS — Pipeline ordering: VSM chain inserts before shading; RT rays during shading
✅ PASS — No conflict with existing BVH/SDF (TLAS is net-new)
✅ PASS — Denoiser contract: visibility source is opaque to denoiser
⚠️ GAP — Data flow: TLAS build ordering not specified → Fix: add step [0] to data flow diagram
⚠️ GAP — Default state: VSM static vs dynamic page split left ambiguous → Fix: declare dynamic-only for initial ship
⚠️ GAP — Milestone sequencing: m54-b → m54-c code path migration not explicit → Fix: add sequencing section

After the check

Report findings to the user. Fix all gaps inline in the design doc. Re-run any check that might have been affected by the fixes. Only proceed to the implementation plan when all checks pass.

Right way / wrong way

Right way	Wrong way
Run all 4 passes systematically	Check only the parts that seem "risky"
Fix gaps in the design doc, not in your head	Note gaps and promise to address them "during implementation"
Use the realtime-rendering skill references as the authority	Trust memory of what the skill says
Report PASS results too — they confirm correct compositing	Report only problems
Check existing Titan code (render_hook.rs, stratum_shading.wgsl)	Assume the architecture from docs alone