@jaguilar87/gaia 5.0.6 → 5.0.8

package/dist/gaia-ops/hooks/adapters/claude_code.py

@@ -603,13 +603,18 @@ class ClaudeCodeAdapter(HookAdapter):
                 exit_code=2,
             )
 
-        # Save state for post-hook
+        # Save state for post-hook. When the command was allowed by consuming a
+        # T3 approval grant, carry that approval_id forward so PostToolUse can
+        # append an EXECUTED/FAILED event to the approval_events chain (the grant
+        # is consumed here at PreToolUse and flips to CONSUMED, so PostToolUse
+        # cannot re-discover it via check_approval_grant).
         effective_command = result.modified_input.get("command", command) if result.modified_input else command
         state = create_pre_hook_state(
             tool_name=tool_name,
             command=effective_command,
             tier=str(result.tier),
             allowed=True,
+            consumed_approval_id=result.consumed_approval_id,
         )
         save_hook_state(state)
 
@@ -1003,6 +1008,26 @@ class ClaudeCodeAdapter(HookAdapter):
                             "T3 grant confirmed (will be consumed at SubagentStop): %s", command[:80],
                         )
 
+            # Close the audit-log cycle for an APPROVED T3 command that just ran.
+            # PreToolUse stashed the consumed grant's approval_id in HookState
+            # when it matched (and consumed) the grant; append EXECUTED on a clean
+            # exit, FAILED otherwise. This continues the approval_events hash chain
+            # via the canonical store.record_event() helper -- the only authorized
+            # writer for the chain (it routes through chain.insert_event(), which
+            # links prev_hash -> this_hash before INSERT).
+            if tool_name == "Bash":
+                consumed_approval_id = (
+                    pre_state.metadata.get("consumed_approval_id") if pre_state else None
+                )
+                if consumed_approval_id:
+                    self._record_t3_outcome_event(
+                        consumed_approval_id,
+                        command=parameters.get("command", ""),
+                        success=success,
+                        exit_code=tool_result_data.exit_code,
+                        session_id=hook_data.get("session_id", ""),
+                    )
+
             events = detect_critical_event(tool_name, parameters, output, success)
             if events:
                 writer = SessionContextWriter()
@@ -1031,6 +1056,53 @@ class ClaudeCodeAdapter(HookAdapter):
 
         return HookResponse(output={}, exit_code=0)
 
+    def _record_t3_outcome_event(
+        self,
+        approval_id: str,
+        *,
+        command: str,
+        success: bool,
+        exit_code: int,
+        session_id: str = "",
+    ) -> None:
+        """Append an EXECUTED or FAILED event for an approved T3 command.
+
+        Closes the audit-log cycle: once a command runs under a consumed grant,
+        the approval_events chain records whether it succeeded (EXECUTED) or
+        failed (FAILED). Writes through gaia.approvals.store.record_event(), the
+        canonical chain writer -- never a raw INSERT -- so prev_hash -> this_hash
+        linkage is preserved and validate_chain() stays intact end to end.
+
+        Best-effort and non-fatal: the approval store lives in gaia.db and may be
+        unavailable in some hook contexts; any failure is logged and swallowed so
+        a chain-write hiccup never breaks tool execution.
+        """
+        event_type = "EXECUTED" if success else "FAILED"
+        try:
+            from gaia.approvals import store as _approval_store
+
+            payload = {
+                "command": command,
+                "exit_code": exit_code,
+                "outcome": "success" if success else "failure",
+            }
+            _approval_store.record_event(
+                approval_id,
+                event_type,
+                session_id=session_id or None,
+                payload_json=json.dumps(payload, sort_keys=True, separators=(",", ":")),
+                metadata_json=json.dumps({"source": "post_tool_use"}),
+            )
+            logger.info(
+                "Recorded %s event for approval_id=%s (exit=%d)",
+                event_type, approval_id[:16], exit_code,
+            )
+        except Exception as exc:
+            logger.warning(
+                "Failed to record %s event for approval_id=%s (non-fatal): %s",
+                event_type, approval_id[:16], exc,
+            )
+
     # ------------------------------------------------------------------ #
     # _handle_ask_user_question_result: grant activation from user answer
     # ------------------------------------------------------------------ #

package/dist/gaia-ops/hooks/modules/agents/handoff_persister.py

@@ -170,19 +170,30 @@ def _intake_command_set_pending(
     }
 
     try:
-        from gaia.approvals.store import insert_requested
+        from gaia.approvals.store import derive_command_set_id, insert_requested
     except ImportError:
         import pathlib as _pl
         import sys as _sys
 
         _repo_root = _pl.Path(__file__).resolve().parent.parent.parent.parent
         _sys.path.insert(0, str(_repo_root))
