@jaguilar87/gaia-ops 4.4.0 → 4.7.2

package/skills/agent-protocol/SKILL.md

@@ -36,20 +36,20 @@ Every response MUST end with a single fenced `json:contract` block.
 
 ### agent_status (always required)
 
-- `plan_status` — one of the 6 valid states below
-- `agent_id` — generate once, reuse across responses
-- `pending_steps` — remaining work (`[]` when done)
-- `next_action` — `"done"` or what happens next
+- `plan_status` -- one of the 5 valid states below
+- `agent_id` -- generate once, reuse across responses
+- `pending_steps` -- remaining work (`[]` when done)
+- `next_action` -- `"done"` or what happens next
 
 ### evidence_report (always required)
 
 All 7 fields validated by runtime. Use `[]` when not applicable.
 Keep each to 1-3 items unless the task genuinely needs more.
 
-- `key_outputs` — actionable findings, not descriptions of what you ran. Highlight what matters: what is wrong, what changed, what needs attention.
-- `verbatim_outputs` — literal command output; truncate at ~100 lines
-- `cross_layer_impacts` — adjacent surfaces affected
-- `open_gaps` — what remains unverified; never imply certainty
+- `key_outputs` -- actionable findings, not descriptions of what you ran. Highlight what matters: what is wrong, what changed, what needs attention.
+- `verbatim_outputs` -- literal command output; truncate at ~100 lines
+- `cross_layer_impacts` -- adjacent surfaces affected
+- `open_gaps` -- what remains unverified; never imply certainty
 
 ### consolidation_report (when multi-surface)
 
@@ -61,30 +61,31 @@ Fields: `ownership_assessment`, `confirmed_findings`,
 
 For examples, read `examples.md` in this skill directory.
 
-### approval_request (when REVIEW or AWAITING_APPROVAL)
+### approval_request (when REVIEW)
 
-Required when `plan_status` is `REVIEW` or `AWAITING_APPROVAL`. Otherwise `null`.
+Required when `plan_status` is `REVIEW`. Otherwise `null`.
 
 Fields: `operation`, `exact_content`, `scope`, `risk_level`, `rollback`, `verification`.
-For `AWAITING_APPROVAL`, also include `nonce`.
+When a hook blocked a T3 command with `[T3_BLOCKED]` and an `approval_id`:
+- Do NOT retry the command -- retrying generates new nonces in a loop
+- Set `plan_status` to `REVIEW` and include `approval_id` in `approval_request`
+- The orchestrator will resume you after user approval; only then retry
 
 ## State Machine
 
 | Status | Meaning |
 |--------|---------|
 | `IN_PROGRESS` | Active work: investigating, planning, executing, retrying (max 2 cycles) |
-| `REVIEW` | Presenting plan or analysis for user feedback. No nonce. |
-| `AWAITING_APPROVAL` | Hook blocked a T3 command. Nonce present. |
+| `REVIEW` | Presenting plan or analysis for user feedback. May include `approval_id` when hook-blocked. |
 | `COMPLETE` | Task finished |
-| `BLOCKED` | Cannot proceed — escalated |
+| `BLOCKED` | Cannot proceed -- escalated |
 | `NEEDS_INPUT` | Missing information from user |
 
 ### Transitions
 
 ```
 IN_PROGRESS -> COMPLETE                                    (T0/T1/T2)
-IN_PROGRESS -> REVIEW -> IN_PROGRESS -> COMPLETE           (plan-first)
-IN_PROGRESS -> AWAITING_APPROVAL -> IN_PROGRESS -> COMPLETE (hook-blocked T3)
+IN_PROGRESS -> REVIEW -> IN_PROGRESS -> COMPLETE           (plan-first or hook-blocked T3)
 IN_PROGRESS -> BLOCKED | NEEDS_INPUT                       (any point)
 IN_PROGRESS -> IN_PROGRESS                                 (retry, max 2)
 ```

package/skills/agent-protocol/examples.md

