@jaguilar87/gaia 5.0.2 → 5.0.5

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

@@ -30,9 +30,16 @@ without the data needed to decide. The job is **verbatim relay, not
 re-authoring**: rewriting any of the 7 sealed fields breaks the fingerprint and
 `verify_fingerprint` (`gaia/approvals/chain.py`) raises `ChainTamperError`.
 
-## Step 0 -- Fingerprint validation (mandatory before SHOWN)
+## Step 0 -- Verify the approval against the DB (mandatory before SHOWN)
 
-Before AskUserQuestion, 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.
+A subagent's reported `approval_id` is an unverified claim, not a fact. The agent runs in its own context and can relay an id that is stale, from another session, or simply wrong -- and a stale id presented as a fresh block walks the user into consenting to nothing real (or to a grant that no longer exists). The DB is the source of truth; the agent's report is a pointer into it that you must resolve, never the authority itself.
+
+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.
 
 ## Mandatory presentation -- 5 labeled fields + nonce-suffixed label
 
@@ -71,12 +78,27 @@ Fields above are extracted from the DB-stored canonical payload (`payload_json`
    grant consumed by the first retry (`consume_db_semantic_grant` in
    `gaia/store/writer.py`). A second invocation is a new APPROVAL_REQUEST.
 
-3. **No batch grant.** Legacy `verb_family` was removed; the `COMMAND_SET`
-   replacement has only the CHECK side wired (`match_command_set_grant` is
-   called by `bash_validator`, but `create_command_set_grant` has no production
-   caller). `batch_scope` is ignored. For N commands, expect N approvals.
+3. **Batch grant is `COMMAND_SET` -- one consent, N commands.** Legacy
+   `verb_family` was removed; its replacement, `COMMAND_SET`, is now wired
+   end-to-end (intake, activation, consume). When a subagent emits a plan-first
+   `APPROVAL_REQUEST` carrying a `command_set` of >= 2 `{command, rationale}`
+   items and **no** `approval_id`, the SubagentStop processor
+   (`handoff_persister._intake_command_set_pending`) mints ONE pending
+   `COMMAND_SET` with one `approval_id`. You present that single approval: list
+   **all N commands** in the question body, but use **one** Approve label with
+   **one** `[P-{nonce8}]` suffix -- one consent covers the whole batch. On
+   approval, `activate_db_pending_by_prefix` Step 3b creates a single
+   `COMMAND_SET` grant (60-min TTL); each command is consumed byte-for-byte on
+   its own retry. `batch_scope` is still ignored (the signal is `command_set`).
    See `reference.md` -> "On batch intents".
 
+   You present the batch the subagent chose to send; you do not steer it toward
+   batching. Whether grouping is warranted is the subagent's judgment (known
+   batch, >= 2, friction reduced -- see `subagent-request-approval`). A singular
+   approval arriving where you imagined a batch is not a defect to correct: the
+   default is just-in-time, and a batch you would have manufactured asks the
+   user to consent to commands that may never run.
+
 4. **Re-dispatch, do not resume.** `mode` does not survive a SendMessage resume:
    the resume runs in `default` and re-blocks the next protected operation even
    after the Gaia grant activated. Prefer a fresh re-dispatch with the same
@@ -97,5 +119,6 @@ wording, see `reference.md` -> "GOOD vs BAD Examples", "Option Label Patterns",
 | "I'll skip the [P-...] suffix, it's cosmetic" | The hook extracts the nonce from the label to find the right pending row; without it, targeted activation fails and no grant is created. |
 | "Similar command, slightly different path -- I'll reuse / wrap it" | Grants match the statement signature byte-for-byte. Any wrapper, redirect, flag, or path drift is a different signature and a fresh re-block. |
 | "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" | No batch activation exists in current code -- the field is ignored. Each blocked command needs its own approval. |
+| "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. |

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

@@ -107,32 +107,49 @@ contain `[P-<hex>]`. Reject labels never carry a nonce. The captured hex is the
 `get_pending(all_sessions=True)` and selects the one whose `id` starts with
 `P-{prefix}`.
 
