execution git:20260528.1895a81A

Immutable. This exact content is served forever at /api/v1/blob/16dfbf56624a1df4.

---
name: execution
description: Use when the user has approved a T3 operation and execution is about to begin
metadata:
  user-invocable: false
  type: discipline
---

# Execution

`execution` governs the post-approval phase of a T3 operation: how to verify the grant is still actionable, run the approved command, detect environment drift, and confirm the result against the plan's verification criteria before declaring success. For the approval handoff that precedes this phase, see `agent-approval-protocol`. For the re-dispatch decision that delivered this command, see `orchestrator-present-approval` Rule 4.

```
Commands finishing is not success.
Verification criteria passing is success.
```

## Mental Model

A command can exit 0 and leave the system in a broken state.
`terraform apply` can succeed while creating a misconfigured resource.
`kubectl apply` can succeed while a pod crash-loops. The only evidence
that matters is verification against the criteria from your plan —
not the exit code, not the absence of errors.

## Pre-Execution Checklist

Before executing an approved operation:

- [ ] Grant is active — the user selected an `Approve [P-xxxxxxxx]` label and `activate_db_pending_by_prefix` (in `hooks/modules/security/approval_grants.py`) wrote a `SCOPE_SEMANTIC_SIGNATURE` grant against the approved command. The runtime matches semantically — `matches_approval_signature` (in `hooks/modules/security/approval_scopes.py`) evaluates the approved signature (base_cmd, verb, dangerous flags, semantic tokens), not byte-for-byte string equality. **Even so, the discipline is verbatim**: relay and execute the approved `exact_content` as literal. Do not reason about what variations the runtime tolerates — wrappers, `cd` prefixes, redirects, or extra flags create a statement the grant may not cover. The semantic tolerance is a runtime safety net, not a license to deviate.
- [ ] Single-use awareness — the grant is consumed on first match by `consume_db_semantic_grant` (in `gaia/store/writer.py`). A retry after success or after a drifted variant re-blocks; the orchestrator must dispatch fresh, not loop.
- [ ] Current state captured — without a rollback baseline, partial failure is unrecoverable
- [ ] Plan still valid — state drifts between planning and execution; re-run dry-run if stale
- [ ] No interactive prompts — agent sessions cannot provide stdin; commands that prompt will hang

If a check fails → `BLOCKED` with which check and why.

## Precondition Verification

Before executing any approved command, verify that the preconditions for success still hold. Use domain knowledge to determine what to check -- this is not a lookup table, it is a judgment call.

The world changes between approval and execution. A command approved 5 minutes ago may fail because the environment moved. Checking first avoids a wasted failure cycle.

**Principle**: If the command depends on external state, verify that state before executing.

**Recovery**: If a precondition fails and the fix is local (pull --rebase, state refresh, resource re-fetch), attempt it ONCE, then retry the original command. If recovery also fails, report the situation -- do not loop.

**Boundary**: Recovery actions must only modify LOCAL state. Never attempt remote-mutating recovery (force push, remote delete, state import) without explicit user approval.

## Environment Drift Detection

When the pending file includes an `environment` snapshot (captured when the command was originally blocked), compare current state against it before executing.

If drift is detected (e.g., remote HEAD has moved, resource version changed), surface the drift to the user before proceeding. The user decides whether to continue or abort.

When no snapshot is available, verify observable state regardless -- the absence of a snapshot does not exempt the agent from precondition checks.

## Execution Protocol

1. Run each step separately — verify exit code before next
2. On failure — classify: recoverable (`IN_PROGRESS`) or not (`BLOCKED`)
3. After all steps — run Verification Criteria from the plan

## Error Reporting

```
Error Type: [Transient | Validation | Permission | State conflict]
Error Message: [exact output]
Rollback Status: [what needs rollback if partial]
```

## Rollback

Know your rollback path BEFORE executing. This varies by domain:
your domain skill defines the specific rollback strategy.

## Traps

| If you're thinking... | The reality is... |
|---|---|
| "Approval-time evidence (plan, dry-run, preconditions) still holds at execution" | State drifts between approval and execution; every precondition you relied on must be re-verified against current state, snapshot or no snapshot |
| "All commands exited 0, I'm done" | Exit 0 ≠ desired state — run the verification criteria from the plan |
| "It's only dev, fewer checks needed" | Irreversibility is irreversibility regardless of env |
| "The grant matched once, I can retry the same shape" | The grant is consumed on first match (`consume_db_semantic_grant`); a second invocation re-blocks even if the command looks identical |
| "Half the bundle ran, I can finish after a SendMessage resume" | `mode` dies on resume; if the remaining steps touch `.claude/` writes, CC native re-blocks. Emit BLOCKED, let orchestrator re-dispatch fresh with the same mode (`security-tiers/SKILL.md` R3) |

## Bundled Multi-Step Execution on Protected Paths

When the approved operation is a **bundle** of steps on `.claude/` paths (e.g.,
mv directory + 4 Edits across `.claude/project-context/`), execute every step in
the SAME turn the dispatch started -- `mode` is per-dispatch and dies on a
SendMessage resume, so split bundles re-block the later steps in `default` mode
(`security-tiers/SKILL.md` R3).

If a hook blocks a step mid-bundle, emit BLOCKED and stop -- do NOT emit
APPROVAL_REQUEST mid-bundle hoping to resume. The orchestrator's correct recovery
is a fresh dispatch (same mode, bundle re-packed), not a SendMessage back in.

## Anti-Patterns

- **COMPLETE without verification** — the most common failure mode; exit 0 is not evidence and the agent stops one step before the only evidence that matters
- **Execute on approximate approval** — the grant is keyed to the approved command's semantic signature (`matches_approval_signature` in `hooks/modules/security/approval_scopes.py`); a drifted argument, an added flag, or a wrapper CLI re-blocks. "Close enough" is rejected by the hook, not the agent
- **Mutate without a rollback path** — if you cannot describe how to undo it, partial failure becomes permanent damage
- **Looping on failed recovery instead of reporting after one attempt** — attempt local recovery once, then report; retry loops compound the broken state
- **Splitting a `.claude/` bundle across a SendMessage resume** — `mode` is per-dispatch; the resume runs in `default` and CC native re-blocks the remaining steps