@@ -106,22 +106,22 @@ See `SKILL.md` for the schema definition and field rules.
 }
 ```
 
-## AWAITING_APPROVAL (hook blocked T3 command, nonce present)
+## REVIEW with approval_id (hook blocked T3 command)
 
 ```json:contract
 {
   "agent_status": {
-    "plan_status": "AWAITING_APPROVAL",
+    "plan_status": "REVIEW",
     "agent_id": "af1d9b7",
     "pending_steps": ["execute git push", "verify Flux reconciliation"],
-    "next_action": "Hook blocked git push -- awaiting nonce-based approval"
+    "next_action": "Hook blocked git push -- awaiting user approval"
   },
   "evidence_report": {
     "patterns_checked": ["git branch naming in flux/clusters/"],
     "files_checked": ["flux/apps/qxo-api/helmrelease.yaml"],
     "commands_run": ["git diff HEAD -> 1 file changed", "git push origin main -> BLOCKED by hook"],
-    "key_outputs": ["Push blocked by mutative_verbs hook, nonce issued"],
-    "verbatim_outputs": ["APPROVAL REQUIRED. Present your plan to the user and include this approval code: NONCE:a1b2c3..."],
+    "key_outputs": ["Push blocked by security hook, approval_id issued"],
+    "verbatim_outputs": ["[T3_BLOCKED] MUTATIVE operation requires user approval. approval_id: a1b2c3..."],
     "cross_layer_impacts": ["Flux will reconcile HelmRelease on push"],
     "open_gaps": []
   },
@@ -133,7 +133,7 @@ See `SKILL.md` for the schema definition and field rules.
     "risk_level": "MEDIUM",
     "rollback": "git revert HEAD && git push",
     "verification": "flux get hr -n qxo -> reconciled",
-    "nonce": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
+    "approval_id": "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6"
   }
 }
 ```

package/skills/agent-response/SKILL.md

@@ -12,12 +12,12 @@ metadata:
 
 ```
 Agent returns json:contract
-  ├─ COMPLETE         → Summarize key_outputs (3-5 bullets)
-  ├─ NEEDS_INPUT      → AskUserQuestion, then SendMessage answer back
-  ├─ REVIEW           → AskUserQuestion (execute/modify/cancel), then SendMessage decision
-  ├─ AWAITING_APPROVAL → Load Skill("orchestrator-approval")
-  ├─ BLOCKED          → Present open_gaps via AskUserQuestion
-  └─ IN_PROGRESS      → SendMessage to resume agent
+  |- COMPLETE         -> Summarize key_outputs (3-5 bullets)
+  |- NEEDS_INPUT      -> AskUserQuestion, then SendMessage answer back
+  |- REVIEW           -> Load Skill("orchestrator-approval") if approval_id present,
+  |                      otherwise AskUserQuestion (execute/modify/cancel)
+  |- BLOCKED          -> Present open_gaps via AskUserQuestion
+  +- IN_PROGRESS      -> SendMessage to resume agent
 ```
 
 ## Mandatory Actions per Status
@@ -25,9 +25,8 @@ Agent returns json:contract
 | Status | Action | Tool |
 |---|---|---|
 | `COMPLETE` | Summarize `key_outputs` in 3-5 bullets. Mention `cross_layer_impacts` and `open_gaps` if non-empty. Say "ask for details" if `verbatim_outputs` exists. | Direct response |
-| `NEEDS_INPUT` | Present the agent's question with options | `AskUserQuestion` → `SendMessage` |
-| `REVIEW` | Present plan with options: execute / modify / cancel | `AskUserQuestion` → `SendMessage` |
-| `AWAITING_APPROVAL` | Do not handle directly | `Skill("orchestrator-approval")` |
+| `NEEDS_INPUT` | Present the agent's question with options | `AskUserQuestion` -> `SendMessage` |
+| `REVIEW` | If `approval_request.approval_id` is present: load `Skill("orchestrator-approval")`. Otherwise: present plan with options execute / modify / cancel. | `AskUserQuestion` -> `SendMessage` |
 | `BLOCKED` | Present alternatives from `open_gaps` | `AskUserQuestion` |
 | `IN_PROGRESS` | Agent was interrupted, let it continue | `SendMessage` |
 
@@ -35,10 +34,10 @@ Agent returns json:contract
 
 | Field | When to surface |
 |---|---|
-| `key_outputs` | Always — base your summary on these |
-| `verbatim_outputs` | Only when user asks for details — relay in code blocks |
+| `key_outputs` | Always -- base your summary on these |
+| `verbatim_outputs` | Only when user asks for details -- relay in code blocks |
 | `cross_layer_impacts` | Always mention if non-empty |
-| `open_gaps` | Always mention — never imply certainty |
+| `open_gaps` | Always mention -- never imply certainty |
 | `consolidation_report` | Check for `conflicts` and `next_best_agent` |
 | `next_best_agent` | Ask user if they want to dispatch |
 
@@ -51,6 +50,4 @@ If agents conflict, present both sides and ask user to decide.
 
 | Situation | Action |
 |---|---|
-| Hook blocks a command | Relay message verbatim. Do not try alternatives. |
-| Agent contradicts another | Show both findings, flag conflict, ask user. |
 | Malformed contract | Resume agent with repair instructions (max 2 retries). |

package/skills/approval/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 ## Overview
 
-The plan is a contract. The user approves the exact contract —
+The plan is a contract. The user approves the exact contract --
 not a vague intent. Structure your plan in the `approval_request`
 field of your `json:contract` so the orchestrator can present it
 directly to the user.
@@ -31,9 +31,9 @@ with these 6 fields:
 }
 ```
 