-## On batch intents -- there is no multi-use grant
+## On batch intents -- the COMMAND_SET grant (one consent, N commands)
 
 The old `verb_family` design (one approval covering many commands of the same
 `base_cmd + verb`) **was removed**. The module docstring in
 `hooks/modules/security/approval_grants.py` is explicit: "The legacy verb_family
 path has been removed."
 
-The intended replacement is the `COMMAND_SET` grant: an explicit list of
+Its replacement is the `COMMAND_SET` grant: an explicit list of
 `{command, rationale}` items, each matched **byte-for-byte** (D10: no whitespace
 normalization, no quote canonicalization, no shell expansion) and consumed
 individually (`create_command_set_grant` and `match_command_set_grant` in
 `approval_grants.py`).
 
-**Current state of the code:** only the CHECK side is wired. `bash_validator`
-(`hooks/modules/tools/bash_validator.py`) calls `match_command_set_grant()` and
-consumes a matched item, but **no production path calls
-`create_command_set_grant()`** -- it exists only in the module and its tests.
-The ElicitationResult / adapter activation paths (`hooks/elicitation_result.py`,
-`hooks/adapters/claude_code.py`) contain no "batch", "verb_family", "multi_use",
-or "command_set" handling; they only call `activate_db_pending_by_prefix()`,
-which creates a single-use `SCOPE_SEMANTIC_SIGNATURE` grant.
-
-**Practical consequence:** putting the word "batch" in a label, or a `batch_scope`
-field in an `approval_request`, does nothing. Each blocked command produces its
-own single-use semantic grant and its own approval. For a sweep of N commands,
-expect N approvals until the COMMAND_SET create path is wired.
+**Current state of the code: all three sides are wired -- intake, activation,
+consume.** It is a **plan-first** flow: the subagent declares the batch up-front
+by emitting an `APPROVAL_REQUEST` whose `approval_request` carries a
+`command_set` list and **no** `approval_id`.
+
+- **Intake.** The SubagentStop processor
+  `hooks/modules/agents/handoff_persister.py` ->
+  `_intake_command_set_pending()` reads the `command_set`; when it holds **>= 2**
+  items it calls `gaia.approvals.store.insert_requested()` with a payload that
+  contains the `command_set` key, minting **exactly ONE** pending `COMMAND_SET`
+  approval with one `approval_id`. A set of `<= 1` item is declined (no
+  COMMAND_SET is minted for one command).
+- **Activation.** When the user approves, `activate_db_pending_by_prefix()`
+  (`hooks/modules/security/approval_grants.py`) reads `payload["command_set"]`,
+  and because it has > 1 item branches at **Step 3b** into
+  `create_command_set_grant()`, inserting ONE `COMMAND_SET` grant row (status
+  `PENDING`, `command_set_json` holding the whole set, 60-min TTL via
+  `DEFAULT_COMMAND_SET_TTL_MINUTES`) instead of a singular
+  `SCOPE_SEMANTIC_SIGNATURE` grant.
+- **Consume.** On each retry, `bash_validator` calls `match_command_set_grant()`
+  (byte-for-byte index match), then `mark_command_set_item_consumed()`; a
+  consumed index never matches again (replay protection), and when every index
+  is consumed the grant flips to `CONSUMED`.
+
+**Practical consequence:** a `batch_scope` field still does nothing -- the signal
+is `command_set`. To approve a sweep of N related commands under one consent,
+present the single `COMMAND_SET` approval the intake minted: show **all N
+commands** in the question body, with **one** Approve label carrying **one**
+`[P-{nonce8}]` suffix. The user gives one consent; each command then runs on its
+own retry within the 60-minute window. You do NOT issue N separate approvals.
 
 ## Grant Activation Mechanics
 

package/dist/gaia-ops/skills/readme-writing/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: readme-writing
-description: Use when writing or updating a README for a Gaia component folder (agents/, skills/, hooks/, commands/, config/, bin/, tests/, build/, templates/, or the repo root)
+description: Use when writing or updating a README for a Gaia component folder (agents/, skills/, hooks/, commands/, config/, bin/, tests/, build/, or the repo root)
 metadata:
   user-invocable: false
   type: technique

