@sugar-crash-studios/vibe-forge 0.4.0

package/tasks/completed/SEC-006-eval-agent-names.md

@@ -0,0 +1,55 @@
+---
+id: SEC-006
+title: "Validate agent names to prevent shell injection via eval"
+type: security
+priority: medium
+assigned_to: aegis
+created_at: 2026-01-16T00:00:00Z
+created_by: scribe-docs-migration
+---
+
+## Summary
+The load_agents_from_json() function uses eval on agent data which could allow shell command execution if agents.json is compromised.
+
+## Current State
+From docs/TODO.md (M-1 - Medium Priority):
+> **eval() of external data in load_agents_from_json()**
+> File: `bin/lib/config.sh` line 95
+> Issue: If agents.json is compromised, malicious agent names could execute shell commands via `eval "$agent_data"`
+> Fix: Add input validation in Node.js script to reject agent names containing shell metacharacters
+
+## Affected Files
+- `bin/lib/config.sh` line 95
+
+## Proposed Fix
+Add input validation in the Node.js script that processes agents.json to reject agent names containing:
+- Shell metacharacters (`;`, `|`, `&`, `$`, backticks, etc.)
+- Newlines
+- Quotes
+
+Alternatively, refactor to avoid eval entirely by using a safer approach to populate the agent data.
+
+## Acceptance Criteria
+- [x] Agent names validated before eval
+- [x] Shell metacharacters rejected with clear error message
+- [x] No change to legitimate agent names
+- [x] Test coverage for injection attempts
+
+## Resolution
+
+**Status: Already Fixed**
+
+The validation was implemented as part of SEC-001 security fixes:
+
+1. **`bin/lib/config.sh`** lines 47-86 contain:
+   - `isValidIdentifier()` function that validates against `^[a-z0-9_-]+$`
+   - Validation of all agent names before processing
+   - Validation of all aliases
+   - `escapeForShell()` for display names, roles, and other string values
+
+2. **Test coverage** exists in `tests/unit/agents.test.js`:
+   - `should reject command injection attempt` (line 89)
+   - `should reject backtick injection` (line 94)
+   - `should reject path traversal attempt` (line 84)
+
+No additional changes required.

package/tasks/completed/SEC-007-spawn-escaping.md

@@ -0,0 +1,67 @@
+---
+id: SEC-007
+title: "Escape variables in Windows Terminal spawn command"
+type: security
+priority: low
+assigned_to: aegis
+created_at: 2026-01-16T00:00:00Z
+created_by: scribe-docs-migration
+---
+
+## Summary
+Variables passed to Windows Terminal command are not properly escaped for nested shell invocation.
+
+## Current State
+From docs/TODO.md (L-1 - Low Priority):
+> **Windows Terminal command escaping**
+> File: `bin/forge-spawn.sh` lines 55-57
+> Issue: `$display_name` and `$FORGE_ROOT` not escaped for nested shell invocation
+> Fix: Use `printf %q` for proper escaping
+
+Current code:
+```bash
+wt.exe "${wt_args[@]}" "$bash_path" -c "cd \"$win_forge_root\" && ./bin/forge.sh start \"$agent\""
+```
+
+The `$win_forge_root` and other variables could contain characters that break the nested shell command.
+
+## Affected Files
+- `bin/forge-spawn.sh` lines 55-57 (and nearby)
+
+## Proposed Fix
+Use `printf %q` to properly escape variables before embedding in the command string:
+```bash
+escaped_path=$(printf %q "$win_forge_root")
+escaped_agent=$(printf %q "$agent")
+wt.exe "${wt_args[@]}" "$bash_path" -c "cd $escaped_path && ./bin/forge.sh start $escaped_agent"
+```
+
+## Risk Assessment
+Low risk because:
+- $agent is already validated through resolve_agent whitelist
+- $FORGE_ROOT is set from script directory, not user input
+
+Still worth fixing for defense in depth.
+
+## Acceptance Criteria
+- [x] Variables properly escaped with printf %q
+- [x] Works with paths containing spaces
+- [x] Works with paths containing special characters
+- [ ] Test on Windows with various path types (manual testing required)
+
+## Resolution
+
+**Status: Fixed**
+
+Updated `bin/forge-spawn.sh` lines 76-87 to use `printf %q` for proper escaping:
+
+```bash
+# SECURITY: Use printf %q to properly escape paths for nested shell invocation
+local escaped_path escaped_agent
+escaped_path=$(printf %q "$win_forge_root")
+escaped_agent=$(printf %q "$agent")
+
+wt.exe "${wt_args[@]}" "$bash_path" -c "cd $escaped_path && ./bin/forge.sh start $escaped_agent"
+```
+
+This ensures paths with spaces, special characters, or shell metacharacters are properly escaped for the nested shell invocation.

