@entelligentsia/forgecli 0.21.0 → 1.0.3

package/dist/forge-payload/commands/store-repair.md

@@ -1,187 +1,6 @@
 ---
 name: store-repair
-description: Diagnose and repair corrupted store records. Use when validate-store reports errors or store data seems wrong.
+description: Renamed in v1.0 — use /forge:repair
 ---
 
-# /forge:store:repair
-
-Diagnose and repair corruption in the Forge JSON store.
-
-## Arguments
-
-$ARGUMENTS
-
-| Argument | Purpose |
-|----------|---------|
-| `--dry-run` | Show what would be repaired without making any changes |
-
-## How to Run
-
-1. Resolve the plugin root:
-   ```
-   FORGE_ROOT: !`echo "${CLAUDE_PLUGIN_ROOT}"`
-   ```
-
-2. Run the four-phase repair workflow below. If `--dry-run` is in `$ARGUMENTS`,
-   preview all changes without writing — skip Phase 2 writes and Phase 3
-   writes, and skip Phase 4 verification since nothing changed.
-
-## Phase 1: Diagnosis
-
-Run the deterministic validator in JSON mode:
-
-```sh
-node "$FORGE_ROOT/tools/validate-store.cjs" --dry-run --json
-```
-
-Parse the JSON output. Categorize each error by its `category` field:
-
-| Category | Example | Deterministic fix? |
-|----------|---------|--------------------|
-| `missing-required` | `"sprintId": null` on a sprint | Yes — backfill |
-| `type-mismatch` | `"iteration": "1"` instead of `1` | Yes — coerce |
-| `invalid-enum` | `"status": "in-progress"` on a bug | No — needs judgment |
-| `undeclared-field` | `"priority": "high"` on a task | No — needs judgment |
-| `orphaned-fk` | `taskId` pointing to deleted task in event | No — needs judgment |
-| `filename-mismatch` | Event filename != eventId | Yes — rename |
-| `minimum-violation` | `"iteration": 0` | Yes — coerce |
-| `orphan-directory` | Sprint dir with no sprint record | No — needs judgment |
-| `stale-path` | `path` pointing to nonexistent dir | No — needs judgment |
-
-## Phase 2: Auto-Fix
-
-Run the deterministic validator with `--fix`:
-
-```sh
-node "$FORGE_ROOT/tools/validate-store.cjs" --fix --json
-```
-
-For dry-run, preview without writing:
-
-```sh
-node "$FORGE_ROOT/tools/validate-store.cjs" --fix --dry-run --json
-```
-
-Report each fix to the user (entity, field, what was backfilled or nullified).
-
-## Phase 3: LLM-Judgment Fixes
-
-For each remaining error from Phase 1 that was not auto-fixed, apply LLM judgment:
-
-1. **Read the corrupted record**:
-   ```sh
-   node "$FORGE_ROOT/tools/store-cli.cjs" read <entity> <id> --json
-   ```
-
-2. **Determine the correct value** based on schema definitions, store context, and
-   the judgment rules below.
-
-3. **Present the proposed fix** to the user with:
-   - Entity ID and field affected
-   - Current (corrupted) value
-   - Proposed (corrected) value
-   - Reasoning
-
-   If the user declines, skip the fix and note it in the report.
-
-4. **Apply the fix** using the appropriate command:
-
-   | Corruption Pattern | Repair Action | Command |
-   |-------------------|---------------|---------|
-   | Invalid enum value | Map to nearest valid enum | `store-cli.cjs update-status <entity> <id> <field> <value> [--force]` |
-   | Undeclared field | Remove the field by rewriting | `store-cli.cjs write <entity> '<fixed-json>'` |
-   | Type mismatch | Coerce to correct type and rewrite | `store-cli.cjs write <entity> '<fixed-json>'` |
-   | Orphaned FK | Nullify or remap to existing entity | `store-cli.cjs write <entity> '<fixed-json>'` |
-   | Dangling sprint.taskIds | Remove taskIds referencing non-existent tasks | `store-cli.cjs write sprint '<fixed-json>'` |
-   | Illegal status transition | Force-correct to valid state | `store-cli.cjs update-status <entity> <id> status <value> --force` |
-   | Stale COLLATION_STATE | Regenerate via collate | `node "$FORGE_ROOT/tools/collate.cjs"` |
-
-### Judgment Rules: Invalid Enum Values
-
-Map common misspellings and variant forms to canonical values:
-
-| Entity | Field | Common Misspellings | Canonical Values |
-|--------|-------|--------------------|------------------|
-| Sprint | status | "in-progress" | active |
-| Sprint | status | "done", "finished" | completed |
-| Task | status | "in-progress" | implementing |
-| Task | status | "in-review", "review" | review-approved |
-| Task | status | "done", "finished" | committed |
-| Bug | severity | "high", "critical" | critical |
-| Bug | severity | "medium" | major |
-| Bug | severity | "low" | minor |
-| Bug | status | "open" | reported |
-| Bug | status | "working" | in-progress |
-| Feature | status | "complete", "done" | shipped |
-
-When no reasonable mapping exists, ask the user to choose from valid values.
-
-### Judgment Rules: Orphaned References
-
-- **Event.taskId → deleted task**: If the event's sprintId is valid, nullify the
-  taskId. If the sprint also doesn't exist, ask the user whether to delete the
-  event or create a stub sprint.
-- **Sprint.taskIds containing deleted task IDs**: Remove the deleted IDs from the
-  array and rewrite the sprint.
-- **Undeclared fields**: Remove the field and rewrite. Mention the removed data in
-  the report so the user can decide whether to add it to the schema.
-
-### Hard Rules
-
-1. **Never fall back to direct file writes.** All repairs go through
-   `store-cli.cjs`. If it rejects a write, fix the data and retry (max 2).
-2. **Never delete data without confirmation.** Ask the user before deleting any
-   record.
-3. **Never skip Phase 4 verification.** Always re-run validate-store after
-   repairs.
-4. **Preserve data priority.** Prefer corrections that retain more original data.
-   Mapping "in-progress" → "implementing" is better than resetting to "draft".
-
-## Phase 4: Verification
-
-Re-run the validator to confirm the store is clean:
-
-```sh
-node "$FORGE_ROOT/tools/validate-store.cjs" --dry-run --json
-```
-
-If `"ok": true`, report success. If errors remain, report them as unresolved
-with suggestions for next steps.
-
-## Repair Report
-
-After all phases, output a structured report:
-
-```
-# Store Repair Report
-
-## Phase 1: Diagnosis
-- Errors found: N
-- Warnings found: M
-- Categories: {breakdown by category}
-
-## Phase 2: Auto-Fix
-- Fixes applied: N
-- Details: {list of each fix}
-
-## Phase 3: LLM-Judgment Fixes
-- Fixes proposed: N
-- Fixes applied: M (with user approval)
-- Fixes skipped: K (user declined)
-- Details: {list of each proposed change with reasoning}
-
-## Phase 4: Verification
-- Errors remaining: N
-- Warnings remaining: M
-- Status: PASS / FAIL
-
-## Unresolved Issues
-{List of issues that could not be automatically resolved, with suggestions}
-```
-
-## On Error
-
-If `validate-store.cjs` crashes or returns unexpected output, report the error
-and suggest running `/forge:report-bug` if it appears to be a Forge bug. Do NOT
-attempt to continue repairs after an unexpected error in a deterministic tool —
-the store state is unknown and further writes could cause additional corruption.
+× /forge:store-repair was renamed to /forge:repair in v1.0.

