@jamie-tam/forge 6.0.0 → 6.2.0

package/skills/quality-test-execution/SKILL.md

@@ -63,6 +63,31 @@ Now that the test plan is parsed and files are verified, run the Codex consent f
 - **Takeover:** Dispatch Codex with the test plan to execute tests and produce the results report. Claude reviews test quality and coverage.
 - **Verify** or **Skip / Codex unavailable:** Proceed with the steps below. The Codex Verify note in Step 9 will dispatch Codex to review test quality (Verify only).
 
+### Step 1.6: Oracle Coverage Check
+
+Before any test runs, verify that every oracle in `aiwiki/oracles/` for this work item is mapped to a test in the plan. Oracles are the Phase 5 (harden) contract — production code must reproduce the prototype's verified behavior. This is the load-bearing closure of the mock-pass / real-break wiring gap; running tests without checking oracle coverage re-creates the gap.
+
+1. Enumerate `aiwiki/oracles/*.md`. Filter to oracles whose `prototype_path` is within this work item's scope (typically `pocs/{name}-prototype/`).
+2. For each in-scope oracle, find the matching test ID(s) in the test plan's "Map Oracles to Tests" table (produced by `quality-test-plan` Step 2.3).
+3. **If any in-scope oracle is unmapped, halt:**
+
+```
+ORACLE COVERAGE FAILURE:
+Unmapped oracle: aiwiki/oracles/auth-login-success.md
+  Type: interaction
+  prototype_path: pocs/myapp-prototype/src/auth/Login.tsx
+  No test in test-plan.md cites this oracle.
+
+Cannot execute the test plan. Mock-heavy tests pass while real integration
+breaks (the wiring gap) — the chain closes only when every oracle has a
+test. Resolve by:
+  (a) Returning to quality-test-plan and adding a test that satisfies the
+      oracle, OR
+  (b) Re-running harden if the oracle is stale or out of scope.
+```
+
+4. **Skip condition:** If no oracles exist for this work item (the test plan recorded "No oracles in scope" in Step 2.3, or `aiwiki/oracles/` is empty for the scope), record "No oracles in scope" in the results and proceed. The check is non-blocking when oracle capture wasn't part of the lifecycle.
+
 ### Step 2: External Service Availability Check
 
 Before executing any tests, determine which external services are available for real testing.
@@ -393,7 +418,7 @@ Do not execute only unit tests and declare success. All test types from the plan
 
 | Field | Value |
 |---|---|
-| **Requires** | Test plan (`.forge/work/{type}/{name}/test-plan.md`) + implementation code (from `build-tdd`) + architecture artifacts (`.forge/work/{type}/{name}/architecture/api-contract.md` for external service verification) |
+| **Requires** | Test plan (`.forge/work/{type}/{name}/test-plan.md`) + implementation code (from `build-tdd`) + architecture artifacts (`.forge/work/{type}/{name}/architecture/api-contract.md` for external service verification) + oracle pages (`aiwiki/oracles/*.md` from harden Step 2.5) when codify ran |
 | **Produces** | `.forge/work/{type}/{name}/test-results.md` |
 | **Feeds into** | `deliver-deploy` (via quality gate -- zero failures required) |
 | **Updates manifest** | `artifacts.test-results: test-results.md`, `phases.quality.test-execution: { status: complete, gate-passed: true }` |

package/skills/quality-test-plan/SKILL.md

@@ -96,6 +96,26 @@ Create a traceability matrix:
 
 **Rule:** Every acceptance criterion MUST have at least one test. If a criterion has no test, the plan is incomplete.
 
