@jamie-tam/forge 6.0.0 → 6.1.0

package/skills/{support-task-force → support-parallel}/references/dispatch-pattern.md

@@ -1,4 +1,4 @@
-# Task-Force Dispatch Pattern
+# Parallel Dispatch Pattern
 
 Operational recipes for spawning per-task Claude+Codex teams.
 
@@ -101,7 +101,7 @@ complex    → architect + tracer + builder + dispatch quality-code-review + spe
 ## Per-agent prompt template
 
 ```
-You are agent {role} in task-force task {n} of {N}, run-id {run-id}.
+You are agent {role} in parallel-run task {n} of {N}, run-id {run-id}.
 
 Task type: {dev|research|debug|docs|review|security|quick|complex}
 Phase mode: {prototype|production}
@@ -120,10 +120,10 @@ Your scope: {paths, subsystem, or "whole repo"}
 
 OUTPUT:
 - Result of doing the task (code diffs, findings, document, etc.)
-- One-line verdict for the task-force aggregator: PASS / CONCERNS / FAIL
-- Hand off any followups by writing them to .forge/task-force/{run-id}/task-{n}/followups.md
+- One-line verdict for the parallel-run aggregator: PASS / CONCERNS / FAIL
+- Hand off any followups by writing them to .forge/parallel/{run-id}/task-{n}/followups.md
 
-Cap your output at {N} words. Save artifacts under .forge/task-force/{run-id}/task-{n}/{role}.{ext}.
+Cap your output at {N} words. Save artifacts under .forge/parallel/{run-id}/task-{n}/{role}.{ext}.
 ```
 
 ## Batched dispatch ceiling
@@ -155,7 +155,7 @@ else:
 | Codex sandbox can't write | "operation blocked in sandbox" | Codex outputs uncommitted; Claude commits or main session commits |
 | Two agents touch same file | Edit tool conflict | Partition more aggressively |
 | Classifier picks command-shaped but rest heterogeneous | Some routed, some not | Surface routing decisions, continue with remainder |
-| User cancels mid-run | Receives interrupt | Mark in-flight tasks abandoned; preserve completed outputs |
+| User cancels mid-run | Receives interrupt | Stop in-flight tasks; preserve completed outputs |
 
 ## Sizing examples
 
@@ -172,7 +172,7 @@ else:
 
 ## Cleanup
 
-`.forge/task-force/{run-id}/` accumulates per-run. Prune via:
-- `/evolve` (include task-force cleanup as a step)
-- Manual: `find .forge/task-force -maxdepth 1 -mtime +30 -exec rm -rf {} +`
-- `support-dream` could consolidate task-force runs into aiwiki summary entries before prune
+`.forge/parallel/{run-id}/` accumulates per-run. Prune via:
+- `/forge-evolve` (include parallel-run cleanup as a step)
+- Manual: `find .forge/parallel -maxdepth 1 -mtime +30 -exec rm -rf {} +`
+- `support-dream` could consolidate parallel runs into aiwiki summary entries before prune

package/skills/{support-task-force → support-parallel}/references/synthesis-template.md

@@ -1,4 +1,4 @@
-# Task-Force Output Templates
+# Parallel Run Output Templates
 
 Use these for per-task verdicts (Step 7) and run summaries (Step 8).
 
@@ -31,20 +31,20 @@ Use these for per-task verdicts (Step 7) and run summaries (Step 8).
 
 ## Artifacts
 
-- `.forge/task-force/{run-id}/task-{n}/builder.md`
-- `.forge/task-force/{run-id}/task-{n}/code-reviewer-claude.md`
-- `.forge/task-force/{run-id}/task-{n}/code-reviewer-codex.md`
-- `.forge/task-force/{run-id}/task-{n}/followups.md` (if any)
+- `.forge/parallel/{run-id}/task-{n}/builder.md`
+- `.forge/parallel/{run-id}/task-{n}/code-reviewer-claude.md`
+- `.forge/parallel/{run-id}/task-{n}/code-reviewer-codex.md`
+- `.forge/parallel/{run-id}/task-{n}/followups.md` (if any)
 
 ## Followups (if any)
 
-- <item> — owner: <user | next task-force run | /evolve>
+- <item> — owner: <user | next parallel run | /forge-evolve>
 ```
 
 ## Run summary
 
 ```markdown