-For `AWAITING_APPROVAL` (hook-blocked), also include:
+When a hook blocked your command with an `approval_id`, also include:
 ```json
-"nonce": "hex from hook block response"
+"approval_id": "hex from hook deny response"
 ```
 
 ### Risk Levels
@@ -47,24 +47,39 @@ For `AWAITING_APPROVAL` (hook-blocked), also include:
 
 ## Which Status to Emit
 
-- `REVIEW` — presenting a plan before executing (no hook block)
-- `AWAITING_APPROVAL` — hook blocked your command with `NONCE:<hex>`
+- `REVIEW` -- presenting a plan before executing (no hook block)
+- `REVIEW` with `approval_id` -- hook blocked your command with an approval_id
 
-## Nonce Flow
+Both use `REVIEW` as the plan_status. The presence or absence of
+`approval_id` in `approval_request` tells the orchestrator which
+handling path to take.
 
-When a hook blocks your command, it returns a nonce:
+## Hook Block Flow
+
+When a hook blocks your command with `[T3_BLOCKED]` and an `approval_id`:
+
+1. **STOP** -- do NOT retry the command. Retrying generates a new nonce
+   each time, creating an infinite loop.
+2. **Report REVIEW** -- set `plan_status` to `REVIEW` in your `json:contract`.
+3. **Include the approval_id** -- copy the hex identifier from the hook deny
+   response into `approval_request.approval_id`.
+4. **Wait** -- the orchestrator presents your plan to the user. When the user
+   approves, the orchestrator resumes you with the grant activated.
+5. **Then retry** -- only after the orchestrator resumes you, retry the command.
+
+The hook deny message looks like:
 ```
-APPROVAL REQUIRED. ... NONCE:<hex>
+[T3_BLOCKED] This command requires user approval.
+Do NOT retry this command. Report REVIEW with this approval_id in your json:contract.
+approval_id: <hex>
 ```
 
-Include this nonce in your `approval_request`. It is machine-readable —
-the orchestrator extracts it silently.
-
-If you lose the nonce, re-attempt the command for a fresh one.
+If you lose the approval_id, re-attempt the command once for a fresh one.
 
 ## Anti-Patterns
 
+- **Retrying after T3_BLOCKED** -- generates a new nonce, causes infinite loop
 - Presenting approval without all 6 fields in `approval_request`
 - Putting approval fields in text only without the JSON object
 - Treating prior approvals as valid for new operations