+### Step 2.3: Map Oracles to Tests
+
+If `aiwiki/oracles/` contains oracle pages for slices in this work item, every in-scope oracle MUST appear in the traceability matrix with at least one mapped test. Oracles are the prototype-derived behavioral contract from Phase 5 (harden); production code is not "tested" if oracles are unverified. This is the load-bearing closure of the mock-pass / real-break wiring gap (Flux/REACH dogfood signal).
+
+For each `aiwiki/oracles/{slug}.md` whose `prototype_path` is within this work item's scope (typically `pocs/{name}-prototype/`):
+
+```markdown
+| Oracle | Type | Setup → Trigger → Assertions cite | Mapped tests |
+|---|---|---|---|
+| `auth-login-success` | interaction | `pocs/myapp-prototype/src/auth/Login.tsx:42` | IT-003, E2E-001 |
+| `dashboard-renders-empty-state` | render | `pocs/myapp-prototype/src/Dashboard.tsx:18` | IT-005 |
+| `checkout-applies-discount-code` | golden-trace | `pocs/myapp-prototype/src/checkout/apply.ts:67` | IT-012, CONTRACT-004 |
+```
+
+**Rule:** Every in-scope oracle MUST have at least one test that exercises its `Setup → Trigger → Assertions`. Unmapped oracles fail this step — either add tests to cover them, or surface to the user that harden's oracle capture missed a slice.
+
+The mapped test SHOULD be an integration or E2E test (oracles describe boundary behavior; unit tests with mocks at the boundary don't satisfy them). A pure-unit test mapping is acceptable only when the oracle is itself a unit-level invariant (rare).
+
+**Skip condition:** If `phase_plan.codify: skipped` for this work item or `aiwiki/oracles/` is empty for the work scope, record "No oracles in scope" in the plan and proceed. The check is non-blocking when oracle capture wasn't part of the lifecycle (e.g. trivial bugfix routed past harden).
+
 ### Step 2.5: Map User Journeys to E2E Scenarios
 
 If the requirements document includes a User Journeys section, create a business flow traceability table. Every journey MUST map to an E2E test scenario. Gaps are flagged before test execution.
@@ -237,7 +257,7 @@ If the critic identifies coverage gaps or missing scenarios, address them before
 
 | Field | Value |
 |---|---|
-| **Requires** | Implementation code (from `build-tdd`), architecture artifacts (`.forge/work/{type}/{name}/architecture/`), requirements (`.forge/work/{type}/{name}/requirements.md`) |
+| **Requires** | Implementation code (from `build-tdd`), architecture artifacts (`.forge/work/{type}/{name}/architecture/`), requirements (`.forge/work/{type}/{name}/requirements.md`), oracle pages (`aiwiki/oracles/*.md` from harden Step 2.5) when codify ran |
 | **Produces** | `.forge/work/{type}/{name}/test-plan.md` |
 | **Feeds into** | `quality-test-execution` (test plan drives execution) |
 | **Updates manifest** | `artifacts.test-plan: test-plan.md` |

package/skills/support-debug/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: support-debug
-description: "Use when encountering any bug, test failure, error, crash, or unexpected behavior — enforces systematic root cause investigation."
+description: "Use when a bug, test failure, error, crash, or unexpected behavior needs systematic investigation — triggered by phrases like 'debug this', 'why is X failing', 'trace this error', 'figure out what's wrong', 'investigate the failure', 'this is broken', 'help me debug'. Enforces a four-phase process (fact-check → root-cause investigation → hypothesis testing → implementation) with a 3-fix threshold that stops the random-fix spiral. Skip when the user is asking a design or architecture question (not a failure to investigate), when the failure is a known limitation already documented, or when the work is prototype iteration where the lightweight feedback loop in iterate-prototype is the right shape."
 ---
 
 # Support: Debug

package/skills/support-dream/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: support-dream
-description: "Use when the user asks to 'consolidate the wiki', 'clean up aiwiki', 'merge duplicate notes', 'prune stale gotchas', or when /evolve runs maintenance. Also auto-fires on phase-close or when context approaches compaction (~85%). Merges aiwiki duplicates, resolves contradictions, refreshes the session index. Output goes to aiwiki/proposed/ for user review — input is never modified."
+description: "Use when the user asks to 'consolidate the wiki', 'clean up aiwiki', 'merge duplicate notes', 'prune stale gotchas', or when /forge-evolve runs maintenance. Auto-fires via /dream slash command (manual), hooks/scripts/pre-compact.sh (PreCompact, ~85% context — writes a 'Status: unconsumed' Checkpoints entry to aiwiki/sessions/{date}-{session_id}.md that the post-compact agent acts on), and phase-close skills (iterate-prototype Step 9, harden Step 4, feature.md Step 8.5 per-slice, deliver-deploy Phase 5.4 retrospective) which dispatch this skill after writing their respective artifacts.{phase}.locked_at. Merges aiwiki duplicates, resolves contradictions, refines the active session file. Output goes to aiwiki/proposed/ for user review — input is never modified."
 ---
 
 # Support: Dream (Wiki Consolidation)
@@ -22,7 +22,7 @@ Three triggers, distinct intents:
 | Trigger | Intent | Scope |
 |---|---|---|
 | **Phase close** (Phase 4 (iterate) lock, Phase 5 (codify) lock, Phase 6 (production-build) per-slice close, Phase 7 (deliver) retrospective) | Promote phase outputs into curated wiki state | Subfolders touched by the phase |
-| **PreCompact hook fire** (~85% context utilization) | Consolidate session signal into durable form before lossy compaction | `aiwiki/sessions/{current}` + `aiwiki/raw/` + recently-touched typed pages |
+| **PreCompact hook fire** (~85% context utilization) | Consolidate signal into durable form before lossy compaction | `aiwiki/raw/` + recently-touched typed pages. Also refines the active session file (`aiwiki/sessions/{date}-{session_id_short}.md`) — pre-compact creates it lazily on first fire; dream consolidates its `## Checkpoints` event log if it grows beyond ~10 entries. |
 | **Manual `/dream`** | User-driven cleanup (after major refactor, branch merge, accumulated noise) | User-specified |
 
 **Do NOT skip when:**
@@ -55,14 +55,15 @@ Fired by phase-close hooks (after user emits the phase-lock signal):
 
 ### PreCompact trigger
 
-Fired by forge's existing pre-compact hook (~85% context):
+Fired indirectly via the pre-compact hook (`hooks/scripts/pre-compact.sh`). The hook itself cannot dispatch a subagent — instead it writes a `**Dream directive (unconsumed)**` block to the active session file's `## Checkpoints` section. The post-compact agent reads the session file, finds the unconsumed directive, and invokes this skill.
 
-1. Hook calls skill with scope `[aiwiki/sessions/{current}, aiwiki/raw/, recently-touched-typed-pages]`
-2. **Sync prerequisite** — session checkpoint hook has already updated `aiwiki/sessions/{current}.md` with all events. Dream IMPROVES this file; does not produce its existence.
+1. Skill is invoked by the post-compact agent acting on the directive. Scope from directive: `aiwiki/raw/` + recently-touched typed pages, plus the active session file itself (`aiwiki/sessions/{date}-{session_id_short}.md`).
+2. **Session file is always present at PreCompact time** — pre-compact.sh creates it lazily on first fire and appends the checkpoint. Dream refines the session file's `## Checkpoints` section if it has grown unwieldy (>10 entries) and may pre-populate the index sections (`## Files touched`, etc.) from git diff and aiwiki writes, leaving `/wrap` to finalize.
 3. Dispatches `dreamer` subagent
 4. Output to `aiwiki/proposed/{dream_id}/`
 5. LINT runs on proposed output
-6. Native compaction proceeds (does not wait for user review — the consolidated session file is already on disk)
+6. Native compaction does not wait for user review — the consolidated raw/typed pages and session-file proposal are already on disk
+7. **Mark the directive consumed** — after dispatch returns, the agent changes the originating entry's header from `**Dream directive (unconsumed):**` to `**Dream directive (consumed at {ISO-timestamp}):**`. Header-flip is what `session-start.sh` counts. Appending a separate "Status: consumed" line leaves the original unconsumed-marked header in place and the next session-start will still surface it as a HARD-INTERRUPT (dogfood-validated 2026-05-18).
 
 ### Manual /dream trigger
 
@@ -176,7 +177,7 @@ This skill operates the dream side; the user-facing CLI is separate but document
 | Mistake | Fix |
 |---|---|
 | Modifying `aiwiki/` directly during consolidation | All writes go to `aiwiki/proposed/{dream_id}/`; the swap is the user's action |
-| Writing to `aiwiki/sessions/{current}.md` to "create" the file | Session checkpoint hook creates the file; dream only refines an existing file |
+| Writing a new file in `aiwiki/sessions/` instead of refining the active session file | The active session file is `aiwiki/sessions/{date}-{session_id_short}.md` — created by pre-compact, /wrap, /dream, or harden. Dream refines that file in place (via the proposed-output path); it does not produce a separate sessions file. |
 | Running dream when there's no signal to consolidate | Skip the dream entirely; record nothing |
 | Skipping LINT on proposed output | LINT MUST run; lint warnings go into the manifest, surface during review |
 | Promoting raw entries without reading the target schema | Read `aiwiki/schemas/{type}.md` first; the raw entry must satisfy required sections + frontmatter |

package/skills/support-gotcha/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: support-gotcha
-description: "Use when a subtle bug, surprising behavior, or hard-won lesson is uncovered that could recur — records it as a typed wiki page for future prevention."
+description: "Use when a reproducible failure mode, hard-won lesson, or surprising behavior with a concrete trigger emerges and is worth preventing next time — triggered by phrases like 'record this gotcha', 'save this lesson', 'capture this finding', 'we should remember this', 'this is a gotcha', 'log this for future', or automatically after support-debug closes a non-trivial bug. Writes a typed page to aiwiki/gotchas/{date}-{slug}.md with reproduction steps, root cause, and concrete fix; promotes to a rule when the same pattern recurs (N=3). Skip for speculation or half-formed thoughts (use /note for those); skip if the failure mode is not reproducible — a gotcha needs a concrete trigger, not a vibe."
 ---
 
 # Support: Gotcha
@@ -43,7 +43,7 @@ Every bug fixed, every failed approach, every "I wish I'd known that earlier" mo
 | **Requires** | Concrete lesson: what broke, why, how to prevent |
 | **Produces** | Gotcha page in `aiwiki/gotchas/{YYYY-MM-DD}-{slug}.md` (project) or `~/.claude/gotchas/{YYYY-MM-DD}-{slug}.md` (global) |
 | **Schema** | `aiwiki/schemas/gotcha.md` — LINT validates frontmatter + sections on write |
-| **Feeds into** | Future sessions (prevention), `gotcha-hunter` agent (surfaces relevant entries to reviewers), `/evolve` (skill improvement) |
+| **Feeds into** | Future sessions (prevention), `gotcha-hunter` agent (surfaces relevant entries to reviewers), `/forge-evolve` (skill improvement) |
 
 ### Storage tiers
 
@@ -234,7 +234,7 @@ When no pending promotions exist, `gotcha-hunter` (separate agent) reads `aiwiki
 | `gotcha-hunter` (agent) | Reads `aiwiki/gotchas/` and surfaces diff-relevant entries to reviewers; never writes |
 | `support-wiki-lint` | Validates frontmatter + sections on every write |
 | `support-dream` | At phase-close / PreCompact: consolidates raw entries, may merge similar gotchas, prunes retired entries (writes proposals to `aiwiki/proposed/{dream_id}/` for user review) |
-| `/evolve` command | Reads gotchas to identify skill improvement opportunities |
+| `/forge-evolve` command | Reads gotchas to identify skill improvement opportunities |
 
 ## Quick reference
 

package/skills/{support-task-force → support-parallel}/SKILL.md

@@ -1,28 +1,28 @@
 ---
-name: support-task-force
-description: "Use when the user prompts a punch list of independent tasks (numbered or bulleted, ≥3 items) OR explicitly invokes /task-force. Classifies each task by type, assembles the right specialist team per task, dispatches all in parallel, aggregates results. Phase-aware: light teams during prototype phases (fast iteration), full crew during harden/production (no shortcuts). Optional Codex adversarial pairing when consent is on. REFUSES command-shaped work — routes feature/bugfix/refactor items to their owning commands instead."
+name: support-parallel
+description: "Use when the user prompts a punch list of independent tasks (numbered or bulleted, ≥3 items) OR explicitly invokes /parallel. Classifies each task by type, assembles the right specialist team per task, dispatches all in parallel, aggregates results. Phase-aware: light teams during prototype phases (fast iteration), full crew during harden/production (no shortcuts). Optional Codex adversarial pairing when consent is on. REFUSES command-shaped work — routes feature/bugfix/refactor items to their owning commands instead."
 ---
 
-# Task Force
+# Parallel
 
 ## Overview
 
 Users don't always invoke `/feature` or `/bugfix`. The daily reality is a paste-in punch list: "do these 10 things: 1. update README; 2. explore option X; 3. add a test for Y; 4. ...". Doing those in series in one context window is slow, conflict-prone, and skips the Codex second-opinion that catches real bugs.
 
-This skill assembles a **task-force per item** — a specialist team sized for the task's type and the project's current phase — and dispatches them in parallel. Each task-force has a Claude reviewer/builder paired with a Codex sibling (when the task is non-trivial). The skill REFUSES to swallow command-shaped work; items that look like features/bugfixes/refactors get routed to their owning commands.
+This skill assembles a **team per item** — sized for the task's type and the project's current phase — and dispatches them in parallel. Each team has a Claude reviewer/builder paired with a Codex sibling (when the task is non-trivial). The skill REFUSES to swallow command-shaped work; items that look like features/bugfixes/refactors get routed to their owning commands.
 
 **Core principle:** match team size to task complexity AND to the project's current phase. Prototype phases iterate fast with light teams. Production phases demand the full crew.
 
-**Announce at start:** "I'm using support-task-force to dispatch N task-forces in parallel — M routed to commands, K running in light mode, L running in full mode." If `!max` / `--full-power` detected: "...running in `!max` mode — production teams enforced regardless of phase."
+**Announce at start:** "I'm using support-parallel to dispatch N teams in parallel — M routed to commands, K running in light mode, L running in full mode." If `!max` / `--full-power` detected: "...running in `!max` mode — production teams enforced regardless of phase."
 
 ## When to Use
 
 Fire when **any** of:
-- User types `/task-force` explicitly
+- User types `/parallel` explicitly
 - User prompt contains a numbered list (`1. xxx 2. xxx 3. xxx`) with ≥3 items
 - User prompt contains a bulleted list (`- xxx / - xxx / - xxx`) with ≥3 items AND items look like work-tasks (not casual mentions)
 
-Confirm with user before dispatching if auto-detected (one-line: "Detected a 5-item task list; dispatching task-forces — say 'no' to cancel").
+Confirm with user before dispatching if auto-detected (one-line: "Detected a 5-item task list; dispatching teams — say 'no' to cancel").
 
 Do NOT use for:
 - A single task (use the appropriate command or skill directly)
@@ -33,7 +33,7 @@ Do NOT use for:
 
 ### Step 0: Codex consent (per `protocols/codex.md`)
 
-Run the Codex consent flow ONCE for the whole task-force run. The choice (Verify / Takeover / Skip / Never) propagates to every per-task dispatch. Record in `.forge/task-force/{run-id}/codex.yaml`.
+Run the Codex consent flow ONCE for the whole parallel run. The choice (Verify / Takeover / Skip / Never) propagates to every per-task dispatch. Record in `.forge/parallel/{run-id}/codex.yaml`.
 
 ### Step 1: Detect repo phase (or honor full-power override)
 
@@ -100,7 +100,7 @@ For each task, apply this classifier in order — first match wins:
 | ≥4 subsystems touched OR ≥3 verbs combined | **complex** |
 | Anything else | **ambiguous** (ask user) |
 
-Command-shaped items get **routed out** — they do NOT get a task-force. Surface them to the user with: "Item X looks like a `/feature` — running it as a forge command instead. The remaining items continue as task-forces." User can override.
+Command-shaped items get **routed out** — they do NOT get a team. Surface them to the user with: "Item X looks like a `/feature` — running it as a forge command instead. The remaining items continue as teams." User can override.
 
 ### Step 4: Assemble team per task
 
@@ -136,20 +136,20 @@ Apply both the **task type** AND the **phase mode**:
 
 Ask the user: "Is this a prototype or production task list?" Then proceed with the matching template.
 
-### Step 5: Dispatch all task-forces in parallel
+### Step 5: Dispatch all teams in parallel
 
 For each non-routed task:
 1. Compose the prompt: include the task text, the detected type, phase mode, the team composition.
 2. Fire each agent in the team as a background subagent (`run_in_background: true`).
 3. For tasks whose team includes "dispatch X skill", spawn ONE agent that invokes that skill (the skill handles its own internal multi-agent chain).
-4. Tag each agent with `task-force/{run-id}/{task-n}/{role}` for telemetry.
+4. Tag each agent with `parallel/{run-id}/{task-n}/{role}` for telemetry.
 
 Batched dispatch ceiling: 20-25 agents per `<function_calls>` block. For 10 tasks × 4 agents = 40 agents, plan 2 dispatch rounds.
 
 ### Step 6: Accumulate
 
 Background notifications arrive asynchronously:
-- Save each agent's result to `.forge/task-force/{run-id}/task-{n}/{role}.md`
+- Save each agent's result to `.forge/parallel/{run-id}/task-{n}/{role}.md`
 - Maintain a per-task status line: `Task 3 of 10: 2 of 3 agents complete (1 pending)`
 - DO NOT narrate every individual agent completion to the user — batch updates every ≥3 returns
 
@@ -161,14 +161,14 @@ When all agents for a task return, synthesize:
 - If only one returned (other failed/timeout) → mark `complete-single-source`, flag for user attention
 - If both failed → mark `failed`, recommend retry or single-task fallback
 
-Per-task output goes to `.forge/task-force/{run-id}/task-{n}/verdict.md`.
+Per-task output goes to `.forge/parallel/{run-id}/task-{n}/verdict.md`.
 
 ### Step 8: Run summary
 
 After all tasks finish (or hit batch limit), produce one consolidated report:
 
 ```
-Task-Force Run {run-id} — {N} tasks, {M} routed to commands
+Parallel Run {run-id} — {N} tasks, {M} routed to commands
 
 | # | Task | Type | Team size | Status | Conflicts |
 |---|------|------|-----------|--------|-----------|
@@ -186,7 +186,7 @@ Followups:
 - Run /feature for item 4 when ready
 ```
 
-Write the summary to `.forge/task-force/{run-id}/run-summary.md` and surface to user.
+Write the summary to `.forge/parallel/{run-id}/run-summary.md` and surface to user.
 
 ### Step 9: Stop
 
@@ -197,8 +197,8 @@ This skill does ONE run per invocation. If the user wants to iterate on findings
 | Field | Value |
 |---|---|
 | Requires | A user-provided task list (parsed in Step 2); optionally an active manifest for phase detection |
-| Produces | `.forge/task-force/{run-id}/codex.yaml`, `.forge/task-force/{run-id}/tasks.yaml` (classification), `.forge/task-force/{run-id}/task-{n}/{role}.md` per agent, `.forge/task-force/{run-id}/task-{n}/verdict.md` per task, `.forge/task-force/{run-id}/run-summary.md` |
-| Updates manifest | If a feature/bugfix manifest is active, append `phases.{phase}.task-force-runs: [{run-id}]`. Otherwise no manifest update — task-force runs are not phase-gated. |
+| Produces | `.forge/parallel/{run-id}/codex.yaml`, `.forge/parallel/{run-id}/tasks.yaml` (classification), `.forge/parallel/{run-id}/task-{n}/{role}.md` per agent, `.forge/parallel/{run-id}/task-{n}/verdict.md` per task, `.forge/parallel/{run-id}/run-summary.md` |
+| Updates manifest | If a feature/bugfix manifest is active, append `phases.{phase}.parallel-runs: [{run-id}]`. Otherwise no manifest update — parallel runs are not phase-gated. |
 | Feeds into | `/feature`, `/bugfix`, `/refactor` (for routed items); `support-gotcha` (for recurring patterns surfaced across tasks) |
 
 ## Agent Dispatch
@@ -224,11 +224,11 @@ Raw agents it dispatches directly:
 | Step | Skill / Command | Why |
 |---|---|---|
 | Pre-dispatch consent | `protocols/codex.md` | Codex pairing requires consent ONCE per run |
-| Task routing-out | `/feature`, `/bugfix`, `/refactor`, `/greenfield`, `/hotfix` | Command-shaped items must use commands, not task-forces |
+| Task routing-out | `/feature`, `/bugfix`, `/refactor`, `/greenfield`, `/hotfix` | Command-shaped items must use commands, not teams |
 | Per-task dev | `quality-code-review` skill | Production dev tasks get the full review chain |
 | Per-task debug | `support-debug` skill | Debug tasks get tracer + gotcha-hunter |
 | Per-task security | `quality-security-audit` skill | Security tasks get the OWASP-aware audit chain |
-| Post-run gotcha | `support-gotcha` | Patterns surfaced across multiple task-forces deserve a recorded lesson |
+| Post-run gotcha | `support-gotcha` | Patterns surfaced across multiple teams deserve a recorded lesson |
 
 ## Red Flags
 
@@ -239,12 +239,12 @@ Raw agents it dispatches directly:
 | Codex consent skipped silently | Means no second-opinion across the whole run — for production-mode tasks this is a regression |
 | 0 conflicts across all tasks | Either every task was trivial OR Claude+Codex are echoing each other; sample-check |
 | Complex tasks in prototype mode | Probably should be a /feature; warn user before proceeding |
-| Run-id directories never get cleaned | Add a periodic prune; aiwiki/dream or /evolve should handle it |
+| Run-id directories never get cleaned | Add a periodic prune; aiwiki/dream or /forge-evolve should handle it |
 | Soft cap warning ignored repeatedly | User has misframed work — recommend splitting into milestones |
 
 ## Anti-Patterns
 
-**Swallowing command-shaped work.** If the user types "add a payment feature, then audit security, then ship", DO NOT run a task-force — that's three workflows pretending to be three tasks. Route them: `/feature` → `quality-security-audit` → `/feature` deploy phase. Task-force is for items that DON'T fit a workflow.
+**Swallowing command-shaped work.** If the user types "add a payment feature, then audit security, then ship", DO NOT dispatch a parallel run — that's three workflows pretending to be three tasks. Route them: `/feature` → `quality-security-audit` → `/feature` deploy phase. `/parallel` is for items that DON'T fit a workflow.
 
 **Phase-blind sizing.** Spawning the full crew on a Phase-4 prototype task wastes tokens AND violates the prototype-throwaway principle. Always read phase first.
 
@@ -252,7 +252,7 @@ Raw agents it dispatches directly:
 
 **Ignoring divergent verdicts.** Claude+Codex disagreement is a SIGNAL, not noise. Surface it. Let the user adjudicate.
 
-**Letting `.forge/task-force/` grow forever.** Each run leaves a directory. Add to `support-dream` consolidation scope, or document a cleanup pattern.
+**Letting `.forge/parallel/` grow forever.** Each run leaves a directory. Add to `support-dream` consolidation scope, or document a cleanup pattern.
 
 **Auto-dispatching without confirmation when auto-detected.** Numbered lists in user prose aren't always task lists (could be a survey of options, a sequence diagram, etc.). Confirm before firing 40 agents.
 

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.