package/dist/forge-payload/commands/update-tools.md

@@ -1,56 +1,10 @@
 ---
 name: update-tools
-description: Use when you want to refresh .forge/schemas/ to match the currently installed Forge plugin version
+description: REMOVED in v1.0 — use /forge:update instead
 ---
 
-# /forge:update-tools
+# /forge:update-tools — Removed
 
-Refresh the JSON schemas in `.forge/schemas/` from the installed Forge plugin.
+× `/forge:update-tools` was removed in v1.0. Schema refresh now happens automatically as part of `/forge:update`.
 
-Forge tools (`collate.cjs`, `manage-config.cjs`, etc.) ship with the plugin and
-are invoked directly from `$FORGE_ROOT/tools/` — they are not copied to the project.
-This command only manages schemas.
-
-## Locate the plugin
-
-```
-FORGE_ROOT: !`echo "${CLAUDE_PLUGIN_ROOT}"`
-```
-
-## Steps
-
-### 1 — Copy schemas
-
-Copy all JSON Schema files from `$FORGE_ROOT/schemas/` to `.forge/schemas/`.
-Create `.forge/schemas/` if it does not exist.
-
-```sh
-mkdir -p .forge/schemas
-cp "$FORGE_ROOT/schemas/"*.schema.json .forge/schemas/
-```
-
-### 2 — Record hashes
-
-Record each copied schema file in the generation manifest so health checks
-can detect modifications:
-
-```sh
-for f in .forge/schemas/*.schema.json; do
-  node "$FORGE_ROOT/tools/generation-manifest.cjs" record "$f"
-done
-```
-
-### 3 — Verify
-
-```sh
-node "$FORGE_ROOT/tools/validate-store.cjs" --dry-run
-```
-
-Print `〇 Schemas updated and store validation passed.` on success.
-Print `× Validation failed — {output}` on non-zero exit.
-
-## 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."
+Run `/forge:update` to refresh schemas along with other project artifacts.

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

