Build
Contributing
How to choose a bounded change, preserve architectural ownership, and prove exactly what the work does.
Public contributions begin after Meridian’s source release. The rules are documented now so the boundary is clear: good Meridian contributions are bounded, name the behavior being changed, identify its owner and evidence, and state what the patch does not claim.
Before editing
- Read the nearest
AGENTS.mdand the specification that owns the behavior. - Check
PLANNING.mdand the typed registries for current maturity and active work. - Confirm that your change does not cross the private-game boundary.
- Identify the smallest package and test surface that can prove the result.
Keep dependencies behind adapters
New third-party types should not become stable Meridian APIs. Dependency adoption also needs ownership, license and provenance review, an update strategy, and an exit plan appropriate to its risk.
Validate proportionately
Run targeted tests first. Then run formatting, workspace tests, warning-denied Clippy, specification validation, relevant smokes, and git diff --check as the change requires. Record native surfaces you could not exercise.
Write the claim last
Describe what passed at a specific source checkpoint. Do not turn a scaffold into a feature, an offscreen capture into a presentation claim, or a package pass into a milestone pass.
AI-assisted work
AI-assisted contributions are allowed. The contributor remains responsible for correctness, licensing, provenance, privacy, tests, and review. Generated or borrowed material starts untrusted and follows the same policies as other contributions.