package/dist/gaia-ops/skills/readme-writing/reference.md

@@ -185,4 +185,3 @@ Copy this when writing a README from scratch. Fill every section -- do not delet
 | `bin/` | Low -- CLI tools, user-invoked | No |
 | `tests/` | Low -- run by CI or developer | No |
 | `build/` | Medium -- triggered by npm run build | Optional |
-| `templates/` | Low -- read by build scripts | No |

package/dist/gaia-ops/skills/security-tiers/SKILL.md

@@ -17,7 +17,11 @@ security-tiers classifies every operation into four tiers so an agent knows whet
 | **T0** | Read-only; observes state, changes nothing | No | get, list, describe, show, logs, status |
 | **T1** | Local validation; no remote calls, no state | No | validate, lint, fmt, check |
 | **T2** | Simulation / dry-run; may read remote, never writes | No | plan, diff, dry-run, template |
-| **T3** | State-mutating; creates, updates, or destroys | **Yes** | apply, create, delete, commit, push, deploy |
+| **T3** | State-mutating; creates, updates, or destroys | **Yes** | apply, create, delete, push, deploy |
+
+`git commit` and `git add` are **not** T3 -- they are local-only operations (they touch the working tree and local refs, never remote state), so they classify as safe by elimination. Only `git push` mutates remote state and is T3. This matches `GIT_LOCAL_SAFE_SUBCOMMANDS` in `mutative_verbs.py`, where `commit` and `add` are listed as local-safe.
+
+**T3 gates a direction, not a category of verb.** An operation needs consent because it moves the system toward *more* capability (it grants) or *less* recoverability (it destroys). An operation that only moves the other way -- that *reduces* capability already granted -- does not need consent, because the worst it can do is take back power that was given. So within Gaia's own consent layer, `gaia approvals revoke|reject|reject-all|clean` are **not** T3: they only revoke or discard grants Gaia itself issued, never reaching outside the local approval store. The asymmetry is deliberate -- `gaia approvals approve` *grants* capability without the AskUserQuestion flow, so it stays T3. This is anchored to the `gaia approvals` group in `CONSENT_REDUCING_SUBCOMMAND_EXCEPTIONS` (`mutative_verbs.py`), not generalized to every CLI's "revoke" -- a cloud IAM revoke is a real remote mutation and remains T3.
 
 ## Classification heuristic
 

package/dist/gaia-ops/skills/security-tiers/reference.md

@@ -36,7 +36,9 @@ Read on-demand by infrastructure agents. Not injected automatically.
 - `kubectl apply -f manifest.yaml`
 - `helm upgrade` (without `--dry-run`)
 - `flux reconcile` (write operations)
-- `git commit`, `git push` (any branch)
+- `git push` (any branch) -- mutates remote state
+
+Note: `git commit` and `git add` are **not** T3. They are local-only (working tree + local refs, never remote), classified safe by elimination via `GIT_LOCAL_SAFE_SUBCOMMANDS` in `mutative_verbs.py`. Only `git push` reaches remote state.
 
 ## Edge Cases
 

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

@@ -63,12 +63,47 @@ prose are invisible to the presentation -- the user would approve blind.
 - **The grant is single-use.** It is consumed on your first matching retry. A
   second run within the TTL will not match -- it needs a fresh approval.
 