-        from gaia.approvals.store import insert_requested
+        from gaia.approvals.store import derive_command_set_id, insert_requested
+
+    # Derive the PUBLIC approval_id deterministically from the post-filter
+    # mutative command strings. Because the id is content-derived (not uuid4),
+    # the orchestrator reproduces the SAME id from the command_set it reads in
+    # the contract via `gaia approvals derive-id` -- no DB search, no
+    # cross-session miss. The list passed here is the SAME list the CLI helper
+    # derives over (post-mutative-filter), so both sides agree.
+    derived_id = derive_command_set_id(
+        [it["command"] for it in command_set_items]
+    )
 
     approval_id = insert_requested(
         sealed_payload,
         agent_id=agent_id,
         session_id=session_id or None,
+        approval_id=derived_id,
     )
     logger.info(
         "INTAKE: plan-first COMMAND_SET pending created approval_id=%s items=%d",

package/dist/gaia-ops/hooks/modules/tools/bash_validator.py

@@ -90,6 +90,11 @@ class BashValidationResult:
     # plain error string (exit 2).  Used for structured block responses that
     # should correct the agent rather than terminate execution.
     block_response: Optional[Dict[str, Any]] = None
+    # When a T3 command is allowed because it matched (and consumed) an active
+    # grant, this carries the approval_id of that grant. The adapter stashes it
+    # in HookState so PostToolUse can append an EXECUTED/FAILED event to the
+    # approval_events chain for this approval. None for non-T3 / no-grant paths.
+    consumed_approval_id: Optional[str] = None
 
     def __post_init__(self):
         if self.suggestions is None:
@@ -667,6 +672,7 @@ class BashValidator:
                     allowed=True,
                     tier=SecurityTier.T3_BLOCKED,
                     reason="Command-set grant matched",
+                    consumed_approval_id=cs_approval_id,
                 )
 
             # DB-primary + filesystem-fallback grant check.
@@ -720,6 +726,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant confirmed",
+                        consumed_approval_id=db_approval_id,
                     )
                 else:
                     # Filesystem grant exists, not yet confirmed -- GAIA approved,
@@ -733,6 +740,7 @@ class BashValidator:
                         allowed=True,
                         tier=SecurityTier.T3_BLOCKED,
                         reason="Grant active, pending confirmation",
+                        consumed_approval_id=db_approval_id,
                     )
             else:
                 # Converge on the single T3 decision point.  When there is an
@@ -808,6 +816,7 @@ class BashValidator:
                             allowed=True,
                             tier=SecurityTier.T3_BLOCKED,
                             reason="Command-set grant matched",
+                            consumed_approval_id=cs_approval_id,
                         )
 
                     grant = check_approval_grant(command, session_id=session_id)
@@ -859,6 +868,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant confirmed",
+                                consumed_approval_id=db_approval_id,
                             )
                         else:
                             logger.info(
@@ -870,6 +880,7 @@ class BashValidator:
                                 allowed=True,
                                 tier=SecurityTier.T3_BLOCKED,
                                 reason="Grant active, pending confirmation",
+                                consumed_approval_id=db_approval_id,
                             )
 
                     # No grant matched -- converge on the single T3 decision
@@ -939,10 +950,18 @@ class BashValidator:
             key=lambda t: tier_order.index(t.value),
         )
 
+        # Propagate the consumed approval_id from whichever component matched a
+        # grant, so PostToolUse can append EXECUTED/FAILED for that approval.
+        consumed_approval_id = next(
+            (r.consumed_approval_id for r in component_results if r.consumed_approval_id),
+            None,
+        )
+
         return BashValidationResult(
             allowed=True,
             tier=highest_tier,
             reason=f"All {len(components)} components validated",
+            consumed_approval_id=consumed_approval_id,
         )
 
     def _phase4_check_composition(

package/dist/gaia-ops/skills/agent-approval-protocol/SKILL.md

@@ -21,10 +21,18 @@ the hash chain, grant activation, reading a granted approval from Python -- see
 
 ## approval_id format
 
+For a **singular** T3 approval (the hook-block path),
 `store._generate_approval_id()` returns `P-{uuid4().hex}` (e.g.
-`P-b1bdfbb0b9474bf5b3f86b1f6a213f7a`). The `P-` prefix is mandatory: without it
-the PostToolUse hook cannot do targeted grant activation. The first 8 hex chars
-after `P-` are the nonce prefix shown in option labels: `[P-b1bdfbb0]`.
+`P-b1bdfbb0b9474bf5b3f86b1f6a213f7a`) -- a random, unique id the subagent relays
+verbatim. For a **plan-first `COMMAND_SET`** the id is instead **content-derived**
+by `store.derive_command_set_id()`: `P-<first 32 hex of
+sha256(canonical(command strings))>`. The two share the `P-` prefix and 32-hex
+length but differ in origin -- the command_set id is deterministic so the
+orchestrator reproduces it from the command_set (via `gaia approvals derive-id`)
+with no DB search; the singular id is random because the subagent relays it
+directly. The `P-` prefix is mandatory in both cases: without it the PostToolUse
+hook cannot do targeted grant activation. The first 8 hex chars after `P-` are
+the nonce prefix shown in option labels: `[P-b1bdfbb0]`.
 
 ## APPROVAL_REQUEST contract shape
 
