@jaguilar87/gaia 5.0.2 → 5.0.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (63) hide show
  1. package/.claude-plugin/marketplace.json +2 -2
  2. package/.claude-plugin/plugin.json +1 -1
  3. package/ARCHITECTURE.md +0 -1
  4. package/CHANGELOG.md +54 -0
  5. package/bin/cli/approvals.py +23 -21
  6. package/config/surface-routing.json +0 -1
  7. package/dist/gaia-ops/.claude-plugin/plugin.json +1 -1
  8. package/dist/gaia-ops/config/surface-routing.json +0 -1
  9. package/dist/gaia-ops/hooks/modules/agents/contract_validator.py +18 -0
  10. package/dist/gaia-ops/hooks/modules/agents/handoff_persister.py +212 -2
  11. package/dist/gaia-ops/hooks/modules/agents/response_contract.py +26 -0
  12. package/dist/gaia-ops/hooks/modules/agents/transcript_reader.py +15 -0
  13. package/dist/gaia-ops/hooks/modules/security/__init__.py +0 -5
  14. package/dist/gaia-ops/hooks/modules/security/approval_grants.py +122 -19
  15. package/dist/gaia-ops/hooks/modules/security/mutative_verbs.py +99 -7
  16. package/dist/gaia-ops/hooks/modules/tools/bash_validator.py +125 -24
  17. package/dist/gaia-ops/skills/agent-contract-handoff/SKILL.md +3 -0
  18. package/dist/gaia-ops/skills/agent-response/SKILL.md +4 -2
  19. package/dist/gaia-ops/skills/gaia-patterns/reference.md +2 -2
  20. package/dist/gaia-ops/skills/orchestrator-present-approval/SKILL.md +20 -5
  21. package/dist/gaia-ops/skills/orchestrator-present-approval/reference.md +32 -15
  22. package/dist/gaia-ops/skills/security-tiers/SKILL.md +5 -1
  23. package/dist/gaia-ops/skills/security-tiers/reference.md +3 -1
  24. package/dist/gaia-ops/skills/subagent-request-approval/SKILL.md +43 -6
  25. package/dist/gaia-ops/skills/subagent-request-approval/reference.md +66 -16
  26. package/dist/gaia-ops/tools/context/README.md +1 -1
  27. package/dist/gaia-ops/tools/gaia_simulator/extractor.py +0 -1
  28. package/dist/gaia-security/.claude-plugin/plugin.json +1 -1
  29. package/dist/gaia-security/hooks/modules/agents/contract_validator.py +18 -0
  30. package/dist/gaia-security/hooks/modules/agents/handoff_persister.py +212 -2
  31. package/dist/gaia-security/hooks/modules/agents/response_contract.py +26 -0
  32. package/dist/gaia-security/hooks/modules/agents/transcript_reader.py +15 -0
  33. package/dist/gaia-security/hooks/modules/security/__init__.py +0 -5
  34. package/dist/gaia-security/hooks/modules/security/approval_grants.py +122 -19
  35. package/dist/gaia-security/hooks/modules/security/mutative_verbs.py +99 -7
  36. package/dist/gaia-security/hooks/modules/tools/bash_validator.py +125 -24
  37. package/gaia/state/transitions.py +4 -4
  38. package/gaia/store/writer.py +56 -0
  39. package/hooks/modules/README.md +2 -4
  40. package/hooks/modules/agents/contract_validator.py +18 -0
  41. package/hooks/modules/agents/handoff_persister.py +212 -2
  42. package/hooks/modules/agents/response_contract.py +26 -0
  43. package/hooks/modules/agents/transcript_reader.py +15 -0
  44. package/hooks/modules/security/__init__.py +0 -5
  45. package/hooks/modules/security/approval_grants.py +122 -19
  46. package/hooks/modules/security/mutative_verbs.py +99 -7
  47. package/hooks/modules/tools/bash_validator.py +125 -24
  48. package/package.json +1 -1
  49. package/pyproject.toml +1 -1
  50. package/skills/agent-contract-handoff/SKILL.md +3 -0
  51. package/skills/agent-response/SKILL.md +4 -2
  52. package/skills/gaia-patterns/reference.md +2 -2
  53. package/skills/orchestrator-present-approval/SKILL.md +20 -5
  54. package/skills/orchestrator-present-approval/reference.md +32 -15
  55. package/skills/security-tiers/SKILL.md +5 -1
  56. package/skills/security-tiers/reference.md +3 -1
  57. package/skills/subagent-request-approval/SKILL.md +43 -6
  58. package/skills/subagent-request-approval/reference.md +66 -16
  59. package/tools/context/README.md +1 -1
  60. package/tools/gaia_simulator/extractor.py +0 -1
  61. package/dist/gaia-ops/hooks/modules/security/gitops_validator.py +0 -179
  62. package/dist/gaia-security/hooks/modules/security/gitops_validator.py +0 -179
  63. package/hooks/modules/security/gitops_validator.py +0 -179
@@ -16,10 +16,12 @@ Two-phase nonce-based approval flow:
16
16
  grant and allows it.
17
17
 
18
18
  Grants are:
19
- - Scoped to a session (CLAUDE_SESSION_ID)
20
- - Time-limited (default 10 minutes)
19
+ - Time-limited (default 10 minutes; DB grants use APPROVAL_GRANT_TTL_MINUTES)
21
20
  - Cleaned up after use or expiry
