mindforge-cc 11.3.0 → 11.3.1

package/.claude/commands/mindforge/steer.md

@@ -0,0 +1,17 @@
+---
+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/.claude/commands/mindforge/stream.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:stream
+description: "Design stream processing pipeline. Usage: /mindforge:stream [pipeline] [--engine kafka|flink|spark] [--guarantee exactly-once|at-least-once]"
+argument-hint: "[pipeline] [--engine kafka|flink|spark] [--guarantee exactly-once|at-least-once]"
+allowed-tools:
+  - list_dir
+  - view_file
+---
+
+<objective>
+Design comprehensive stream system architecture with best practices and production-ready patterns.
+</objective>
+
+<execution_context>
+@.mindforge/skills/stream-processing/SKILL.md
+</execution_context>
+
+<context>
+Skills Directory: `.mindforge/skills/stream-processing/`
+State: Analyzes requirements, constraints, and scale to generate optimized stream architecture.
+</context>
+
+<process>
+1. **Requirement Analysis**: Analyze domain-specific requirements, performance constraints, and scalability needs.
+2. **Architecture Design**: Design system architecture with component interaction patterns and data flow.
+3. **Technology Selection**: Evaluate and select appropriate technologies, tools, and frameworks.
+4. **Integration Strategy**: Define integration patterns with existing systems and external dependencies.
+5. **Optimization Approach**: Implement performance, cost, and resource optimization strategies.
+6. **Monitoring Framework**: Design observability, alerting, and debugging mechanisms.
+7. **Deployment Planning**: Create deployment strategy with rollback procedures and disaster recovery.
+</process>

package/.claude/commands/mindforge/sync-confluence.md

@@ -0,0 +1,15 @@
+---
+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/.claude/commands/mindforge/sync-jira.md

@@ -0,0 +1,16 @@
+---
+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/.claude/commands/mindforge/system-design.md

@@ -0,0 +1,87 @@
+---
+description: "Architect large-scale distributed systems with capacity planning. Usage: /mindforge:system-design [system] [--qps N] [--latency Nms]"
+---
+
+<objective>
+Design a scalable distributed system from requirements through capacity planning, selecting appropriate patterns, designing for failure, and documenting trade-offs with concrete numbers.
+</objective>
+
+<execution_context>
+@.mindforge/skills/system-design/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (system name or description, optional --qps and --latency constraints)
+Knowledge: Current ARCHITECTURE.md, infrastructure topology, known bottlenecks.
+</context>
+
+<process>
+1. **Quantify requirements**: Establish concrete numbers for the system:
+   - QPS (queries per second) — read vs write ratio
+   - Latency targets (p50, p95, p99)
+   - Storage requirements (current + 3-year growth projection)
+   - Bandwidth (ingress/egress)
+   - Availability target (99.9%, 99.99%, etc.) and implied error budget
+
+2. **Back-of-envelope calculations**: Compute:
+   - Daily/monthly active users to QPS conversion
+   - Storage per entity * entity count * retention period
+   - Network bandwidth = QPS * avg payload size
+   - Cache hit ratio needed to meet latency targets
+   - Replication factor impact on storage and write amplification
+
+3. **Identify bottlenecks**: Given the numbers, identify where the system will break first:
+   - Database write throughput limits
+   - Network bandwidth saturation points
+   - Memory constraints for caching layers
+   - CPU-bound computation hotspots
+   - Connection pool exhaustion thresholds
+
+4. **Select architectural patterns**: Choose patterns that address identified bottlenecks:
+   - Caching strategy (write-through, write-behind, cache-aside)
+   - Sharding strategy (hash-based, range-based, geographic)
+   - Replication topology (leader-follower, multi-leader, leaderless)
+   - Message queue placement (decouple writes, absorb spikes)
+   - CDN and edge caching for read-heavy paths
+
+5. **Design for failure**: For each component, define:
+   - Failure mode (crash, slow, corrupt, partition)
+   - Detection mechanism (health checks, heartbeats, anomaly detection)
+   - Recovery strategy (failover, retry, degrade gracefully)
+   - Blast radius containment (bulkheads, cell-based architecture)
+   - Data durability guarantees during failure
+
+6. **Capacity plan**: Produce a concrete resource estimate:
+   - Compute: instance type * count per tier
+   - Storage: disk type * size * IOPS requirement
+   - Network: load balancer capacity, cross-AZ traffic cost
+   - Cache: memory per node * node count * eviction headroom
+   - Scale triggers: auto-scaling thresholds with cooldown periods
+
+7. **Define data flow**: Draw the request lifecycle:
+   - Client → CDN/Edge → Load Balancer → Application tier → Cache → Database
+   - Async paths: Application → Queue → Worker → Database/External
+   - Mark latency budget allocation at each hop
+
+8. **Document trade-offs**: For every major decision, state:
+   - What was chosen and why
+   - What was rejected and why
+   - Under what conditions the decision should be revisited
+   - CAP theorem positioning (CP vs AP per subsystem)
+
+9. **Observability design**: Define monitoring for the system:
+   - Golden signals per service (latency, traffic, errors, saturation)
+   - Distributed tracing span architecture
+   - Alerting thresholds tied to SLO error budget burn rate
+   - Dashboard layout (overview → drill-down hierarchy)
+
+10. **Output system design document**: Produce a structured design doc:
+    - Requirements summary with numbers
+    - High-level architecture diagram (ASCII or description)
+    - Component breakdown with responsibilities
+    - Data model and storage design
+    - API design (external and internal)
+    - Capacity estimates table
+    - Trade-off decision log
+    - Open questions and risks
+</process>

