Development Workflow

Development Workflow

Use a small, reviewable loop that keeps implementation facts, evidence, and publication boundaries aligned.

issue or narrow question
         |
         v
inspect current source/tests
         |
         v
focused change + synthetic regression
         |
         v
focused verification
         |
         v
broader local gates + publication audit
         |
         v
pull request -> review -> maintainer merge

Before editing

• Search GitHub Issues; they are canonical for actionable work and acceptance criteria.
• Read the maintained subsystem guide and the current source/tests.
• Inspect overlapping open pull requests before starting a new lane.
• Record the intended base and keep unrelated work out of the branch.

During the change

Prefer root-cause fixes over compatibility band-aids. Preserve the CpuState ABI, whole-span guest-memory validation, visible HLE gaps, and the two-phase generated-code build. Add a synthetic behavioral regression before relying on a title route. When a route needs private input, state that boundary explicitly rather than copying private evidence into a fixture.

Before review

Run the focused gate, the relevant native/reference/renderer/media route, and the broader local checks required by the change. Run both publication-audit modes when publication safety is in scope. Report hosted CI, hardware, visual, DCO, and maintainer-dependent conditions separately; local success does not imply those states.

Keep the pull request narrow. Link the canonical issue, list exact commands and results, describe residual acceptance criteria, and preserve third-party notices and provenance.

The repository's CONTRIBUTING.md, AGENTS.md, and AI-assisted development policy remain authoritative.