-## Batch / many-command intents
-
-There is **no `batch_scope` field** and no production batch grant: each blocked
-command is one single-use approval, so a sweep of N commands is N approvals.
-The `COMMAND_SET` mechanism exists in code but no path activates it from an
-approval, so emitting `batch_scope` does nothing. See `reference.md` for why.
+## Batch / many-command intents -- COMMAND_SET as a judgment, not a default
+
+Grouping commands under one consent is a **judgment call you earn, not the
+reflex you reach for**. The default is singular, just-in-time approval: attempt
+the command, let the hook block it, request that one. Reach for `COMMAND_SET`
+**only when all three hold** -- the batch is already **known** (the commands are
+determined, not predicted), there are **>= 2** of them, and grouping **actually
+reduces friction** versus approving each as it arrives. If any fails (a single
+command, a sequential flow where the next depends on the last's output, or a
+set you cannot yet name), use the singular path. The principle with its
+consequence: **grouping trades the user's per-command visibility for fewer
+prompts; make that trade only when the batch is real and known, because a batch
+you guessed at asks the user to approve commands that may never run.**
+
+The hard prohibition this rules out: **never invent or predict commands just to
+have something to group.** Speculatively enumerating a `command_set` to "save
+turns" inverts the cost -- it manufactures ceremony (a multi-command consent
+surface) around work that was never determined, which is more overhead than the
+just-in-time blocks it was meant to avoid. If you do not already know the
+commands, you do not have a batch.
+
+When the three conditions do hold, emit an `APPROVAL_REQUEST` whose
+`approval_request` carries a `command_set` -- a list of `{command, rationale}`
+items -- and **no `approval_id`** (nothing has been attempted yet). The
+per-command rationale is what makes the grouped consent honest: the user sees
+why each *known* command is in the batch before approving (D10).
+
+What happens to that envelope: the SubagentStop processor
+(`hooks/modules/agents/handoff_persister.py` -> `_intake_command_set_pending`)
+reads the `command_set`, and when it holds **>= 2** items it calls
+`gaia.approvals.store.insert_requested` with a payload containing the
+`command_set` key. That mints **exactly ONE pending `COMMAND_SET` approval**
+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).
+
+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
+`reference.md` for the envelope shape, the intake processor, the grant TTL, and
+the consume path.
 
 ## Pointers
 
@@ -84,3 +119,5 @@ approval, so emitting `batch_scope` does nothing. See `reference.md` for why.
 - **Fabricating `approval_id`, fingerprint, or `sealed_payload`** -- the orchestrator validates against the DB; invented values never match.
 - **Reusing a prior approval** -- single-use, consumed on first retry.
 - **Emitting `batch_scope`** -- the field does not exist; it is ignored.
+- **Grouping by reflex** -- reaching for `COMMAND_SET` because a batch *might* form, instead of because a known batch of >= 2 already exists that grouping makes cheaper. The default is singular just-in-time; grouping is the exception you justify.
+- **Predicting commands to fill a batch** -- inventing commands you have not determined so a `command_set` has >= 2 items. You cannot ask consent for work that does not yet exist; the speculative batch is pure overhead.

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

@@ -69,35 +69,85 @@ On your retry, `check_approval_grant()` matches it and immediately consumes it
 TTL will NOT match -- the grant is gone. This is replay protection by design;
 re-approve if you need to run the command again.
 
-## Batch / COMMAND_SET -- designed, not wired
+## Batch / COMMAND_SET -- wired
 
 The legacy `verb_family` multi-use grant was removed (see module docstring in
-`approval_grants.py`: "The legacy verb_family path has been removed"). Its intended
+`approval_grants.py`: "The legacy verb_family path has been removed"). Its
 replacement is the `COMMAND_SET` grant -- an explicit list of `{command, rationale}`
 items, each matched byte-for-byte and consumed individually
 (`approval_grants.create_command_set_grant()`; `approval_grants.match_command_set_grant()`).
