Last updated: 2026-02-15
This document defines non-negotiable engineering laws for Git Mind.
These laws are canonical engineering guardrails. They are not the product roadmap, and some of the terms here come from broader platform work that predates the current product narrowing.
The WARP graph (entities, relations, properties, provenance, receipts) is the source of truth.
Materialized files are derived artifacts and are non-canonical by default.
Git worktree state is a convenience context, not authoritative state.
HEAD is a default query parameter, never the truth boundary.
Law 3: No Hidden Context Coupling
If output can vary by time/observer/trust/extensions, commands must accept explicit context (or deterministic defaults) and surface it in output metadata.
Required context dimensions:
at/asOfobservertrustPolicyextensionSet(and lock hash)
Materialization must be a deterministic function of:
- projection input/frontier
- context envelope
- renderer/template/version
- options
Same inputs must produce identical output bytes (excluding explicitly non-semantic metadata).
Generated artifacts are written outside repo root by default.
If repo-local output is used, it must be policy-controlled (ignore + hook + CI + allowlist).
Cache keys for projections/materializations must be content-addressed and derived exclusively from semantic inputs and pinned tool/template versions.
No ambient state in cache keys.
Any external sync/effectful operation must:
- produce deterministic plan
- apply explicitly
- emit provenance receipt
No implicit mutation from opaque fetch-transform logic.
Extensions may add domain semantics, but may not bypass:
- determinism rules
- trust/provenance requirements
- context envelope semantics
- contract versioning requirements
Machine-facing outputs require versioned schemas.
Breaking changes require explicit version bumps and migration path.
For any meaningful entity/property, lineage must be queryable and explainable (“why this value?”), including trust-relevant transitions where available.
Tracking generated artifacts in Git is an explicit publication action, never incidental side effect of normal workflows.
If a design tradeoff conflicts with reproducibility, reproducibility wins.
A PR must be rejected or redesigned if it introduces any of:
- Canonical truth split between graph and generated files
- Hidden dependency on ambient worktree state
- Non-deterministic output without explicit opt-in and labeling
- Effectful sync without plan/apply + receipt
- Extension behavior that bypasses trust/provenance/context contracts
- Generated artifact tracking without policy allowlist
- Contract-breaking output changes without schema version update