executionlisted

# 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. Approval and execution are coupled: the user approving the T3 is itself the order to execute, so the orchestrator re-dispatches the verbatim command automatically -- this phase begins with that fresh dispatch, not a separate "should I run it" turn. 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 5. ``` 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/s