@@ -95,8 +95,7 @@ node "$FORGE_ROOT/tools/banners.cjs" --subtitle "Updating Forge — checking rem
 At the start of each step, emit a step header via `banners.cjs --phase`:
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase {N} 7 "{Step Name}" {bannerKey} \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase {N} 7 "{Step Name}" {bannerKey}
 ```
 
 Step ↔ banner key map:
@@ -130,7 +129,7 @@ If `updateStatus === "pending"`:
    △ Previous update is incomplete — pending migration(s): {pendingMigrations}
      Reason: {pendingReason}
 
-     Run /forge:migrate to complete the pending migration, then re-run
+     Run /forge:init --migrate to complete the pending migration, then re-run
      /forge:update to verify.
    ```
 
@@ -138,7 +137,7 @@ If `updateStatus === "pending"`:
    were completed in the previous run. The project already has the correct
    plugin version installed; only the migration chain remains.
 
-3. Exit. The user runs `/forge:migrate` to complete, then re-runs `/forge:update`.
+3. Exit. The user runs `/forge:init --migrate` to complete, then re-runs `/forge:update`.
 
 If `updateStatus !== "pending"` (or field absent): proceed normally with Step 1.
 
@@ -147,8 +146,7 @@ If `updateStatus !== "pending"` (or field absent): proceed normally with Step 1.
 ## Step 1 — Check for updates
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 1 7 "Check for updates" north \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 1 7 "Check for updates" north
 ```
 
 Read `$FORGE_ROOT/.claude-plugin/plugin.json`. Extract `"version"` → `LOCAL_VERSION`.
@@ -263,8 +261,7 @@ Now evaluate — **stop at the first matching row and follow only that row's act
 ## Step 2A — Plugin update available
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 2 7 "Plugin update available" rift \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 2 7 "Plugin update available" rift
 ```
 
 > **Only reached when `REMOTE_VERSION` != `LOCAL_VERSION` (row 4 above).**
@@ -320,7 +317,7 @@ Present the update summary:
 ```
 
 If no migration path can be constructed, show available notes and recommend
-`/forge:regenerate workflows`.
+`/forge:rebuild workflows`.
 
 Ask the user to choose. If they choose **[2]**, exit.
 
@@ -359,8 +356,7 @@ Wait for the user to confirm the install completed.
 ## Step 2B — Project migration pending (plugin already current)
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 2 7 "Apply project migrations" drift \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 2 7 "Apply project migrations" drift
 ```
 
 > **Only reached from rows 2 or 3 — the plugin is already at the right version.**