@@ -55,8 +63,11 @@ becomes `rollback` in the contract; `commands` (`[exact_content]`) and
 }
 ```
 
-There is no `batch_scope` field: the `verb_family` grant was removed, so each
-blocked command gets its own single-use grant. See
+There is no `batch_scope` field: the `verb_family` grant was removed. For a
+single blocked command, each gets its own single-use `SCOPE_SEMANTIC_SIGNATURE`
+grant. For a batch of >= 2 T3 commands known up-front, emit a `command_set`
+list and **no** `approval_id` -- the SubagentStop intake mints a single
+`COMMAND_SET` grant (one consent covers all). See
 `Skill('orchestrator-present-approval')` for the orchestrator side.
 
 ## Status vocabularies -- distinct columns, opposite casing, never collapse
@@ -69,8 +80,8 @@ blocked command gets its own single-use grant. See
 ## Event chain
 
 The `approval_events.event_type` CHECK admits nine values: `REQUESTED` `SHOWN`
-`APPROVED` `REJECTED` `EXECUTED` `FAILED` `NOOP` `REVOKED` `REVERTED`. Only these
-are written by production code today:
+`APPROVED` `REJECTED` `EXECUTED` `FAILED` `NOOP` `REVOKED` `REVERTED`. These are
+written by production code today:
 
 | Event | Who writes it | When |
 |-------|--------------|------|
@@ -78,11 +89,16 @@ are written by production code today:
 | `SHOWN` | ElicitationResult hook via `activate_db_pending_by_prefix()` | User selects an Approve `[P-xxx]` label |
 | `APPROVED` | ElicitationResult hook (same call as `SHOWN`) | Immediately after `SHOWN` |
 | `REJECTED` / `REVOKED` | `gaia approvals` CLI via `store.reject()` / `store.revoke()` | User rejects or admin cancels |
-
-`EXECUTED` `FAILED` `NOOP` `REVERTED` are valid in the CHECK and are *read* by
-`store.get_executed_payload()` and `revert.py`, but no production hook *writes*
-them today -- treat them as a designed extension point, not a live invariant. Do
-not assume an `EXECUTED` event exists after a command runs.
+| `EXECUTED` / `FAILED` | PostToolUse adapter (`_record_t3_outcome_event`) via `store.record_event()` | An approved T3 command runs under a consumed grant -- `EXECUTED` on clean exit, `FAILED` otherwise |
+
+The PostToolUse path closes the audit cycle: PreToolUse stashes the consumed
+grant's `approval_id` in `HookState`, and PostToolUse appends `EXECUTED` or
+`FAILED` for that approval, continuing the hash chain through `record_event()`.
+`store.get_executed_payload()` and `gaia approvals replay` read the `EXECUTED`
+payload to re-present the commands that ran. `NOOP` and `REVERTED` remain valid
+in the CHECK but are **inert** -- no production code writes them (the revert
+feature was removed). Do not assume an `EXECUTED` event exists for an approval
+whose command never ran, or that ran through the redirect-sanitized path.
 
 ## Key invariants
 

package/dist/gaia-ops/skills/agent-approval-protocol/reference.md

@@ -27,9 +27,11 @@ Each event links to the previous via `prev_hash` -> `this_hash`
 Because `approval_events` is append-only (UPDATE/DELETE blocked by the
 `bu_approval_events_immutable` and `bd_approval_events_immutable` triggers),
 `this_hash` is computed in the application layer before INSERT, inside
-`chain.insert_event()` -- not by a DB trigger. `REVERTED` events, when written,
-carry the original `event_id` in `metadata_json` per the revert design (D14);
-see `gaia/approvals/revert.py`.
+`chain.insert_event()` -- not by a DB trigger. `EXECUTED` / `FAILED` events,
+appended by the PostToolUse adapter through `store.record_event()` after an
+approved T3 command runs, extend the same chain. `REVERTED` remains a valid
+CHECK value but is **inert** -- the revert feature was removed, so no code
+writes it.
 
 ## Grant activation walk-through
 

package/dist/gaia-ops/skills/agent-protocol/examples.md

@@ -330,4 +330,15 @@ The agent discovered a project fact a section it owns did not yet hold, and writ
 
 ## Notes on multi-command APPROVAL_REQUEST sweeps
 
-There is no batch/multi-use grant in the current code: the legacy `verb_family` grant was removed (`hooks/modules/security/approval_grants.py`) and its `COMMAND_SET` replacement has no production activation path yet. Do **not** emit a `batch_scope` field -- it is ignored. When one intent expands into many T3 commands, each blocked command produces its own single-use approval; emit one `APPROVAL_REQUEST` per blocked command (shape identical to example 4 above) and let the user approve each.
+**Just-in-time (unknown batch):** when T3 commands appear one at a time as the
+agent works, each blocked command produces its own `APPROVAL_REQUEST` with an
+`approval_id` (shape identical to example 4 above). Do not emit `batch_scope`
+-- it is ignored.
+
+**Plan-first (known batch):** when the agent knows >= 2 T3 commands up-front,
+emit ONE `APPROVAL_REQUEST` carrying a `command_set` list of `{command,
+rationale}` items and **no** `approval_id`. The SubagentStop intake
+(`handoff_persister._intake_command_set_pending`) mints a single `COMMAND_SET`
+approval; the orchestrator presents it as one consent covering all N commands.
+Each command then runs on its own retry, byte-for-byte matched and consumed
+individually.

package/dist/gaia-ops/skills/gaia-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gaia-patterns
-description: Use when building or modifying gaia-ops components -- agents, skills, hooks, CLI tools, commands, or routing config
+description: Use when building or modifying gaia-ops components -- agents, skills, hooks, CLI tools, or routing config
 metadata:
   user-invocable: false
   type: domain
@@ -77,10 +77,6 @@ Agents get instantiated as: identity (.md) + skills (injected from frontmatter)
 
 CLI tools live in `bin/` and are registered in `package.json` `bin` field. Pattern: parse args, resolve paths (follow symlinks to source), run checks, exit with code. `gaia doctor` is the diagnostic model -- read it first.
 
-## Command Patterns
-
-Slash commands live in `commands/<name>.md` -- markdown files that instruct the orchestrator on `/<name>`. To add: create the `.md`, add to `build/<plugin>.manifest.json`.
-
 ## Documentation Drift Awareness
 
 When you modify any Gaia component (hook, skill, agent definition, routing config, security rule), check if existing reference docs describe that component's behavior. If drift exists, report it via `cross_layer_impacts` in your agent_contract_handoff. The orchestrator then decides whether to dispatch a documentation update task.
@@ -91,7 +87,7 @@ When you modify any Gaia component (hook, skill, agent definition, routing confi
 - Changed `_is_protected()` paths in `adapters/claude_code.py` → check `security-tiers/SKILL.md` for path documentation
 - Added a new agent definition → check `gaia-patterns/reference.md` for agents table
 - Modified hook enforcement logic → check `security-tiers` and `agent-protocol` references
-- When adding or modifying files in agents/, skills/, hooks/, commands/, config/, bin/, tests/, build/ or the repo root, load Skill('readme-writing') to update the relevant README.md
+- When adding or modifying files in agents/, skills/, hooks/, config/, bin/, tests/, build/ or the repo root, load Skill('readme-writing') to update the relevant README.md
 
 **Format:** In `cross_layer_impacts`, list the doc file and the behavior change, e.g.:
 ```

