Harness gates operate on typed tool requirements. They decide whether a call may proceed, but they do not enforce OS isolation and they do not parse raw model arguments. This boundary is where a Rig chooses a headless or interactive approval policy and where every unmet gated requirement becomes one auditable decision.

Boundary

gate.Evaluator consumes tool.Request values and structural AccessBinding sources. NewHeadlessEvaluator and NewInteractiveEvaluator select the decision mode. Resolution records approval, denial, or a gate requirement; GateResponse carries one of the offered approval actions. Rule matching and persistence are supplied by the consumer through RuleMatcher and RuleWriter.

The gate package deliberately does not import sandbox, does not read a permission file, and does not grant authority based on a tool display name. A requirement kind and normalized match identify the capability being evaluated.

Evaluation order

The runtime sequence is preparation, gate evaluation, grant issuance, and effect. A CallPreparer must reject malformed arguments before the evaluator is called. Deny sources are checked before allow sources, so an allow rule cannot override an explicit deny. Gated requirements are combined into one approval prompt, then the caller issues the narrow grant that the enforcing layer can verify.

The gate’s decision is not the Sandbox’s guarantee. An approved command.execute request still needs a correctly scoped executor and a matching grant. Conversely, a Sandbox backend cannot turn a denied gate into a process.

Lifecycle

An interactive evaluator owns its approver and rule writer for the evaluator lifetime. A resolution must be answered through the same gate identity and route that opened it. Durable gate events are journaled by Harness; a pending gate is not an invitation to retry the underlying tool call without a new decision.

Errors and limits

Validate requirements, bindings, gate payloads, and approval actions at construction and response boundaries. Handle AccessError, GateValidationError, payload codec errors, and evaluator failures with errors.Is or errors.As. Bounds cover requirement counts, review context, payload size, classifier names, and form fields. Diagnostic text is bounded and not a compatibility contract.

Runnable proof

stage-12-gate-rules installs a source that reports a gated capability and a matcher that reports both deny and allow. It asserts that the result is not approved and that the allow matcher is never consulted after deny. Run it with node scripts/docs/run-examples.mjs. The pinned evaluator and gate tests show the ordering contract.