mindforge-cc 8.2.0 → 9.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:skills.md

@@ -1,144 +0,0 @@
----
-description: /mindforge:skills list
----
-# MindForge — Skills Command
-# Usage: /mindforge:skills [subcommand] [args]
-# Subcommands: list | add | update | validate | info | search
-
-## Subcommand: list
-`/mindforge:skills list`
-
-Read MANIFEST.md. Display all registered skills in a formatted table
-(include path for each skill):
-
-```
-MindForge Skills Registry
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-  Tier 1 — Core Skills (10 installed)
-  ────────────────────────────────────────────────────────────
-  ✅  security-review     v1.0.0   stable   .mindforge/skills/security-review/SKILL.md
-  ✅  code-quality        v1.0.0   stable   .mindforge/skills/code-quality/SKILL.md
-  ✅  api-design          v1.0.0   stable   .mindforge/skills/api-design/SKILL.md
-  ✅  testing-standards   v1.0.0   stable   .mindforge/skills/testing-standards/SKILL.md
-  ✅  documentation       v1.0.0   stable   .mindforge/skills/documentation/SKILL.md
-  ✅  performance         v1.0.0   stable   .mindforge/skills/performance/SKILL.md
-  ✅  accessibility       v1.0.0   stable   .mindforge/skills/accessibility/SKILL.md
-  ✅  data-privacy        v1.0.0   stable   .mindforge/skills/data-privacy/SKILL.md
-  ✅  incident-response   v1.0.0   stable   .mindforge/skills/incident-response/SKILL.md
-  ✅  database-patterns   v1.0.0   stable   .mindforge/skills/database-patterns/SKILL.md
-
-  Tier 2 — Org Skills (0 installed)
-  ────────────────────────────────────────────────────────────
-  (none — run /mindforge:skills add to add org skills)
-
-  Tier 3 — Project Skills (0 installed)
-  ────────────────────────────────────────────────────────────
-  (none)
-
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  Total: 10 skills   |   Run /mindforge:skills validate to check health
-```
-
-## Subcommand: info
-`/mindforge:skills info [skill-name]`
-
-Display detailed information about a specific skill:
-
-```
-Skill: security-review
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  Version      : 1.0.0
-  Status       : stable
-  Tier         : 1 (Core)
-  Min MindForge: 0.1.0
-  Path         : .mindforge/skills/security-review/SKILL.md
-
-  Triggers (25):
-  auth, authentication, authorisation, authorization, login,
-  logout, password, token, JWT, session, cookie, OAuth,
-  payment, billing, stripe, PII, GDPR, personal data,
-  upload, file upload, credentials, API key, secret, env,
-  environment variable, encryption, hashing, bcrypt, argon2
-
-  Changelog:
-  1.0.0 — Initial stable release
-```
-
-## Subcommand: search
-`/mindforge:skills search [keyword]`
-
-Find which skills would activate for a given keyword:
-
-```
-/mindforge:skills search "database query"
-
-  Matching skills for "database query":
-  ────────────────────────────────────────────────────────────
-  database-patterns  v1.0.0  [tier 1]  trigger: "database", "query"
-  performance        v1.0.0  [tier 1]  trigger: "query time"
-
-  These 2 skills would be automatically loaded for a task
-  containing "database query" in its description.
-```
-
-## Subcommand: validate
-`/mindforge:skills validate`
-
-Run a health check on all installed skills:
-
-```
-Validating skills...
-
-  ✅  security-review     — frontmatter valid, file readable, triggers: 29
-  ✅  code-quality        — frontmatter valid, file readable, triggers: 14
-  ✅  performance         — frontmatter valid, file readable, triggers: 31
-  ⚠️  [org-skill-name]   — frontmatter valid but missing 'version' field
-  ❌  [missing-skill]    — listed in MANIFEST.md but file not found
-
-  Issues found: 2
-  Run /mindforge:skills add to fix missing skills.
-  Fix frontmatter issues manually in the SKILL.md file.
-```
-
-Validation checks:
-1. Every manifest entry has a corresponding SKILL.md file
-2. Every SKILL.md has: `name`, `version`, `status`, `triggers` in frontmatter
-3. Every SKILL.md has a self-check or checklist section
-4. All versions are valid semver strings
-5. No two skills at the same tier share the same trigger keyword (flag as ⚠️)
-6. Every skill file is readable (not empty, not corrupted)
-
-## Subcommand: add
-`/mindforge:skills add [path-to-skill-dir]`
-
-Register a new skill in the manifest:
-
-1. Read the SKILL.md in the provided path
-2. Validate the frontmatter (all required fields present)
-3. Check for trigger keyword conflicts with existing skills
-4. Ask the user: "Which tier should this skill be registered as? (2=Org / 3=Project)"
-5. Show the exact MANIFEST.md entry that will be written and ask for confirmation
-6. Add the entry to MANIFEST.md in the correct section
-7. Run `/mindforge:skills validate` to confirm registration is clean
-8. Commit: `feat(skills): register [skill-name] v[version] as tier [N] skill`
-
-## Subcommand: update
-`/mindforge:skills update [skill-name]`
-
-Update a skill to a newer version:
-
-1. Read current version from MANIFEST.md
-2. Check the skill's changelog in SKILL.md for available updates
-3. If MAJOR version change: show breaking changes, require confirmation
-4. If MINOR or PATCH: update automatically
-5. Update MANIFEST.md version entry
-6. Run `/mindforge:skills validate` after update
-7. Run `node tests/skills-platform.test.js` after update
-8. Commit: `chore(skills): update [name] v[old] → v[new]`
-
-## Error handling
-- If MANIFEST.md does not exist: offer to create it with current skills
-- If a skill name is not found: suggest similar names (fuzzy match)
-- If validation finds critical errors: block any phase execution until fixed
-  (A skills validation failure is a BLOCKING issue)

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:soul.md