22
- - Stored in .claude/cache/approvals/
21
+ - Stored AUTHORITATIVELY in the DB (``approval_grants`` in gaia.db) since the
22
+ Brief 71 cutover. The filesystem plane (.claude/cache/approvals/) is the
23
+ DEPRECATED fallback retained only for grants minted before the cutover; new
24
+ grants are created and consumed through the DB plane (gaia.store.writer).
23
25
 
24
26
  Security properties:
25
27
  - Grants are created ONLY by the hook (not by agents)
@@ -28,8 +30,11 @@ Security properties:
28
30
  - The deny list (blocked_commands.py) is NEVER bypassed -- grants only
29
31
  override the dangerous verb detector
30
32
  - Nonces are 128-bit random hex (cannot be guessed)
31
- - Pending files are session-scoped (cannot be activated from another session)
32
- - A nonce can only be activated ONCE (pending file deleted on activation)
33
+ - A nonce can only be activated ONCE (DB row marked CONSUMED on activation;
34
+ legacy pending files are deleted on activation)
35
+ - DB grants are session-AGNOSTIC by design: the block-approve-retry flow
36
+ legitimately spans sessions, so replay protection comes from the CONSUMED
37
+ status + TTL, not from session scoping (see the DB-backed model note below)
33
38
 
34
39
  =============================================================================
35
40
  Grant lifetime (DB-backed model -- Brief 71 cutover)
@@ -1160,16 +1165,26 @@ def consume_grant(command: str, session_id: str = None) -> bool:
1160
1165
 
1161
1166
 
1162
1167
  def consume_session_grants(session_id: str = None) -> int:
1163
- """Consume all confirmed grants for a session.
1168
+ """Consume confirmed grants on the LEGACY FILESYSTEM plane for a session.
1164
1169
 
1165
- Called at SubagentStop to clean up all grants that were used during the
1166
- subagent's lifetime. Multi-use grants are also consumed (session is over).
1170
+ Called at SubagentStop. Scope is the deprecated FS plane ONLY: it sweeps
1171
+ ``grant-{session_id}-*.json`` files under the approvals cache dir and marks
1172
+ confirmed ones used (multi-use grants too, since the session is over).
1173
+
1174
+ This is a NO-OP for grants on the authoritative DB plane (post Brief 71):
1175
+ DB semantic grants are consumed on the MATCHING RETRY via
1176
+ ``consume_db_semantic_grant`` (see the module docstring, "DB-backed model"),
1177
+ NOT at SubagentStop. There is therefore no DB cleanup gap here -- DB replay
1178
+ protection is handled at consume-on-retry time, and this function
1179
+ intentionally does not (and must not) touch the DB plane. It remains live
1180
+ only to drain pre-cutover FS grants; new sessions that never write an FS
1181
+ grant simply get a return value of 0.
1167
1182
 
1168
1183
  Args:
1169
1184
  session_id: Session ID to scope consumption (defaults to env var).
1170
1185
 
1171
1186
  Returns:
