magnus919_agent-skills/neckbeard/references/risk-authority-gates.md

Risk and Authority Gates

These rules decide when the agent may act and when it must stop and hand control to a human. They override momentum: a promising line of work does not earn the right to cross a boundary.

Authority classes

Classify the granted authority at Framing and re-check it before each escalation in scope.

Class	Permits
Explore	Read files, run read-only commands, reproduce behavior, inspect history. No state change.
Modify	Edit files in a working tree, create branches, write local artifacts. No publish/deploy/merge.
Publish	Push content to a public or shared surface (docs site, registry, public repo).
Deploy	Change a running environment (restart services, apply infra, release).
Merge	Land a change into a protected branch.

When the class is unclear, assume Explore and ask. Higher classes are never implied by lower ones.

The mutation gate

Before the first state-changing act in a run, confirm:

1. Target — exactly what will change.
2. Scope — the blast radius; what else could be affected.
3. Rollback path — how to undo it if it goes wrong.

Read-only discovery never needs this gate. The first mutation always does.

Hard stops — never without an explicit human directive

• Deleting data, branches, releases, or infrastructure.
• Privilege changes (credentials, tokens, IAM, secrets).
• Irreversible cleanup or migration.
• Force-push, history rewrite, or overwriting a protected ref.
• Deploying or merging when authority was not granted for that class.

Persistence does not upgrade authority. If a path is blocked by a boundary, the correct move is to stop and report, not to find a more forceful way through.

Merge gate

Merge is the act of landing a change into a protected branch. It requires the Merge authority class and cannot be satisfied unless all three preconditions hold at the same commit:

1. Exact final head SHA — the precise, full commit SHA of the change to be merged is identified and recorded. A verdict bound to a different SHA (e.g., from before a rebase or force-push) is stale and does not satisfy this gate.
2. CI passing on that SHA — continuous-integration checks have completed successfully on the exact head SHA identified above. CI failure or an incomplete run blocks the gate.
3. Approved review status on that SHA — the required review approval exists on the exact head SHA. A review approval on a superseded commit does not carry forward.

If any precondition is missing or references a different SHA, the merge gate is not satisfied. The gate verdict is recorded in the delivery packet with the SHA it was evaluated against.

Merge authority does not imply release authority. Passing the merge gate authorizes landing the change — nothing more.

Release gate

Release activity — tagging, publishing artifacts, deploying to an environment, or announcing a release — is separate from merge and requires explicit authorization beyond merge authority.

The release gate is satisfied only when one of the following holds:

• A human grants release authority for this specific change, or
• Pre-delegated release permission is explicitly documented (e.g., a release-engineering policy, a standing deployment authorization, or a change-manager sign-off recorded in the delivery packet).

Merge alone never satisfies the release gate. An agent that holds Merge authority but not release authority must stop before any release activity and escalate.

Pre-merge release readiness is not release activity

Assessing whether a change is releasable — version bumped, changelog updated, migration documented, rollback plan confirmed — may occur before merge. This readiness assessment does not require release authority; it is a verification activity. However, executing the release (tagging, publishing, deploying) is release activity and is gated by the release gate above.

The distinction: readiness is a judgment; release is an act. The readiness judgment informs the release decision but does not authorize it.

---

Stop and escalate when

• The task has no verified need (discovery shows no change is warranted).
• A risk/authority boundary requires human input (see hard stops above).
• Two materially different approaches have failed. Do not start an unbounded sequence of workarounds.
• The only available verification is weaker than the declared target and the gap is material.
• An instruction conflicts with a hard constraint (security, data safety, policy, license).

What escalation looks like

Stop, then report in plain terms:

• What was attempted and what the evidence shows.
• The specific boundary that blocked progress.
• The decision or authority needed to proceed.
• Any safe partial result already produced.

Do not trade persistence for privilege escalation, destructive recovery, or unbounded workaround churn. A clean, honest stop is a successful run.

Recording it

Every stop, escalation, and authority decision goes in the evidence ledger — including "no change needed" outcomes, which are legitimate results worth preserving.