-- Fabricating or paraphrasing the nonce token
+- Fabricating or paraphrasing the approval_id token

package/skills/approval/reference.md

@@ -43,10 +43,10 @@ These 6 fields MUST appear in the `approval_request` object of your `json:contra
 | `rollback` | `"terraform -chdir=/infra/dev apply -target=module.vpc -var='cidr=10.0.0.0/16'"` |
 | `verification` | `"terraform -chdir=/infra/dev output vpc_id -- expect vpc-xxx"` |
 
-For `AWAITING_APPROVAL`, also include:
+When a hook blocked the command, also include:
 | Field | Example value |
 |-------|---------------|
-| `nonce` | `"a1b2c3d4e5f6..."` (hex from hook block response) |
+| `approval_id` | `"a1b2c3d4e5f6..."` (hex from hook deny response) |
 
 ### Files Affected
 

package/skills/execution/SKILL.md

@@ -24,7 +24,7 @@ system in a broken state.
 
 Before executing ANY approved operation:
 
-- [ ] Prompt contains canonical token: `APPROVE:<nonce>`
+- [ ] User approved via AskUserQuestion and ElicitationResult hook activated the grant
 - [ ] Capture current state — know what you can roll back to
 - [ ] Plan still valid — re-run dry-run if time has passed
 - [ ] Commands will not prompt for interactive input

package/skills/gaia-patterns/SKILL.md

@@ -27,8 +27,7 @@ Domain knowledge for the gaia-ops meta-system. For the Component Map details, se
 5. Post-Tool Hook — audit + metrics
    ↓
 6. Orchestrator processes `json:contract` block (plan_status)
-   ├─ REVIEW → present plan, get feedback → resume
-   ├─ AWAITING_APPROVAL → present plan + nonce relay → resume
+   ├─ REVIEW → present plan, get feedback → resume (with approval_id if hook-blocked)
    ├─ NEEDS_INPUT → ask user → resume
    └─ COMPLETE → respond to user
 ```
@@ -38,7 +37,7 @@ Domain knowledge for the gaia-ops meta-system. For the Component Map details, se
 - **Binary Delegation:** The orchestrator always delegates. Its only tools are Agent and AskUserQuestion.
 - **Agent Instantiation:** identity (.md) + skills (injected) + project-context (contracts) + orchestrator request.
 - **Security Tiers:** T0 (read) → T1 (validate) → T2 (simulate) → T3 (realize, requires approval).
-- **T3 Flow:** IN_PROGRESS → REVIEW → IN_PROGRESS → COMPLETE (plan-first) or IN_PROGRESS → AWAITING_APPROVAL → IN_PROGRESS → COMPLETE (hook-blocked).
+- **T3 Flow:** IN_PROGRESS → REVIEW → IN_PROGRESS → COMPLETE (plan-first or hook-blocked with approval_id).
 - **Consolidation Loop:** for multi-surface work, Gaia may dispatch more than one round of agents, but only while gaps are actionable and evidence is still improving.
 - **Principle:** Skills teach process. Agents teach identity and domain knowledge. Runtime enforces deterministic contracts. Never duplicate.
 

package/skills/orchestrator-approval/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: orchestrator-approval
-description: Use when processing AWAITING_APPROVAL from a subagent -- enforces showing values before asking for user consent (not for REVIEW)
+description: Use when processing REVIEW with approval_id from a subagent -- enforces showing values before asking for user consent
 metadata:
   user-invocable: false
   type: discipline
@@ -9,9 +9,9 @@ metadata:
 # Orchestrator Approval
 
 ```
-THIS SKILL HANDLES ONLY AWAITING_APPROVAL (hook-blocked T3 with nonce).
-REVIEW states are handled directly by the orchestrator -- this skill does not apply.
-NEVER RELAY APPROVE:<nonce> WITHOUT SHOWING THE USER
+THIS SKILL HANDLES REVIEW WITH approval_id (hook-blocked T3).
+Plain REVIEW (plan-first, no approval_id) is handled directly by the orchestrator.
+NEVER PRESENT AN APPROVAL WITHOUT SHOWING THE USER
 (1) WHAT WILL HAPPEN, (2) EXACT CONTENT/COMMAND, (3) WHAT IT MODIFIES.
 ```
 