@@ -1,54 +0,0 @@
----
-description: Manage the MindForge Sovereign Identity (SOUL.md).
----
-
-<workflow name="MindForge Sovereign Identity Management">
-  <metadata>
-    <version>8.1.0-IDENTITY</version>
-    <pillar>XIX: Sovereign Identity Synthesis</pillar>
-    <objective>Manage and evolve the Behavioral Operating System of the agent instance.</objective>
-  </metadata>
-
-  <step id="1" name="Context Selection">
-    <instructions>
-      Ask the user to select an identity management action.
-    </instructions>
-    <prompt>
-      "What would you like to do with the Sovereign Identity? (view/evolve/reset)"
-    </prompt>
-  </step>
-
-  <step id="2" name="Execution Logic">
-    <branch condition="action == 'view'">
-      <instructions>
-        Read SOUL.md from the root directory and present the Identity, Core Truths, and Decision Engine sections.
-      </instructions>
-    </branch>
-
-    <branch condition="action == 'evolve'">
-      <instructions>
-        Trigger the Pillar XIX synthesis engine to analyze recent traces in celestial.db.
-      </instructions>
-      <command>
-        node -e "require('./bin/memory/identity-synthesizer').evolve()"
-      </command>
-      <output>
-        "Sovereign Identity evolved based on the latest execution traces. Decisions and interaction style have been mirrored to your engineering patterns."
-      </output>
-    </branch>
-
-    <branch condition="action == 'reset'">
-      <instructions>
-        Restore the SOUL.md to the Grand Blueprint state.
-      </instructions>
-      <command>
-        node -e "require('./bin/memory/identity-synthesizer').bootstrap({ user: 'User', goal: 'Reset Identity' })"
-      </command>
-    </branch>
-  </step>
-
-  <verification>
-    <check>Verify existence of SOUL.md in project root.</check>
-    <check>Confirm v8.1.0-IDENTITY compliance in instruction hierarchy.</check>
-  </verification>
-</workflow>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:status.md