@@ -420,8 +416,7 @@ Then jump to **Step 4** to execute the regeneration.
 ## Step 3 — Verify installation
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 3 7 "Verify installation" lumen \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 3 7 "Verify installation" lumen
 ```
 
 After the user confirms the install:
@@ -461,8 +456,7 @@ path) — skip the re-derivation and keep the original value.
 ## Step 4 — Apply migrations
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 4 7 "Apply migrations" forge \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 4 7 "Apply migrations" forge
 ```
 
 > **Sequencing note:** `paths.forgeRoot` is written at the very start of Step 4,
@@ -507,6 +501,19 @@ If the project was recently initialized and all fields are already present, the
 command prints `〇 No missing fields to backfill.` and exits cleanly —
 no changes, no side effects.
 
+**Fix `paths.commands` prefix (v1.0.2+):** Pre-v1.0.2 projects may have
+`paths.commands` set to `.claude/commands/forge` regardless of the project
+prefix. Correct it to use the lowercased project prefix:
+
+```sh
+PREFIX=$(node -e "try{console.log(require('./.forge/config.json').project.prefix.toLowerCase())}catch{console.log('forge')}")
+CURRENT_COMMANDS=$(node "$FORGE_ROOT/tools/manage-config.cjs" get paths.commands 2>/dev/null || echo "")
+EXPECTED_COMMANDS=".claude/commands/$PREFIX"
+if [ "$CURRENT_COMMANDS" != "$EXPECTED_COMMANDS" ]; then
+  node "$FORGE_ROOT/tools/manage-config.cjs" set paths.commands "$EXPECTED_COMMANDS"
+fi
+```
+
 Determine the baseline version:
 - Use `migratedFrom` from `CACHE_FILE` (set in Step 1)
 - Or the `--from <version>` argument if provided
@@ -540,7 +547,7 @@ Walk the migration chain from baseline forward to `LOCAL_VERSION`:
 - Collect the ordered list of migration steps that bridge baseline → current.
 - If no path exists, warn:
   > No migration path found from {baseline} to {LOCAL_VERSION}. Running
-  > `/forge:regenerate workflows` is recommended.
+  > `/forge:rebuild workflows` is recommended.
   Then exit.
 
 Aggregate across all steps in the path, applying the dominance rule:
@@ -568,7 +575,7 @@ Execute regeneration targets in this order:
 | 4 | `personas` | — (independent) | — |
 | 5 | `commands` | Must run after `workflows` | — |
 | 6 | `knowledge-base` sub-targets | — (independent) | — |
-| 7 | `schemas` | — (independent) | **Delegate to `/forge:update-tools`.** Emit: `Delegating schemas regeneration to /forge:update-tools…` then read and follow `$FORGE_ROOT/commands/update-tools.md`. |
+| 7 | `schemas` | — (independent) | **Run schema refresh inline** (see Schema Refresh below). Emit: `〇 Refreshing schemas…` |
 
 > **Known special targets — note for migration authors:** `hooks` and `schemas` are
 > special-cased here. Future `migrations.json` entries should only use recognised
@@ -650,19 +657,37 @@ If the user declines, exit without modifying anything.
 If `breaking: true`, require the user to confirm they have completed the manual
 steps before proceeding.
 
-For each category in the aggregated result, invoke `/forge:regenerate` by
+For each category in the aggregated result, invoke `/forge:rebuild` by
 reading and following `$FORGE_ROOT/commands/regenerate.md`:
-- If flagged for full rebuild: invoke `/forge:regenerate <category>`
-- If sub-targets collected: invoke `/forge:regenerate <category> <sub-target>`
+- If flagged for full rebuild: invoke `/forge:rebuild <category>`
+- If sub-targets collected: invoke `/forge:rebuild <category> <sub-target>`
   for each sub-target in order
 
 **Category-to-command mapping:** most categories are handled by