@@ -19,13 +19,13 @@ NEVER RELAY APPROVE:<nonce> WITHOUT SHOWING THE USER
 
 The orchestrator sits between the subagent and the user. The subagent presents a plan; the user decides. But the user cannot decide on information they have not seen. Every approval prompt must contain enough detail for informed consent -- not a summary, not a reference to "the plan above", not an offer to show details on request. The values go in the prompt, every time, before the question is asked.
 
-The agent-facing approval skill (`skills/approval/SKILL.md`) ensures the subagent builds a complete plan. This skill ensures the orchestrator presents that plan faithfully before asking for consent.
+When a hook blocks a T3 command, it writes a pending approval and returns an `approval_id` in the deny response. The subagent includes this `approval_id` in its `approval_request`. The orchestrator presents the plan via AskUserQuestion with structured options (Approve / Modify / Reject). When the user selects "Approve", the PostToolUse hook for AskUserQuestion fires and activates the pending grant. No nonce or approval_id is relayed through SendMessage -- grant activation is handled entirely by the hook.
 
-**Scope:** This skill applies ONLY when a subagent emits `AWAITING_APPROVAL` (a hook blocked a T3 command and a nonce is present). When a subagent emits `REVIEW` (plan-first, no nonce), the orchestrator handles it directly by summarizing and asking the user -- no nonce relay is involved.
+**Scope:** This skill applies ONLY when a subagent emits `REVIEW` with an `approval_id` in its `approval_request`. Without `approval_id`, the orchestrator handles REVIEW directly.
 
 ## Mandatory Presentation Block
 
-Every `AWAITING_APPROVAL` presented to the user MUST include these 5 fields.
+Every hook-blocked `REVIEW` presented to the user MUST include these 5 fields.
 Read them from the `approval_request` object in the agent's `json:contract` block:
 
 | Field | Source in `approval_request` | Content |
@@ -36,57 +36,29 @@ Read them from the `approval_request` object in the agent's `json:contract` bloc
 | **RISK_LEVEL** | `approval_request.risk_level` | LOW / MEDIUM / HIGH / CRITICAL |
 | **ROLLBACK** | `approval_request.rollback` | How to undo if wrong |
 
-The nonce comes from `approval_request.nonce` (present only for `AWAITING_APPROVAL`).
-
-Present these fields, then use AskUserQuestion with labeled options: **Approve / Modify / Reject**.
-
 ## Rules
 
-**1. Human approval is not a hook nonce.**
-Human approval = semantic consent for an operation. Hook nonce = machine token for one blocked T3 command. They are different things with different lifecycles.
-
-**2. Never synthesize a nonce.**
-Only use `APPROVE:<nonce>` with a real hex nonce from the subagent's latest blocked command output. Never construct tokens like `APPROVE:commit`, `APPROVE:git push`, or `APPROVE:terraform apply prod`.
-
-**3. Approval intent vs nonce relay.**
-If the user approves but no nonce exists yet, store that as intent only. Resume the subagent with natural language and let it continue until the hook generates a real nonce.
-
-**4. Scope guard.**
-When a nonce arrives, compare the blocked command's scope to what the user originally approved. If the command expands scope, changes operation, or targets something materially different -- present the new scope and ask again.
-
-**5. Fresh presentation every time.**
-Each `AWAITING_APPROVAL` requires its own presentation with all mandatory fields. Prior approvals do not carry forward.
-
-## Nonce Relay Procedure
-
-1. Extract the 5 mandatory fields from `approval_request` in the subagent's `json:contract` block. Extract the nonce from `approval_request.nonce` (present only for `AWAITING_APPROVAL`).
-2. Present to the user via AskUserQuestion with all mandatory fields populated. Options: **Approve / Modify / Reject**. Never include the nonce in user-facing text.
-3. On user approval:
-   - If nonce exists: resume the subagent via SendMessage(to: agentId) with `APPROVE:<nonce>` as the message.
-   - If no nonce yet: store approval intent. Resume subagent via SendMessage with natural language describing the approved direction.
-4. On scope change: if the eventual blocked command differs materially from what the user approved, present the new scope with all mandatory fields and ask again.
+**1. Grant activates through the PostToolUse hook for AskUserQuestion -- not SendMessage.**
+Resume the subagent via SendMessage with natural language only (e.g., "Proceed with the approved operation"). Never include any nonce, approval_id, or APPROVE: token.
 