+All three sides are now wired end-to-end -- **intake**, **activation**, and
+**consume** -- so one consent covers N commands.
+
+**Intake -- plan-first, one pending.** The batch is declared up-front: you emit
+an `APPROVAL_REQUEST` whose `approval_request` carries a `command_set` list and
+**no `approval_id`** (you have attempted nothing). The production intake caller
+is the SubagentStop processor `handoff_persister.persist_handoff()`, which calls
+`_intake_command_set_pending()`. That helper normalizes the `command_set` and,
+when it holds **>= 2** `{command, rationale}` items, builds a sealed_payload
+carrying the `command_set` key (mirroring the shape
+`bash_validator._build_sealed_payload()` emits) and calls
+`gaia.approvals.store.insert_requested()` -- minting **exactly ONE** pending
+`COMMAND_SET` approval with one `approval_id`. A set of length `<= 1` is not a
+batch: the intake declines and the singular semantic-signature path owns it (no
+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.
+
+**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:
 
-**Current state:** only the CHECK side is wired. `bash_validator._validate_single_command()`
-calls `match_command_set_grant()` and consumes a matched item, but **no
-production path calls `approval_grants.create_command_set_grant()`** -- it exists only in the
-module and its tests. The activation paths only call
-`approval_grants.activate_db_pending_by_prefix()`, which creates a single-use
-`SCOPE_SEMANTIC_SIGNATURE` grant.
+```json
+{
+  "operation": "MUTATIVE command intercepted: push",
+  "exact_content": "git add -A",
+  "commands": ["git add -A", "git commit -m 'v1.2.0'", "git push origin main"],
+  "command_set": [
+    {"command": "git add -A",             "rationale": "stage release files"},
+    {"command": "git commit -m 'v1.2.0'", "rationale": "record the release commit"},
+    {"command": "git push origin main",   "rationale": "publish to the remote"}
+  ]
+}
+```
 
-**Consequence:** a `batch_scope` field in `approval_request`, or the word "batch"
-in a label, does nothing. Each blocked command produces its own single-use
-semantic grant and its own approval. For a sweep of N commands, expect N
-approvals until the COMMAND_SET create path is wired.
+**Activation -- one consent, one grant.** When the user approves, the
+ElicitationResult hook (`approval_grants.activate_db_pending_by_prefix()`)
+detects the `command_set` and branches to `approval_grants.create_command_set_grant()`,
+which inserts a single `COMMAND_SET` grant row into `approval_grants`
+(status `PENDING`, `command_set_json` holding the whole set). The grant TTL is
+**60 minutes** (`DEFAULT_COMMAND_SET_TTL_MINUTES`), aligned to the singular
+active-grant TTL so the batch does not expire mid-consume across sessions.
+
+**Consume -- item by item, replay-protected.** On each retry,
+`bash_validator._validate_single_command()` calls `match_command_set_grant()`,
+which finds the matching command's index byte-for-byte and returns it; the
+validator then calls `mark_command_set_item_consumed()`, appending that index to
+`consumed_indexes_json`. A consumed index never matches again (replay
+protection), and when every index is consumed the grant flips to `CONSUMED`.
+Wrapping an approved command -- adding `cd`, a redirect, a pipe, or a flag --
+produces a different string and matches nothing in the set; it requires fresh
+approval.
+
+**Consequence:** for a set of N related T3 commands, emit the `command_set`
+envelope and the user approves once. Each command runs on its own retry,
+single-use within the 60-minute window.
 
 ## Status to emit -- with vs without approval_id
 
 Always `plan_status: "APPROVAL_REQUEST"`. The presence of `approval_id` tells the
 orchestrator which path:
 
-- **With `approval_id`** -- the hook blocked; orchestrator validates the
-  fingerprint and activates the grant on user approval.
-- **Without `approval_id`** -- plan-first (you are presenting a T3 plan before
-  attempting); the orchestrator gates on user consent before any execution.
+- **With `approval_id`** -- the hook blocked a single command; orchestrator
+  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.
+- **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.
 
 ## Examples
 

package/dist/gaia-ops/tools/context/README.md

@@ -77,7 +77,7 @@ Agent contracts live in `~/.gaia/gaia.db` (`project_context_contracts` + `agent_
 **cloud-troubleshooter:**
 - project_identity, stack, git, environment, infrastructure, orchestration
 - cluster_details, infrastructure_topology, terraform_infrastructure
-- gitops_configuration, application_services, monitoring_observability, architecture_overview
+- gitops_configuration, application_services, architecture_overview
 
 The same contracts are exposed under `write_permissions`:
 - `readable_sections`

package/dist/gaia-ops/tools/gaia_simulator/extractor.py

@@ -221,7 +221,6 @@ class LogExtractor:
                 # Exit 2 BLOCK (block_response is None):
                 #   - "Command blocked by security policy ..." -- permanent deny list
                 #   - "Commit message validation failed ..." -- validation error
-                #   - "GitOps policy violation ..." -- GitOps validation
                 #   - "Empty command not allowed"
                 if (
                     reason.startswith("Dangerous")

package/dist/gaia-ops/tools/scan/ui.py

@@ -16,6 +16,22 @@ import sys
 from typing import Any, Dict, List, Optional
 
 
+# ---------------------------------------------------------------------------
+# Glyphs
+#
+# Hoisted to module-level constants so they are never written as escape
+# sequences *inside* an f-string replacement field. A backslash within an
+# f-string expression (e.g. f"{self._green('◇')}") is a SyntaxError on
+# Python 3.11 (our declared minimum); it is only permitted on 3.12+ via PEP
+# 701. Referencing a bare name inside the braces keeps the same rendered
+# output while staying 3.11-compatible.
+# ---------------------------------------------------------------------------
+
+_GLYPH_DIAMOND_OUTLINE = "◇"  # ◇
+_GLYPH_WARNING = "⚠"          # ⚠
+_GLYPH_CORNER_BL = "└"        # └
+
+
 # ---------------------------------------------------------------------------
 # ANSI color helpers
 # ---------------------------------------------------------------------------
@@ -119,7 +135,7 @@ class RailUI:
             name: Section title (e.g. "Stack", "Infrastructure").
             lines: Detail lines to display under the section.
         """
-        self._write(f"{self._green('\u25c7')}  {self._cyan(name)}")
+        self._write(f"{self._green(_GLYPH_DIAMOND_OUTLINE)}  {self._cyan(name)}")
         for line in lines:
             self._write(f"{self._rail()}  {line}")
         self._write(self._rail())
@@ -131,7 +147,7 @@ class RailUI:
             names: List of section names to join with middle-dot.
         """
         joined = self._cyan(" \u00b7 ".join(names))
-        self._write(f"{self._green('\u25c7')}  {joined}")
+        self._write(f"{self._green(_GLYPH_DIAMOND_OUTLINE)}  {joined}")
         self._write(self._rail())
 
     def warning(self, count: int, messages: List[str]) -> None:
@@ -141,7 +157,7 @@ class RailUI:
             count: Total number of warnings.
             messages: Warning messages to display.
         """
-        self._write(f"{self._yellow('\u26a0')}  {self._yellow(f'Warnings ({count})')}")
+        self._write(f"{self._yellow(_GLYPH_WARNING)}  {self._yellow(f'Warnings ({count})')}")
         for msg in messages:
             self._write(f"{self._rail()}  {msg}")
         self._write(self._rail())
@@ -193,7 +209,7 @@ class RailUI:
         Args:
             message: Footer message text.
         """
-        self._write(f"{self._dim('\u2514')}  {message}")
+        self._write(f"{self._dim(_GLYPH_CORNER_BL)}  {message}")
 
 
 # ---------------------------------------------------------------------------

package/dist/gaia-ops/tools/scan/verify.py

@@ -45,8 +45,8 @@ class CheckResult:
 def check_symlinks(project_root: Path) -> CheckResult:
     """Verify that all expected symlinks exist in .claude/.
 
-    Checks for: agents, tools, hooks, commands, templates, config,
-    skills, CHANGELOG.md (8 total).
+    Checks for: agents, tools, hooks, commands, config,
+    skills, CHANGELOG.md (7 total).
 
     Args:
         project_root: Project root directory.
@@ -56,7 +56,7 @@ def check_symlinks(project_root: Path) -> CheckResult:
     """
     names = [
         "agents", "tools", "hooks", "commands",
-        "templates", "config", "skills",
+        "config", "skills",
         "CHANGELOG.md",
     ]
     valid = 0

package/dist/gaia-ops/tools/validation/README.md

@@ -25,7 +25,7 @@ without requiring explicit imports in agent code.
 - ✅ Subject line rules (max 72 chars, no period at end)
 - ✅ Forbidden footers (no "Generated with" footers)
 
-**Configuration:** `.claude/config/git_standards.json` (SSOT)
+**Configuration:** Standards are inlined as module-level constants in `hooks/modules/validation/commit_validator.py` (`TYPE_ALLOWED`, `SUBJECT_MAX_LENGTH`, `SUBJECT_RULES`, `BODY_MAX_LINE_LENGTH`, `ENFORCEMENT`). Forbidden-footer detection lives in `bash_validator`.
 **Logs:** `.claude/logs/commit-violations.jsonl`
 
 ---
@@ -108,16 +108,11 @@ This validation module works with skills in a **hybrid model**:
 
 ```
 ┌──────────────────────────────────────────────────────────┐
-│  config/git_standards.json (SSOT)                         │
-│  - Conventional commit types                              │
-│  - Forbidden footers                                      │
-│  - Max lengths                                            │
-└──────────────────────────────────────────────────────────┘
-                        │
-                        ▼
-┌──────────────────────────────────────────────────────────┐
 │  hooks/modules/validation/ (Commit Validation)            │
 │  └─ commit_validator.py                                   │
+│     ├─ Standards inlined as module-level constants        │
+│     │   (types, subject/body max lengths, rules)          │
+│     ├─ Forbidden footers handled by bash_validator        │
 │     └─ Used by bash_validator.py only                     │
 └──────────────────────────────────────────────────────────┘
                         │
@@ -178,24 +173,20 @@ Note: commit_validator.py moved to hooks/modules/validation/
 
 ## Configuration
 
-**Git Standards:** `.claude/config/git_standards.json`
+**Git Standards:** Inlined as module-level constants in `hooks/modules/validation/commit_validator.py`.
 
 Example:
-```json
-{
-  "commit_message": {
-    "type_allowed": ["feat", "fix", "refactor", "docs", "test", "chore"],
-    "subject_max_length": 72,
-    "footer_forbidden": ["Generated with Claude Code"]
-  },
-  "enforcement": {
-    "enabled": true,
-    "block_on_failure": true,
-    "log_violations": true
-  }
-}
+```python
+TYPE_ALLOWED = ("feat", "fix", "refactor", "docs", "test", "chore",
+                "ci", "perf", "style", "build")
+SUBJECT_MAX_LENGTH = 72
+SUBJECT_RULES = {"no_period_at_end": True, "no_emoji": True,
+                 "imperative_mood": True, "capitalize_first_letter": False}
+ENFORCEMENT = {"enabled": True, "block_on_failure": True, "log_violations": True}
 ```
 
+Forbidden-footer detection lives, hardcoded, in `bash_validator`.
+
 ---
 
 ## Logs
@@ -232,7 +223,7 @@ Example entry:
 
 ## See Also
 
-- `.claude/config/git_standards.json` - Git standards configuration
+- `hooks/modules/validation/commit_validator.py` - Git standards (inlined constants)
 - `.claude/skills/subagent-request-approval/SKILL.md` - Approval-request workflow patterns
 - `.claude/skills/execution/SKILL.md` - Execution workflow patterns
 - `CLAUDE.md` - Orchestrator protocol with T3 workflow

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

@@ -1,6 +1,6 @@
 {
   "name": "gaia-security",
-  "version": "5.0.2",
+  "version": "5.0.5",
   "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/modules/agents/contract_validator.py

@@ -19,6 +19,7 @@ Provides:
     - parse_rollback_executed(): Parse rollback_executed clause (advisory)
     - parse_context_consumption(): Parse context_consumption clause (advisory)
     - parse_memory_suggestions(): Parse memory_suggestions clause (advisory)
+    - parse_user_facing_summary(): Parse user_facing_summary clause (advisory)
 """
 
 import json
@@ -655,6 +656,23 @@ def parse_memory_suggestions(contract: dict) -> List[str]:
     return [str(item) for item in raw if item is not None]
 
 
+def parse_user_facing_summary(contract: dict) -> Optional[str]:
+    """Parse the optional top-level ``user_facing_summary`` clause (advisory).
+
+    The single human-audience field in the contract: a short prose summary the
+    subagent writes once for the user. The orchestrator relays it near-verbatim
+    on a single-agent COMPLETE (N=1) instead of re-synthesizing ``key_outputs``.
+
+    Strictly additive and advisory -- the validator never rejects based on this
+    field. Returns the trimmed string when present and non-empty, else None.
+    """
+    raw = contract.get("user_facing_summary")
+    if not isinstance(raw, str):
+        return None
+    text = raw.strip()
+    return text or None
+
+
 def extract_plan_status_from_output(agent_output: str) -> str:
     """Extract the effective plan_status string from agent output.