package/tasks/completed/TASK-DASH-001-server-infrastructure.md

@@ -0,0 +1,185 @@
+---
+id: TASK-DASH-001
+title: "Dashboard Server Infrastructure (Phase 1A)"
+type: feature
+priority: critical
+status: completed
+created_at: 2026-01-16T22:00:00Z
+created_by: planning-hub
+assigned_to: furnace
+parent: FEATURE-001
+completed_at: 2026-01-16T22:30:00Z
+completed_by: furnace
+---
+
+# Dashboard Server Infrastructure (Phase 1A)
+
+## Summary
+
+Scaffold the dashboard server infrastructure as the first phase of FEATURE-001-dashboard-mvp.
+
+## Requirements
+
+Create standalone HTTP + WebSocket server that can be tested independently:
+
+1. `bin/dashboard/server.js` - HTTP + WebSocket server using Node.js built-in http module + ws package
+2. `bin/dashboard/api/tasks.js` - API endpoint for listing tasks from tasks/ directory
+3. `bin/dashboard/api/agents.js` - API endpoint for agent status from context/agent-status/
+4. `bin/dashboard/api/dispatch.js` - API endpoint to create task files
+5. `bin/dashboard/public/index.html` - Basic placeholder
+6. Add `ws` to package.json devDependencies
+
+## Technical Details
+
+### Server Configuration
+- Default port: 5555 (configurable via DASHBOARD_PORT env or config)
+- Host: localhost (configurable)
+- Serve static files from public/
+- REST API at /api/*
+- WebSocket at /ws for real-time updates
+
+### API Endpoints
+```
+GET  /api/tasks              # List all tasks by status
+GET  /api/tasks/:id          # Get task details
+POST /api/tasks              # Create new task (for dispatch)
+GET  /api/agents             # List agents and their status
+POST /api/dispatch           # Dispatch agent for a task
+WS   /ws                     # Real-time updates
+```
+
+## Scope
+
+- DO NOT integrate with daemon yet
+- Standalone server for independent testing
+- Read from existing SQLite database or task files
+
+## Acceptance Criteria
+
+- [x] Server starts on port 5555
+- [x] GET /api/tasks returns task list
+- [x] GET /api/agents returns agent status
+- [x] POST /api/dispatch creates task file
+- [x] WebSocket connection established at /ws
+- [x] Static files served from public/
+- [x] ws package added to devDependencies
+
+---
+
+## Completion Summary
+
+completed_by: furnace
+completed_at: 2026-01-16T22:30:00Z
+duration_minutes: 30
+
+### Files Created
+
+- `bin/dashboard/server.js` - Main HTTP + WebSocket server (280 lines)
+- `bin/dashboard/api/tasks.js` - Task listing and creation API (220 lines)
+- `bin/dashboard/api/agents.js` - Agent status API (215 lines)
+- `bin/dashboard/api/dispatch.js` - Task dispatch API (310 lines)
+- `bin/dashboard/public/index.html` - Placeholder dashboard UI (370 lines)
+
+### Files Modified
+
+- `package.json` - Added `ws` ^8.18.0 to devDependencies
+
+### API Endpoints Implemented
+
+- `GET /api/health` - Server health check
+- `GET /api/tasks` - List all tasks grouped by status (pending, in-progress, review, completed)
+- `GET /api/tasks/:id` - Get single task details with full body
+- `POST /api/tasks` - Create new task file
+- `GET /api/agents` - List all agents with status, icon, role metadata
+- `POST /api/dispatch` - Create task file for agent dispatch
+
+### Dispatch Types Supported
+
+- `stale-docs` - Stale documentation detection
+- `failing-test` - Test failure dispatch
+- `security-issue` - Security vulnerability dispatch
+- `low-coverage` - Low test coverage dispatch
+- `todo-fixme` - TODO/FIXME marker dispatch
+- `pending-review` - Pending PR review dispatch
+- `custom` - Custom task dispatch
+
+### Features
+
+1. **HTTP Server**
+   - Static file serving with security (path traversal prevention)
+   - CORS headers for local development
+   - JSON request/response handling
+   - Request logging
+
+2. **WebSocket Server**
+   - Real-time connection at `/ws`
+   - Ping/pong support
+   - Broadcast function for real-time updates
+   - Graceful reconnection in client
+
+3. **Tasks API**
+   - Parses YAML frontmatter from markdown task files
+   - Groups tasks by directory (pending, in-progress, review, completed)
+   - Sorts by priority (critical > high > medium > low)
+   - Summary stats (total, by status)
+
+4. **Agents API**
+   - Reads from JSON status files in `context/agent-status/`
+   - Falls back to SQLite database if available
+   - Includes agent metadata (icon, role, color) from personality files
+   - Lists all known agents even if status file missing
+
+5. **Dispatch API**
+   - Creates properly formatted task files
+   - Auto-generates task IDs with type prefixes
+   - Suggests appropriate agent based on file type
+   - Broadcasts task creation via WebSocket
+
+### Usage
+
+```bash
+# Start server (default port 5555)
+node bin/dashboard/server.js
+
+# Custom port
+node bin/dashboard/server.js --port 3000
+DASHBOARD_PORT=3000 node bin/dashboard/server.js
+
+# Custom host
+node bin/dashboard/server.js --host 0.0.0.0
+
+# Help
+node bin/dashboard/server.js --help
+```
+
+### Testing
+
+Server can be tested independently:
+
+```bash
+# Install ws dependency
+npm install
+
+# Start server
+node bin/dashboard/server.js
+
+# Test endpoints
+curl http://localhost:5555/api/health
+curl http://localhost:5555/api/tasks
+curl http://localhost:5555/api/agents
+
+# Test dispatch
+curl -X POST http://localhost:5555/api/dispatch \
+  -H "Content-Type: application/json" \
+  -d '{"type": "stale-docs", "target": "README.md", "agent": "scribe"}'
+```
+
+### Notes
+
+- Server uses Node.js built-in `http` module (no Express dependency)
+- WebSocket gracefully degrades if `ws` package not installed
+- Agents API tries SQLite first, falls back to JSON files
+- All task files use standard YAML frontmatter format
+- Placeholder UI includes dark mode styling per FEATURE-001 spec
+
+ready_for_review: true

package/tasks/completed/TASK-anvil-001-dashboard-frontend.md

@@ -0,0 +1,133 @@
+---
+id: TASK-anvil-001
+title: "Dashboard Frontend MVP Implementation"
+type: task
+priority: critical
+status: completed
+created_at: 2026-01-16T21:30:00Z
+created_by: planning-hub
+assigned_to: anvil
+parent_feature: FEATURE-001
+completed_at: 2026-01-16T22:15:00Z
+---
+
+# Dashboard Frontend MVP Implementation
+
+## Summary
+
+Build the complete frontend UI for the Vibe Forge Dashboard based on Pixel's wireframes.
+
+## Acceptance Criteria
+
+- [x] Three-panel layout: Tasks, Agents, Notifications
+- [x] Issues panel with dispatch buttons (the killer feature)
+- [x] Dark mode by default with light mode toggle
+- [x] CSS variables for theming per Pixel's spec
+- [x] WebSocket connection for real-time updates
+- [x] Keyboard shortcuts (1-4 panels, j/k nav, d dispatch)
+- [x] Responsive design (desktop, tablet, mobile)
+- [x] Accessible (ARIA labels, focus indicators, keyboard nav)
+- [x] Loading, empty, and error states
+- [x] Dispatch confirmation modal
+- [x] Toast notifications for feedback
+
+## Completion Summary
+
+completed_by: anvil
+completed_at: 2026-01-16T22:15:00Z
+duration_minutes: 45
+
+### Files Created
+
+- `bin/dashboard/public/index.html` (created - 335 lines)
+  - Semantic HTML5 structure with ARIA landmarks
+  - Skip links for accessibility
+  - Connection lost banner
+  - Header with logo and theme toggle
+  - Four panels: Tasks, Agents, Notifications, Issues
+  - Dispatch confirmation modal
+  - Keyboard shortcuts help modal
+  - Toast notification container
+  - Mobile tab bar navigation
+
+- `bin/dashboard/public/style.css` (created - 1100+ lines)
+  - CSS custom properties for theming (dark mode default)
+  - Light mode color scheme
+  - Full WCAG AA compliant contrast ratios
+  - Agent-specific colors per Pixel's spec
+  - Issue category colors
+  - Card, panel, and modal styles
+  - Button variants (primary, secondary, dispatch)
+  - Loading skeletons with shimmer animation
+  - Empty and error states
+  - Toast notifications
+  - Responsive breakpoints (desktop, tablet, mobile)
+  - Focus indicators for keyboard navigation
+  - Print styles
+
+- `bin/dashboard/public/app.js` (created - 900+ lines)
+  - WebSocket connection with auto-reconnect
+  - API fetch functions for tasks, agents, issues
+  - Dispatch flow implementation (POST /api/dispatch)
+  - Dynamic rendering of all panels
+  - Task filtering by status (pending, in-progress, review, done)
+  - Keyboard shortcuts (1-4 panel focus, j/k navigation, d dispatch, t theme, ? help)
+  - Theme toggle with localStorage persistence
+  - Toast notification system
+  - Focus trap for modals
+  - Mobile panel switching
+  - Mock issues data for demonstration
+
+### Key Features Implemented
+
+1. **Four-Panel Layout**
+   - Tasks panel with Kanban-style filters
+   - Agents panel with status indicators
+   - Notifications panel with grouping by date
+   - Issues panel (the killer feature) with dispatch buttons
+
+2. **Dispatch Flow**
+   - Click [Dispatch Agent] on any issue
+   - Confirmation modal shows task preview
+   - POST to /api/dispatch on confirm
+   - Success toast notification
+   - Issue removed from panel
+   - Task appears in Tasks panel via WebSocket
+
+3. **Dark Mode**
+   - Default theme per Pixel's spec
+   - CSS variables for all colors
+   - 200ms transition on theme change
+   - Theme persisted in localStorage
+
+4. **Keyboard Shortcuts**
+   - `1-4` to focus panels
+   - `j/k` to navigate items
+   - `Enter` to expand/select
+   - `d` to dispatch selected issue
+   - `r` to refresh current panel
+   - `t` to toggle theme
+   - `?` to show help modal
+   - `Escape` to close modals
+
+5. **Responsive Design**
+   - Desktop: 3-column top row, full-width issues
+   - Tablet: 2-column layout
+   - Mobile: Single panel with bottom tab bar
+
+6. **Accessibility**
+   - Skip links
+   - ARIA landmarks and labels
+   - Focus indicators
+   - Screen reader announcements
+   - Keyboard navigation throughout
+
+### Notes
+
+- Mock issues data provided for demonstration since /api/issues endpoint may not exist yet
+- WebSocket reconnects automatically with exponential backoff
+- Connection banner shows after 3 failed reconnect attempts
+- All animations follow Pixel's timing guidelines (150ms-300ms)
+- Used vanilla JS to keep bundle lightweight per requirements
+
+ready_for_review: true

package/tasks/completed/review-bmad-aegis.md

@@ -0,0 +1,89 @@
+---
+id: review-bmad-aegis
+title: "BMAD vs Vibe Forge: Security Review"
+type: review
+priority: high
+status: completed
+assigned_to: aegis
+blocked_by: []
+depends_on: []
+created: 2026-03-31T00:00:00-05:00
+updated: 2026-03-31T00:00:00-05:00
+estimated_complexity: medium
+epic: BMAD-REVIEW
+---
+
+# Context
+
+## Background
+We are doing a comprehensive comparison of Vibe Forge (this framework) against BMAD-METHOD (https://github.com/bmad-code-org/BMAD-METHOD) to identify gaps and improvements to bring into Vibe Forge.
+
+You are Aegis - the security specialist. Your job is to review BOTH frameworks through the lens of: security posture, agent authorization boundaries, prompt injection risks, secret handling, and how well each framework prevents agents from doing harmful things.
+
+## Your Review Focus
+1. **Agent authorization** - Does BMAD have a better model for what agents are/aren't allowed to do? How are boundaries enforced?
+2. **Prompt injection** - Are there prompt injection risks in either framework's agent design? Can a malicious task file compromise an agent?
+3. **Secret handling** - How does each framework handle secrets, tokens, API keys in agent context?
+4. **Shell script security** - Review Vibe Forge's bash scripts for injection vulnerabilities, unsafe evals, etc.
+5. **Task file trust** - Should agents trust task files completely? What validation exists?
+6. **Least privilege** - Does BMAD enforce least privilege for agents better than Vibe Forge?
+7. **Audit trail** - Does BMAD have better logging/auditing of agent actions?
+8. **Security agent design** - Compare your own personality to BMAD's security guidance. What's missing?
+
+## Files to Read
+- /agents/aegis/personality.md (your own definition)
+- /bin/forge-daemon.sh (check for security issues)
+- /bin/lib/config.sh (already has security notes - evaluate them)
+- /bin/forge-spawn.sh (validate security handling)
+- /config/agents.json
+- Then fetch and read BMAD: https://github.com/bmad-code-org/BMAD-METHOD
+
+---
+
+# Acceptance Criteria
+
+- [ ] Read all scripts with a security focus
+- [ ] Fetch and review BMAD repo
+- [ ] Identify any actual security vulnerabilities in Vibe Forge scripts
+- [ ] Compare agent authorization models
+- [ ] Write findings to tasks/review/bmad-review-aegis.md
+
+---
+
+# Agent Instructions
+
+Aegis: Assume breach. Question everything. Find the vulnerability that everyone else missed. Pay special attention to the eval in config.sh and any other dynamic execution.
+
+**Boundaries:**
+- DO read: all scripts, agent files, BMAD repo (via web fetch)
+- DO write: tasks/review/bmad-review-aegis.md
+- DO NOT modify: any framework files
+
+**On Completion:**
+1. Write your findings to tasks/review/bmad-review-aegis.md
+2. Move this file to /tasks/completed/
+
+---
+
+# Output Expected
+
+- [ ] tasks/review/bmad-review-aegis.md created with findings
+- [ ] Any actual vulnerabilities identified
+- [ ] Agent authorization model comparison
+
+---
+
+# Completion Summary
+```yaml
+completed_by: aegis
+completed_at: 2026-03-31T00:00:00Z
+files_created:
+  - tasks/review/bmad-review-aegis.md
+notes: >
+  1 HIGH (CI script injection via github.head_ref), 1 MEDIUM (eval in config.sh),
+  1 MEDIUM (dangerous eval example in json.sh comment), 3 LOW findings.
+  BMAD has no security specialist agent and minimal shell scripting.
+  Vibe Forge shell scripts are significantly more security-conscious than BMAD.
+  Both frameworks share the same fundamental weakness: agent authorization is
+  entirely behavioral (prompt-based), not technically enforced.
+```

package/tasks/completed/review-bmad-anvil.md

@@ -0,0 +1,80 @@
+---
+id: review-bmad-anvil
+title: "BMAD vs Vibe Forge: Frontend/UI Tooling Review"
+type: review
+priority: high
+status: completed
+assigned_to: anvil
+blocked_by: []
+depends_on: []
+created: 2026-03-31T00:00:00-05:00
+updated: 2026-03-31T00:00:00-05:00
+estimated_complexity: medium
+epic: BMAD-REVIEW
+---
+
+# Context
+
+## Background
+We are doing a comprehensive comparison of Vibe Forge (this framework) against BMAD-METHOD (https://github.com/bmad-code-org/BMAD-METHOD) to identify gaps and improvements to bring into Vibe Forge.
+
+You are Anvil - the frontend dev perspective. Your job is to review BOTH frameworks specifically through the lens of: developer experience, UI tooling, dashboard design, frontend agent capabilities, and how well each framework supports frontend-heavy projects.
+
+## Your Review Focus
+1. **Dashboard** - How does Vibe Forge's dashboard (bin/dashboard/) compare in concept/quality to anything BMAD provides for UI?
+2. **Frontend agent** - Compare Anvil's (your own) personality/capabilities vs BMAD's equivalent frontend agent. What does BMAD do better?
+3. **Frontend project support** - How well does each framework scaffold and support frontend projects (React, Vue, etc.)?
+4. **Developer UX** - Which framework has better DX for a frontend developer using it day-to-day?
+5. **Templates** - Are there frontend-specific templates in BMAD that Vibe Forge lacks?
+6. **Component/UI patterns** - Does BMAD have opinions on UI architecture that Vibe Forge should adopt?
+
+## Files to Read
+- /agents/anvil/personality.md (your own definition)
+- /agents/pixel/personality.md (if exists - UX agent)
+- /bin/dashboard/ (current dashboard implementation)
+- /config/agents.json (agent config)
+- Then fetch and read BMAD: https://github.com/bmad-code-org/BMAD-METHOD
+
+---
+
+# Acceptance Criteria
+
+- [ ] Read your own personality file and BMAD's equivalent agent
+- [ ] Fetch and review the BMAD repo
+- [ ] Identify 3-5 specific improvements Vibe Forge should make for frontend support
+- [ ] Call out anything BMAD does worse (so we don't copy mistakes)
+- [ ] Write findings to tasks/review/bmad-review-anvil.md
+
+---
+
+# Agent Instructions
+
+Anvil: Review both frameworks from a frontend developer's perspective. Be specific - reference actual files and line numbers. Don't just say "BMAD is better at X" - show WHY with examples from the actual files.
+
+**Boundaries:**
+- DO read: all agent files, dashboard code, BMAD repo (via web fetch)
+- DO write: tasks/review/bmad-review-anvil.md (your findings report)
+- DO NOT modify: any framework files (read-only review)
+
+**On Completion:**
+1. Write your findings to tasks/review/bmad-review-anvil.md
+2. Move this file to /tasks/completed/
+
+---
+
+# Output Expected
+
+- [ ] tasks/review/bmad-review-anvil.md created with findings
+- [ ] Specific, actionable improvement recommendations
+- [ ] Honest assessment of Vibe Forge weaknesses
+
+---
+
+# Completion Summary
+```yaml
+completed_by: anvil
+completed_at: 2026-04-02T00:00:00-05:00
+files_created:
+  - tasks/review/bmad-review-anvil.md
+notes: "Dashboard code reviewed in full (27 files). BMAD UX designer agent (Sally) and create-ux-design skill fetched and compared. 5 actionable recommendations produced."
+```

package/tasks/completed/review-bmad-crucible.md

@@ -0,0 +1,81 @@
+---
+id: review-bmad-crucible
+title: "BMAD vs Vibe Forge: Quality & Testing Framework Review"
+type: review
+priority: high
+status: completed
+assigned_to: crucible
+blocked_by: []
+depends_on: []
+created: 2026-03-31T00:00:00-05:00
+updated: 2026-03-31T00:00:00-05:00
+estimated_complexity: medium
+epic: BMAD-REVIEW
+---
+
+# Context
+
+## Background
+We are doing a comprehensive comparison of Vibe Forge (this framework) against BMAD-METHOD (https://github.com/bmad-code-org/BMAD-METHOD) to identify gaps and improvements to bring into Vibe Forge.
+
+You are Crucible - the QA/testing specialist. Your job is to review BOTH frameworks through the lens of: quality gates, testing philosophy, validation mechanisms, acceptance criteria design, and how well each framework enforces quality.
+
+## Your Review Focus
+1. **QA agent** - Compare your own personality/capabilities vs BMAD's equivalent. What does BMAD's QA approach do that yours doesn't?
+2. **Quality gates** - Does BMAD have explicit quality gates or checkpoints that Vibe Forge lacks?
+3. **Acceptance criteria patterns** - How does BMAD structure acceptance criteria in tasks vs Vibe Forge's template? What makes BMAD's criteria more testable?
+4. **Test coverage enforcement** - Does BMAD have mechanisms to ensure agents write tests? How does it compare to Vibe Forge?
+5. **Review workflow** - How does Sentinel (code reviewer) compare to BMAD's review equivalent?
+6. **Definition of Done** - Does BMAD have a more rigorous "done" standard than Vibe Forge?
+7. **Bug tracking** - How does each framework handle bug reports, reproduction steps, and regression prevention?
+
+## Files to Read
+- /agents/crucible/personality.md (your own definition)
+- /agents/sentinel/personality.md (reviewer)
+- /config/task-template.md (look at acceptance criteria section)
+- /tests/ (existing tests for the framework itself)
+- Then fetch and read BMAD: https://github.com/bmad-code-org/BMAD-METHOD
+
+---
+
+# Acceptance Criteria
+
+- [ ] Read your own personality file and BMAD's QA equivalent
+- [ ] Fetch and review the BMAD repo
+- [ ] Identify quality gate gaps in Vibe Forge
+- [ ] Evaluate how acceptance criteria compares
+- [ ] Write findings to tasks/review/bmad-review-crucible.md
+
+---
+
+# Agent Instructions
+
+Crucible: Be skeptical of both frameworks. Find the holes. What happens when an agent marks a task complete without writing tests? What prevents bad PRs from merging? Look for the absence of safeguards, not just their presence.
+
+**Boundaries:**
+- DO read: all agent files, task templates, tests/, BMAD repo (via web fetch)
+- DO write: tasks/review/bmad-review-crucible.md
+- DO NOT modify: any framework files
+
+**On Completion:**
+1. Write your findings to tasks/review/bmad-review-crucible.md
+2. Move this file to /tasks/completed/
+
+---
+
+# Output Expected
+
+- [ ] tasks/review/bmad-review-crucible.md created with findings
+- [ ] Quality gate gap analysis
+- [ ] Specific recommendations for enforcement mechanisms
+
+---
+
+# Completion Summary
+```yaml
+completed_by: crucible
+completed_at: 2026-03-31T00:00:00Z
+files_created:
+  - tasks/review/bmad-review-crucible.md
+notes: "Reviewed Crucible vs Quinn, Sentinel vs BMAD code review, DoD, test enforcement, adversarial review skills, automated gates. 10 gaps identified, ranked by severity. Critical gaps: no formal DoD, no automated quality gates."
+```