1172
- Number of grants consumed.
1187
+ Number of legacy FS grants consumed (0 when no FS grants exist).
1173
1188
  """
1174
1189
  if not session_id:
1175
1190
  session_id = _get_session_id()
@@ -1789,7 +1804,31 @@ def activate_db_pending_by_prefix(
1789
1804
  reason="DB pending approval has invalid payload_json.",
1790
1805
  )
1791
1806
 
1807
+ # Multi-command (COMMAND_SET) detection. A payload carrying a
1808
+ # ``command_set`` list of more than one {command, rationale} item is a
1809
+ # batch the user approved under ONE consent. It must NOT be degraded to
1810
+ # a single command (the historic bug at this site) -- it activates into
1811
+ # a COMMAND_SET grant via the dedicated branch below. A set of length
1812
+ # <= 1 falls through to the singular SCOPE_SEMANTIC_SIGNATURE path so we
1813
+ # never mint a COMMAND_SET grant for one command.
1814
+ raw_command_set = payload.get("command_set")
1815
+ command_set_items: list = []
1816
+ if isinstance(raw_command_set, list):
1817
+ for _item in raw_command_set:
1818
+ if isinstance(_item, dict) and _item.get("command"):
1819
+ command_set_items.append(
1820
+ {
1821
+ "command": _item["command"],
1822
+ "rationale": _item.get("rationale", ""),
1823
+ }
1824
+ )
1825
+ is_command_set = len(command_set_items) > 1
1826
+
1792
1827
  command = payload.get("exact_content") or payload.get("commands", [None])[0] or ""
1828
+ if is_command_set and not command:
1829
+ # For a command_set the first item is a safe stand-in for the
1830
+ # singular display/signature path; the set itself is authoritative.
1831
+ command = command_set_items[0]["command"]
1793
1832
  if not command:
1794
1833
  logger.warning(
1795
1834
  "activate_db_pending_by_prefix: no command found in payload for %s",
@@ -1836,6 +1875,57 @@ def activate_db_pending_by_prefix(
1836
1875
  reason=f"DB transition failed: {ve}",
1837
1876
  )
1838
1877
 
1878
+ # Step 3b: COMMAND_SET branch. When the approved payload carries a set
1879
+ # of more than one command, create ONE COMMAND_SET grant covering the
1880
+ # whole batch instead of a singular SCOPE_SEMANTIC_SIGNATURE grant. The
1881
+ # set is consumed item-by-item (byte-for-byte) by bash_validator's
1882
+ # match_command_set_grant / mark_command_set_item_consumed path -- the
1883
+ # consume side is unchanged; this is the create side that was orphaned.
1884
+ #
1885
+ # Precondition: ``command_set`` in the payload is already pre-filtered to
1886
+ # mutative commands by ``_intake_command_set_pending`` (handoff_persister,
1887
+ # the only producer of these pending records in production). Activation
1888
+ # therefore assumes every item is consumable and does NOT re-filter here;
1889
+ # do not add a filtering step at this site -- it would silently drop items
1890
+ # the user already consented to under one grant.
1891
+ if is_command_set:
1892
+ created = create_command_set_grant(
1893
+ command_set_items,
1894
+ approval_id,
1895
+ session_id=current_session_id,
1896
+ agent_id=agent_id,
1897
+ ttl_minutes=DEFAULT_COMMAND_SET_TTL_MINUTES,
1898
+ )
1899
+ if not created:
1900
+ logger.error(
1901
+ "activate_db_pending_by_prefix: COMMAND_SET grant creation "
1902
+ "failed for approval_id=%s (items=%d)",
1903
+ approval_id[:16], len(command_set_items),
1904
+ )
1905
+ return ApprovalActivationResult(
1906
+ success=False,
1907
+ status=ACTIVATION_ERROR,
1908
+ reason="Failed to create COMMAND_SET grant from approved payload.",
1909
+ )
1910
+ logger.info(
1911
+ "activate_db_pending_by_prefix: COMMAND_SET grant created: "
1912
+ "approval_id=%s, items=%d, ttl=%d min, originating_session=%s, "
1913
+ "current_session=%s",
1914
+ approval_id[:16], len(command_set_items),
1915
+ DEFAULT_COMMAND_SET_TTL_MINUTES,
1916
+ (originating_session or "")[:12],
1917
+ current_session_id[:12],
1918
+ )
1919
+ return ApprovalActivationResult(
1920
+ success=True,
1921
+ status=ACTIVATION_ACTIVATED,
1922
+ reason=(
1923
+ "DB pending approval activated as a COMMAND_SET grant "
1924
+ f"({len(command_set_items)} commands under one consent)."
1925
+ ),
1926
+ grant_path=None,
1927
+ )
1928
+
1839
1929
  # Step 4: Rebuild approval signature from the command so the
1840
1930
  # filesystem grant has a valid scope_signature for check_approval_grant().
1841
1931
  from .approval_scopes import build_approval_signature, SCOPE_SEMANTIC_SIGNATURE
@@ -2026,7 +2116,13 @@ def activate_grants_for_session(
2026
2116
  # approved command (adding cd, redirect, pipe, flag) produces a different
2027
2117
  # string and requires fresh approval. Each item in the set is single-use.
2028
2118
 
2029
- DEFAULT_COMMAND_SET_TTL_MINUTES = 10
2119
+ # COMMAND_SET grant TTL in minutes. Aligned to the singular active-grant TTL
2120
+ # (DEFAULT_GRANT_TTL_MINUTES / APPROVAL_GRANT_TTL_MINUTES = 60) so a batch of
2121
+ # commands approved under one consent gets the same cross-session retry window
2122
+ # as a single approved command -- the block-approve-retry flow legitimately
2123
+ # spans sessions, and a shorter window would expire the batch before the
2124
+ # subagent could consume every item.
2125
+ DEFAULT_COMMAND_SET_TTL_MINUTES = 60
2030
2126
 
2031
2127
 
2032
2128
  def create_command_set_grant(
@@ -2107,7 +2203,6 @@ def create_command_set_grant(
2107
2203
  def match_command_set_grant(
2108
2204
  retried_command: str,
2109
2205
  *,
2110
- session_id: str | None = None,
2111
2206
  db_path=None,
2112
2207
  ) -> tuple | None:
2113
2208
  """Find an active COMMAND_SET grant containing ``retried_command``.
