Module gate 

The first-class gate interface (ticket .kranz/tickets/gate-plugin-interface.md, KRZ-311; scored-gates addendum KRZ-315).

Until this module every gate in the engine was bespoke — contract command assertions, scrutiny validators, the empty-deliverable final gate, crate::merge_gate, crate::workspace_gate, preflight — and each invented its own pass/fail shape, so nothing could register, order, or record gates uniformly. This module is the shared contract: a Gate is ordered, typed, independently registrable into a GatePipeline, and every evaluation returns a GateOutcome — an authoritative GateVerdict plus an ArtefactRef handle to the evidence behind it.

WHY the ordering is structural: deterministic gates (exit codes, lints, scans) are cheap and reproducible, while model-judged gates spend tokens and want the deterministic evidence in hand first. A GatePipeline therefore cannot represent “model gate ahead of deterministic gate” at all — it stores the two kinds in separate sections and evaluates every deterministic gate (in registration order) before any model-judged one (also in registration order). There is no insertion-position API to get wrong, and registration can only ever choose an order WITHIN a section.

WHY the score is optional and inert (KRZ-315): a gate may report a confidence score and the threshold it judged against so a later slice (gate-confidence-score) can persist and query low-confidence verdicts. The score never decides anything here — GateOutcome has no constructor that derives a verdict from a score, so the verdict a gate states IS the verdict. Boolean-only gates simply never name the field.

WHY artefacts are references, not events: persisting outcomes as first-class events is gate-results-first-class-events (KRZ-312). This module fixes only the handle shape so that slice needs no rework here.

Ownership is unchanged by this interface: who WRITES a gate’s config is a property of the reader, not the registry. The merge-gate suite stays base-branch-owned (its bytes are read from the live base sha in crate::merge), so a mission cannot weaken or reorder the gates that judge its own diff.

Structs

ArtefactRef

A handle to the evidence behind a verdict.

GateOutcome

What one gate evaluation produced: an authoritative verdict, the artefact behind it, and an optional confidence score.

GatePipeline

An ordered gate sequence with the deterministic/model-judged ordering encoded in its storage: two sections, evaluated deterministic-first, so a pipeline with a model gate ahead of a deterministic gate is unrepresentable rather than merely rejected.

GateReport

One gate’s outcome, annotated with the identity and kind the pipeline registered it under.

GateScore

A gate-supplied confidence score and the threshold the gate judged it against (KRZ-315). Purely evidentiary: nothing in this module reads it.

Enums

GateKind

Whether a gate’s verdict comes from a reproducible check or from model judgement. The kind selects the gate’s pipeline section — deterministic gates always evaluate first (see the module docs).

GateSurface

Which evaluation surface ran the pipeline a gate.result event came from (KRZ-312). The same gate id is evaluated more than once per mission — once at plan approval and once at the final gate — so a gate id plus ladder position alone cannot name ONE evaluation; the surface does. It is recorded on the event itself rather than inferred from neighbouring events: a replay that reconstructs the ladder from the log alone must not depend on emission-order conventions that a later refactor could move.

GateVerdict

The authoritative outcome of one gate evaluation: pass or fail, as stated by the gate — never derived from GateOutcome::score.

Traits

Gate

A gate: an ordered, typed, independently registrable check.