@@ -1,107 +0,0 @@
----
-description: Display a rich dashboard of the current project state.
----
-# MindForge — Status Command
-# Usage: /mindforge:status
-
-Display a rich dashboard of the current project state.
-Pull data from STATE.md, AUDIT.jsonl, REQUIREMENTS.md, and the phases directory.
-
-## Dashboard sections
-
-### Section 1 — Project header
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-⚡ MindForge Status — [Project Name]
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-  Last updated : [STATE.md last updated timestamp]
-  Current phase: Phase [N] — [phase description]
-  Status       : [status from STATE.md]
-```
-
-### Section 2 — Phase progress
-```
-Phase Progress
-───────────────────────────────────────────────────────
-  Phase 1  [████████████████████] 100% — Complete ✅
-  Phase 2  [████████░░░░░░░░░░░░]  40% — In progress
-  Phase 3  [░░░░░░░░░░░░░░░░░░░░]   0% — Not started
-  Phase 4  [░░░░░░░░░░░░░░░░░░░░]   0% — Not started
-```
-Calculate percentage from: tasks with SUMMARY files / total tasks in phase.
-Count ONLY SUMMARY files that contain `Status: Completed ✅` (or `Status` + `Completed`).
-Do not count failed tasks as progress.
-If VERIFICATION.md is missing for a phase: label it "In progress" not "0% verified".
-
-### Section 3 — Requirements coverage
-Read REQUIREMENTS.md and count:
-- Total v1 requirements
-- Requirements with a passing test (from VERIFICATION.md files)
-- Requirements implemented but untested
-- Requirements not yet started
-
-```
-Requirements (v1)
-───────────────────────────────────────────────────────
-  Total        : [N]
-  ✅ Done + tested  : [N]
-  ⚠️  Done, no test : [N]
-  🔴 Not started   : [N]
-```
-
-### Section 4 — Recent activity (from AUDIT.jsonl)
-Read the last 10 entries from AUDIT.jsonl and display:
-```
-Recent Activity
-───────────────────────────────────────────────────────
-  [timestamp]  task_completed  Plan 03: User API endpoints ✅
-  [timestamp]  task_completed  Plan 02: Product model ✅
-  [timestamp]  task_started    Plan 03: User API endpoints
-  [timestamp]  task_completed  Plan 01: User model ✅
-  [timestamp]  context_compaction  Phase 2, Plan 03 (72% context)
-```
-If AUDIT.jsonl is empty or missing, display:
-```
-Recent Activity
-───────────────────────────────────────────────────────
-  No activity logged yet. Activity will appear here
-  after running /mindforge:execute-phase.
-```
-
-### Section 5 — Open issues
-Check for:
-- Any open SECURITY-REVIEW files with CRITICAL or HIGH findings
-- Any BUGS.md files with open issues
-- Any failed tasks in WAVE-REPORT files
-- Any blockers in STATE.md
-
-```
-Open Issues
-───────────────────────────────────────────────────────
-  🔴 CRITICAL: [if any — from SECURITY-REVIEW]
-  🟠 HIGH:     [if any]
-  ✅ No open issues
-```
-
-### Section 6 — Next action
-```
-Next Action
-───────────────────────────────────────────────────────
-  [What STATE.md says the next action is]
-  Run: /mindforge:next
-     to auto-execute the next step.
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-```
-
-## Data sources (in priority order)
-1. STATE.md — authoritative for current status
-2. AUDIT.jsonl — authoritative for history
-3. REQUIREMENTS.md — authoritative for scope
-4. VERIFICATION.md files — authoritative for test coverage
-5. WAVE-REPORT files — authoritative for execution history
-6. HANDOFF.json — authoritative for session state
-
-## Performance notes
-- For recent activity, read only the last 500 bytes of AUDIT.jsonl:
-  `tail -c 500 .planning/AUDIT.jsonl | [parse last complete JSON objects]`
-- For requirement counts, count lines starting with `| FR-` instead of parsing the whole file.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:steer.md

@@ -1,16 +0,0 @@
----
-description: Injects mid-execution guidance into the running autonomous engine.
----
-# /mindforge:steer "[instruction]"
-
-**Purpose**: Injects mid-execution guidance into the running autonomous engine.
-Steering guidance is applied at the next task boundary to course-correct MindForge.
-
-## Usage
-- `/mindforge:steer "Use the new logger in all created files"`
-- `/mindforge:steer --task 3-05 "This plan is too broad, focus on login only"`
-- `/mindforge:steer --cancel` (Clears the steering queue)
-
-## Precedence
-- Steering instructions take precedence over the original `PLAN-N-MM.md` actions.
-- Steering cannot override core security constraints or governance gates.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:sync-confluence.md

@@ -1,14 +0,0 @@
----
-description: Publish approved planning artifacts to Confluence. Usage:
----
-Publish approved planning artifacts to Confluence. Usage:
-`/mindforge:sync-confluence [--architecture] [--phase N] [--milestone name]`
-
-## Behaviour
-- verify Confluence availability through `connection-manager.md`
-- publish idempotently by existing page title or page ID
-- never publish secrets, raw approval notes, or raw audit logs
-- log success, skip, or failure to AUDIT
-
-Publishing failures are non-fatal and create a pending manual action in
- `STATE.md`.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:sync-jira.md

@@ -1,15 +0,0 @@
----
-description: Synchronise MindForge phase and plan metadata to Jira. Usage:
----
-Synchronise MindForge phase and plan metadata to Jira. Usage:
-`/mindforge:sync-jira [--phase N] [--plan M]`
-
-## Behaviour
-- verify Jira availability through `connection-manager.md`
-- create or update Epic and Story mappings in `.planning/jira-sync.json`
-- use dynamic transition lookup, never hardcoded IDs
-- preserve manual Jira edits
-- log all actions to AUDIT
-
-Integration failures are non-fatal and should be written to `STATE.md` for
- manual retry.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:tdd.md

@@ -1,46 +0,0 @@
----
-description: Strict TDD workflow (Red-Green-Refactor).
----
-# 🧪 /mindforge:tdd
-
-<instruction>
-Execute a strict Test-Driven Development (TDD) loop using the Red-Green-Refactor pattern with an emphasis on "Tracer Bullets" (vertical slices).
-</instruction>
-
-<context>
-Follow the specialized MindForge TDD standards defined in [.agent/skills/mindforge-tdd_extended/SKILL.md](.agent/skills/mindforge-tdd_extended/SKILL.md).
-</context>
-
-<rules>
-- **No Implementation without Test**: Do not write production code unless it is to make a failing test pass.
-- **Minimalist Green**: Write the absolute minimum code required to satisfy the test.
-- **Refactor Ruthlessly**: Clean up after every green state while keeping tests passing.
-- **Vertical Slicing**: Strict Red-Green-Refactor development. Ensure test coverage before implementation logic.
-</rules>
-
-## Step 0 — Protocol Activation
-
-**MANDATORY**: Invoke the `mindforge-tdd_extended` skill.
-This ensures the implementation uses isolated test-first logic and anti-pattern detection.
-
-<process>
-1.  **RED**: Define a single behavioral requirement and write a failing test.
-2.  **GREEN**: Implement the simplest code to fix the failure.
-3.  **REFACTOR**: Optimize the code and tests for readability and maintainability.
-4.  **VERIFY**: Ensure all tests in the suite pass before proceeding.
-</process>
-
-<supporting_documents>
-- [Deep Modules](.agent/skills/mindforge-tdd/deep-modules.md)
-- [Interface Design](.agent/skills/mindforge-tdd/interface-design.md)
-- [Mocking Strategies](.agent/skills/mindforge-tdd/mocking.md)
-- [Refactoring Guide](.agent/skills/mindforge-tdd/refactoring.md)
-- [Test Infrastructure](.agent/skills/mindforge-tdd/tests.md)
-</supporting_documents>
-
-<output_format>
-Summarize each TDD cycle with:
-- `[RED]`: The test added.
-- `[GREEN]`: The minimal change made.
-- `[REFACTOR]`: Specific improvements made.
-</output_format>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:tokens.md

@@ -1,11 +0,0 @@
----
-description: Display token consumption profile and efficiency analysis.
----
-# MindForge — Token Usage Command
-# Usage: /mindforge:tokens [--phase N] [--session ID] [--window short|medium|long] [--optimise]
-
-## Purpose
-Display token consumption profile and efficiency analysis.
-Helps identify where tokens are being spent and how to reduce waste.
-
-## Default output (no flags — last 5 sessions)

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:tool.md

@@ -1,18 +0,0 @@
----
-description: Invoke the System Operator persona (mf-tool)
----
-# 🔌 /mindforge:tool
-
-## Objective
-Adopt the **System Operator** persona for safe external system interaction and tool execution logic.
-
----
-
-## Execution
-// turbo
-1. Execute the MindForge CLI to spawn the tool essence:
-   ```bash
-   node bin/mindforge-cli.js spawn mf-tool
-   ```
-
-2. The AI will adopt the **Least-Privilege Gating** pattern and await your tool-use requests.

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:ui-phase.md

@@ -1,27 +0,0 @@
----
-description: Generate a UI Design Contract (UI-SPEC.md) for the current phase
----
-<objective>
-Generate a detailed UI design contract (UI-SPEC.md) for a frontend development phase to ensure consistent spacing, typography, color palettes, and accessibility standards before implementation.
-</objective>
-
-<execution_context>
-.claude/commands/mindforge/ui-phase.md
-</execution_context>
-
-<context>
-Arguments: $ARGUMENTS (The phase number [N], optional)
-Configuration: MINDFORGE.md `UI_PHASE_ACCESSIBILITY_STANDARD`
-State: Resolves the phase from STATE.md if N is not provided.
-</context>
-
-<process>
-1. **Identify Phase**: Get the current or targeted phase number.
-2. **Read Inputs**: Read `REQUIREMENTS.md` and `DESIGN_SYSTEM.md`.
-3. **Generate UI-SPEC.md**:
-    - Define component-level spacing and layout for the phase.
-    - Specify required colors and typography from the design system.
-    - List accessibility requirements (WCAG level).
-4. **Finalize**: Write `UI-SPEC.md` to the phase's planning directory or the root `.planning/`.
-5. **Confirm**: Provide a link to the user for review.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:ui-review.md

@@ -1,28 +0,0 @@
----
-description: Perform a retroactive visual audit of implemented UI against the DESIGN_SYSTEM.md and UI-SPEC.md
----
-<objective>
-Perform a retroactive, multi-pillar visual audit of implemented UI features against the defined Design System and UI-SPEC.md to ensure pixel-perfect fidelity and accessibility compliance.
-</objective>
-
-<execution_context>
-.claude/commands/mindforge/ui-review.md
-</execution_context>
-
-<context>
-Arguments: $ARGUMENTS (The phase number [N], optional)
-Sources: `DESIGN_SYSTEM.md`, `UI-SPEC.md`, and the live application UI.
-</context>
-
-<process>
-1. **Identify Target**: Determine the phase to review.
-2. **Audit Application**:
-    - Use the browser tool to inspect the implemented features.
-    - Compare against the `UI-SPEC.md` for spacing, colors, and layout.
-    - Audit for accessibility (ARIA labels, contrast, keyboard navigation).
-3. **Generate UI-REVIEW.md**:
-    - Grade each pillar (Layout, Color, Typography, etc.).
-    - List specific "Needs Work" items.
-    - Provide "Approved" status if all criteria are met.
-4. **Finalize**: Notify the user of the audit results.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:update.md

@@ -1,45 +0,0 @@
----
-description: Check for and apply MindForge framework updates in a safe, scope-preserving way.
----
-# MindForge — Update Command
-# Usage: /mindforge:update [--apply] [--force] [--check] [--skip-changelog]
-
-## Purpose
-Check for and apply MindForge framework updates in a safe, scope-preserving way.
-
-## Execution flow
-
-### 1. Version check
-Execute `bin/updater/self-update.js` `checkAndUpdate()`.
-Always show: current version, latest version, update type (major/minor/patch).
-
-### 2. Changelog display (unless --skip-changelog)
-Fetch and display the relevant CHANGELOG.md section.
-For major updates: prefix with ⚠️ BREAKING CHANGES notice.
-Limit display to 3,000 characters — link to full CHANGELOG for the rest.
-
-### 3. Confirmation gate (unless --apply)
-Without --apply: show update info, stop. Do not modify any files.
-Message: "To apply this update: /mindforge:update --apply"
-
-### 4. Apply (with --apply)
-a. Detect original install scope (local vs global, claude vs antigravity)
-b. Read schema_version from HANDOFF.json (captures current version BEFORE update)
-c. Run `npx mindforge-cc@[latest] --[runtime] --[scope]`
-d. Run migration: `node bin/migrations/migrate.js` with captured schema_version
-e. Run /mindforge:health to verify update succeeded
-
-### 5. Post-update health check
-If health errors: surface them immediately with specific fix instructions.
-Common post-update issue: CLAUDE.md and .agent/CLAUDE.md drifted → auto-repair.
-
-## Error scenarios and recovery
-
-| Error | Recovery |
-|---|---|
-| npm registry unreachable | Message: "Check internet. Manual: npm info mindforge-cc version" |
-| Update download fails | Retry once, then suggest manual: `npx mindforge-cc@latest` |
-| Migration fails | Restored from backup automatically. Run /mindforge:migrate manually. |
-| Install scope detection fails | Prompt user: "Is your install global or local?" |
-
-## AUDIT entry

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:validate-phase.md

@@ -1,25 +0,0 @@
----
-description: Audit the current phase for requirement coverage and test gaps
----
-<objective>
-Audit a completed project phase to ensure every requirement has been addressed and that corresponding automated tests have been implemented and are passing.
-</objective>
-
-<execution_context>
-.claude/commands/mindforge/validate-phase.md
-</execution_context>
-
-<context>
-Arguments: $ARGUMENTS (The phase number [N], optional)
-Knowledge: `STATE.md`, `REQUIREMENTS.md`, and the codebase test suite.
-</context>
-
-<process>
-1. **Identify Phase**: Resolve the targeted phase.
-2. **Cross-reference**:
-    - List all requirements in `REQUIREMENTS.md` marked for this phase.
-    - Verify implementation of each requirement in the code.
-    - Check for the existence of passing tests for each requirement.
-3. **Analyze Gaps**: Identify any "orphaned" requirements or features missing tests.
-4. **Report Findings**: Summarize coverage and call out specific gaps to the user.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:verify-phase.md

@@ -1,65 +0,0 @@
----
-description: Human acceptance testing for a completed phase. Usage: /mindforge:verify-phase [N]
----
-Human acceptance testing for a completed phase. Usage: /mindforge:verify-phase [N]
-
-## Pre-check
-`.planning/phases/[N]/VERIFICATION.md` must exist.
-If it does not: instruct the user to run /mindforge:execute-phase [N] first.
-
-## Step 1 — Extract testable deliverables
-Read REQUIREMENTS.md and the phase PLAN files.
-Generate a list of testable deliverables — things the user can actually check.
-
-Format each as a clear, actionable test instruction:
-"Navigate to /login and submit a form with a valid email and password.
- You should be redirected to /dashboard within 2 seconds."
-
-## Step 2 — Walk through each deliverable
-Present one at a time. After each:
-"Please test this now and tell me: pass ✅ or fail ❌ — and describe what you saw."
-
-Wait for the user's response before proceeding to the next.
-
-## Step 3 — Handle failures
-If the user reports a failure:
-1. Ask: "What exactly happened? (error message, wrong behaviour, nothing happened)"
-2. Spawn a debug subagent with: the failure description, the relevant PLAN file,
-   and the relevant source files. Instruct it to find the root cause.
-3. Create a fix plan: `.planning/phases/[N]/FIX-PLAN-[N]-[NN].md`
-   using the same XML format as regular plans.
-4. Ask the user: "Fix plan created. Run /mindforge:execute-phase [N] again
-   to apply the fixes?"
-
-## Step 4 — Write UAT record
-Write `.planning/phases/[N]/UAT.md`:
-
-```markdown
-# UAT — Phase [N]
-
-## Tester
-[User name or "developer"]
-
-## Date
-[ISO 8601 date]
-
-## Results
-
-| # | Deliverable                        | Result | Notes                  |
-|---|------------------------------------|--------|------------------------|
-| 1 | [description]                      | ✅     | [what was observed]    |
-| 2 | [description]                      | ❌     | [what went wrong]      |
-
-## Overall status
-All passed ✅ / Issues found — fix plans created ❌
-
-## Sign-off
-[Passed / Pending fixes]
-```
-
-## Step 5 — Update state if all pass
-If all deliverables pass:
-Update STATE.md: phase N = verified and signed off.
-Tell the user:
-"✅ Phase [N] verified and signed off.
- Run /mindforge:ship [N] to create the release PR."

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/workflows/mindforge:workspace.md

@@ -1,32 +0,0 @@
----
-description: Monorepo workspace management.
----
-# MindForge — Workspace Command
-# Usage: /mindforge:workspace [detect|list|plan phase N|test]
-
-Monorepo workspace management.
-
-## detect
-Run workspace detector from `.mindforge/monorepo/workspace-detector.md`.
-Write WORKSPACE-MANIFEST.json.
-Report: workspace type, packages found, dependency order.
-
-## list
-Read WORKSPACE-MANIFEST.json and display package list:
-```
-Workspace: Turborepo (4 packages)
-  packages/shared    → @myapp/shared   (lib, 0 dependents)
-  apps/api           → @myapp/api      (api, depends on: shared)
-  apps/web           → @myapp/web      (web, depends on: shared, api)
-  apps/mobile        → @myapp/mobile   (mobile, depends on: shared)
-Execution order: shared → api → (web, mobile in parallel)
-```
-
-## plan phase N
-Create a phase plan that spans multiple packages.
-Uses cross-package-planner.md to determine package execution order.
-Each PLAN file includes a `<package>` and `<working-dir>` field.
-
-## test
-Run tests across all packages in dependency order.
-Report per-package test results and aggregate coverage.