-`/forge:regenerate`, but the `tools` category is special. When `tools`
-appears in the aggregated result, invoke `/forge:update-tools` instead of
-`/forge:regenerate tools`. The update-tools command copies JSON schemas from
-`$FORGE_ROOT/schemas/` to `.forge/schemas/` and validates the store. It does
-not use the regeneration framework — tools ship with the plugin and are invoked
-directly via `$FORGE_ROOT/tools/`.
+`/forge:rebuild`, but the `tools` and `schemas` categories are special.
+
+When `tools` appears in the aggregated result, run the schema refresh inline
+(see **Schema Refresh** section below) instead of invoking `/forge:rebuild tools`.
+Tools ship with the plugin and are invoked directly via `$FORGE_ROOT/tools/`.
+
+When `schemas` appears in the aggregated result, run the schema refresh inline
+(same **Schema Refresh** section). Do NOT delegate to the removed `/forge:update-tools` command.
+
+### Schema Refresh
+
+When the migration chain includes a `schemas` or `tools` target, refresh schemas inline:
+
+```sh
+mkdir -p .forge/schemas
+cp "$FORGE_ROOT/schemas/"*.schema.json .forge/schemas/
+for f in .forge/schemas/*.schema.json; do
+  node "$FORGE_ROOT/tools/generation-manifest.cjs" record "$f"
+done
+node "$FORGE_ROOT/tools/validate-store.cjs" --dry-run
+```
+
+Emit `〇 Schemas updated and store validation passed.` on success.
+Emit `× Validation failed — {output}` on non-zero exit from `validate-store.cjs`.
 
 Run non-knowledge-base targets first (workflows, templates, commands, tools),
 then knowledge-base sub-targets if present.
@@ -685,9 +710,9 @@ If exit 1 (gaps remain):
 > △ Structure check: N file(s) still missing after migration:
 >   (list missing files)
 >
-> This may indicate a failed regeneration step. Re-run `/forge:regenerate <namespace>`
-> for each affected namespace, or `/forge:regenerate` to rebuild all targets.
-> Note: skills entries require an explicit `/forge:regenerate skills` — they are not
+> This may indicate a failed regeneration step. Re-run `/forge:rebuild <namespace>`
+> for each affected namespace, or `/forge:rebuild` to rebuild all targets.
+> Note: skills entries require an explicit `/forge:rebuild skills` — they are not
 > included in the default regenerate run.
 
 Do NOT block migration success on gaps — surface them as a warning only. The user
@@ -699,7 +724,7 @@ is an additional safety net.
 After the structure check, if at least one regeneration target was applied (the
 aggregated `regenerate` list was non-empty), refresh `calibrationBaseline` in
 `.forge/config.json`. This keeps the calibration baseline in sync with the newly
-materialized artifacts so `/forge:calibrate` does not report false drift.
+materialized artifacts so `/forge:health --fix` does not report false drift.
 
 Skip this step if no regeneration targets were applied (e.g. all targets were absent
 from the migration path, or Step 4 was entered with `baseline == LOCAL_VERSION`).
@@ -798,7 +823,7 @@ ADR-S14-01 decision criteria to determine the update outcome:
 - No changes to `calibrationBaseline` semantics
 
 Concretely, a low-risk step is one where the only actions are: schema-only
-changes (`/forge:update-tools` for schemas), file-copy from base-pack
+changes (inline schema refresh for schemas), file-copy from base-pack
 (templates, workflows, personas), or config-key additions with deterministic
 defaults.
 
@@ -834,7 +859,7 @@ pass:
      only performs operations that can be completed without any user prompts.
    - **Deterministic file copies from base-pack:** if
      `structure-versions.json` already exists (post-T05 install), the
-     deterministic path is simply running any remaining `/forge:regenerate`
+     deterministic path is simply running any remaining `/forge:rebuild`
      targets that were not already applied in the main Step 4 regeneration
      sequence.
 
@@ -850,7 +875,7 @@ pass:
    - Write `updateStatus: "pending"`, `pendingReason: "Auto-invoke failed:
      {error description}"`, and `pendingMigrations: [list]` to
      `.forge/update-check-cache.json`.
-   - Print: "Update Pending — auto-invoke failed. Run `/forge:migrate` to
+   - Print: "Update Pending — auto-invoke failed. Run `/forge:init --migrate` to
      complete" with the failure details.
    - Exit without proceeding to Steps 5-7.
 