package/dist/gaia-ops/skills/gaia-patterns/reference.md

@@ -80,14 +80,6 @@ SessionStart emits a one-shot `hookSpecificOutput.additionalContext` manifest (E
 | `skill-creation/` | Technique | Injected (gaia-system) |
 | `skills/reference.md` | Reference | On-demand (shared security-tiers ref) |
 
-### Commands (slash commands)
-
-| Command | File | Purpose |
-|---------|------|---------|
-| `/gaia` | `commands/gaia.md` | Invoke gaia meta-agent |
-| `/scan-project` | `commands/scan-project.md` | Scan project, update project context in ~/.gaia/gaia.db |
-| `/gaia-plan` | `commands/gaia-plan.md` | Plan a feature, create brief, decompose into tasks |
-
 ### Tools (7 subsystems)
 
 | Subsystem | Location | Purpose |
@@ -139,7 +131,7 @@ The package ships a single `gaia` binary (`bin/gaia.js`) that dispatches to Pyth
 
 | Mode | Package | What ships |
 |------|---------|-----------|
-| `gaia-ops` | `@jaguilar87/gaia` (full) | All hooks, all modules, all agents, all skills, all commands, all tools, all config |
+| `gaia-ops` | `@jaguilar87/gaia` (full) | All hooks, all modules, all agents, all skills, all tools, all config |
 | `gaia-security` | `@jaguilar87/gaia` (security dist) | 6 hooks (`pre_tool_use`, `post_tool_use`, `stop_hook`, `user_prompt_submit`, `session_start`, `session_end_hook`), all modules, no agents, no skills, no config |
 
 ### Detection Cascade (`hooks/modules/core/plugin_mode.py`)
@@ -159,7 +151,6 @@ The package ships a single `gaia` binary (`bin/gaia.js`) that dispatches to Pyth
 | T3 approval | Claude Code native dialog (`permissionDecision: ask`) | Hook blocks with nonce, orchestrator approval flow |
 | Agents | None | 8 agents routed by orchestrator |
 | Skills | None | 24 skills injected per frontmatter |
-| Commands | None | 7 slash commands |
 | PreToolUse matchers | `Bash` only | `Bash`, `Task`, `Agent`, `SendMessage`, multi-tool |
 | File write protection | `_is_protected()` blocks hooks/ and settings*.json for Edit/Write tools | Same -- fires regardless of permissionMode |
 
@@ -206,7 +197,7 @@ npm publish                    # publishes @jaguilar87/gaia
 3. Run `scripts/bootstrap_database.sh` -- seeds the schema (v17), agent rows, and `schema_version`. Fail-loud: any non-zero exit writes `~/.gaia/last-install-error.json` and propagates the error.
 4. Merge permissions, env vars, and agent key into `settings.local.json` (preserves user config).
 5. Merge hooks from `hooks.json` into `settings.local.json` via the consolidated `merge_hooks` step.
-6. Create `.claude/{agents, tools, hooks, commands, templates, config, skills}` symlinks (7) plus `CHANGELOG.md` file link.
+6. Create `.claude/{agents, tools, hooks, config, skills}` symlinks (5) plus `CHANGELOG.md` file link.
 7. Write `plugin-registry.json` with `installed[].name == "gaia-ops"` (or `gaia-security`).
 8. Verification.
 
@@ -229,8 +220,6 @@ The hook invoker is `python3 <script>` rather than executing the script directly
 .claude/agents    -> node_modules/@jaguilar87/gaia/agents/
 .claude/tools     -> node_modules/@jaguilar87/gaia/tools/
 .claude/hooks     -> node_modules/@jaguilar87/gaia/hooks/
-.claude/commands  -> node_modules/@jaguilar87/gaia/commands/
-.claude/templates -> node_modules/@jaguilar87/gaia/templates/
 .claude/config    -> node_modules/@jaguilar87/gaia/config/
 .claude/skills    -> node_modules/@jaguilar87/gaia/skills/
 .claude/CHANGELOG.md (file link) -> node_modules/@jaguilar87/gaia/CHANGELOG.md
@@ -333,7 +322,6 @@ ln -sf /home/jorge/ws/me/gaia-dev/agents   .claude/agents
 ln -sf /home/jorge/ws/me/gaia-dev/hooks    .claude/hooks
 ln -sf /home/jorge/ws/me/gaia-dev/skills   .claude/skills
 ln -sf /home/jorge/ws/me/gaia-dev/tools    .claude/tools
-ln -sf /home/jorge/ws/me/gaia-dev/commands .claude/commands
 ln -sf /home/jorge/ws/me/gaia-dev/config   .claude/config
 ```
 

package/dist/gaia-ops/skills/orchestrator-present-approval/SKILL.md

@@ -39,7 +39,13 @@ So before AskUserQuestion, two checks against the DB, in order:
 1. **The approval exists, is fresh, and is from the current session.** Query `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (or `--json` for parsing). The reported `approval_id` MUST appear in that result. If it appears only under `--all-sessions` but not the current session, it is leakage from another session (a test session such as `e2e-sim`, a prior run) -- **do not present**. If it does not appear at all, it does not exist or was already consumed/rejected -- **do not present**. Freshness is the `created_at` of the pending row plus its presence as still-`pending`; an id the agent reports that is not currently pending in *this* session is not a fresh block, whatever the agent says.
 2. **The payload is untampered.** Call `verify_fingerprint(approval_id, payload_json, con) -> bool` from `gaia/approvals/chain.py`. It raises `ChainTamperError` if the payload was modified between subagent emission and your relay (security boundary, do not present), and `ValueError` if no REQUESTED event exists for this `approval_id`. Either case: **do not present**, report the failure, stop.
 
-**For a `command_set` (plan-first batch) the agent does not know the id at all.** The hook mints the `approval_id` at SubagentStop (`_intake_command_set_pending` -- see Rule 3); the subagent emits the `command_set` with **no** `approval_id`. So you do not have an agent-reported id to trust even if you wanted to -- you ALWAYS recover the freshly minted id from `gaia approvals pending` for the current session. This is the general shape made unavoidable: the DB mints, the orchestrator recovers, the agent never owns the id.
+**For a `command_set` (plan-first batch) the agent does not know the id at all -- so you DERIVE it deterministically, you do not search the DB.** The hook mints the `approval_id` at SubagentStop (`_intake_command_set_pending` -- see Rule 3) from the **content** of the command_set, not from a uuid4. The id is `P-<first 32 hex of sha256(canonical(command list))>` (`derive_command_set_id` in `gaia/approvals/store.py`). Because it is content-derived, you reproduce the EXACT minted id from the `command_set` you already hold in the contract -- with **no `gaia approvals pending --session` search**. Run:
+
+```
+gaia approvals derive-id --commands-json '<the command_set from the contract>'
+```
+
+It applies the SAME mutative filter the intake used and prints the `P-...` id (the same function `derive_command_set_id` the hook minted with). This closes the cross-session miss: the SubagentStop output never reaches the parent (Claude Code issue #5812), so a random id could not be recovered across sessions -- a content-derived one needs no recovery at all. Having derived the id, run Step 0's existence/fingerprint checks against it exactly as for a singular id (the row is now findable by that exact id). The shape: the DB mints content-derived, the orchestrator re-derives, the agent never owns the id and no search is needed.
 
 ## Mandatory presentation -- 5 labeled fields + nonce-suffixed label
 
@@ -121,4 +127,4 @@ wording, see `reference.md` -> "GOOD vs BAD Examples", "Option Label Patterns",
 | "The same command emitted a new approval_id" | Grants are single-use and consumed on the first retry. A second run is a new APPROVAL_REQUEST -- approve again. |
 | "I'll set batch_scope to approve many at once" | `batch_scope` is ignored -- but a real batch path exists: a plan-first `command_set` (>= 2 items, no `approval_id`) is intaken into ONE pending `COMMAND_SET`. Present that single approval (N commands shown, one `[P-...]` nonce, one consent), not N separate approvals. |
 | "I can paraphrase a field before relaying" | The fingerprint covers all 7 sealed fields; any modification raises `ChainTamperError` in Step 0 and the presentation is refused. |
-| **"The agent reported an `approval_id`, so it's a real fresh block"** -- trusting a nonce relayed by the subagent | The agent's reported id is an unverified pointer, not a fact. It can be stale or belong to another session -- subagents have presented a STALE nonce from a test session (`e2e-sim`) as if it were a fresh block. Resolve every reported id against `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (Step 0): it must be currently pending in *this* session. Visible only under `--all-sessions`, or absent entirely, means do not present. For `command_set` the hook mints the id and the agent never has one -- you always recover it from the DB. |
+| **"The agent reported an `approval_id`, so it's a real fresh block"** -- trusting a nonce relayed by the subagent | The agent's reported id is an unverified pointer, not a fact. It can be stale or belong to another session -- subagents have presented a STALE nonce from a test session (`e2e-sim`) as if it were a fresh block. Resolve every reported id against `gaia approvals pending --session "$CLAUDE_SESSION_ID"` (Step 0): it must be currently pending in *this* session. Visible only under `--all-sessions`, or absent entirely, means do not present. For `command_set` the hook mints the id and the agent never has one -- you **derive** it deterministically from the command_set via `gaia approvals derive-id` (content-derived, no DB search), then run the same existence/fingerprint checks. |

package/dist/gaia-ops/skills/orchestrator-present-approval/template.md

@@ -26,16 +26,17 @@ AskUserQuestion(
 Where `approval_id_prefix8` is the first 8 characters of the `approval_id`
 field from the subagent's `approval_request` (after the `P-` prefix).
 
-## No batch template
-
-There is no batch/multi-use approval in the current code. The `verb_family` grant
-was removed (see the module docstring of
-`hooks/modules/security/approval_grants.py`) and the `COMMAND_SET` replacement
-has no production activation path (`create_command_set_grant` has no production
-caller). The word "batch" in a label and a `batch_scope` field are both ignored.
-For a sweep of N commands, present each command with its own single-command
-approval (the template above), once per `approval_id`. See `reference.md` ->
-"On batch intents".
+## Batch template (COMMAND_SET)
+
+When the subagent emits a plan-first `APPROVAL_REQUEST` with a `command_set`
+of >= 2 `{command, rationale}` items and **no** `approval_id`, the
+SubagentStop intake mints ONE pending `COMMAND_SET` approval. Present it as
+a single approval: list all N commands in the question body, one Approve
+label with one `[P-{nonce8}]` suffix. See `reference.md` -> "On batch
+intents" for the full layout.
+
+A `batch_scope` field and the word "batch" in an option label are both
+ignored -- the signal is the presence of `command_set` in the contract.
 
 ## Field Extraction Reference
 

package/dist/gaia-ops/skills/subagent-request-approval/SKILL.md

@@ -99,6 +99,17 @@ with one `approval_id` -- so a batch of N commands is **one consent, N
 commands**, not N approvals. A set of `<= 1` item is not a batch: it does not
 mint a COMMAND_SET (use the normal singular block path for a single command).
 
+You still emit the `command_set` with **no `approval_id`** -- nothing changes on
+your side. What changed underneath: the minted `approval_id` is now
+**content-derived** from the command_set
+(`derive_command_set_id` -> `P-<first 32 hex of sha256(canonical commands)>`),
+not a random uuid4. You do not compute or emit it (you cannot hash reliably, and
+you have nothing to attempt yet); the value is purely internal. The reason it
+matters: the orchestrator reproduces that exact id from the `command_set` you
+emitted (via `gaia approvals derive-id`), with no DB search and no cross-session
+miss. Your contract stays the same -- `command_set` of `{command, rationale}`
+items, no `approval_id`.
+
 On the user's approval, that one pending activates into a single `COMMAND_SET`
 grant (60-minute TTL); each item is then consumed byte-for-byte on its own
 retry, with replay protection, until the whole set is `CONSUMED`. See

package/dist/gaia-ops/skills/subagent-request-approval/reference.md

@@ -94,6 +94,22 @@ COMMAND_SET is ever minted for one command). The intake runs independently of
 the audit handoff-row write, so a batch consent is never lost to an unrelated
 DB failure.
 
+**The COMMAND_SET `approval_id` is content-derived, not uuid4.** Unlike the
+singular hook-block path (which mints `P-{uuid4hex}`), the intake derives the id
+from the command_set content via `gaia.approvals.store.derive_command_set_id()`:
+`P-<first 32 hex of sha256(canonical(post-filter command strings))>`. It then
+passes that id to `insert_requested(..., approval_id=...)` as the pending row id.
+The point is reproducibility without a DB lookup: the orchestrator holds the
+same `command_set` (you emitted it in the contract) and reproduces the EXACT id
+with `gaia approvals derive-id`, which applies the same mutative filter and the
+same canonicalization (`chain.canonical_payload`). This closes the cross-session
+miss -- a uuid4 minted at SubagentStop could not be recovered by the parent
+(Claude Code #5812), but a content-derived id needs no recovery. The id is
+**order-sensitive** (the consume side matches positionally) and **content-only**
+(rationale/session/agent are not folded in, so both sides agree from the command
+list alone). Idempotency follows the existing fingerprint dedup: two identical
+command sets map to one id.
+
 **Envelope shape.** The sealed_payload the intake writes carries a `command_set`
 key holding the verbatim list of `{command, rationale}` items, and `commands`
 listing every command string in the set:
@@ -142,9 +158,11 @@ orchestrator which path:
   validates the fingerprint and activates the single-use semantic grant on user
   approval.
 - **Without `approval_id`, with a `command_set` of >= 2 items** -- plan-first
-  batch. The SubagentStop intake processor mints ONE pending `COMMAND_SET` and
-  the orchestrator presents that single approval (N commands, one nonce) before
-  any execution. See "Batch / COMMAND_SET -- wired" above.
+  batch. The SubagentStop intake processor mints ONE pending `COMMAND_SET` with a
+  **content-derived** id (`derive_command_set_id`), and the orchestrator
+  reproduces that exact id from the command_set via `gaia approvals derive-id`
+  (no DB search) before presenting the single approval (N commands, one nonce).
+  See "Batch / COMMAND_SET -- wired" above.
 - **Without `approval_id` and without a multi-item `command_set`** -- plan-first
   single (you are presenting one T3 plan before attempting); the orchestrator
   gates on user consent before any execution.

package/dist/gaia-security/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gaia-security",
-  "version": "5.0.6",
+  "version": "5.0.8",
   "description": "Keeps you in the loop only when it matters. Gaia Security analyzes every command and classifies it into risk tiers: read-only queries run freely, simulations and validations pass through, and state-changing operations (create, delete, apply, push) pause for your explicit approval before executing. Irreversible commands like dropping databases or deleting cloud infrastructure are permanently blocked.",
   "author": {
     "name": "jaguilar87",

package/dist/gaia-security/hooks/adapters/claude_code.py

@@ -603,13 +603,18 @@ class ClaudeCodeAdapter(HookAdapter):
                 exit_code=2,
             )
 
-        # Save state for post-hook
+        # Save state for post-hook. When the command was allowed by consuming a
+        # T3 approval grant, carry that approval_id forward so PostToolUse can
+        # append an EXECUTED/FAILED event to the approval_events chain (the grant
+        # is consumed here at PreToolUse and flips to CONSUMED, so PostToolUse
+        # cannot re-discover it via check_approval_grant).
         effective_command = result.modified_input.get("command", command) if result.modified_input else command
         state = create_pre_hook_state(
             tool_name=tool_name,
             command=effective_command,
             tier=str(result.tier),
             allowed=True,
+            consumed_approval_id=result.consumed_approval_id,
         )
         save_hook_state(state)
 
@@ -1003,6 +1008,26 @@ class ClaudeCodeAdapter(HookAdapter):
                             "T3 grant confirmed (will be consumed at SubagentStop): %s", command[:80],
                         )
 
+            # Close the audit-log cycle for an APPROVED T3 command that just ran.
+            # PreToolUse stashed the consumed grant's approval_id in HookState
+            # when it matched (and consumed) the grant; append EXECUTED on a clean
+            # exit, FAILED otherwise. This continues the approval_events hash chain
+            # via the canonical store.record_event() helper -- the only authorized
+            # writer for the chain (it routes through chain.insert_event(), which
+            # links prev_hash -> this_hash before INSERT).
+            if tool_name == "Bash":
+                consumed_approval_id = (
+                    pre_state.metadata.get("consumed_approval_id") if pre_state else None
+                )
+                if consumed_approval_id:
+                    self._record_t3_outcome_event(
+                        consumed_approval_id,
+                        command=parameters.get("command", ""),
+                        success=success,
+                        exit_code=tool_result_data.exit_code,
+                        session_id=hook_data.get("session_id", ""),
+                    )
+
             events = detect_critical_event(tool_name, parameters, output, success)
             if events:
                 writer = SessionContextWriter()
@@ -1031,6 +1056,53 @@ class ClaudeCodeAdapter(HookAdapter):
 
         return HookResponse(output={}, exit_code=0)
 
+    def _record_t3_outcome_event(
+        self,
+        approval_id: str,
+        *,
+        command: str,
+        success: bool,
+        exit_code: int,
+        session_id: str = "",
+    ) -> None:
+        """Append an EXECUTED or FAILED event for an approved T3 command.
+
+        Closes the audit-log cycle: once a command runs under a consumed grant,
+        the approval_events chain records whether it succeeded (EXECUTED) or
+        failed (FAILED). Writes through gaia.approvals.store.record_event(), the
+        canonical chain writer -- never a raw INSERT -- so prev_hash -> this_hash
+        linkage is preserved and validate_chain() stays intact end to end.
+
+        Best-effort and non-fatal: the approval store lives in gaia.db and may be
+        unavailable in some hook contexts; any failure is logged and swallowed so
+        a chain-write hiccup never breaks tool execution.
+        """
+        event_type = "EXECUTED" if success else "FAILED"
+        try:
+            from gaia.approvals import store as _approval_store
+
+            payload = {
+                "command": command,
+                "exit_code": exit_code,
+                "outcome": "success" if success else "failure",
+            }
+            _approval_store.record_event(
+                approval_id,
+                event_type,
+                session_id=session_id or None,
+                payload_json=json.dumps(payload, sort_keys=True, separators=(",", ":")),
+                metadata_json=json.dumps({"source": "post_tool_use"}),
+            )
+            logger.info(
+                "Recorded %s event for approval_id=%s (exit=%d)",
+                event_type, approval_id[:16], exit_code,
+            )
+        except Exception as exc:
+            logger.warning(
+                "Failed to record %s event for approval_id=%s (non-fatal): %s",
+                event_type, approval_id[:16], exc,
+            )
+
     # ------------------------------------------------------------------ #
     # _handle_ask_user_question_result: grant activation from user answer
     # ------------------------------------------------------------------ #