-**Note:** After relaying the nonce, Claude Code will show a native confirmation
-dialog to the user for the first execution. This is the double-barrier security
-gate -- the user approved the plan through the orchestrator, and now confirms the
-actual command execution through the native dialog. Subsequent commands within the
-approval TTL window proceed without the native dialog.
+**2. Scope guard.**
+Compare the blocked command's scope to what the user originally approved. If the command expands scope, changes operation, or targets something materially different -- present the new scope and ask again.
 
-## Red Flags -- Stop Before Relaying
+**3. Fresh presentation every time.**
+Each hook-blocked REVIEW requires its own presentation with all mandatory fields. Prior approvals do not carry forward.
 
-If you are forming any of these thoughts, stop. You are about to violate the presentation contract:
+## Approval Procedure
 
-- *"The change is obvious from the operation name"* -- Show exact content anyway.
-- *"The subagent already showed the user the plan"* -- Show it again in the approval prompt.
-- *"It's just a git commit / small edit"* -- Size does not change the contract.
-- *"I'll show details if they ask"* -- Show BEFORE asking, not after.
-- *"The user already approved this type of operation"* -- Each AWAITING_APPROVAL requires fresh presentation.
-- *"I can construct the nonce from the operation description"* -- Nonces are hex tokens from the hook, never synthesized.
+1. Extract the 5 mandatory fields from `approval_request` in the subagent's `json:contract` block.
+2. Present to the user via AskUserQuestion with all mandatory fields populated. Use exactly these options: **Approve / Modify / Reject**. Never include the approval_id in user-facing text.
+3. On "Approve": resume the subagent via SendMessage with natural language describing the approved direction.
+4. On scope change: present the new scope with all mandatory fields and ask again.
 
 ## Anti-Patterns
 
 - **Summary-only approval** -- presenting "Deploy to dev?" without the exact command, files, or rollback.
-- **Stale nonce** -- relaying a nonce from a previous blocked command instead of the latest one.
-- **Nonce in user text** -- showing the hex token to the user. The nonce is a machine handshake, never user-facing.
-- **Implicit carry-forward** -- treating a prior approval as valid for a new AWAITING_APPROVAL.
+- **Token relay in SendMessage** -- including approval_id or nonce in the resume message.
+- **Implicit carry-forward** -- treating a prior approval as valid for a new hook-blocked REVIEW.
 - **Details on demand** -- offering to show the plan instead of showing it upfront.
+- **"It's just a small change"** -- size does not change the contract. Show exact content regardless.
+- **"The subagent already showed it"** -- show it again in the approval prompt.

package/skills/security-tiers/SKILL.md

@@ -54,7 +54,7 @@ Conditional commands like `git branch` are safe for listing but T3 with mutative
 
 ## T3 Workflow
 
-For T3 operations, follow the state flow in `agent-protocol`: IN_PROGRESS -- REVIEW -- IN_PROGRESS -- COMPLETE (plan-first) or IN_PROGRESS -- AWAITING_APPROVAL -- IN_PROGRESS -- COMPLETE (hook-blocked).
+For T3 operations, follow the state flow in `agent-protocol`: IN_PROGRESS -- REVIEW -- IN_PROGRESS -- COMPLETE (plan-first or hook-blocked with approval_id).
 
 On-demand workflow skills (read from disk when needed):
 - `.claude/skills/approval/SKILL.md` -- informed-consent plan quality and approval presentation