@@ -865,7 +890,7 @@ If any step is user-affecting (and the chain was NOT auto-invoked), enter the
 - Do NOT bump `calibrationBaseline.version`.
 - Write `updateStatus: "pending"`, `pendingReason`, and `pendingMigrations` to
   `.forge/update-check-cache.json`.
-- Print: "Update Pending — run `/forge:migrate` to complete" with the list of
+- Print: "Update Pending — run `/forge:init --migrate` to complete" with the list of
   pending migrations and next steps.
 - Exit without proceeding to Steps 5-7.
 
@@ -890,8 +915,7 @@ On the "Update Complete" path (all migrations applied,
 ## Step 5 — Pipeline and configuration audit
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 5 7 "Pipeline audit" oracle \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 5 7 "Pipeline audit" oracle
 ```
 
 Runs on every update. Collects all findings first, then presents a single
@@ -1007,7 +1031,7 @@ For each file containing legacy `model:` fields, add item:
 `type: legacy-model-field`, `required: false`,
 `path: .forge/workflows/{filename}`,
 `label: ".forge/workflows/{filename} — legacy model: field detected"`,
-`action: "Will be auto-migrated by /forge:regenerate workflows"`
+`action: "Will be auto-migrated by /forge:rebuild workflows"`
 
 **5b-rename — Retired command names in pipeline config.** Scan every configured
 pipeline for phases that use retired built-in command names.
@@ -1153,7 +1177,7 @@ and emit:
   [1] △ .claude/commands/supervisor.md — retired name, user edits detected.
          Merge into review-plan.md before deleting. Delete old file?
   [2] 〇 .forge/workflows/architect_sprint_plan.md — legacy model: field detected.
-         Will be auto-migrated by /forge:regenerate workflows. No action needed.
+         Will be auto-migrated by /forge:rebuild workflows. No action needed.
   [3] 〇 pipeline "main" phase 3 — no workflow field.
          Add: "workflow": "engineering/commands/qa.md"
   [4] 〇 pipeline "main" phase 4 — command file missing.
@@ -1287,8 +1311,7 @@ Proceed to **Step 6**.
 ## Step 6 — Record state and summarise
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 6 7 "Record state" drift \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 6 7 "Record state" drift
 ```
 
 > **Note:** `paths.forgeRoot` and `paths.forgeRef` were already written at the start
@@ -1347,29 +1370,12 @@ Print the final summary:
   Subagent isolation: {used | bypassed (inline)}
 ```
 
-**Fast-mode promotion hint.** After printing the summary, read
-`.forge/config.json` `mode`:
-
-```sh
-CURRENT_MODE=$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo "unset")
-```
-
-If `CURRENT_MODE == "fast"`, also emit:
-
-```
-〇 Migration applied in fast mode. Materialized artifacts refreshed; stubs will pick up changes on first use.
-〇 To fully promote: /forge:config mode full
-```
-
-This is informational only — no behavioural change. Do not block on it.
-
 ---
 
 ## Step 7 — Link KB to Agent Instruction Files
 
 ```sh