-# Task-Force Run {run-id}
+# Parallel Run {run-id}
 
 **Started:** {ISO-8601}
 **Completed:** {ISO-8601}
@@ -95,9 +95,9 @@ Use these for per-task verdicts (Step 7) and run summaries (Step 8).
 
 ## Next steps
 
-If divergence > 30%, sample-check a few task-force outputs — your classifier or team-assembly might be miscalibrated.
+If divergence > 30%, sample-check a few team outputs — your classifier or team-assembly might be miscalibrated.
 
-If all tasks PASSED with no divergence, run a `/evolve` to consider whether patterns recurred enough to warrant capturing as a gotcha or rule.
+If all tasks PASSED with no divergence, run a `/forge-evolve` to consider whether patterns recurred enough to warrant capturing as a gotcha or rule.
 ```
 
 ## Severity / verdict definitions
@@ -123,4 +123,4 @@ After run summary, if any task is `complete-divergent` AND the divergence is ove
 - Debug task with divergent verdicts → `support-debug` skill standalone
 - Research task with divergent verdicts → user adjudication required
 
-Task-force is for parallel speed. When agreement breaks down, the right tool is depth, not parallelism.
+`/parallel` is for parallel speed. When agreement breaks down, the right tool is depth, not parallelism.

package/skills/support-skill-validator/SKILL.md

@@ -16,7 +16,7 @@ As the forge harness grows -- skills added, rules promoted from gotchas, command
 | Trigger | Validation Scope | Performance Target |
 |---|---|---|
 | `/validate` command | Full scan (all 5 checks) | Under 30 seconds |
-| `/evolve` modifies a skill | Pre-apply check (modified skill vs all others) | Under 10 seconds |
+| `/forge-evolve` modifies a skill | Pre-apply check (modified skill vs all others) | Under 10 seconds |
 | Session start | Lightweight I/O graph check only | Under 3 seconds |
 | Manual request | Full scan or targeted check | Depends on scope |
 | After gotcha promotion | Promoted rule vs existing rules and skills | Under 10 seconds |
@@ -32,7 +32,7 @@ As the forge harness grows -- skills added, rules promoted from gotchas, command
 |---|---|
 | **Requires** | All `SKILL.md` files + all `rules/*.md` files + all `commands/*.md` files |
 | **Produces** | Validation report (structured, actionable) |
-| **Feeds into** | `/evolve` command (fix contradictions before applying changes) |
+| **Feeds into** | `/forge-evolve` command (fix contradictions before applying changes) |
 | **Updates** | Nothing directly -- produces a report for human/AI action |
 
 ### Input Files
@@ -127,9 +127,9 @@ No blocking errors. System is consistent.
 Warnings should be reviewed when convenient.
 ```
 
-### /evolve Command (Pre-Apply Check)
+### /forge-evolve Command (Pre-Apply Check)
 
-Before `/evolve` applies any skill modification:
+Before `/forge-evolve` applies any skill modification:
 
 1. Receive the proposed change
 2. Apply the change to a temporary copy
@@ -139,7 +139,7 @@ Before `/evolve` applies any skill modification:
 6. If clean: ALLOW the change
 
 ```
-/evolve proposes modifying build-tdd...
+/forge-evolve proposes modifying build-tdd...
 
 Pre-apply validation:
   [PASS] No directive conflicts

package/skills/support-skill-validator/references/validation-checks.md

@@ -267,7 +267,7 @@ Only escalate to WARNING/ERROR when you can name the downstream skill that fails
    ```
    DRIFT:
 
-   [ERROR] D-001: New Contradiction After /evolve
+   [ERROR] D-001: New Contradiction After /forge-evolve
      Modified: support-debug (added "ALWAYS verify with context7 before debugging")
      Conflicts with: rules/common/verification.md ("verify when UNCERTAIN, not always")
      Analysis: New directive is stricter than existing rule.

package/skills/support-system-guide/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: support-system-guide
-description: "Use when the user opens a fresh session, asks 'what should I run', 'where do I start', 'which command for X', 'is this a /feature or /greenfield', or describes intent without naming a command. Routes them to the right command (/feature, /greenfield, /task-force, /harden, etc.) and explains the phase model. Skip if the user has already invoked a specific command."
+description: "Use when the user opens a fresh session, asks 'what should I run', 'where do I start', 'which command for X', 'is this a /feature or /greenfield', or describes intent without naming a command. Routes them to the right command (/feature, /greenfield, /parallel, /harden, etc.) and explains the phase model. Skip if the user has already invoked a specific command."
 ---
 
 <EXTREMELY-IMPORTANT>
@@ -71,13 +71,14 @@ When the user describes what they want to do, route them to the correct command.
 
 | User Intent | Command | What It Does |
 |---|---|---|
-| "What does this project have?" / "Show me forge" / "What can I run?" | `/forge` | One-screen discovery — installed capabilities, active work, suggested next |
+| "What does this project have?" / "Show me forge" / "What can I run?" | `/discover` | One-screen discovery — installed capabilities, active work, suggested next |
+| "Capture this thought" / "Note this for later" / "Save this research" | `/note <text>` | Append to `aiwiki/raw/{date}.md` — for Phase 1-2 research, ad-hoc brainstorm, anything not yet a typed page |
 | "Add a feature" / "Implement X" / "Build Y" | `/feature` | Full lifecycle: discover -> plan -> build -> quality -> deliver |
 | "New project" / "Start from scratch" / "Greenfield" | `/greenfield` | Scaffold + full lifecycle for a new project |
 | "Fix this bug" / "Something is broken" / "Error when..." | `/bugfix` | Debug -> fix -> test -> PR |
 | "Clean up" / "Refactor" / "Improve code quality" | `/refactor` | Analyze -> refactor -> review -> PR |
 | "Production is down" / "Emergency fix" / "Critical bug" | `/hotfix` | Emergency: debug -> fix -> test -> deploy (expedited gates) |
-| "Improve the skills" / "Update a skill" / "System enhancement" | `/evolve` | Self-improvement: review skills, propose changes, validate |
+| "Improve the skills" / "Update a skill" / "System enhancement" | `/forge-evolve` | Self-improvement: review skills, propose changes, validate |
 | "Check consistency" / "Validate skills" / "Run validator" | `/validate` | Validate all skills/rules for contradictions and gaps |
 
 ### Command vs. Direct Skill Use

package/skills/support-wiki-lint/scripts/lint.mjs

@@ -23,8 +23,23 @@ const FRONTMATTER_RE = /^---\n([\s\S]*?)\n---\n([\s\S]*)$/;
 const CITATION_HASHED_RE = /([\w./@~-]+\.\w+):(\d+)@([0-9a-f]{7})\b/g;
 const CITATION_BARE_RE = /([\w./@~-]+\.\w+):(\d+)(?!@?[0-9a-f]{7})\b/g;
 const ACK_STALE_RE = /\/\/\s*ack-stale\s*:|#\s*ack-stale\s*:/;
+const ACK_SECRET_RE = /\back-secret\s*:/;
 const SECTION_RE = /^##\s+(.+?)\s*$/gm;
 
+// Possible-secret patterns. Advisory only — emitted as warnings, not errors.
+// Lint hook is non-blocking (`hooks/scripts/wiki-lint.sh` returns continue:true
+// unconditionally), so these never block a write — they surface on stderr so
+// the next edit can address them. False positives are downgraded to info if
+// the same line carries an `ack-secret: <reason>` annotation.
+const SECRET_PATTERNS = [
+  { name: 'aws_access_key', re: /AKIA[0-9A-Z]{16}/g },
+  { name: 'private_key_block', re: /-----BEGIN (?:[A-Z ]+ )?PRIVATE KEY-----/g },
+  { name: 'password_assignment', re: /\b(?:password|passwd|pwd)\s*[=:]\s*['"][^'"\s$][^'"\s]{3,}['"]/gi },
+  { name: 'api_key_assignment', re: /\b(?:api[_-]?key|apikey|secret[_-]?key|access[_-]?token|bearer[_-]?token)\s*[=:]\s*['"][^'"\s$][^'"\s]{7,}['"]/gi },
+  { name: 'jwt_token', re: /\beyJ[A-Za-z0-9_-]{10,}\.eyJ[A-Za-z0-9_-]{10,}\.[A-Za-z0-9_-]{10,}\b/g },
+  { name: 'url_credentials', re: /\b[a-z][a-z0-9+.-]*:\/\/[^\s/:@]+:[^\s/@]+@/gi },
+];
+
 // ---- Minimal YAML parser ---------------------------------------------------
 // Handles only what our schema + frontmatter files use:
 //   - Top-level mapping
@@ -389,6 +404,43 @@ export function lint({ file, schemasDir, root }) {
     fs.writeFileSync(absFile, newContent, 'utf8');
   }
 
+  // Secrets scan — advisory only, never an error. The wiki-lint hook is
+  // non-blocking; these warnings surface on stderr so the next edit can
+  // address them. Scan the FINAL post-backfill content (after citation hash
+  // updates). Skip lines annotated with `ack-secret: <reason>`.
+  const finalContent = updates.length > 0
+    ? `---\n${modifiedFm}\n---\n${modifiedBody}`
+    : original;
+  const finalLines = finalContent.split('\n');
+  const finalLineOffsets = computeLineOffsets(finalContent);
+  for (const { name, re } of SECRET_PATTERNS) {
+    re.lastIndex = 0;
+    let m;
+    while ((m = re.exec(finalContent)) !== null) {
+      const matchOffset = m.index;
+      // Find the line number (1-based).
+      let lineNum = 1;
+      for (let i = 0; i < finalLineOffsets.length; i++) {
+        if (finalLineOffsets[i] > matchOffset) break;
+        lineNum = i + 1;
+      }
+      const lineText = finalLines[lineNum - 1] || '';
+      const ackedOnSameLine = ACK_SECRET_RE.test(lineText);
+      const finding = {
+        kind: 'possible_secret',
+        type: name,
+        line: lineNum,
+        preview: m[0].slice(0, 40),
+        message: `Possible ${name} on line ${lineNum} (preview: ${m[0].slice(0, 40)}). If this is an intentional example or test fixture, add an \`ack-secret: <reason>\` annotation on the same line to downgrade to info.`,
+      };
+      if (ackedOnSameLine) {
+        warnings.push({ ...finding, kind: 'possible_secret_acked' });
+      } else {
+        warnings.push(finding);
+      }
+    }
+  }
+
   return {
     ok: errors.length === 0,
     file,

package/templates/README.md

@@ -12,7 +12,7 @@ Installed into the target project by `npx @jamie-tam/forge init` (or kept in-syn
 
 ## Legacy
 
-Kept on-disk so older manifests still parse and so `/evolve` can migrate them forward. Not installed into new projects.
+Kept on-disk so older manifests still parse and so `/forge-evolve` can migrate them forward. Not installed into new projects.
 
 - **`manifests/v5/`** — v5 schema (`SCHEMA.md` plus a `feature.yaml` reference). v5 manifests still parse against the v6 reader (see `manifests/v6/SCHEMA.md` §4). v4 manifests also still parse but no template is retained — the reader synthesizes the missing fields.
 

package/templates/aiwiki/schemas/session.md

@@ -21,7 +21,7 @@ required_sections:
   - "## Next steps"
 section_order: strict
 citation_rule: required-in-files-touched
-maintained_by: hooks-and-dream
+maintained_by: manual-or-harden
 ---
 
 # Schema: session (per-session handoff)
@@ -32,16 +32,17 @@ A session file is an **index of links** for one work session — what files were
 
 **Index of links, not distilled summary.** No prose paragraphs. No narrative. No screenshots-from-the-moment. Future sessions follow the links to actual artifacts (ADRs, gotchas, raw notes); the session file is just the routing layer.
 
-## How it's maintained (NOT by hand)
+## How it's maintained
 
-This page type is unusual: it's maintained by **hooks and dream**, not by humans typing.
+**Current state (2026-05-15):** session files are maintained manually or by the `harden` skill at Phase 5 (codify). The original design called for hook-driven maintenance, but the session-checkpoint hook layer (SessionStart creating the file, PostToolUse appending events, SessionEnd marking done) is **deferred** — not yet shipped.
 
-- `SessionStart` hook creates the file from this schema's skeleton (frontmatter + empty sections)
-- `PostToolUse` hooks append event lines to the appropriate sections (commit / gotcha / decision / raw)
-- `PreCompact` dream consolidates the event log into the schema sections (deduplicates, summarises bullet sequences, prunes noise)
-- `SessionEnd` (manual `/handoff` or detected) marks `status: done`
+Until the hooks ship, write session files by either:
+- **Manually**, when a session produced durable handoff signal worth persisting. The AI should OFFER to write a session file before ending a long session; the user accepts or declines.
+- **Via `harden`** at codify (Phase 5), which writes one session entry summarising the prototype-to-production work.
 
-Do NOT manually edit a session file unless correcting a hook misfire. Manual edits should be rare.
+Once the session-checkpoint hooks ship, this section will be updated to reflect the auto-maintenance contract: SessionStart creates the file from this schema's skeleton, PostToolUse hooks append event lines under the appropriate sections, PreCompact dream consolidates the event log, and `SessionEnd` marks `status: done`. Dependents (`support-dream`, `dreamer`) already include a graceful fallback: if `aiwiki/sessions/{current}.md` does not exist, session-file refinement is skipped (no `SESSION_FILE_MISSING` failure).
+
+Do NOT speculate-write a session file in the meantime. Empty `## Decisions made` / `## Gotchas surfaced` / `## Open questions` sections are signal-free noise.
 
 ## File location and naming
 
@@ -67,13 +68,13 @@ The companion file `aiwiki/sessions/INDEX.md` is a sortable table of all session
 
 ## Required sections
 
-| Section | Purpose | Maintained by |
+| Section | Purpose | Maintained by (current) |
 |---|---|---|
-| `## Files touched` | Bullet list of files modified, with citations | PostToolUse hooks (append-only) |
-| `## Decisions made` | Links to ADRs in `aiwiki/decisions/` written this session | PostToolUse hook on `aiwiki/decisions/` write |
-| `## Gotchas surfaced` | Links to gotchas captured this session | PostToolUse hook on `aiwiki/gotchas/` write |
-| `## Open questions` | Links to raw context in `aiwiki/raw/` for unresolved items | PostToolUse hook on `aiwiki/raw/` write |
-| `## Next steps` | What the next session should do | Dream at PreCompact / SessionEnd |
+| `## Files touched` | Bullet list of files modified, with citations | manual or `harden` — will be auto-appended once PostToolUse session-checkpoint hook ships |
+| `## Decisions made` | Links to ADRs in `aiwiki/decisions/` written this session | manual or `harden` — same |
+| `## Gotchas surfaced` | Links to gotchas captured this session | manual or `harden` — same |
+| `## Open questions` | Links to raw context in `aiwiki/raw/` for unresolved items | manual or `harden` — same |
+| `## Next steps` | What the next session should do | manual; dream will refine once session-checkpoint hooks ship |
 
 ## Line caps
 

package/templates/manifests/bugfix.yaml

@@ -11,7 +11,7 @@ schema_version: "6"
 name: {name}
 type: bugfix
 description: "{description}"
-status: in-progress  # in-progress | paused | completed | escalated | abandoned
+status: in-progress  # in-progress | paused | completed | escalated
 created: "{date}"
 command: bugfix
 escalated_from: null

package/templates/manifests/feature.yaml

@@ -18,7 +18,7 @@ schema_version: "6"
 name: {name}
 type: feature
 description: "{description}"
-status: in-progress  # in-progress | paused | completed | escalated | abandoned
+status: in-progress  # in-progress | paused | completed | escalated
 created: "{date}"
 command: feature
 complexity: standard  # trivial | standard | major

package/templates/manifests/greenfield.yaml

@@ -12,7 +12,7 @@ schema_version: "6"
 name: {name}
 type: greenfield
 description: "{description}"
-status: in-progress  # in-progress | paused | completed | escalated | abandoned
+status: in-progress  # in-progress | paused | completed | escalated
 created: "{date}"
 command: greenfield
 complexity: standard  # trivial | standard | major

package/templates/manifests/hotfix.yaml

@@ -11,7 +11,7 @@ schema_version: "6"
 name: {name}
 type: hotfix
 description: "{description}"
-status: in-progress  # in-progress | paused | completed | escalated | abandoned
+status: in-progress  # in-progress | paused | completed | escalated
 created: "{date}"
 command: hotfix
 escalated_from: null

package/templates/manifests/refactor.yaml

@@ -7,7 +7,7 @@ schema_version: "6"
 name: {name}
 type: refactor
 description: "{description}"
-status: in-progress  # in-progress | paused | completed | escalated | abandoned
+status: in-progress  # in-progress | paused | completed | escalated
 created: "{date}"
 command: refactor
 coverage-baseline: null  # recorded in Step 0

package/templates/manifests/v5/SCHEMA.md

@@ -16,7 +16,7 @@ Required:
 | `name` | string | kebab-case identifier; matches `.forge/work/{type}/{name}/` |
 | `type` | enum | `feature` \| `bugfix` \| `hotfix` \| `refactor` \| `greenfield` |
 | `description` | string | one-line human description |
-| `status` | enum | `in-progress` \| `paused` \| `completed` \| `escalated` \| `abandoned` |
+| `status` | enum | `in-progress` \| `paused` \| `completed` \| `escalated` |
 | `created` | ISO-8601 date | |
 | `command` | string | which slash command produced the manifest |
 | `phases` | object | pre-build (discover, plan) and post-build (quality, deliver, support) gates |
@@ -64,7 +64,7 @@ slice_graph:
       type: skeleton | feature-slice | refactor-slice
       variant: <string>          # only for type: skeleton; identifies stack
       depends_on: [<slice-id>...]
-      status: pending | in-progress | gated | complete | abandoned
+      status: pending | in-progress | gated | complete
       gates:
         <gate-name>: { status: <enum>, gate-passed: <bool> }
 ```
@@ -127,25 +127,23 @@ Lifecycle path (recommended; skills are written to follow this):
 
 ```
 pending → in-progress → gated → complete
-                       ↘ abandoned
 gated → in-progress       (gate failed; rework)
 ```
 
-`complete` and `abandoned` are conventionally terminal. If a downstream
-change invalidates a completed slice's work, the convention is to add a
-NEW slice that supersedes the old (preserving the audit trail) rather
-than mutate the completed slice's status. Skills enforce this in their
+`complete` is the conventional terminal state. If a downstream change
+invalidates a completed slice's work, the convention is to add a NEW
+slice that supersedes the old (preserving the audit trail) rather than
+mutate the completed slice's status. Skills enforce this in their
 prompts; the verifier does not.
 
 A slice should enter `in-progress` only when every slice in its
-`depends_on` is in `complete` status. `abandoned` does not satisfy a
-dependency — descendants of an abandoned slice block. Skills check this
-before advancing.
+`depends_on` is in `complete` status. Skills check this before
+advancing.
 
 ### 3.6 Fan-out / fan-in completion (planning convention)
 
 The slice graph is **terminally settled** when every slice is in
-`complete` or `abandoned` status. Skills running the post-build
+`complete` status. Skills running the post-build
 `phases.quality.code-review-final` gate check this convention before
 proceeding.
 
@@ -153,8 +151,7 @@ Fan-out: a slice with multiple non-dependent successors creates parallel
 branches. Each branch advances independently when its own gates pass.
 
 Fan-in: a slice with multiple `depends_on` entries waits for ALL of them
-to reach `complete` before entering `in-progress`. An `abandoned`
-dependency does NOT satisfy fan-in.
+to reach `complete` before entering `in-progress`.
 
 `current_slice` is a single global pointer in v5.0; multi-active-slice
 (per-worker pointer for parallel terminal tabs) is deferred to v6.0
@@ -223,7 +220,7 @@ type ErrorCode =
   | 'E_GATE_COLLISION' | 'E_BAD_SLICE_ID' | 'E_BAD_CURRENT_SLICE'
   | 'E_MISSING_REQUIRED_FIELD' | 'E_BAD_ENUM_VALUE'
   | 'E_PHASE_GATE_PREMATURE'   // §3.6: phases.quality.code-review-final.gate-passed = true
-                                //       while any slice is not in terminal state (complete/abandoned)
+                                //       while any slice is not in terminal state (complete)
   | 'E_YAML_PARSE' | 'E_FILE_NOT_FOUND';
 ```
 
@@ -292,7 +289,7 @@ duplicated into the synthesized slice). They run at v4-style "post-build"
 time — after `legacy-build` slice completes.
 
 The migration is a **read-time synthesis**, not an on-disk rewrite. v4
-manifests on disk stay v4-shaped until `/evolve` runs, which writes a
+manifests on disk stay v4-shaped until `/forge-evolve` runs, which writes a
 true v5 `slice_graph` block.
 
 ### 6.1 Migration semantic limitation (acknowledged)
@@ -307,11 +304,11 @@ followed.
 Consequence: a v4-migrated manifest read by v5 tooling will show
 `build-tdd: passed` even if no TDD occurred. This is acceptable because
 (a) the v4 work has already shipped — re-litigating the gate would
-block all in-flight v4 features, and (b) `/evolve` prompts the user to
+block all in-flight v4 features, and (b) `/forge-evolve` prompts the user to
 review the synthesis and rewrite the slice graph if they want true
 v5 gate semantics for ongoing work.
 
-`/evolve` shows the synthesized slice graph alongside the v4 task list
+`/forge-evolve` shows the synthesized slice graph alongside the v4 task list
 and asks: "Accept this synthesis (treat as legacy build), or rewrite as
 v5 slice graph (re-run gates per slice)?". The default is "accept".
 

package/templates/manifests/v5/feature.yaml

@@ -58,7 +58,7 @@ slice_graph:
       type: skeleton          # skeleton | feature-slice | refactor-slice
       variant: {skeleton_variant}   # backend-server | frontend-spa | cli-tool | library | mobile-app — set during stack selection
       depends_on: []
-      status: pending         # pending | in-progress | gated | complete | abandoned
+      status: pending         # pending | in-progress | gated | complete
       gates:
         skeleton-runs:    { status: pending, gate-passed: false }
         wiki-lint:        { status: pending, gate-passed: false }

package/templates/manifests/v6/SCHEMA.md

@@ -27,7 +27,6 @@ The two blocks are complementary, not redundant. A phase with `phase_plan.X: act
 | `phase_plan` | (absent) | **required** at top level |
 | `phases` | required | required (unchanged — still tracks gate state per phase/sub-phase) |
 | `slice_graph` | required by parser | optional (the v5 SCHEMA already documented this as optional; v6 aligns the parser) |
-| `status` enum | `in-progress` \| `paused` \| `completed` \| `escalated` | adds `abandoned` (terminal state recorded by `/abort`; preserves artifacts) |
 | Everything else | — | unchanged |
 
 The `slice_graph` change is a parser fix: v5's SCHEMA §1 listed `slice_graph` as optional but the verifier rejected its absence. v6 manifests can ship without a slice graph — it is populated at codify, not at preflight. v4 and v5 manifests continue to require it (v4 synthesizes one; v5 always shipped one in practice).
@@ -75,17 +74,17 @@ phase_plan:
 
 The verifier rejects any other value with `E_BAD_PHASE_PLAN_STATUS`.
 
-### 3.2 Key naming convention
+### 3.2 Key naming — strict enum per work type
 
-Keys are free-form strings — the verifier does NOT validate them against any canonical vocabulary. This is intentional: `/bugfix`, `/hotfix`, `/refactor` workflows have different shapes than `/feature` or `/greenfield`, and each command enumerates its own plannable steps.
+Keys are validated against a per-work-type allow-list. An unknown key produces `E_UNKNOWN_PHASE_PLAN_KEY` with a "did you mean?" suggestion when a near-match exists.
 
-**This means typos in keys are silent failures.** A misspelled `prototpe` produces no parse error but breaks any downstream routing that reads `phase_plan.prototype` — including the mode-detection signals in `rules/common/skill-selection.md` and command preflight redirects. Treat phase_plan keys as load-bearing identifiers: copy them from the templates exactly, do not invent variants.
+This was a convention through early v6 — the verifier accepted any string and a `W_UNKNOWN_PHASE_PLAN_KEY` warning surfaced typos. Dogfood signal (a misspelled `prototpe` parsed fine but broke `rules/common/skill-selection.md`'s mode-detection read of `phase_plan.prototype`) drove the 2026-05-17 promotion to a hard error.
 
-#### Recommended keys per work type
+#### Allowed keys per work type
 
-Commands should use these keys (kebab-case, match the templates verbatim):
+Commands MUST use these keys (kebab-case, match the templates verbatim). The list in `src/work-manifest.ts` (`ALLOWED_PHASE_PLAN_KEYS`) is the source of truth — this table must stay in sync.
 
-| Work type | Recommended `phase_plan` keys |
+| Work type | Allowed `phase_plan` keys |
 |---|---|
 | `feature` | `discover-codebase`, `concept`, `wireframe`, `plan-design-system`, `prototype`, `iterate`, `codify`, `worktree`, `production-build`, `test-plan`, `uiux-review`, `code-review-final`, `deliver`, `onboarding`, `gotchas` |
 | `greenfield` | `discover-requirements`, `concept`, `wireframe`, `plan-design-system`, `prototype`, `iterate`, `codify`, `scaffold`, `production-build`, `test-plan`, `uiux-review`, `code-review-final`, `deliver`, `onboarding`, `gotchas` |
@@ -93,11 +92,16 @@ Commands should use these keys (kebab-case, match the templates verbatim):
 | `hotfix` | `debug-root-cause`, `production-build`, `smoke-tests`, `code-review-critical`, `deliver`, `gotchas`, `followup-ticket` |
 | `refactor` | `discover-codebase`, `brainstorm`, `task-decompose`, `production-build`, `test-execution`, `assessment`, `deliver`, `gotchas` |
 
-`plan-design-system` is a workflow-specific gate that runs at Step 4.5 of `/feature` and `/greenfield` (post-wireframe-lock, pre-prototype). It is not in `references/common/phases.md` because it is a step within Phase 3-4 rather than its own canonical phase. Backend-only / CLI work skips it (`status: skipped` with a reason); frontend work uses `status: active`.
+`plan-design-system` is a workflow-specific gate that runs at Step 4.5 of `/feature` and `/greenfield` (post-wireframe-lock, pre-prototype). It is not in `references/common/phases.md` because it is a step within Phases 2-3 rather than its own canonical phase. Backend-only / CLI work skips it (`status: skipped` with a reason); frontend work uses `status: active`.
 
 The seven canonical phase names from `references/common/phases.md` (`concept`, `wireframe`, `prototype`, `iterate`, `codify`, `production-build`, `deliver`) MUST match the canonical spelling when used. Other keys are workflow-specific gates or sub-phases.
 
-If real usage shows typos causing failures, harden this from convention to per-type enum validation — the parser knows `manifest.type`, so a per-type allowed-keys map is a single Set lookup.
+#### Adding a new key
+
+To extend a workflow with a new phase_plan key:
+1. Add it to the appropriate `ManifestType` entry in `ALLOWED_PHASE_PLAN_KEYS` (`src/work-manifest.ts`).
+2. Add it to the table above.
+3. Update the relevant command's preflight planner so it emits the new key.
 
 ### 3.3 gate-passed discipline
 
@@ -113,7 +117,7 @@ This convention is enforced by skills (they read phase_plan and choose not to se
 
 A v5 manifest read by the v6 parser is accepted as-is. The parser returns `schema: 'v5'` and the synthesized in-memory manifest has `phase_plan: undefined`. Tools that need a phase_plan can synthesize a default: every phase in `phases.{block}.{gate}` becomes `phase_plan.{gate}: active`.
 
-`/evolve` (when it lands) will offer to rewrite v5 manifests on-disk into v6 shape, prompting for plan-status per phase. v5 manifests parse forever; no forced migration.
+`/forge-evolve` (when it lands) will offer to rewrite v5 manifests on-disk into v6 shape, prompting for plan-status per phase. v5 manifests parse forever; no forced migration.
 
 ---
 

package/commands/abort.md

@@ -1,25 +0,0 @@
----
-name: abort
-description: "Mark a .forge/work item abandoned without deleting files."
-argument-hint: "[type/name] [reason]"
----
-
-# /abort — Abandon Work Item
-
-Mark a work item abandoned while preserving every artifact for audit and future reference.
-
-## Scope
-
-Marks a `.forge/work/` item `status: abandoned` in its manifest. Preserves every artifact — work directory, branches, logs, prototypes, wiki entries — so the abandonment is auditable. Does NOT delete files, close branches, prune the wiki, or reset gate state. Invoke when work is being walked away from (replaced by a different approach, blocked indefinitely, or pivoted) and the user wants the trail kept for future reference.
-
-## Input
-
-Accept `type/name` and an optional reason. If no work item is provided, run `/status` first and ask the user which item to abandon.
-
-## Steps
-
-1. Read `.forge/work/{type}/{name}/manifest.yaml`.
-2. Confirm with the user before changing status.
-3. Set `status: abandoned`, `abandoned_at: <ISO-8601 UTC timestamp>` (executing agent fills this — e.g. `2026-05-12T15:42:00Z`; not a literal placeholder), and `abandon_reason: {reason}` in the manifest. Preserve all existing phase, gate, and artifact fields.
-4. Do not delete the work directory, branches, logs, prototypes, wiki entries, or any generated artifacts.
-5. Report the manifest path and the reason recorded.