Contributing
Propose a small, evidence-backed change without weakening architecture, generated truth, or public safety.
Small changes that deliver a clear user or operator outcome are welcome. Large changes should begin with an issue that names the outcome, owning path, current limitation, and smallest complete vertical slice. A broad subsystem scaffold, speculative extension point, compatibility layer for unreleased behavior, or second source of machine-readable truth is not an acceptable substitute for a working path.
Before you edit
Read CONTRIBUTING.md and the nearest AGENTS.md, then the relevant sections of BLUEPRINT.md and
DESIGN.md. Inspect current dependencies, primary upstream documentation, the owning implementation,
tests, generated contracts, and git status. Existing changes may belong to another task; do not
revert or stage them broadly.
Keep credentials, private research, proprietary data, copied product material, comparison notes, and unreviewed generated or vendor code out of the repository. Use synthetic data in examples and issue reproductions.
Build a reviewable change
Implement the smallest complete behavior and delete the obsolete pre-release path when its replacement is proven. Add proportional normal, failure, and integration-edge tests. Update the relevant user or operator documentation and execution evidence in the same change. Regenerate OpenAPI, browser types, or reference pages only from their canonical source; never hand-edit generated output to make drift checks pass.
Run the narrow test first, then pnpm check. User-facing work also needs the complete reachable
browser, accessibility, viewport, appearance, motion, console, and network proof owned by the design
contract. Dependency changes require license, provenance, integrity, and generated lockfile review.
Submit and respond
Describe the outcome, changed boundary, exact validation commands and results, known limitations, and rollback or recovery behavior. Screenshots support interface review but do not replace behavior, accessibility, or network evidence. Keep the change focused; if review reveals a second owner or contract, coordinate that boundary rather than expanding silently.
Security vulnerabilities use private security reporting, not a public issue. By participating, you agree to the code of conduct. Continue with the local development workflow before changing code.