-node "$FORGE_ROOT/tools/banners.cjs" --phase 7 7 "Tomoshibi" lumen \
-  "$(node "$FORGE_ROOT/tools/manage-config.cjs" get mode 2>/dev/null || echo full)"
+node "$FORGE_ROOT/tools/banners.cjs" --phase 7 7 "Tomoshibi" lumen
 ```
 
 Invoke Tomoshibi to ensure every coding-agent instruction file in the project

package/dist/forge-payload/hooks/check-update.cjs

@@ -162,7 +162,7 @@ if (hasForge && projectCache && projectCache.updateStatus === 'pending') {
     : '(unknown)';
   pendingStateMsg =
     `Forge update is incomplete — pending migration(s): ${pendingMigrations}.` +
-    ` Run /forge:update to continue or /forge:migrate to complete.`;
+    ` Run /forge:update to continue or /forge:init --migrate to complete.`;
 }
 
 const elapsed = pluginCache ? now - (pluginCache.lastCheck || 0) : Infinity;

package/dist/forge-payload/hooks/post-init.cjs

@@ -4,7 +4,7 @@
 // Forge hook: post-init
 // PostToolUse hook that fires once at the END of a successful /forge:init
 // Phase 4 (NOT on Resume "start over" or stale-checkpoint cleanup) and
-// invokes /forge:enhance --phase 1 --auto.
+// invokes /forge:rebuild --enrich --phase 1 --auto.
 //
 // Trigger detection uses a positive end-of-flow signal: the hook matches
 // `rm -f .forge/init-progress.json` AND requires `.forge/structure-versions.json`
@@ -112,7 +112,7 @@ try {
     hookSpecificOutput: {
       hookEventName: 'PostToolUse',
       additionalContext:
-        'Forge: /forge:init has completed Phase 4. Run /forge:enhance --phase 1 --auto to materialise project-specific starter-pack content from the freshly captured structural snapshot.',
+        'Forge: /forge:init has completed Phase 4. Run /forge:rebuild --enrich --phase 1 --auto to materialise project-specific starter-pack content from the freshly captured structural snapshot.',
     },
   }) + '\n');
 } catch (outputErr) { logSwallowedError('post-init:output', outputErr, process.env.CLAUDE_PLUGIN_DATA); }

package/dist/forge-payload/hooks/post-sprint.cjs

@@ -4,7 +4,7 @@
 // Forge hook: post-sprint
 // PostToolUse hook that fires after a sprint retrospective completes
 // (`collate.cjs <SPRINT_ID> --purge-events` where the ID matches the
-// `*-S\d+` shape) and invokes /forge:enhance --phase 2.
+// `*-S\d+` shape) and invokes /forge:rebuild --enrich --phase 2.
 //
 // The sprint-ID shape gate ensures bug-fix invocations like
 // `collate.cjs FORGE-B07 --purge-events` (which run after every successful
@@ -100,7 +100,7 @@ try {
     hookSpecificOutput: {
       hookEventName: 'PostToolUse',
       additionalContext:
-        `Forge: sprint ${detectedSprintId} retrospective has completed. Run /forge:enhance --phase 2 to propose KB enhancements derived from the sprint's lessons (proposals are written for review, not auto-applied).`,
+        `Forge: sprint ${detectedSprintId} retrospective has completed. Run /forge:rebuild --enrich --phase 2 to propose KB enhancements derived from the sprint's lessons (proposals are written for review, not auto-applied).`,
     },
   }) + '\n');
 } catch (outputErr) { logSwallowedError('post-sprint:output', outputErr, process.env.CLAUDE_PLUGIN_DATA); }

package/dist/forge-payload/hooks/triage-error.cjs

@@ -24,7 +24,7 @@ const FORGE_PATTERNS = [
   /engineering\/tools\//,
   /forge:init/,
   /forge:health/,
-  /forge:regenerate/,
+  /forge:rebuild/,
   /forge:update/,
   /forge:add-pipeline/,
   /forge:add-task/,
@@ -33,21 +33,22 @@ const FORGE_PATTERNS = [
   /forge:approve/,
   /forge:commit/,
   /forge:review/,
-  /forge:sprint/,
+  /forge:new-sprint/,
+  /forge:plan-sprint/,
   /forge:run-task/,
   /forge:run-sprint/,
   /forge:fix-bug/,
-  /forge:retrospective/,
-  /forge:quiz-agent/,
+  /forge:retro/,
+  /forge:check-agent/,
   /forge:report-bug/,
-  /forge:enhance/,
-  /forge:collate/,
+  // forge:enhance removed in v1.0 (T03) — absorbed into forge:rebuild --enrich
+  // forge:collate removed from user-facing surface in v1.0 (T03) — internal tool only
   /forge:validate/,
-  /forge:calibrate/,
-  /forge:materialize/,
+  // forge:calibrate removed in v1.0 (T03) — absorbed into forge:health --fix (T04)
+  // forge:materialize removed in v1.0 (T03) — fast-mode eliminated in T01
   /forge:remove/,
-  /forge:store-query/,
-  /forge:store-repair/,
+  /forge:search/,
+  /forge:repair/,
   /forge:store-custodian/,
   /forge:config/,
   /forge:ask/,