5.8 KiB
Gate Registry and Negative Controls
gates/gates.manifest.json is the machine-readable registry for the initial RM-02 gate slice. Run:
pnpm gate:verify
Registered slice
The registry covers root typecheck, lint, and format checks; RM-01 checkout preflight; the Mosaic CI queue guard; and root Husky pre-commit/pre-push hooks. It does not imply repository-wide coverage. Framework scripts, package-local build/test scripts, templates, and deployment/release scripts remain assigned to RM-54.
Every gate declares exact invocations, observed and required outcomes, criterion bindings, and a single exact inerting mutation. Every must-fail case requires a non-empty reason diagnostic. The verifier rejects a stale, ambiguous, crashing, or ineffective mutation. Fixture and mutation writes reject path traversal and final-component symlinks. Independent validation phases collect labeled failures instead of letting one thrown fixture, claim, discovery, deployment, mutation, or compatibility error mask already-known stable-ID diagnostics. This proves detection of the declared inerting mutation, not every possible semantic weakening.
Required versus actual
A case may record different required and actual outcomes only with a tracked owner. The verifier checks current reality against actual, prints each difference as DEFECT (owner: ...), and fails when behavior changes without a matching registry update. A defect is never described as passing, green, or OK.
The queue guard currently has RM-03-owned deltas. In particular, its stdin/heredoc classifier does not consume piped status JSON, so terminal-success, no-status, and terminal-failure payloads become unknown; unknown and malformed states exit zero; push purpose defaults to main. RM-02 records these observations and does not edit the guard.
Criteria, prose, and compatibility
Each criterion declares exact caseRefs; the verifier compares those semantic declarations bidirectionally with case-side criterionIds and requires at least one must-fail case. Moving a criterion ID to an unrelated case therefore fails as both a missing declared exercising case and an undeclared binding. Registered meta-negative controls misbind a criterion, remove meaning provenance, and misbind a prose claim, and each must make structure verification red for its stated reason.
Designated governing prose uses GATE-CLAIM:<id> markers. Each claim also names the exact must-fail caseRef that exercises its criterion; unknown, positive-only, unrelated, unbound, or registered-but-missing claims fail. Orchestrator-owned claims from TASKS.md are bound through docs/remediation/GATE-CLAIMS.md, which records source headings and anchored text without changing task tracking. Marker completeness still requires RM-54 review because arbitrary English claims cannot be inferred safely.
Compatibility checks detect direct contradictions in declared finite constructions. The verifier combines referenced case fixtures and environments in one isolated tree, rejects conflicting fixture/environment values, executes the construction's exact invocation, and checks its exact outcome. They do not prove semantic consistency of arbitrary natural language.
Restatements preserve original text, current text, reason, finding/task, and date.
Source and deployed identity
A gate with an external installed counterpart declares it explicitly. When the installed queue guard is reachable, its bytes must equal repository source and an internal drift control is observed red. In CI the operator-home installation may be outside the container; the verifier checks the pinned observed source digest, reports DEPLOYED IDENTITY UNAVAILABLE (owner: RM-04), and does not infer live equality.
Commit and provider boundary
DOES: Every PR evaluates the current checkout's registered gates and declared inerting mutations directly, unprivileged and fail-closed.
DOES NOT: Repository-controlled PR CI does not execute a commit's own verifier in an isolated replay. Doing so safely would require granting namespace capability before PR-controlled configuration or code runs; that same PR could consume the capability directly. This is an absent trust boundary, not unfinished hardening. RM-60 owns a runner-level rootless sandbox or protected immutable launcher; RM-59 owns the parallel artifact-integrity anchor.
The replay implementation and abuse-case tests remain fail-closed: when invoked by a future protected authority, inability to establish Bubblewrap is terminal nonzero; controls are never omitted or treated as replay success. On an unprivileged CI runner, sandbox integration tests pass only when the result carries parent-generated Bubblewrap-launch provenance and proves the sandbox entry command never ran. Child-controlled text that merely reproduces a Bubblewrap denial is not accepted. Capable local/protected environments exercise the full abuse cases. Historical installs use frozen lockfiles, isolated network/PID/IPC/UTS and environment/home boundaries, and authoritative-file snapshots that detect lifecycle rewrites.
Retained provider evidence can assert terminal-success current-tree records for prior commits when supplied through GATE_PROVIDER_EVIDENCE_FILE. Each normalized record contains commit, unique integer pipeline number, pipeline status, and exactly one gate-verify step; the highest-numbered rerun is authoritative. Ambiguous duplicates fail. Absent, expired, or currently-running evidence is reported explicitly and never inferred as success.
Once RM-60 supplies the external pre-execution anchor, protected post-merge/main replay is detection, not pre-merge prevention. A failed replay requires quarantine of the affected result and revert of the offending merge. It must never be represented as proof that CI blocked that merge. RM-25 tracks provider enforcement.