@@ -2117,14 +2212,26 @@ def match_command_set_grant(
2117
2212
  ``retried_command``. No normalization of any kind is applied.
2118
2213
 
2119
2214
  The grant must:
2215
+ - Have scope COMMAND_SET
2120
2216
  - Have status PENDING (not CONSUMED, REVOKED, or EXPIRED)
2121
2217
  - Not be past its expires_at timestamp
2122
2218
  - Contain ``retried_command`` at an index that has NOT been consumed
2123
- - Belong to the current session_id
2219
+
2220
+ The lookup is SESSION-AGNOSTIC (Brief 71), exactly like the singular path
2221
+ (``check_db_semantic_grant``). The block-approve-retry flow legitimately
2222
+ spans sessions, and CLAUDE_SESSION_ID is not guaranteed to be exported into
2223
+ the bash subprocess -- where ``get_session_id()`` falls back to the literal
2224
+ ``"default"``. A session_id filter therefore silently dropped every grant
2225
+ created under the real session, letting approved COMMAND_SET commands run
2226
+ WITHOUT being consumed (the consumption-bypass bug). Replay protection is
2227
+ preserved by the conjunction of the byte-for-byte match, status='PENDING'
2228
+ plus per-index ``consumed_indexes_json``, and the expires_at TTL -- none of
2229
+ which depend on which session is asking. See
2230
+ ``gaia.store.writer.list_command_set_grants_agnostic`` for the full
2231
+ security-boundary rationale.
2124
2232
 
2125
2233
  Args:
2126
2234
  retried_command: The exact command string the agent wants to run.
2127
- session_id: CLAUDE_SESSION_ID (defaults to current session).
2128
2235
  db_path: Optional explicit DB path override (used by tests).
2129
2236
 
2130
2237
  Returns:
@@ -2132,15 +2239,11 @@ def match_command_set_grant(
2132
2239
  The caller should call mark_command_set_item_consumed(approval_id, index)
2133
2240
  after successful execution.
2134
2241
  """
2135
- if session_id is None:
2136
- session_id = _get_session_id()
2137
-
2138
2242
  try:
2139
- from gaia.store.writer import list_approval_grants
2243
+ from gaia.store.writer import list_command_set_grants_agnostic
2140
2244
  from datetime import datetime, timezone
2141
2245
 
2142
- grants = list_approval_grants(
2143
- session_id=session_id,
2246
+ grants = list_command_set_grants_agnostic(
2144
2247
  status="PENDING",
2145
2248
  db_path=db_path,
2146
2249
  )
@@ -151,10 +151,10 @@ MUTATIVE_VERBS: FrozenSet[str] = frozenset({
151
151
  "disconnect", "unbind", "force-delete", "force-remove", "erase",
152
152
  # Collaboration (GitHub/GitLab CLI)
153
153
  "comment", "label", "annotate", "approve", "close", "reopen", "tag",
154
- # Helm-specific
155
- "uninstall",
156
154
  # HTTP methods (e.g., glab api -X POST, gh api -X DELETE)
157
- "post", "put", "patch",
155
+ # NOTE: "put" and "patch" already appear under Modification above, and
156
+ # "uninstall" under Deletion/removal -- so only "post" is new here.
157
+ "post",
158
158
  })
159
159
 
160
160
  SIMULATION_VERBS: FrozenSet[str] = frozenset({
@@ -283,6 +283,12 @@ COMMAND_SUBCOMMAND_TIER_EXCEPTIONS: Dict[Tuple[str, str], str] = {
283
283
  # `gaia ac <verb>` (add/remove/edit/show/list/set-status): local acceptance-
284
284
  # criteria bookkeeping — reversible, no external effects.
285
285
  ("gaia", "ac"): CATEGORY_READ_ONLY,
286
+ # `gaia plan <verb>` (save/edit/show/list/set-status): local planning
287
+ # bookkeeping in the plan store — reversible, no external effects. Anchored
288
+ # here (not left to the SIMULATION_VERBS['plan'] lexical collision) so the
289
+ # exemption is explicit and carries the same DENY-verb guard as `gaia brief`:
290
+ # `gaia plan delete` (whole-record destruction) stays T3.
291
+ ("gaia", "plan"): CATEGORY_READ_ONLY,
286
292
  }
287
293
 
288
294
  # Verbs that stay gated even under an excepted group above. The exception
@@ -294,6 +300,37 @@ COMMAND_SUBCOMMAND_EXCEPTION_DENY_VERBS: FrozenSet[str] = frozenset({
294
300
  })
295
301
 
296
302
 
303
+ # ============================================================================
304
+ # PRINCIPLE: consent-REDUCING operations are not T3.
305
+ # ----------------------------------------------------------------------------
306
+ # An operation requires T3 approval because it GRANTS capability or DESTROYS
307
+ # state — it moves the system toward *more* power or *less* recoverability, the
308
+ # directions that need informed consent. An operation that REVOKES, REJECTS,
309
+ # or CLEANS a consent grant Gaia itself issued moves in the opposite direction:
310
+ # it can only REDUCE the capability already granted. It never grants anything
311
+ # and never reaches outside the local approval store. Gating it creates an
312
+ # absurd loop — you would need an approval to clean up approvals.
313
+ #
314
+ # So: within Gaia's own consent layer (`gaia approvals ...`), verbs that REDUCE
315
+ # consent are exempted to read-only; the one verb that GRANTS capability
316
+ # (`approve`) is deliberately NOT in this set and stays T3. That asymmetry is
317
+ # the whole point: `approve` hands out capability without the AskUserQuestion
318
+ # flow, so it must remain gated; `revoke`/`reject`/`reject-all`/`clean` only
319
+ # take capability back, so they must not be.
320
+ #
321
+ # This is anchored to (base_cmd, group) so it applies ONLY to Gaia's own
322
+ # consent store, not to any other CLI's notion of "revoke"/"reject" (e.g. a
323
+ # cloud IAM revoke is a real remote mutation and must stay T3).
324
+ #
325
+ # Key: (base_cmd, subcommand-group) — e.g. ("gaia", "approvals").
326
+ # Value: frozenset of consent-REDUCING verbs under that group that are exempt.
327
+ CONSENT_REDUCING_SUBCOMMAND_EXCEPTIONS: Dict[Tuple[str, str], FrozenSet[str]] = {
328
+ ("gaia", "approvals"): frozenset({
329
+ "revoke", "reject", "reject-all", "clean",
330
+ }),
331
+ }
332
+
333
+
297
334
  # ============================================================================
298
335
  # Inline Code Detection — Language-Agnostic 3-Layer Approach
299
336
  # ============================================================================
@@ -1159,10 +1196,30 @@ def detect_mutative_command(command: str) -> MutativeResult:
1159
1196
  group_verb.split("-", 1)[0] in COMMAND_SUBCOMMAND_EXCEPTION_DENY_VERBS
1160
1197
  or group_verb in COMMAND_SUBCOMMAND_EXCEPTION_DENY_VERBS
1161
1198
  )
1162
- if (
1163
- subcommand_key in COMMAND_SUBCOMMAND_TIER_EXCEPTIONS
1164
- and not verb_is_destructive
1165
- ):
1199
+ if subcommand_key in COMMAND_SUBCOMMAND_TIER_EXCEPTIONS:
1200
+ if verb_is_destructive:
1201
+ # Whole-record destruction (e.g. `gaia plan delete`) must stay
1202
+ # T3 even inside an excepted group. Anchor it MUTATIVE here
1203
+ # instead of falling through to Step 4: the group token itself
1204
+ # (`plan`) collides lexically with SIMULATION_VERBS['plan'], so
1205
+ # the verb scanner would otherwise mis-classify the whole
1206
+ # command as SIMULATION and silently un-gate the delete. This
1207
+ # explicit return is what makes `gaia plan delete` behave like
1208
+ # `gaia brief delete` (where `brief` has no such collision).
1209
+ dangerous_flags = _scan_dangerous_flags(tokens, base_cmd)
1210
+ return MutativeResult(
1211
+ is_mutative=True,
1212
+ category=CATEGORY_MUTATIVE,
1213
+ verb=group_verb.split("-", 1)[0],
1214
+ dangerous_flags=dangerous_flags,
1215
+ cli_family=family,
1216
+ confidence="high",
1217
+ reason=(
1218
+ f"Whole-record destruction "
1219
+ f"'{base_cmd} {semantics.non_flag_tokens[0]} {group_verb}' "
1220
+ f"stays T3 despite the local bookkeeping exception"
1221
+ ),
1222
+ )
1166
1223
  dangerous_flags = _scan_dangerous_flags(tokens, base_cmd)
1167
1224
  if not dangerous_flags:
1168
1225
  target_category = COMMAND_SUBCOMMAND_TIER_EXCEPTIONS[subcommand_key]
@@ -1179,6 +1236,41 @@ def detect_mutative_command(command: str) -> MutativeResult:
1179
1236
  ),
1180
1237
  )
1181
1238
 
1239
+ # --- Step 3f: Consent-reducing operations are not T3 (anchored) ---
1240
+ # Within Gaia's own consent layer (`gaia approvals ...`), verbs that REDUCE
1241
+ # consent (revoke/reject/reject-all/clean) can only take back capability
1242
+ # already granted — they never grant anything and never reach outside the
1243
+ # local approval store, so they are not T3. The one consent-GRANTING verb
1244
+ # (`approve`) is deliberately absent from CONSENT_REDUCING_SUBCOMMAND_
1245
+ # EXCEPTIONS and falls through to Step 4, where it stays MUTATIVE/T3. That
1246
+ # asymmetry is the principle: granting capability needs consent, reducing it
1247
+ # does not. Anchored to (base_cmd, group) so it never relaxes another CLI's
1248
+ # "revoke" (e.g. a cloud IAM revoke is a real remote mutation, still T3).
1249
+ # Dangerous flags are still scanned so a slip like `--force` re-gates.
1250
+ if semantics.non_flag_tokens:
1251
+ consent_group_key = (base_cmd, semantics.non_flag_tokens[0])
1252
+ consent_verb = (
1253
+ semantics.non_flag_tokens[1]
1254
+ if len(semantics.non_flag_tokens) > 1 else ""
1255
+ )
1256
+ reducing_verbs = CONSENT_REDUCING_SUBCOMMAND_EXCEPTIONS.get(consent_group_key)
1257
+ if reducing_verbs is not None and consent_verb in reducing_verbs:
1258
+ dangerous_flags = _scan_dangerous_flags(tokens, base_cmd)
1259
+ if not dangerous_flags:
1260
+ return MutativeResult(
1261
+ is_mutative=False,
1262
+ category=CATEGORY_READ_ONLY,
1263
+ verb=consent_verb,
1264
+ cli_family=family,
1265
+ confidence="high",
1266
+ reason=(
1267
+ f"Consent-reducing operation "
1268
+ f"'{base_cmd} {semantics.non_flag_tokens[0]} {consent_verb}' "
1269
+ f"only revokes/rejects capability already granted — "
1270
+ f"not state-granting, so not T3"
1271
+ ),
1272
+ )
1273
+
1182
1274
  # --- Step 4: Scan semantic non-flag tokens near the command head ---
1183
1275
  # Priority order: SIMULATION > MUTATIVE > READ_ONLY > ALIASES
1184
1276
  for semantic_index, token in enumerate(semantics.semantic_head_tokens[1:], start=1):
@@ -32,7 +32,6 @@ from dataclasses import dataclass
32
32
 
33
33
  from ..security.tiers import SecurityTier
34
34
  from ..security.blocked_commands import is_blocked_command
35
- from ..security.gitops_validator import validate_gitops_workflow
36
35
  from ..security.mutative_verbs import (
37
36
  detect_mutative_command,
38
37
  build_t3_block_response,
@@ -96,12 +95,35 @@ class BashValidationResult:
96
95
 
97
96
 
98
97
  # Patterns for AI tool attribution footers (auto-stripped from commits).
99
- # Covers Claude Code, GitHub Copilot, Aider, Windsurf, and any future
100
- # tool using the Co-authored-by git trailer convention.
98
+ # Covers Claude Code, GitHub Copilot, Aider, Windsurf, Codex, Gemini, the
99
+ # Anthropic model family (Opus/Sonnet/Haiku), and any future tool using the
100
+ # Co-authored-by git trailer convention.
101
+ #
102
+ # IMPORTANT: this list is the DETECTOR (`_detect_claude_footers`). It MUST stay
103
+ # aligned with the line patterns in `_strip_claude_footers` -- if the stripper
104
+ # can remove a footer the detector cannot see, the strip never fires (the
105
+ # early-normalization guard only strips when the detector returns True). Every
106
+ # footer shape the stripper removes has a corresponding detector entry here.
107
+ #
108
+ # None of these patterns anchor on a newline, so they also catch footers that
109
+ # arrive in a SECOND `-m "..."` argument (no preceding newline) -- the detector
110
+ # fires, and the stripper's `-m`-aware branch removes them.
101
111
  FORBIDDEN_FOOTER_PATTERNS = [
102
112
  r"Generated with\s+Claude Code",
103
113
  r"Generated with\s+\[?Claude Code\]?",
114
+ # Bare robot-emoji "Generated with ..." line (e.g. "🤖 Generated with ...")
115
+ # WITHOUT requiring the literal "Claude Code" after it -- the stripper has
116
+ # always removed this shape; the detector now sees it too.
117
+ r"🤖\s*Generated with",
118
+ # Robot emoji on its own is a strong AI-attribution signal.
119
+ r"🤖",
104
120
  r"Co-Authored-By:\s+Claude\b",
121
+ # Anthropic model family attributed via Co-Authored-By / Co-authored-with.
122
+ r"Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):[^\n]*\bOpus\b",
123
+ r"Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):[^\n]*\bSonnet\b",
124
+ r"Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):[^\n]*\bHaiku\b",
125
+ # "Approved-by:" attribution trailer.
126
+ r"Approved-by:",
105
127
  r"Co-authored-by:\s+GitHub Copilot\b",
106
128
  r"Co-authored-by:\s+aider\b",
107
129
  r"Co-authored-by:\s+Windsurf\b",
@@ -466,7 +488,7 @@ class BashValidator:
466
488
  # 3d. Smart sanitization (strip nohup, &, redirects)
467
489
  # 3e. Cloud pipe/redirect/chain check (corrective deny)
468
490
  # 3f. Dispatch to single/compound classification
469
- # (mutative_verbs, gitops_validator, safe-by-elimination)
491
+ # (mutative_verbs, safe-by-elimination)
470
492
  # ================================================================
471
493
 
472
494
  # 3a. Blocked commands check on FULL command (exit 2).
@@ -624,7 +646,7 @@ class BashValidator:
624
646
  if result.is_mutative:
625
647
  # Check for a DB-backed command_set grant first (M3 path).
626
648
  # Byte-for-byte match per D10: no normalization.
627
- cs_match = match_command_set_grant(command, session_id=session_id)
649
+ cs_match = match_command_set_grant(command)
628
650
  if cs_match is not None:
629
651
  cs_approval_id, cs_index = cs_match
630
652
  try:
@@ -732,17 +754,6 @@ class BashValidator:
732
754
  agent_type=agent_type,
733
755
  )
734
756
 
735
- # Check GitOps policy for kubectl/helm/flux commands
736
- if any(keyword in command for keyword in ("kubectl", "helm", "flux")):
737
- gitops_result = validate_gitops_workflow(command)
738
- if not gitops_result.allowed:
739
- return BashValidationResult(
740
- allowed=False,
741
- tier=SecurityTier.T3_BLOCKED,
742
- reason=f"GitOps policy violation: {gitops_result.reason}",
743
- suggestions=gitops_result.suggestions,
744
- )
745
-
746
757
  # Flag-dependent classification (sed -i, find -exec, tar -x, etc.)
747
758
  # This supplements mutative_verbs -- it catches flag-dependent mutations
748
759
  # that verb-based detection misses (e.g. "sed" has no mutative verb, but
@@ -775,7 +786,7 @@ class BashValidator:
775
786
  # never honoured and the command re-blocks unconditionally on
776
787
  # every retry (the flag path never reaches the matcher). The
777
788
  # consume + return semantics replicate the verb branch exactly.
778
- cs_match = match_command_set_grant(command, session_id=session_id)
789
+ cs_match = match_command_set_grant(command)
779
790
  if cs_match is not None:
780
791
  cs_approval_id, cs_index = cs_match
781
792
  try:
@@ -1004,32 +1015,77 @@ class BashValidator:
1004
1015
 
1005
1016
  def _strip_claude_footers(self, command: str) -> str:
1006
1017
  """
1007
- Strip Claude Code attribution footers from a command.
1018
+ Strip AI attribution footers from a commit command.
1008
1019
 
1009
1020
  Removes full lines matching forbidden footer patterns.
1010
1021
  Works on raw command string regardless of quoting/HEREDOC format.
1011
1022
  Preserves trailing quote/paren characters that close the commit
1012
1023
  message (e.g., the closing " in -m "...footer").
1013
1024
 
1025
+ Covers, kept ALIGNED with FORBIDDEN_FOOTER_PATTERNS (the detector):
1026
+ - Co-authored-by / Co-authored-with: Claude, Copilot, aider,
1027
+ Windsurf, Cursor, Codex, Gemini, and the Anthropic model family
1028
+ (Opus / Sonnet / Haiku)
1029
+ - "Generated with [Claude Code]" and the bare "🤖 Generated with ..."
1030
+ - a bare robot emoji 🤖 line
1031
+ - "Approved-by:" trailers
1032
+ Both newline-anchored footer LINES and footers carried in a SECOND
1033
+ ``-m "..."`` argument (no preceding newline) are handled.
1034
+
1035
+ LIMITATION -- ``git commit -F <file>`` / ``--file=<file>``: when the
1036
+ message body lives in a file, the footer is NOT in the command string
1037
+ the PreToolUse hook receives. This stripper CANNOT see or remove it,
1038
+ and deliberately does NOT read the referenced file (reading arbitrary
1039
+ paths from a hook would be an unbounded side effect and a new attack
1040
+ surface). Footer suppression for ``-F`` commits is therefore out of
1041
+ scope here and must be enforced elsewhere (e.g. a commit-msg git hook).
1042
+
1014
1043
  Args:
1015
1044
  command: Raw command string
1016
1045
 
1017
1046
  Returns:
1018
1047
  Command with footer lines removed
1019
1048
  """
1020
- # Remove full lines that contain AI attribution patterns.
1049
+ # Author/model alternation reused across line- and -m-shaped patterns.
1050
+ _authors = (
1051
+ r"Claude|GitHub Copilot|aider|Windsurf|Cursor|Codex|Gemini"
1052
+ r"|Opus|Sonnet|Haiku"
1053
+ )
1054
+
1055
+ # (1) Remove full lines that contain AI attribution patterns.
1021
1056
  # Each pattern matches the newline + footer content, then uses a
1022
1057
  # lookahead to stop before any trailing quote/paren/bracket
1023
1058
  # sequence that closes the command structure. The captured group
1024
1059
  # is replaced with empty string, leaving the closing chars intact.
1025
1060
  footer_line_patterns = [
1026
- r'\n\s*Co-[Aa]uthored-[Bb]y:\s+(?:Claude|GitHub Copilot|aider|Windsurf|Cursor|Codex|Gemini)[^\n]*?(?=["\')\]]*(?:\n|$))',
1061
+ r'\n\s*Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):\s+(?:' + _authors + r')[^\n]*?(?=["\')\]]*(?:\n|$))',
1062
+ # Co-authored-* lines naming an Anthropic model anywhere on the line.
1063
+ r'\n\s*Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):[^\n]*?\b(?:Opus|Sonnet|Haiku)\b[^\n]*?(?=["\')\]]*(?:\n|$))',
1064
+ r'\n\s*Approved-by:[^\n]*?(?=["\')\]]*(?:\n|$))',
1027
1065
  r'\n\s*Generated with\s+\[?Claude Code\]?[^\n]*?(?=["\')\]]*(?:\n|$))',
1028
1066
  r'\n\s*🤖\s*Generated with[^\n]*?(?=["\')\]]*(?:\n|$))',
1067
+ # Bare robot-emoji line (emoji not followed by "Generated with").
1068
+ r'\n\s*🤖[^\n]*?(?=["\')\]]*(?:\n|$))',
1029
1069
  ]
1030
1070
  for pattern in footer_line_patterns:
1031
1071
  command = re.sub(pattern, '', command, flags=re.IGNORECASE)
1032
1072
 
1073
+ # (2) Remove footers carried in a SEPARATE ``-m "..."`` / ``-m '...'``
1074
+ # argument. Repeated ``-m`` flags are concatenated by git as separate
1075
+ # paragraphs, so an attribution footer often arrives as
1076
+ # git commit -m "real message" -m "Co-Authored-By: ... Opus"
1077
+ # with NO preceding newline -- the line patterns above cannot see it.
1078
+ # Drop the entire trailing ``-m "<footer>"`` flag+value when its value
1079
+ # is (essentially) just an attribution footer.
1080
+ m_footer_patterns = [
1081
+ r'''\s+-m\s+(["'])\s*Co-[Aa]uthored-(?:[Bb]y|[Ww]ith):\s+(?:''' + _authors + r''')[^"']*\1''',
1082
+ r'''\s+-m\s+(["'])\s*Approved-by:[^"']*\1''',
1083
+ r'''\s+-m\s+(["'])\s*🤖[^"']*\1''',
1084
+ r'''\s+-m\s+(["'])\s*Generated with\s+\[?Claude Code\]?[^"']*\1''',
1085
+ ]
1086
+ for pattern in m_footer_patterns:
1087
+ command = re.sub(pattern, '', command, flags=re.IGNORECASE)
1088
+
1033
1089
  # Clean up trailing whitespace inside quotes/heredoc
1034
1090
  # Collapse 3+ consecutive newlines to 2
1035
1091
  command = re.sub(r'\n{3,}', '\n\n', command)
@@ -1222,6 +1278,7 @@ def _build_sealed_payload(
1222
1278
  verb: str,
1223
1279
  category: str,
1224
1280
  agent_type: str = "",
1281
+ command_set: list | None = None,
1225
1282
  ) -> dict:
1226
1283
  """Build a sealed_payload dict from hook-intercepted command context.
1227
1284
 
@@ -1229,16 +1286,51 @@ def _build_sealed_payload(
1229
1286
  and calls store.insert_requested(). The 7 D13 fields are populated from
1230
1287
  what is available at intercept time.
1231
1288
 
1289
+ Single vs. multi-command (COMMAND_SET):
1290
+ By default this builds a SINGLE-command payload -- ``commands`` is
1291
+ ``[command]`` and no ``command_set`` key is present, so activation
1292
+ mints a single-use SCOPE_SEMANTIC_SIGNATURE grant.
1293
+
1294
+ When ``command_set`` is supplied (a list of ``{command, rationale}``
1295
+ dicts representing more than one command the agent wants under ONE
1296
+ consent), the payload additionally carries a ``command_set`` key
1297
+ verbatim and ``commands`` lists every command string in the set. This
1298
+ is the signal ``activate_db_pending_by_prefix`` reads to branch into
1299
+ ``create_command_set_grant`` instead of degrading to a single command.
1300
+ The set is NOT collapsed -- every item survives into the grant.
1301
+
1232
1302
  Args:
1233
- command: The full Bash command string that was blocked.
1303
+ command: The full Bash command string that was blocked (the primary /
1304
+ first command; used for ``exact_content`` and the singular display).
1234
1305
  verb: The detected mutative verb (e.g. 'push', 'delete').
1235
1306
  category: The verb category string (e.g. 'MUTATIVE').
1236
1307
  agent_type: Name of the originating agent (may be empty).
1308
+ command_set: Optional list of ``{command, rationale}`` dicts. When it
1309
+ contains more than one item, the payload becomes a COMMAND_SET
1310
+ envelope. A list with a single item (or None) keeps the singular
1311
+ semantic-signature behaviour.
1237
1312
 
1238
1313
  Returns:
1239
- Dict with the 7 sealed_payload fields from D13.
1314
+ Dict with the 7 sealed_payload fields from D13, plus an optional
1315
+ ``command_set`` key when a multi-command set was supplied.
1240
1316
  """
1241
- return {
1317
+ # Normalize the command_set into the canonical [{command, rationale}, ...]
1318
+ # shape and decide whether this is a genuine multi-command envelope. A set
1319
+ # of length <= 1 is NOT multi-command -- it stays the singular path so we
1320
+ # never mint a COMMAND_SET grant for one command.
1321
+ normalized_set: list = []
1322
+ if command_set:
1323
+ for item in command_set:
1324
+ if isinstance(item, dict) and item.get("command"):
1325
+ normalized_set.append(
1326
+ {
1327
+ "command": item["command"],
1328
+ "rationale": item.get("rationale", ""),
1329
+ }
1330
+ )
1331
+ is_command_set = len(normalized_set) > 1
1332
+
1333
+ payload = {
1242
1334
  "operation": f"{category} command intercepted: {verb}",
1243
1335
  "exact_content": command,
1244
1336
  "scope": command.split()[0] if command.strip() else "unknown",
@@ -1250,9 +1342,18 @@ def _build_sealed_payload(
1250
1342
  if agent_type
1251
1343
  else f"A {category.lower()} ({verb}) command requires user approval per T3 policy."
1252
1344
  ),
1253
- "commands": [command],
1345
+ "commands": (
1346
+ [it["command"] for it in normalized_set] if is_command_set else [command]
1347
+ ),
1254
1348
  }
1255
1349
 
1350
+ if is_command_set:
1351
+ # Carry the full {command, rationale} set verbatim. This is the
1352
+ # multi-command signal the activation path branches on.
1353
+ payload["command_set"] = normalized_set
1354
+
1355
+ return payload
1356
+
1256
1357
 
1257
1358
  def decide_t3_outcome(
1258
1359
  command: str,
@@ -43,6 +43,7 @@ The fenced `agent_contract_handoff` block. Parsed by `parse_contract` (regex `_R
43
43
  | `consolidation_report` | Conditional | required when INPUT set `consolidation_required` / `cross_check_required` / `surface_routing.multi_surface` (`requires_consolidation_report`); else may be `null` |
44
44
  | `approval_request` | Conditional | required when `plan_status` is `APPROVAL_REQUEST`; see sub-field table |
45
45
  | `loop_state` | Conditional | agentic-loop turns only; `_check_loop_state_blocking` blocks `COMPLETE` when `iteration < max_iterations AND metric < threshold` |
46
+ | `user_facing_summary` | Optional | a brief prose summary written ONCE for the human reader; `parse_user_facing_summary`. The only human-audience field in the contract -- every other field is machine-audience for the orchestrator. On a single-agent `COMPLETE` (N=1) the orchestrator relays it near-verbatim (adapted to the user's language) instead of re-synthesizing `key_outputs`. Absent, or N>1 (multi-agent), the orchestrator falls back to synthesizing `key_outputs`. Purely additive: never required, never rejected. |
46
47
  | `memorialize_suggestions` | Optional | structured memory candidates for the user to triage; `parse_memorialize_suggestions` |
47
48
  | `memory_suggestions` | Optional | advisory text-only notes (array of strings); `parse_memory_suggestions` |
48
49
  | `update_contracts` | Optional | array of `{contract, payload}` for project-context writes; `parse_update_contracts`; see sub-field table |
@@ -67,6 +68,8 @@ The required keys are EXACTLY 7 (`_EVIDENCE_REQUIRED_FIELDS` in `contract_valida
67
68
 
68
69
  `verification` is a SEPARATE field, NOT one of the 7. It is required ONLY when `plan_status` is `COMPLETE`: it must be a dict and `verification.result` must equal `"pass"`. Missing -> `VERIFICATION_RESULT_REQUIRED_FOR_COMPLETE`; non-pass -> `VERIFICATION_RESULT_MUST_BE_PASS`. For non-COMPLETE statuses `verification` may be absent.
69
70
 
71
+ **Audience boundary.** `key_outputs` and every other `evidence_report` key are written for the **orchestrator** -- distilled findings it reasons over to route the next turn. The optional top-level `user_facing_summary` is the **single** field written for the **human**. Keeping the two distinct is what lets the orchestrator relay a human-shaped summary on N=1 without re-synthesizing machine-shaped evidence, and lets it still synthesize from `key_outputs` when the summary is absent or when multiple agents must be consolidated.
72
+
70
73
  ### consolidation_report
71
74
 
72
75
  Required keys when present (`_CONSOLIDATION_REQUIRED_FIELDS`):