package/templates/README.md

@@ -16,12 +16,12 @@ Generates final file in project
 
 ## Available Templates
 
-### `settings.template.json`
+### `managed-settings.template.json`
 
-Template for permissions and security configuration. Replaced on every update -- the template is the source of truth.
+Reference template for enterprise deployment via Claude.ai Admin Console or `/etc/claude-code/managed-settings.json`. Contains wildcard deny rules with highest precedence (cannot be overridden by user/project settings). Includes `disableBypassPermissionsMode` to prevent `--dangerously-skip-permissions`.
 
-**Generated by:** `bin/gaia-scan.py`, `bin/gaia-update.js`
-**Output file:** `./.claude/settings.json`
+**Deployed by:** Organization admin (not automated)
+**Output:** `/etc/claude-code/managed-settings.json` (Linux) or Admin Console
 
 ---
 
@@ -40,7 +40,7 @@ Template for the project governance document. Placeholders are filled with value
 
 ## Note on CLAUDE.md
 
-Orchestrator identity is no longer generated from a template. It is injected dynamically by the UserPromptSubmit hook via `ops_identity.py` and on-demand skills (`project-dispatch`, `agent-response`).
+Orchestrator identity is no longer generated from a template. It is injected dynamically by the UserPromptSubmit hook via `ops_identity.py` with deterministic surface routing and on-demand skills (`agent-response`).
 
 ## Usage
 
@@ -56,15 +56,15 @@ node node_modules/@jaguilar87/gaia-ops/bin/gaia-update.js
 
 ```
 templates/
-├── settings.template.json
-├── governance.template.md
+├── managed-settings.template.json   # Enterprise deny rules (manual deploy)
+├── governance.template.md           # Project governance (interpolated)
 └── README.md
 ```
 
 **Scripts using templates:**
 - `bin/gaia-scan.py` - Installer
-- `bin/gaia-update.js` - Updater
+- `bin/gaia-update.js` - Updater (permissions merge into settings.local.json)
 
 ---
 
-**Updated:** 2026-03-19 | **Templates:** 2
+**Updated:** 2026-03-26 | **Templates:** 2

package/templates/managed-settings.template.json

@@ -0,0 +1,43 @@
+{
+  "_comment": [
+    "Managed settings template for enterprise/organization deployment.",
+    "Deploy to: /etc/claude-code/managed-settings.json (Linux/WSL)",
+    "           /Library/Application Support/ClaudeCode/managed-settings.json (macOS)",
+    "           Or via Claude.ai Admin > Claude Code > Managed Settings",
+    "",
+    "These rules have the HIGHEST precedence and CANNOT be overridden by",
+    "user, project, or local settings. They are the ultimate security gate."
+  ],
+  "permissions": {
+    "deny": [
+      "Bash(aws * delete-*:*)",
+      "Bash(aws * terminate-*:*)",
+      "Bash(az * delete:*)",
+      "Bash(gcloud * delete:*)",
+      "Bash(gsutil rb:*)",
+      "Bash(gsutil rm:*)",
+      "Bash(gcloud storage rm:*)",
+      "Bash(kubectl delete:*)",
+      "Bash(kubectl drain:*)",
+      "Bash(terraform destroy:*)",
+      "Bash(terragrunt destroy:*)",
+      "Bash(terragrunt run-all destroy:*)",
+      "Bash(helm uninstall:*)",
+      "Bash(helm delete:*)",
+      "Bash(flux uninstall:*)",
+      "Bash(docker system prune:*)",
+      "Bash(docker volume prune:*)",
+      "Bash(git push --force:*)",
+      "Bash(git push -f:*)",
+      "Bash(git reset --hard:*)",
+      "Bash(gh repo delete:*)",
+      "Bash(glab project delete:*)",
+      "Bash(dd:*)",
+      "Bash(fdisk:*)",
+      "Bash(mkfs:*)",
+      "Bash(mkfs.*:*)"
+    ]
+  },
+  "disableBypassPermissionsMode": "disable",
+  "allowManagedHooksOnly": false
+}

