Sigil: Decision Gate

• a task has multiple viable options,
• the choice affects future scope, implementation, documentation, rollout, policy, verification, cost, or risk,
• the agent cannot responsibly infer the correct option,
• downstream work should stop until the decision is explicit,
• a durable decision record is needed.

• target scope or task name,
• existing request, plan, notes, requirements, architecture docs, or implementation files,
• known constraints,
• options already proposed by the user,
• preferred output path,
• decision profile, if the project has one.

1. docs/decisions/{target-scope}.md when a docs folder exists,
2. decisions/{target-scope}.md when a decisions folder exists,
3. DECISIONS.md at the repository root when no better location exists.

• restate the decision and why it blocks the consequential work,
• give the deeper rationale and the source evidence behind each option, citing files, prior decisions, or notes,
• spell out what each option concretely changes downstream, including reversibility, cost, risk, and any decision it forces or forecloses,
• surface related or dependent decisions,
• name the recommended option and why, without choosing it.

Then route the explanation through complexity-example-ladder:

• produce low, medium, and complex examples that preserve one shared concept or comparison invariant,
• increase structural complexity rather than prose length or jargon,
• within each rung, use the same scenario for every admissible action option and give each option equivalent explanatory depth,
• represent defer and stop only as unchanged or terminated continuation states, not as invented product behavior,
• label hypothetical details and state what each example does not prove,
• preserve the recommendation, admissibility receipt, gate result, and owner authority with decision effect: none.

If the reusable sidecar is unavailable, apply the same ladder contract locally, surface the missing dependency, and do not omit the examples.

After explaining, re-present the same decision with the same real options and the standing "Explain / more context" choice again. Loop until the user picks a real option or explicitly defers or stops. The explain choice never counts as consent.

Before relying on an override:

1. Run scripts/consume-override.py with the override artifact, live request, and canonical schemas.
2. Require exact target, scope, and hazard equality; valid issuance/expiry timestamps; and consumed_by=null.
3. For a non-protected override, the consumer acquires an exclusive lock, re-reads the current artifact, persists the consuming run, and emits a schema-valid consumption receipt.
4. On every rejection, preserve the override bytes. A replay retains the first consumer and returns block.
5. For a protected hazard, return owner_route_required=true and route to the owning gate. A free-form owner_gate_receipt path is not producer-owned typed evidence and cannot make the generic override valid.

The consumption receipt authorizes only the exact decision override it names. It is not reusable authority and does not satisfy another lifecycle, publication, promotion, destructive-action, or spend gate.

Recommended signals:

• decision count,
• blocker count,
• unresolved blocker count,
• pass/block result,
• output path,
• user override, if any,
• follow-up reflection trigger when the same decision type repeats.

• identify every visible blocker-level multi-option decision,
• prefilter structurally inadmissible and unsafe-unowned candidates before asking the user,
• route zero/one/two-plus admissible candidates to block/direct/gate exactly,
• preserve defer and stop as legitimate typed options,
• never treat a direct route as consent, execution, or owner-gate satisfaction,
• require exact target/scope/hazard/time bindings before consuming an override,
• persist one-use consumption before returning an admitted override receipt,
• preserve the first consumer on replay and leave rejected override bytes unchanged,
• route every protected hazard to its owning gate,
• separate blocker decisions from deferrable decisions and assumptions,
• present options with meaningful trade-offs,
• offer a non-committal explain / more-context choice on every blocker decision and expand on request before asking again,
• include aligned low, medium, and complex examples whenever the explain / more-context path is taken,
• cover every admissible action option evenly inside each shared example scenario without changing the gate,
• avoid choosing on the user's behalf when the decision is consequential,
• persist a reviewable decision record,
• return a clear PASS or BLOCK result,
• preserve enough context for future reviewers to understand why each decision was made.

• asking the user to decide trivial or fully reversible details,
• presenting structurally inadmissible options to the user,
• invoking Decision Gate when zero or one admissible option remains,
• treating owner-supplied structural status as permission to bypass a protected owner gate,
• treating ambient assent, a path string, or an untyped approval note as an override,
• accepting stale, mismatched, already consumed, or scope-expanding override evidence,
• admitting a protected hazard through the generic override consumer,
• returning override success before consumed_by is durably persisted,
• silently dropping defer or stop from the candidate set,
• bundling multiple independent decisions into one vague question,
• presenting options without trade-offs,
• increasing example length or jargon without increasing structural complexity,
• using examples that favor one option, change admissibility, imply consent, or resolve the gate,
• forcing a choice when the user is unsure instead of offering deeper explanation,
• treating silence as consent for a blocker decision,
• proceeding with consequential mutation after a BLOCK result,
• hiding assumptions inside implementation or documentation,
• writing a decision record that cannot be traced back to the user choice or source context.

## Decision Gate Result

- Target scope: <scope>
- Result: PASS | BLOCK
- Decisions resolved: <count>
- Blockers remaining: <count>
- Admissibility receipt: <path>
- Admissible routing: block | direct | gate
- Override receipt: <path or none>
- Override verdict: consumed | block | not-requested
- Decision artifact: <path>
- Deferred decisions: <summary or none>
- Assumptions recorded: <summary or none>
- Validation: <checks performed>
- Next step: <proceed | ask remaining decision | stop>