package/.claude/commands/mindforge/team-topology.md

@@ -0,0 +1,27 @@
+---
+description: "Design team structure with interaction modes. Usage: /mindforge:team-topology [teams] [--type stream-aligned|platform|enabling] [--load-assess]"
+---
+
+<objective>
+Design or evaluate team structures using Team Topologies principles, assessing cognitive load, defining team types and interaction modes, and planning transitions to reduce delivery bottlenecks.
+</objective>
+
+<execution_context>
+@.mindforge/skills/team-topology-design/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (team names or org scope, optional --type, optional --load-assess)
+Knowledge: Current org chart, service ownership map, deployment frequency per team, incident escalation patterns.
+</context>
+
+<process>
+1. **Inventory Current Teams**: Map all existing teams, their members, owned services/domains, and current responsibilities. Identify any shared ownership or unclear boundaries.
+2. **Assess Cognitive Load Per Team**: For each team, evaluate: number of services owned, technology diversity, domain complexity, on-call burden, and cross-team dependencies. Flag teams exceeding sustainable load.
+3. **Identify Overloaded Teams**: Teams with cognitive load score > 7/10 are candidates for splitting. Teams with < 3/10 may be candidates for merging or expanding scope.
+4. **Recommend Team Type**: Classify each team as stream-aligned (delivers end-to-end value), platform (provides self-service capabilities), enabling (helps others adopt new skills), or complicated-subsystem (manages complex domain requiring specialists).
+5. **Define Team Boundaries**: Draw clear boundaries using domain-driven design bounded contexts. Each team should own a coherent domain with minimal cross-cutting concerns.
+6. **Specify Interaction Modes**: For each team pair that interacts, define the mode: collaboration (working closely together, time-limited), X-as-a-service (clear API contract), or facilitating (helping another team learn).
+7. **Identify Team APIs**: Define what each team exposes to others: service contracts, documentation, support channels, SLAs. Platform teams need explicit self-service interfaces.
+8. **Plan Transition**: If restructuring is needed, create a phased migration plan with intermediate states, communication plan, and success metrics. Avoid big-bang reorgs.
+</process>

package/.claude/commands/mindforge/tech-debt.md

@@ -0,0 +1,31 @@
+---
+description: Inventory and prioritize technical debt with payoff ROI. Usage - /mindforge:tech-debt [--audit] [--budget 20%] [--prioritize]
+---
+
+<objective>
+Systematically inventory technical debt across the codebase, classify by type
+and severity, calculate the ongoing interest cost (time lost per sprint), compute
+payoff ROI for each item, and allocate sprint budget to maximize debt reduction
+impact while maintaining feature velocity.
+</objective>
+
+<execution_context>
+@.mindforge/skills/technical-debt-management/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Scan for debt signals across the codebase: TODO/FIXME/HACK comments, skipped tests (@skip, .skip()), outdated dependencies (major versions behind), high cyclomatic complexity (>15), duplicated code blocks (>30 lines), and missing type coverage (<80%).
+2. Classify each debt item by type: deliberate (conscious trade-off documented in ADR), inadvertent (accidental, discovered post-hoc), bit-rot (gradual decay from ecosystem changes), or reckless (no justification, likely under time pressure). Tag with affected domain.
+3. Calculate interest for each item: estimate time lost per sprint due to the debt (slower development, extra bugs, onboarding friction, workarounds). Express as hours/sprint and annualized cost at team rate ($).
+4. Compute payoff ROI for each item: (annual interest saved - one-time fix cost) / one-time fix cost. Items with ROI > 3x are high-priority, 1-3x are medium, <1x are low-priority or acceptable debt.
+5. Rank all items by payoff ratio descending, with tiebreakers: items blocking new features first, items causing production incidents second, items affecting developer happiness third.
+6. Allocate sprint budget based on --budget flag (default 20%): assign top-ranked items to the debt budget, ensure each item is completable within one sprint, create stories with clear acceptance criteria and definition of done.
+7. Assign debt items to sprints: distribute across team members based on domain expertise, pair high-risk items with thorough test coverage requirements, and schedule refactoring spikes for items needing design exploration.
+8. Track reduction trend over time: maintain a debt ledger with total estimated interest, plot interest reduction sprint-over-sprint, celebrate when annual interest drops below threshold, and flag when new debt outpaces reduction.
+9. Establish debt prevention gates: complexity threshold in CI (fail on cyclomatic > 20), dependency update cadence (monthly minor, quarterly major), test coverage floor (never decrease), and mandatory ADR for deliberate debt.
+10. Log tech-debt audit in AUDIT with: total items found, classification breakdown, top 5 by ROI, sprint budget allocation, and estimated interest reduction.
+</process>

package/.claude/commands/mindforge/tech-radar.md

@@ -0,0 +1,28 @@
+---
+description: "Assess technology for adoption, trial, hold, or retirement. Usage: /mindforge:tech-radar [technology] [--action adopt|trial|assess|hold|retire]"
+---
+
+<objective>
+Evaluate a technology for placement on the project's technology radar, determining whether it should be adopted, trialed, held, assessed, or retired based on ecosystem maturity, team readiness, and strategic fit.
+</objective>
+
+<execution_context>
+@.mindforge/skills/technology-radar/SKILL.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS (technology name, optional --action to force a ring)
+Knowledge: Current tech stack, team skills inventory, existing radar entries, industry benchmarks.
+</context>
+
+<process>
+1. **Identify Technology**: Clarify the technology, its category (language, framework, tool, platform, technique), and the specific use case being evaluated.
+2. **Evaluate Ecosystem Maturity**: Assess release stability, backward compatibility track record, documentation quality, and production usage at scale by known companies.
+3. **Assess Community and Hiring Pool**: Check GitHub stars/activity, Stack Overflow questions, conference presence, and availability of engineers with this skill in the hiring market.
+4. **Check Breaking Change Frequency**: Review the last 12 months of releases for breaking changes, deprecation policy clarity, and migration tooling availability.
+5. **Benchmark Performance**: Compare against current solution on relevant metrics (throughput, latency, bundle size, memory usage). Use published benchmarks and validate with a spike if high-stakes.
+6. **Evaluate Team Skill Gap**: Assess current team proficiency, estimated ramp-up time, training resources available, and whether champions exist internally.
+7. **Determine Ring Placement**: Based on evidence, place in one of: Adopt (proven, use by default), Trial (worth pursuing in a low-risk project), Assess (explore with research), Hold (do not start new usage), Retire (actively migrate away).
+8. **Document Rationale**: Write a radar blip entry with the ring, rationale, evidence links, and date. Include dissenting opinions if any.
+9. **Define Migration Path If Retiring**: If the recommendation is Hold or Retire, document the migration path, estimated effort, and timeline for moving to the replacement.
+</process>

package/.claude/commands/mindforge/threat-model.md

@@ -0,0 +1,48 @@
+---
+description: Run STRIDE/DREAD threat modeling on the current change or specified component. Usage - /mindforge:threat-model [component-path] [--scope full|diff] [--output DFD]
+---
+
+<objective>
+Perform structured threat modeling on a system component using STRIDE methodology
+with DREAD scoring. Identify attack surfaces, trust boundaries, and recommend mitigations.
+</objective>
+
+<execution_context>
+@.mindforge/skills/threat-modeling/SKILL.md
+@.mindforge/personas/threat-modeler.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse arguments: component path (or current diff), --scope (full component or just diff), --output format.
+2. Switch to threat-modeler persona.
+3. **Scope definition:**
+   - If component path provided: analyze that directory/file
+   - If --scope diff: analyze only current uncommitted changes
+   - If no path: analyze most recently modified files
+4. **Data flow mapping:**
+   - Identify entry points (user input, API calls, file uploads)
+   - Identify storage (databases, caches, files)
+   - Identify processing (business logic)
+   - Identify exit points (responses, exports, logs)
+   - Mark ALL trust boundary crossings
+5. **STRIDE analysis:**
+   - For each trust boundary: apply all 6 STRIDE categories
+   - Document each identified threat with concrete example
+6. **DREAD scoring:**
+   - Score each threat (Damage, Reproducibility, Exploitability, Affected Users, Discoverability)
+   - Calculate risk score (average of 5 dimensions)
+   - Classify: Low (1-3), Medium (4-6), High (7-10)
+7. **Attack trees** (for threats scoring 7+):
+   - Build prerequisite chain showing attack path
+   - Identify cheapest path for attacker
+8. **Mitigation recommendations:**
+   - For each threat: recommend specific mitigation
+   - Prioritize by: risk score * ease of fix
+9. Write output to `.planning/THREAT-MODEL-[component]-[timestamp].md`
+10. Log threat model in AUDIT with finding counts by severity.
+11. If any Critical/High findings: flag that these MUST be addressed before shipping.
+</process>

package/.claude/commands/mindforge/tokens.md

@@ -0,0 +1,12 @@
+---
+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/.claude/commands/mindforge/ui-phase.md

@@ -0,0 +1,34 @@
+---
+name: mindforge:ui-phase
+description: Generate a UI Design Contract (UI-SPEC.md) for the current phase
+argument-hint: [N]
+allowed-tools:
+  - view_file
+  - write_to_file
+  - list_dir
+---
+
+<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/.claude/commands/mindforge/ui-review.md

@@ -0,0 +1,36 @@
+---
+name: mindforge:ui-review
+description: Perform a retroactive visual audit of implemented UI against the DESIGN_SYSTEM.md and UI-SPEC.md
+argument-hint: [N]
+allowed-tools:
+  - view_file
+  - write_to_file
+  - read_browser_page
+  - open_browser_url
+---
+
+<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/.claude/commands/mindforge/update.md

@@ -0,0 +1,46 @@
+---
+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/.claude/commands/mindforge/validate-phase.md

@@ -0,0 +1,31 @@
+---
+name: mindforge:validate-phase
+description: Audit the current phase for requirement coverage and test gaps
+argument-hint: [N]
+allowed-tools:
+  - view_file
+  - list_dir
+---
+
+<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/.claude/commands/mindforge/verify-loop.md

@@ -0,0 +1,45 @@
+---
+description: Run the full 6-phase verification gate (Build, Type Check, Lint, Test, Security Scan, Diff Review). Usage - /mindforge:verify-loop [--phase N] [--fix] [--skip-build]
+---
+
+<objective>
+Execute the complete verification pipeline to confirm code is ready to ship.
+Runs 6 sequential quality gates, failing fast on any issue.
+</objective>
+
+<execution_context>
+@.mindforge/skills/verification-loop/SKILL.md
+@.mindforge/engine/verification-pipeline.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse flags: --phase (start from specific phase), --fix (auto-fix where possible), --skip-build.
+2. **Phase 1 — Build** (skip if --skip-build):
+   - Run `npm run build` (or project equivalent)
+   - PASS: zero errors. FAIL: report errors, halt.
+3. **Phase 2 — Type Check:**
+   - Run `npx tsc --noEmit` (or project equivalent)
+   - PASS: zero type errors. FAIL: report errors, halt.
+4. **Phase 3 — Lint:**
+   - Run `npm run lint`
+   - If --fix: run with `--fix` flag first, then re-check
+   - PASS: zero errors. FAIL: report errors, halt.
+5. **Phase 4 — Test:**
+   - Run `npm test`
+   - PASS: zero failures, no skipped tests without reason. FAIL: report failures, halt.
+6. **Phase 5 — Security Scan:**
+   - Grep for hardcoded secrets, dangerous patterns, new vulnerable deps
+   - Apply security-review skill checklist to the diff
+   - PASS: no findings. FAIL: report findings with severity, halt.
+7. **Phase 6 — Diff Review:**
+   - Run `git diff --staged` or `git diff main...HEAD`
+   - Check for: debug code, unintended changes, sensitive data, logic errors
+   - PASS: clean diff. FAIL: flag specific lines, halt.
+8. On any failure: report which phase failed, what the error is, suggest fix.
+9. On all pass: report "All 6 verification gates passed. Safe to proceed."
+10. Log verification result in AUDIT with per-phase timing.
+</process>

package/.claude/commands/mindforge/verify-phase.md

@@ -0,0 +1,66 @@
+---
+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/.claude/commands/mindforge/vibe-check.md

@@ -0,0 +1,37 @@
+---
+description: Quick security assessment across 7 attack domains in 2-5 minutes. Usage - /mindforge:vibe-check [path] [--domain web|api|cli|all] [--headers-only]
+---
+
+<objective>
+Rapid security gut-check covering the most common vulnerability categories.
+Faster than full threat modeling — catches 80% of issues in 20% of the time.
+</objective>
+
+<execution_context>
+@.mindforge/skills/vibe-security/SKILL.md
+@.mindforge/skills/security-review/SKILL.md
+</execution_context>
+
+<context>
+$ARGUMENTS
+</context>
+
+<process>
+1. Parse target path (default: current diff) and domain filter (default: all).
+2. If --headers-only: skip code analysis, check security headers only, report.
+3. Identify application type (web app, API, CLI tool, library) to scope checks.
+4. Quick-scan all 7 domains applicable to the type:
+   - Access Control: check for sequential IDs, missing ownership verification, broken authz
+   - XSS: check output encoding, CSP presence, unsafe innerHTML or React raw-HTML usage
+   - CSRF: check token presence, SameSite cookies, state-changing GET requests
+   - SSRF: check URL inputs, allowlists, metadata endpoint blocking
+   - SQL Injection: check for string concatenation in queries, missing parameterization
+   - File Upload: check extension vs magic bytes validation, storage location
+   - Path Traversal: check user input in file paths, canonicalization
+5. Check security headers: HSTS, CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
+6. Check for common IP bypass patterns if SSRF-relevant code found.
+7. Classify findings by severity: LOW / MEDIUM / HIGH / CRITICAL.
+8. If any HIGH/CRITICAL: recommend escalating to `/mindforge:threat-model` for full analysis.
+9. Write VIBE-SECURITY-CHECK.md to `.planning/` with findings + remediation.
+10. Log vibe-check event in AUDIT. Total time target: under 5 minutes.
+</process>

package/.claude/commands/mindforge/workspace.md

@@ -0,0 +1,33 @@
+---
+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.