package/tools/gaia_simulator/runner.py

@@ -352,6 +352,39 @@ class HookRunner:
 
         return base_dir
 
+    # Tools that the orchestrator is allowed to use directly.
+    # Payloads for these tools should NOT get agent_id injected, because
+    # they are orchestrator-level operations (dispatch, communication).
+    _ORCHESTRATOR_TOOLS = frozenset({
+        "agent", "task", "sendmessage", "skill",
+        "taskcreate", "taskupdate", "tasklist", "taskget",
+        "toolsearch", "websearch", "webfetch", "askuserquestion",
+        "stop",  # stop_hook payloads are not subject to delegate mode
+    })
+
+    def _prepare_payload(self, event: ReplayEvent) -> str:
+        """Serialize the event payload for the hook subprocess.
+
+        Injects ``agent_id`` into tool-call payloads that lack one, so
+        delegate mode recognises them as subagent context instead of
+        blocking them as orchestrator calls. Agent/SendMessage/Task
+        payloads are left untouched since the orchestrator context is
+        correct for those.
+
+        Args:
+            event: The ReplayEvent being replayed.
+
+        Returns:
+            JSON string to feed to the hook subprocess via stdin.
+        """
+        payload = event.stdin_payload
+        tool_name = (payload.get("tool_name") or event.tool_name or "").lower()
+
+        if not payload.get("agent_id") and tool_name not in self._ORCHESTRATOR_TOOLS:
+            payload = {**payload, "agent_id": "replay-simulator"}
+
+        return json.dumps(payload)
+
     def _resolve_hook_script(self, hook_name: str) -> Path:
         """Resolve hook name to script path.
 
@@ -403,7 +436,7 @@ class HookRunner:
         try:
             result = subprocess.run(
                 [sys.executable, str(script_path)],
-                input=json.dumps(event.stdin_payload),
+                input=self._prepare_payload(event),
                 capture_output=True,
                 text=True,
                 env=env,

package/tools/scan/orchestrator.py

@@ -37,6 +37,7 @@ from tools.scan.merge import (
 )
 from tools.scan.registry import ScannerRegistry
 from tools.scan.scanners.base import BaseScanner, ScanResult
+from tools.scan.workspace import WorkspaceInfo, detect_workspace_type
 
 logger = logging.getLogger(__name__)
 
@@ -267,12 +268,24 @@ class ScanOrchestrator:
         existing_sections = existing_full.get("sections", {})
         existing_metadata = existing_full.get("metadata", {})
 
+        # Step 1.5: Detect workspace type BEFORE running scanners
+        workspace_info = detect_workspace_type(root)
+        if workspace_info.is_multi_repo:
+            logger.info(
+                "Multi-repo workspace: %d repos detected",
+                len(workspace_info.repo_dirs),
+            )
+
         # Step 2: Run all scanners
         scanners = self.registry.get_all()
         if self.config.scanners:
             requested = set(self.config.scanners)
             scanners = [s for s in scanners if s.SCANNER_NAME in requested]
 
+        # Pass workspace info to each scanner instance
+        for scanner in scanners:
+            scanner.workspace_info = workspace_info
+
         scanner_results: Dict[str, ScanResult] = {}
         all_warnings: List[str] = []
         all_errors: List[str] = []

package/tools/scan/scanners/base.py

@@ -53,8 +53,16 @@ class BaseScanner(ABC):
     Performance:
     - SHOULD complete in under 3 seconds for typical projects
     - MUST respect 2-second timeout for --version calls
+
+    Optional workspace_info attribute:
+    - Set by the orchestrator before scan() when workspace type has been
+      pre-detected. Scanners can check self.workspace_info for multi-repo
+      awareness. Defaults to None (single-repo assumed).
     """
 
+    def __init__(self) -> None:
+        self.workspace_info = None  # Set by orchestrator if available
+
     @property
     @abstractmethod
     def SCANNER_NAME(self) -> str: