Section 27Governance and Roadmap

Engineering process requirements

Defines traceability, review, continuous integration, conformance, benchmarking, release evidence, and change control.

Section relationships
IDNamePriorityRequirementVerification
PROC-001Architecture decisionsMVPMajor irreversible or cross-cutting design decisions SHALL be recorded in versioned architecture decision records.Inspection
PROC-002Requirement traceabilityMVPEach committed MVP feature SHALL reference one or more requirement IDs and associated verification evidence.Inspection
PROC-003Continuous integrationMVPMain-branch changes SHALL pass formatting, linting, unit, integration, numerical, import, security, and applicable benchmark gates.Test
PROC-004Platform CIMVPThe supported platform matrix SHALL be exercised at the frequency documented by the release policy.Inspection
PROC-005Dependency reviewMVPNew mandatory dependencies SHALL document purpose, license, maintenance status, native-code use, safety implications, and replacement strategy.Inspection
PROC-006Native system-interface exceptionMVPLinking a non-Rust operating-system or device-driver interface into a portable binary SHALL require an architecture decision naming the platform need, API boundary, safety review, owner, tests, and replacement analysis; project-supplied code SHALL never qualify for this exception.Inspection
PROC-007Fuzzed portable inputsMVPProject, archive, URDF, SDFormat, and committed mesh parsers SHALL have continuous fuzzing or equivalent adversarial-input evidence before release.Analysis
PROC-008Benchmark fixturesMVPNumerical and performance benchmark inputs and expected criteria SHALL be versioned with the source.Inspection
PROC-009Migration fixturesBetaEvery supported project-schema migration SHALL have an automated fixture covering success and expected diagnostics.Test
PROC-010Release manifestMVPEvery release SHALL publish checksums, compatibility matrix, dependency inventory, known limitations, and validation changes.Inspection
PROC-011Upstream-first fixesBetaA required third-party fix SHOULD be contributed upstream before BeforeMetal adopts a long-lived fork.Inspection
PROC-012Temporary fork policyBetaA temporary fork SHALL have a named owner, blocking rationale, benchmark coverage, rebase plan, upstream status, and exit criterion.Inspection
PROC-013Fuzzed protocol boundariesBetaProcess protocols, shared-memory descriptors, extension inputs, and remote request parsers SHALL have bounded-input tests and continuous fuzzing or equivalent adversarial evidence.Analysis

Generated from the canonical specification. Edit section metadata or prose in docs/requirements.md; the website rebuilds this page and its relationships automatically.