diff --git a/.archon/workflows/defaults/archon-fix-github-issue.yaml b/.archon/workflows/defaults/archon-fix-github-issue.yaml index 69112edbe9..2c3f554a89 100644 --- a/.archon/workflows/defaults/archon-fix-github-issue.yaml +++ b/.archon/workflows/defaults/archon-fix-github-issue.yaml @@ -161,7 +161,14 @@ nodes: elif [ -f "$ARTIFACTS_DIR/investigation.md" ]; then echo "investigation.md exists from investigate step" else - echo "WARNING: No investigation.md or plan.md found — implement may fail" + # Fail, do not warn. investigate/plan can "succeed" while producing no + # artifact — an AI node that declines the task still exits 0, so the + # refusal reads downstream as a completed investigation. This node holds + # the only cheap deterministic view of that precondition, so it is where + # the run has to stop, before implement spends a model on nothing. + echo "bridge-artifacts: neither investigation.md nor plan.md exists in \$ARTIFACTS_DIR." >&2 + echo "The investigate/plan phase produced no specification — implement has nothing to work from." >&2 + exit 1 fi depends_on: [investigate, plan] trigger_rule: one_success diff --git a/.archon/workflows/experimental/archon-fix-github-issue-experimental.yaml b/.archon/workflows/experimental/archon-fix-github-issue-experimental.yaml index 4ec2563176..8d4b146d3e 100644 --- a/.archon/workflows/experimental/archon-fix-github-issue-experimental.yaml +++ b/.archon/workflows/experimental/archon-fix-github-issue-experimental.yaml @@ -523,6 +523,11 @@ nodes: # pass. (Workflow constitution: the reliability carve-out, not a style rule.) - id: capture-pr-number bash: | + # Clear first so .pr-number reflects THIS validation and nothing earlier. + # pr-exists treats the file's presence as authoritative, so a stale one + # left by a prior attempt would send the review tail at a PR that is no + # longer there. + rm -f "$ARTIFACTS_DIR/.pr-number" "$ARTIFACTS_DIR/.pr-url" pr=$(gh pr view --json number --jq .number 2>/dev/null || true) if ! printf '%s' "$pr" | grep -qE '^[0-9]+$'; then echo "capture-pr-number: no PR resolves for the current branch." >&2 diff --git a/packages/workflows/src/defaults/bundled-defaults.generated.ts b/packages/workflows/src/defaults/bundled-defaults.generated.ts index 561e6be221..b4ee8ff5f7 100644 --- a/packages/workflows/src/defaults/bundled-defaults.generated.ts +++ b/packages/workflows/src/defaults/bundled-defaults.generated.ts @@ -62,7 +62,7 @@ export const BUNDLED_WORKFLOWS: Record = { "archon-comprehensive-pr-review": "name: archon-comprehensive-pr-review\ndescription: |\n Use when: User wants a comprehensive code review of a pull request with automatic fixes.\n Triggers: \"review this PR\", \"review PR #123\", \"comprehensive review\", \"full PR review\",\n \"review and fix\", \"check this PR\", \"code review\".\n Does: Syncs PR with main (rebase if needed) -> runs 5 specialized review agents in parallel ->\n synthesizes findings -> auto-fixes CRITICAL/HIGH issues -> reports remaining issues.\n NOT for: Quick questions about a PR, checking CI status, simple \"what changed\" queries.\n\n This workflow produces artifacts in $ARTIFACTS_DIR/../reviews/pr-{number}/ and posts\n a comprehensive review comment to the GitHub PR.\n\nnodes:\n - id: scope\n command: archon-pr-review-scope\n\n - id: sync\n command: archon-sync-pr-with-main\n depends_on: [scope]\n\n - id: code-review\n command: archon-code-review-agent\n depends_on: [sync]\n\n - id: error-handling\n command: archon-error-handling-agent\n depends_on: [sync]\n\n - id: test-coverage\n command: archon-test-coverage-agent\n depends_on: [sync]\n\n - id: comment-quality\n command: archon-comment-quality-agent\n depends_on: [sync]\n\n - id: docs-impact\n command: archon-docs-impact-agent\n depends_on: [sync]\n\n - id: synthesize\n command: archon-synthesize-review\n depends_on: [code-review, error-handling, test-coverage, comment-quality, docs-impact]\n trigger_rule: one_success\n\n - id: implement-fixes\n command: archon-implement-review-fixes\n depends_on: [synthesize]\n", "archon-create-issue": "name: archon-create-issue\ndescription: |\n Use when: User wants to report a bug or problem as a GitHub issue with automated reproduction.\n Triggers: \"create issue\", \"file a bug\", \"report this bug\", \"open an issue for\",\n \"create github issue\", \"report issue\", \"log this bug\".\n Does: Classifies problem area (haiku) -> gathers context in parallel (templates, git state, duplicates) ->\n investigates relevant code -> reproduces the issue using area-specific tools (agent-browser, CLI, DB queries) ->\n gates on reproduction success -> creates issue with full evidence OR reports back if cannot reproduce.\n NOT for: Feature requests, enhancements, or non-bug work. Only for bugs/problems.\n\n Reproduction gating: If the issue cannot be reproduced, the workflow does NOT create an issue.\n Instead, it reports what was tried and suggests next steps to the user.\n\nnodes:\n # ═══════════════════════════════════════════════════════════════\n # PHASE 1: CLASSIFY — Haiku classification of user's problem\n # ═══════════════════════════════════════════════════════════════\n\n - id: classify\n prompt: |\n You are a problem classifier for the Archon codebase. Analyze the user's\n description and determine the issue type and which area of the system is affected.\n\n ## User's Description\n $ARGUMENTS\n\n ## Area Definitions\n | Area | Packages | Indicators |\n |------|----------|------------|\n | web-ui | @archon/web, @archon/server (routes, web adapter) | UI rendering, SSE streaming, React components, browser behavior |\n | api-server | @archon/server (routes, middleware) | HTTP endpoints, response codes, request handling |\n | cli | @archon/cli | CLI commands, workflow invocation from terminal, output formatting |\n | isolation | @archon/isolation, @archon/git | Worktrees, branch operations, cleanup, environment lifecycle |\n | workflows | @archon/workflows | YAML parsing, DAG execution, variable substitution, node types |\n | database | @archon/core (db/) | SQLite/PostgreSQL queries, schema, data integrity, migrations |\n | adapters | @archon/adapters | Slack/Telegram/GitHub/Discord message handling, auth, polling |\n | core | @archon/core (orchestrator, handlers, clients) | Message routing, session management, AI client streaming |\n | other | Any package not covered above | Cross-cutting concerns, build tooling, config, unknown area |\n\n ## Classification Rules\n - Choose the MOST SPECIFIC area. \"SSE disconnects\" = web-ui (not api-server).\n - If ambiguous between two areas, pick the one closer to the user-facing symptom.\n - Use \"other\" only when the problem genuinely doesn't fit any specific area.\n - needs_server: Set to \"true\" if reproducing requires a running Archon server.\n Typically true for: web-ui, api-server, core, adapters.\n Typically false for: cli, isolation, workflows, database.\n For \"other\": use your judgment based on the description.\n - repro_hint: Extract the user's reproduction steps into a concise instruction.\n If no explicit steps given, infer the most likely way to trigger the issue.\n\n Provide reasoning for your classification.\n model: small\n allowed_tools: []\n output_format:\n type: object\n properties:\n type:\n type: string\n enum: [\"bug\", \"regression\", \"crash\", \"performance\", \"configuration\"]\n area:\n type: string\n enum: [\"web-ui\", \"api-server\", \"cli\", \"isolation\", \"workflows\", \"database\", \"adapters\", \"core\", \"other\"]\n title:\n type: string\n keywords:\n type: string\n repro_hint:\n type: string\n needs_server:\n type: string\n enum: [\"true\", \"false\"]\n required: [type, area, title, keywords, repro_hint, needs_server]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 2: PARALLEL CONTEXT GATHERING\n # ═══════════════════════════════════════════════════════════════\n\n - id: fetch-template\n bash: |\n # Search for GitHub issue templates in standard locations\n TEMPLATES_FOUND=0\n\n # Check for issue template directory (YAML-based templates)\n if [ -d \".github/ISSUE_TEMPLATE\" ]; then\n echo \"=== Issue Templates Found ===\"\n for f in .github/ISSUE_TEMPLATE/*.md .github/ISSUE_TEMPLATE/*.yaml .github/ISSUE_TEMPLATE/*.yml; do\n if [ -f \"$f\" ]; then\n TEMPLATES_FOUND=$((TEMPLATES_FOUND + 1))\n echo \"--- Template: $f ---\"\n cat \"$f\"\n echo \"\"\n fi\n done\n fi\n\n # Check for single issue template\n for f in .github/ISSUE_TEMPLATE.md docs/ISSUE_TEMPLATE.md; do\n if [ -f \"$f\" ]; then\n TEMPLATES_FOUND=$((TEMPLATES_FOUND + 1))\n echo \"--- Template: $f ---\"\n cat \"$f\"\n fi\n done\n\n if [ \"$TEMPLATES_FOUND\" -eq 0 ]; then\n echo \"No issue templates found — will use standard format\"\n fi\n depends_on: [classify]\n\n - id: git-context\n bash: |\n echo \"=== Branch ===\"\n git branch --show-current\n\n echo \"=== Recent Commits (last 15) ===\"\n git log --oneline -15\n\n echo \"=== Working Tree Status ===\"\n git status --short\n\n echo \"=== Modified Files (last 3 commits) ===\"\n git diff --name-only HEAD~3..HEAD 2>/dev/null || echo \"(fewer than 3 commits)\"\n\n echo \"=== Environment ===\"\n echo \"Node: $(node --version 2>/dev/null || echo 'N/A')\"\n echo \"Bun: $(bun --version 2>/dev/null || echo 'N/A')\"\n echo \"OS: $(uname -s 2>/dev/null || echo 'Windows') $(uname -r 2>/dev/null || ver 2>/dev/null || echo '')\"\n echo \"Platform: $(uname -m 2>/dev/null || echo 'unknown')\"\n depends_on: [classify]\n\n - id: dedup-check\n bash: |\n KEYWORDS=$classify.output.keywords\n echo \"=== Searching for duplicates: $KEYWORDS ===\"\n\n echo \"--- Open Issues ---\"\n gh issue list --search \"$KEYWORDS\" --state open --limit 5 --json number,title,url,labels 2>/dev/null || echo \"No open matches\"\n\n echo \"--- Recently Closed ---\"\n gh issue list --search \"$KEYWORDS\" --state closed --limit 3 --json number,title,url,labels 2>/dev/null || echo \"No closed matches\"\n depends_on: [classify]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 3: INVESTIGATE — Search codebase for related code\n # ═══════════════════════════════════════════════════════════════\n\n - id: investigate\n prompt: |\n You are a codebase investigator. Search for code related to the reported problem.\n\n ## Problem\n - **Area**: $classify.output.area\n - **Type**: $classify.output.type\n - **Title**: $classify.output.title\n - **Reproduction hint**: $classify.output.repro_hint\n\n ## Git Context\n $git-context.output\n\n ## Instructions\n\n 1. Based on the area, search the relevant packages:\n - web-ui: `packages/web/src/`, `packages/server/src/adapters/web/`, `packages/server/src/routes/`\n - api-server: `packages/server/src/routes/`, `packages/server/src/`\n - cli: `packages/cli/src/`\n - isolation: `packages/isolation/src/`, `packages/git/src/`\n - workflows: `packages/workflows/src/`\n - database: `packages/core/src/db/`\n - adapters: `packages/adapters/src/`\n - core: `packages/core/src/orchestrator/`, `packages/core/src/handlers/`\n - other: search broadly based on keywords — check `packages/*/src/`, config files, build scripts\n\n 2. Find: entry points, error handling paths, related type definitions, recent changes\n to the affected area (check git log for the specific files).\n\n 3. Write your findings to `$ARTIFACTS_DIR/issue-context.md` with this structure:\n ```\n # Codebase Investigation\n ## Relevant Files\n - `file:line` — description of what's there\n ## Error Handling\n - How errors are currently handled in this area\n ## Recent Changes\n - Any recent commits touching this code\n ## Suspected Root Cause\n - Based on code analysis, where the bug likely is\n ```\n\n Be thorough but focused. Only include files directly relevant to the reported problem.\n depends_on: [classify, git-context]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 4: REPRODUCE — Area-specific issue reproduction\n # ═══════════════════════════════════════════════════════════════\n\n - id: start-server\n bash: |\n # Allocate a free port using Bun's OS assignment\n PORT=$(bun -e \"const s = Bun.serve({port: 0, fetch: () => new Response('')}); console.log(s.port); s.stop()\")\n echo \"$PORT\" > \"$ARTIFACTS_DIR/.server-port\"\n\n # Start dev server in background\n PORT=$PORT bun run dev:server > \"$ARTIFACTS_DIR/.server-log\" 2>&1 &\n SERVER_PID=$!\n echo \"$SERVER_PID\" > \"$ARTIFACTS_DIR/.server-pid\"\n\n # Wait for server to be ready (up to 30s)\n for i in $(seq 1 30); do\n if curl -s \"http://localhost:$PORT/api/health\" > /dev/null 2>&1; then\n echo \"Server ready on port $PORT (PID: $SERVER_PID)\"\n exit 0\n fi\n sleep 1\n done\n\n echo \"WARNING: Server may not be fully ready after 30s (port $PORT, PID $SERVER_PID)\"\n echo \"Continuing anyway — reproduce node will handle connection errors\"\n depends_on: [classify]\n when: \"$classify.output.needs_server == 'true'\"\n timeout: 45000\n\n - id: reproduce\n prompt: |\n You are an issue reproduction specialist. Your job is to reproduce the reported\n problem and capture evidence (screenshots, command output, error messages).\n\n ## Problem Context\n - **Area**: $classify.output.area\n - **Type**: $classify.output.type\n - **Title**: $classify.output.title\n - **Reproduction hint**: $classify.output.repro_hint\n\n ## Investigation Findings\n $investigate.output\n\n ## Server Info\n If a server was started, read the port from: `cat \"$ARTIFACTS_DIR/.server-port\"`\n If the file doesn't exist, no server is running (area doesn't need one).\n\n ---\n\n ## Reproduction Playbooks\n\n Follow the playbook matching the area. Capture ALL evidence to `$ARTIFACTS_DIR/`.\n\n ### web-ui\n 1. Read the server port: `PORT=$(cat \"$ARTIFACTS_DIR/.server-port\" | tr -d '\\n')`\n 2. Open the app: `agent-browser open http://localhost:$PORT`\n 3. Take a baseline screenshot: `agent-browser screenshot \"$ARTIFACTS_DIR/repro-01-baseline.png\"`\n 4. Get interactive elements: `agent-browser snapshot -i`\n 5. Navigate to the area related to the issue (use @refs from snapshot)\n 6. Perform the actions described in the repro_hint\n 7. Screenshot each significant state: `agent-browser screenshot \"$ARTIFACTS_DIR/repro-02-action.png\"`\n 8. If an error appears, capture it: `agent-browser get text @errorElement`\n 9. Check browser console: `agent-browser console`\n 10. Check for JS errors: `agent-browser errors`\n 11. Final screenshot: `agent-browser screenshot \"$ARTIFACTS_DIR/repro-03-result.png\"`\n 12. Close browser: `agent-browser close`\n\n ### api-server\n 1. Read the server port: `PORT=$(cat \"$ARTIFACTS_DIR/.server-port\" | tr -d '\\n')`\n 2. Create a test conversation: `curl -s -X POST http://localhost:$PORT/api/conversations -H \"Content-Type: application/json\" -d '{}'`\n 3. Hit the problematic endpoint based on the repro_hint\n 4. Capture response codes and bodies: `curl -s -w \"\\nHTTP_CODE: %{http_code}\\n\" ...`\n 5. For SSE issues: `curl -s -N http://localhost:$PORT/api/stream/` (timeout after 10s)\n 6. Check server logs: `cat \"$ARTIFACTS_DIR/.server-log\" | tail -50`\n 7. Save all curl output to `$ARTIFACTS_DIR/repro-api-responses.txt`\n\n ### cli\n 1. Run the CLI command that should trigger the issue\n 2. Capture stdout and stderr separately:\n `bun run cli > \"$ARTIFACTS_DIR/repro-cli-stdout.txt\" 2> \"$ARTIFACTS_DIR/repro-cli-stderr.txt\"; echo \"EXIT_CODE: $?\" >> \"$ARTIFACTS_DIR/repro-cli-stdout.txt\"`\n 3. If workflow-related: `bun run cli workflow list --json > \"$ARTIFACTS_DIR/repro-workflow-list.json\" 2>&1`\n 4. If the command hangs, use timeout: `timeout 30 bun run cli `\n 5. Check for error messages in output\n\n ### isolation\n 1. Check current state: `bun run cli isolation list > \"$ARTIFACTS_DIR/repro-isolation-list.txt\" 2>&1`\n 2. Check git worktrees: `git worktree list > \"$ARTIFACTS_DIR/repro-worktree-list.txt\"`\n 3. Check branches: `git branch -a > \"$ARTIFACTS_DIR/repro-branches.txt\"`\n 4. Try the operation that should fail (based on repro_hint)\n 5. Capture the error output\n 6. Query isolation DB: `sqlite3 ~/.archon/archon.db \"SELECT * FROM remote_agent_isolation_environments ORDER BY created_at DESC LIMIT 10\" > \"$ARTIFACTS_DIR/repro-isolation-db.txt\" 2>&1`\n\n ### workflows\n 1. List workflows: `bun run cli workflow list --json > \"$ARTIFACTS_DIR/repro-workflow-list.json\" 2>&1`\n 2. If a specific workflow is mentioned, try running it:\n `bun run cli workflow run --no-worktree \"test input\" > \"$ARTIFACTS_DIR/repro-workflow-run.txt\" 2>&1`\n 3. If YAML parsing is the issue, try loading the definition directly\n 4. Check for error messages in execution output\n\n ### database\n 1. Check DB exists: `ls -la ~/.archon/archon.db 2>/dev/null`\n 2. Run targeted queries against affected tables:\n - `sqlite3 ~/.archon/archon.db \".schema \" > \"$ARTIFACTS_DIR/repro-db-schema.txt\"`\n - `sqlite3 ~/.archon/archon.db \"SELECT COUNT(*) FROM
\" > \"$ARTIFACTS_DIR/repro-db-counts.txt\"`\n 3. Check for the specific data condition described in the repro_hint\n 4. If PostgreSQL: use `psql $DATABASE_URL -c \"...\"` instead\n\n ### adapters\n 1. Read the server port: `PORT=$(cat \"$ARTIFACTS_DIR/.server-port\" | tr -d '\\n')`\n 2. Check adapter configuration: look for relevant env vars in `.env`\n 3. Check server startup logs: `cat \"$ARTIFACTS_DIR/.server-log\" | grep -i \"adapter\\|slack\\|telegram\\|github\\|discord\" | head -20`\n 4. If the adapter fails to initialize, capture the error\n 5. Test message routing via web API as a proxy:\n `curl -s -X POST http://localhost:$PORT/api/conversations//message -H \"Content-Type: application/json\" -d '{\"message\":\"/status\"}'`\n\n ### core\n 1. Read the server port: `PORT=$(cat \"$ARTIFACTS_DIR/.server-port\" | tr -d '\\n')`\n 2. Create a conversation: `curl -s -X POST http://localhost:$PORT/api/conversations -H \"Content-Type: application/json\" -d '{}'`\n 3. Send a message that triggers the issue:\n `curl -s -X POST http://localhost:$PORT/api/conversations//message -H \"Content-Type: application/json\" -d '{\"message\":\"\"}'`\n 4. Poll for responses: `curl -s http://localhost:$PORT/api/conversations//messages`\n 5. Check session state in DB: `sqlite3 ~/.archon/archon.db \"SELECT * FROM remote_agent_sessions WHERE conversation_id=''\" 2>/dev/null`\n 6. Check server logs: `cat \"$ARTIFACTS_DIR/.server-log\" | tail -50`\n\n ### other\n 1. Run `bun run validate` to check for any obvious failures — capture output:\n `bun run validate > \"$ARTIFACTS_DIR/repro-validate.txt\" 2>&1; echo \"EXIT_CODE: $?\" >> \"$ARTIFACTS_DIR/repro-validate.txt\"`\n 2. Search the codebase for keywords from the repro_hint:\n - Use Grep/Glob to find related files\n - Check recent git log for relevant changes\n 3. If the description implies a build or config issue:\n - Check `package.json` scripts, `tsconfig.json`, `.env.example`\n - Try running the relevant build/dev command\n 4. If the description implies a runtime issue:\n - Start the server (if `.server-port` file exists) and try to trigger the behavior\n - Check logs for errors\n 5. Document everything you tried, even if nothing reproduces clearly\n\n ---\n\n ## Output\n\n After following the playbook, write your findings to `$ARTIFACTS_DIR/reproduction-results.md`:\n\n ```markdown\n # Reproduction Results\n\n ## Status: [REPRODUCED | NOT_REPRODUCED | PARTIAL]\n\n ## Steps Taken\n 1. [step]\n 2. [step]\n\n ## Expected Behavior\n [what should happen]\n\n ## Actual Behavior\n [what actually happened — or \"could not trigger the reported behavior\"]\n\n ## Evidence Files\n - `$ARTIFACTS_DIR/repro-*.png` — screenshots (if web-ui)\n - `$ARTIFACTS_DIR/repro-*.txt` — command output\n - `$ARTIFACTS_DIR/repro-*.json` — structured data\n\n ## Environment\n [OS, versions, relevant config]\n\n ## Notes\n [any additional observations, suspected root cause refinements]\n ```\n\n CRITICAL: The Status line MUST be exactly one of: REPRODUCED, NOT_REPRODUCED, PARTIAL.\n This value is read by a downstream bash node to decide whether to create the issue.\n\n Even if you cannot fully reproduce the issue, document what you tried\n and what you observed. Partial reproduction is still valuable evidence.\n depends_on: [classify, git-context, investigate, start-server]\n context: fresh\n skills:\n - agent-browser\n trigger_rule: one_success\n idle_timeout: 300000\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 5: CLEANUP + GATE\n # ═══════════════════════════════════════════════════════════════\n\n - id: cleanup-server\n bash: |\n SERVER_PID=$(cat \"$ARTIFACTS_DIR/.server-pid\" 2>/dev/null | tr -d '\\n')\n SERVER_PORT=$(cat \"$ARTIFACTS_DIR/.server-port\" 2>/dev/null | tr -d '\\n')\n\n if [ -z \"$SERVER_PID\" ]; then\n echo \"No server was started — skipping cleanup\"\n exit 0\n fi\n\n echo \"Cleaning up server PID $SERVER_PID on port $SERVER_PORT...\"\n\n # Kill by PID (cross-platform)\n kill \"$SERVER_PID\" 2>/dev/null || taskkill //F //T //PID \"$SERVER_PID\" 2>/dev/null || true\n\n # Kill by port (fallback)\n if [ -n \"$SERVER_PORT\" ]; then\n fuser -k \"$SERVER_PORT/tcp\" 2>/dev/null || true\n lsof -ti:\"$SERVER_PORT\" 2>/dev/null | xargs kill -9 2>/dev/null || true\n netstat -ano 2>/dev/null | grep \":$SERVER_PORT \" | grep LISTENING | awk '{print $5}' | sort -u | while read pid; do\n taskkill //F //T //PID \"$pid\" 2>/dev/null || true\n done\n fi\n\n # Close any agent-browser session\n agent-browser close 2>/dev/null || true\n\n sleep 1\n echo \"Cleanup complete\"\n depends_on: [reproduce]\n trigger_rule: all_done\n\n - id: check-reproduction\n bash: |\n # Read the reproduction status from the results file\n if [ ! -f \"$ARTIFACTS_DIR/reproduction-results.md\" ]; then\n echo \"NOT_REPRODUCED\"\n exit 0\n fi\n\n STATUS=$(grep -oE '(NOT_REPRODUCED|REPRODUCED|PARTIAL)' \"$ARTIFACTS_DIR/reproduction-results.md\" | head -1)\n\n if [ -z \"$STATUS\" ]; then\n echo \"NOT_REPRODUCED\"\n else\n echo \"$STATUS\"\n fi\n depends_on: [cleanup-server]\n trigger_rule: all_done\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 6: BRANCH ON REPRODUCTION RESULT\n # ═══════════════════════════════════════════════════════════════\n\n - id: report-failure\n prompt: |\n The issue could not be reproduced. Report this to the user with actionable detail.\n\n ## Problem Description\n - **Title**: $classify.output.title\n - **Area**: $classify.output.area\n - **Type**: $classify.output.type\n - **Reproduction hint**: $classify.output.repro_hint\n\n ## What Was Tried\n $reproduce.output\n\n ## Investigation Findings\n $investigate.output\n\n ## Instructions\n\n Report to the user clearly:\n\n 1. **State upfront**: \"Could not reproduce the reported issue. No GitHub issue was created.\"\n\n 2. **Summarize what was tried**: List the specific steps the reproduce node took,\n based on the area playbook. Be concrete — \"Started server on port X, navigated to Y,\n clicked Z — no error appeared.\"\n\n 3. **Share what was found**: Include relevant findings from the investigation\n (code references, recent changes, suspected areas).\n\n 4. **Suggest next steps**:\n - Ask the user to provide more specific reproduction steps\n - Mention any environment-specific factors that might matter\n (OS, browser, database state, specific data conditions)\n - If the investigation found suspicious code, mention it as a lead\n - Suggest running with debug logging: `LOG_LEVEL=debug bun run dev`\n\n 5. **Offer to retry**: \"If you can provide more specific steps, run the workflow\n again with those details.\"\n\n Do NOT create a GitHub issue. The purpose of this node is to communicate back to the\n user so they can provide better information or investigate manually.\n depends_on: [check-reproduction]\n when: \"$check-reproduction.output == 'NOT_REPRODUCED'\"\n context: fresh\n\n - id: draft-issue\n prompt: |\n You are a technical writer drafting a GitHub issue. Assemble all gathered\n context into a clear, well-structured issue body.\n\n ## Classification\n - **Type**: $classify.output.type\n - **Area**: $classify.output.area\n - **Title**: $classify.output.title\n\n ## Issue Template\n If templates were found, use the most appropriate one as the structure:\n $fetch-template.output\n\n ## Duplicate Check Results\n $dedup-check.output\n\n ## Codebase Investigation\n $investigate.output\n\n ## Reproduction Results\n $reproduce.output\n\n ## Instructions\n\n 1. **Check duplicates first**: If the dedup-check found a clearly matching open issue,\n note this prominently at the top. Still draft the issue but add a note suggesting\n it may be a duplicate of #XYZ.\n\n 2. **Use the template** if one was found for bug reports. Fill every section with real data.\n\n 3. **Structure** (if no template):\n ```markdown\n ## Description\n [Clear 1-2 sentence description]\n\n ## Steps to Reproduce\n [Numbered steps from reproduction results]\n\n ## Expected Behavior\n [What should happen]\n\n ## Actual Behavior\n [What actually happened, with evidence]\n\n ## Environment\n - OS: [from git-context]\n - Bun: [version]\n - Node: [version]\n - Branch: [current branch]\n\n ## Relevant Code\n [Key file:line references from investigation]\n\n ## Additional Context\n [Screenshots, logs, database state — reference artifact files]\n ```\n\n 4. **Include reproduction evidence**:\n - If REPRODUCED: include full steps and all evidence\n - If PARTIAL: include what was observed, note incomplete reproduction\n\n 5. **Suggest labels** based on classification:\n - Area label: `area: web`, `area: cli`, `area: workflows`, etc.\n - Type label: `bug`, `regression`, `performance`, etc.\n\n 6. Write the complete issue body to `$ARTIFACTS_DIR/issue-draft.md`\n\n 7. Write a one-line suggested title to `$ARTIFACTS_DIR/.issue-title`\n\n 8. Write suggested labels (comma-separated) to `$ARTIFACTS_DIR/.issue-labels`\n depends_on: [check-reproduction, fetch-template, dedup-check, investigate]\n when: \"$check-reproduction.output != 'NOT_REPRODUCED'\"\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 7: CREATE ISSUE\n # ═══════════════════════════════════════════════════════════════\n\n - id: create-issue\n prompt: |\n Create the GitHub issue using the drafted content.\n\n ## Instructions\n\n 1. Read the draft: `cat \"$ARTIFACTS_DIR/issue-draft.md\"`\n 2. Read the title: `cat \"$ARTIFACTS_DIR/.issue-title\"`\n 3. Read suggested labels: `cat \"$ARTIFACTS_DIR/.issue-labels\"`\n\n 4. Check which labels actually exist in the repo:\n ```bash\n gh label list --json name -q '.[].name' | head -50\n ```\n Only use labels that exist. Skip any suggested label that doesn't match.\n\n 5. Create the issue:\n ```bash\n gh issue create \\\n --title \"$(cat \"$ARTIFACTS_DIR/.issue-title\")\" \\\n --body-file \"$ARTIFACTS_DIR/issue-draft.md\" \\\n --label \"label1,label2\"\n ```\n\n 6. Capture the result:\n ```bash\n ISSUE_URL=$(gh issue list --limit 1 --json url -q '.[0].url')\n echo \"$ISSUE_URL\" > \"$ARTIFACTS_DIR/.issue-url\"\n ```\n\n 7. Report to the user:\n - Issue URL\n - Title\n - Labels applied\n - Whether duplicates were found\n - Summary of reproduction results (reproduced/partial)\n depends_on: [draft-issue]\n context: fresh\n", "archon-feature-development": "name: archon-feature-development\ndescription: |\n Use when: Implementing a feature from an existing plan.\n Input: Path to a plan file ($ARTIFACTS_DIR/plan.md) or GitHub issue containing a plan.\n Does: Implements the plan with validation loops -> creates pull request.\n NOT for: Creating plans (plans should be created separately), bug fixes, code reviews.\n\nnodes:\n - id: implement\n command: archon-implement\n provider: claude\n model: large\n\n - id: create-pr\n command: archon-create-pr\n depends_on: [implement]\n context: fresh\n\n - id: verify-pr-base\n bash: |\n set -euo pipefail\n # Pin to the origin remote — in a fork clone, gh otherwise queries the upstream parent\n ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')\n HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)\n PR_NUMBER=$(gh pr list --repo \"$ORIGIN_REPO\" --head \"$HEAD_BRANCH\" --state open --json number -q '.[0].number')\n if [ -z \"$PR_NUMBER\" ]; then\n echo \"No open PR found for branch $HEAD_BRANCH\" >&2\n exit 1\n fi\n EXPECTED=\"$BASE_BRANCH\"\n ACTUAL=$(gh pr view \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --json baseRefName -q '.baseRefName')\n if [ \"$ACTUAL\" != \"$EXPECTED\" ]; then\n echo \"Base mismatch on PR #$PR_NUMBER: expected=$EXPECTED actual=$ACTUAL — re-targeting\" >&2\n gh pr edit \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --base \"$EXPECTED\"\n else\n echo \"PR base verified: $EXPECTED\"\n fi\n depends_on: [create-pr]\n", - "archon-fix-github-issue": "name: archon-fix-github-issue\ndescription: |\n Use when: User wants to FIX, RESOLVE, or IMPLEMENT a solution for a GitHub issue.\n Triggers: \"fix this issue\", \"implement issue #123\", \"resolve this bug\", \"fix it\",\n \"fix issue\", \"resolve issue\", \"fix #123\".\n NOT for: Comprehensive multi-agent reviews (use archon-issue-review-full),\n questions about issues, CI failures, PR reviews, general exploration.\n\n DAG workflow that:\n 1. Classifies the issue (bug/feature/enhancement/etc)\n 2. Researches context (web research + codebase exploration via investigate/plan)\n 3. Routes to investigate (bugs) or plan (features) based on classification\n 4. Implements the fix/feature with validation\n 5. Creates a draft PR using the repo's PR template\n 6. Runs smart review (always code review + CLAUDE.md check, conditional additional agents)\n 7. Aggressively self-fixes all findings (tests, docs, error handling)\n 8. Simplifies changed code (implements fixes directly, not just reports)\n 9. Reports results back to the GitHub issue with follow-up suggestions\n\nprovider: claude\nmodel: medium\n\nnodes:\n # ═══════════════════════════════════════════════════════════════\n # PHASE 1: FETCH & CLASSIFY\n # ═══════════════════════════════════════════════════════════════\n\n - id: parse-request\n command: archon-parse-user-request\n model: small\n output_format:\n type: object\n properties:\n user_request:\n type: string\n issue_number:\n type: string\n repo:\n type: string\n repo_url:\n type: string\n required:\n - user_request\n - issue_number\n - repo\n - repo_url\n\n - id: fetch-issue\n bash: |\n # Substitutions are injected already shell-quoted by Archon — assign them\n # unquoted, then quote normally as locals (see #1884).\n req=$parse-request.output.user_request\n num=$parse-request.output.issue_number\n repo=$parse-request.output.repo\n url=$parse-request.output.repo_url\n\n # user_request is the ONE guaranteed field: verbatim input, never empty for\n # a non-empty message. Empty here means the parse step failed to return what\n # it was given — a real defect, and a countable one, rather than an unusual\n # input. The other three are best-effort by contract.\n if [ -z \"$req\" ]; then\n echo \"parse-request returned an empty user_request — the parse step failed.\" >&2\n echo \"This is a parser defect, not a bad request. Consider raising its model tier.\" >&2\n exit 1\n fi\n\n # `gh issue view ` resolves against the CURRENT checkout, so a number\n # separated from the repository it came from silently fetches this repo's\n # issue of the same number (#2412). Prefer whichever form the operator\n # actually gave, most-complete first, and never reassemble one from parts.\n if [ -n \"$url\" ]; then\n # A URL carries its repository with it — no number needed, and no\n # reassembly step to get wrong. Checked BEFORE the numeric gate below: a\n # best-effort miss on issue_number must not fail a run whose URL alone is\n # a complete, valid argument.\n gh issue view \"$url\" --json title,body,labels,comments,state,url,author\n else\n if ! printf '%s' \"$num\" | grep -qE '^[0-9]+$'; then\n echo \"No GitHub issue number found in: $req\" >&2\n echo \"This workflow fixes a GitHub issue; give it an issue number or URL.\" >&2\n exit 1\n fi\n if [ -n \"$repo\" ]; then\n # owner/repo#N states the repository explicitly; honour it.\n gh issue view \"$num\" --repo \"$repo\" --json title,body,labels,comments,state,url,author\n else\n gh issue view \"$num\" --json title,body,labels,comments,state,url,author\n fi\n fi\n depends_on: [parse-request]\n\n - id: classify\n prompt: |\n You are an issue classifier. Analyze the GitHub issue below and determine its type.\n\n ## Issue Content\n\n $fetch-issue.output\n\n ## Classification Rules\n\n | Type | Indicators |\n |------|------------|\n | bug | \"broken\", \"error\", \"crash\", \"doesn't work\", stack traces, regression |\n | feature | \"add\", \"new\", \"support\", \"would be nice\", net-new capability |\n | enhancement | \"improve\", \"better\", \"update existing\", \"extend\", incremental improvement |\n | refactor | \"clean up\", \"simplify\", \"reorganize\", \"restructure\" |\n | chore | \"update deps\", \"upgrade\", \"maintenance\", \"CI/CD\" |\n | documentation | \"docs\", \"readme\", \"clarify\", \"examples\" |\n\n Provide reasoning for your classification.\n depends_on: [fetch-issue]\n model: small\n allowed_tools: []\n output_format:\n type: object\n properties:\n issue_type:\n type: string\n enum: [\"bug\", \"feature\", \"enhancement\", \"refactor\", \"chore\", \"documentation\"]\n title:\n type: string\n reasoning:\n type: string\n required: [issue_type, title, reasoning]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 2: RESEARCH (parallel with PR template fetch)\n # ═══════════════════════════════════════════════════════════════\n\n - id: web-research\n command: archon-web-research\n depends_on: [classify]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 3: INVESTIGATE (bugs) / PLAN (features)\n # ═══════════════════════════════════════════════════════════════\n\n - id: investigate\n command: archon-investigate-issue\n depends_on: [classify, web-research]\n when: \"$classify.output.issue_type == 'bug'\"\n context: fresh\n\n - id: plan\n command: archon-create-plan\n depends_on: [classify, web-research]\n when: \"$classify.output.issue_type != 'bug'\"\n context: fresh\n\n # Bridge: ensure investigation.md exists for the implement step\n # archon-fix-issue reads from $ARTIFACTS_DIR/investigation.md\n # archon-create-plan writes to $ARTIFACTS_DIR/plan.md\n # This node copies plan.md → investigation.md when the plan path was taken\n - id: bridge-artifacts\n bash: |\n if [ -f \"$ARTIFACTS_DIR/plan.md\" ] && [ ! -f \"$ARTIFACTS_DIR/investigation.md\" ]; then\n cp \"$ARTIFACTS_DIR/plan.md\" \"$ARTIFACTS_DIR/investigation.md\"\n echo \"Bridged plan.md to investigation.md for implement step\"\n elif [ -f \"$ARTIFACTS_DIR/investigation.md\" ]; then\n echo \"investigation.md exists from investigate step\"\n else\n echo \"WARNING: No investigation.md or plan.md found — implement may fail\"\n fi\n depends_on: [investigate, plan]\n trigger_rule: one_success\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 4: IMPLEMENT\n # ═══════════════════════════════════════════════════════════════\n\n - id: implement\n command: archon-fix-issue\n depends_on: [bridge-artifacts]\n context: fresh\n model: large\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 5: VALIDATE\n # ═══════════════════════════════════════════════════════════════\n\n - id: validate\n command: archon-validate\n depends_on: [implement]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 6: CREATE DRAFT PR\n # ═══════════════════════════════════════════════════════════════\n\n - id: create-pr\n prompt: |\n Create a draft pull request for the current branch.\n\n ## Context\n\n - **Issue**: $ARGUMENTS\n - **Classification**: $classify.output\n - **Issue title**: $classify.output.title\n\n ## Instructions\n\n 1. Check git status. If uncommitted changes exist, stage and commit ONLY source files that are part of the fix:\n - List them by name with `git add ...` — never `git add -A`, `git add .`, or `git add -u`\n - **Never commit** scratch / review / PR-body artifacts, even if they appear in `git status`:\n - `.pr-body.md`, `pr-body.md`, `*.scratch.md`, `*.tmp.md` at any path\n - `review/`, `*-report.md` at the repo root\n - Anything under `$ARTIFACTS_DIR`\n - Repo-local Archon telemetry: `.archon/artifacts/`, `.archon/logs/`, `.archon/state/` (local-only — never in git)\n - Verify with `git status --porcelain` that nothing scratch is staged before committing\n - If files you don't recognize as part of the fix appear modified or untracked, leave them alone\n 2. Push the branch: `git push -u origin HEAD`\n 3. Read implementation artifacts from `$ARTIFACTS_DIR/` for context:\n - `$ARTIFACTS_DIR/investigation.md` or `$ARTIFACTS_DIR/plan.md`\n - `$ARTIFACTS_DIR/implementation.md`\n - `$ARTIFACTS_DIR/validation.md`\n 4. Resolve the origin repo — in a fork clone, gh otherwise targets the upstream parent:\n `ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')`\n Then check if a PR already exists for this branch: `gh pr list --repo \"$ORIGIN_REPO\" --head $(git branch --show-current)`\n - If PR exists, skip creation and capture its number\n 5. Look for the project's PR template at `.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE.md`, or `docs/PULL_REQUEST_TEMPLATE.md`. Read whichever one exists.\n 6. Create a DRAFT PR: `gh pr create --repo \"$ORIGIN_REPO\" --draft --base $BASE_BRANCH`\n - Title: concise, imperative mood, under 70 chars\n - Body: if a PR template was found, fill in **every section** with details from the artifacts. Don't skip sections or leave placeholders. If no template, write a body with summary, changes, validation evidence, and `Fixes #...`.\n - **PR body file location**: if you write the body to a file (e.g. for `--body-file`), the file MUST live at `$ARTIFACTS_DIR/pr-body.md` or under `/tmp/` — NEVER inside the worktree. Files like `.pr-body.md` at the repo root will be picked up by later commits.\n - Link to issue: include `Fixes #...` or `Closes #...`\n 7. Capture PR identifiers:\n ```bash\n ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')\n HEAD_BRANCH=$(git branch --show-current)\n PR_NUMBER=$(gh pr list --repo \"$ORIGIN_REPO\" --head \"$HEAD_BRANCH\" --state open --json number -q '.[0].number')\n if [ -z \"$PR_NUMBER\" ]; then\n echo \"No open PR found for branch $HEAD_BRANCH — PR creation failed\" >&2\n exit 1\n fi\n echo \"$PR_NUMBER\" > \"$ARTIFACTS_DIR/.pr-number\"\n PR_URL=$(gh pr view \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --json url -q '.url')\n echo \"$PR_URL\" > \"$ARTIFACTS_DIR/.pr-url\"\n ```\n depends_on: [validate]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 7: REVIEW\n # ═══════════════════════════════════════════════════════════════\n\n - id: verify-pr-base\n bash: |\n set -euo pipefail\n # Pin to the origin remote — in a fork clone, gh otherwise queries the upstream parent\n ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')\n HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)\n PR_NUMBER=$(gh pr list --repo \"$ORIGIN_REPO\" --head \"$HEAD_BRANCH\" --state open --json number -q '.[0].number')\n if [ -z \"$PR_NUMBER\" ]; then\n echo \"No open PR found for branch $HEAD_BRANCH\" >&2\n exit 1\n fi\n EXPECTED=\"$BASE_BRANCH\"\n ACTUAL=$(gh pr view \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --json baseRefName -q '.baseRefName')\n if [ \"$ACTUAL\" != \"$EXPECTED\" ]; then\n echo \"Base mismatch on PR #$PR_NUMBER: expected=$EXPECTED actual=$ACTUAL — re-targeting\" >&2\n gh pr edit \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --base \"$EXPECTED\"\n else\n echo \"PR base verified: $EXPECTED\"\n fi\n depends_on: [create-pr]\n\n - id: review-scope\n command: archon-pr-review-scope\n depends_on: [verify-pr-base]\n context: fresh\n\n - id: review-classify\n prompt: |\n You are a PR review classifier. Analyze the PR scope and determine\n which review agents should run.\n\n ## PR Scope\n\n $review-scope.output\n\n ## Rules\n\n - **Code review**: ALWAYS run. This is mandatory for every PR. It also checks\n the PR against CLAUDE.md rules and project conventions.\n - **Error handling**: Run if the diff touches code with try/catch, error handling,\n async/await, or adds new failure paths.\n - **Test coverage**: Run if the diff touches source code (not just tests, docs, or config).\n - **Comment quality**: Run if the diff adds or modifies comments, docstrings, JSDoc,\n or significant documentation within code files.\n - **Docs impact**: Run if the diff adds/removes/renames public APIs, commands, CLI flags,\n environment variables, or user-facing features.\n\n Provide your reasoning for each decision.\n depends_on: [review-scope]\n model: small\n allowed_tools: []\n context: fresh\n output_format:\n type: object\n properties:\n run_code_review:\n type: string\n enum: [\"true\", \"false\"]\n run_error_handling:\n type: string\n enum: [\"true\", \"false\"]\n run_test_coverage:\n type: string\n enum: [\"true\", \"false\"]\n run_comment_quality:\n type: string\n enum: [\"true\", \"false\"]\n run_docs_impact:\n type: string\n enum: [\"true\", \"false\"]\n reasoning:\n type: string\n required:\n - run_code_review\n - run_error_handling\n - run_test_coverage\n - run_comment_quality\n - run_docs_impact\n - reasoning\n\n # Code review always runs — mandatory\n - id: code-review\n command: archon-code-review-agent\n depends_on: [review-classify]\n context: fresh\n\n - id: error-handling\n command: archon-error-handling-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_error_handling == 'true'\"\n context: fresh\n\n - id: test-coverage\n command: archon-test-coverage-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_test_coverage == 'true'\"\n context: fresh\n\n - id: comment-quality\n command: archon-comment-quality-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_comment_quality == 'true'\"\n context: fresh\n\n - id: docs-impact\n command: archon-docs-impact-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_docs_impact == 'true'\"\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 8: SYNTHESIZE + SELF-FIX\n # ═══════════════════════════════════════════════════════════════\n\n - id: synthesize\n command: archon-synthesize-review\n depends_on: [code-review, error-handling, test-coverage, comment-quality, docs-impact]\n trigger_rule: one_success\n context: fresh\n\n - id: self-fix\n command: archon-self-fix-all\n depends_on: [synthesize]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 9: SIMPLIFY\n # ═══════════════════════════════════════════════════════════════\n\n - id: simplify\n command: archon-simplify-changes\n depends_on: [self-fix]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 10: REPORT\n # ═══════════════════════════════════════════════════════════════\n\n - id: report\n command: archon-issue-completion-report\n depends_on: [simplify]\n context: fresh\n", + "archon-fix-github-issue": "name: archon-fix-github-issue\ndescription: |\n Use when: User wants to FIX, RESOLVE, or IMPLEMENT a solution for a GitHub issue.\n Triggers: \"fix this issue\", \"implement issue #123\", \"resolve this bug\", \"fix it\",\n \"fix issue\", \"resolve issue\", \"fix #123\".\n NOT for: Comprehensive multi-agent reviews (use archon-issue-review-full),\n questions about issues, CI failures, PR reviews, general exploration.\n\n DAG workflow that:\n 1. Classifies the issue (bug/feature/enhancement/etc)\n 2. Researches context (web research + codebase exploration via investigate/plan)\n 3. Routes to investigate (bugs) or plan (features) based on classification\n 4. Implements the fix/feature with validation\n 5. Creates a draft PR using the repo's PR template\n 6. Runs smart review (always code review + CLAUDE.md check, conditional additional agents)\n 7. Aggressively self-fixes all findings (tests, docs, error handling)\n 8. Simplifies changed code (implements fixes directly, not just reports)\n 9. Reports results back to the GitHub issue with follow-up suggestions\n\nprovider: claude\nmodel: medium\n\nnodes:\n # ═══════════════════════════════════════════════════════════════\n # PHASE 1: FETCH & CLASSIFY\n # ═══════════════════════════════════════════════════════════════\n\n - id: parse-request\n command: archon-parse-user-request\n model: small\n output_format:\n type: object\n properties:\n user_request:\n type: string\n issue_number:\n type: string\n repo:\n type: string\n repo_url:\n type: string\n required:\n - user_request\n - issue_number\n - repo\n - repo_url\n\n - id: fetch-issue\n bash: |\n # Substitutions are injected already shell-quoted by Archon — assign them\n # unquoted, then quote normally as locals (see #1884).\n req=$parse-request.output.user_request\n num=$parse-request.output.issue_number\n repo=$parse-request.output.repo\n url=$parse-request.output.repo_url\n\n # user_request is the ONE guaranteed field: verbatim input, never empty for\n # a non-empty message. Empty here means the parse step failed to return what\n # it was given — a real defect, and a countable one, rather than an unusual\n # input. The other three are best-effort by contract.\n if [ -z \"$req\" ]; then\n echo \"parse-request returned an empty user_request — the parse step failed.\" >&2\n echo \"This is a parser defect, not a bad request. Consider raising its model tier.\" >&2\n exit 1\n fi\n\n # `gh issue view ` resolves against the CURRENT checkout, so a number\n # separated from the repository it came from silently fetches this repo's\n # issue of the same number (#2412). Prefer whichever form the operator\n # actually gave, most-complete first, and never reassemble one from parts.\n if [ -n \"$url\" ]; then\n # A URL carries its repository with it — no number needed, and no\n # reassembly step to get wrong. Checked BEFORE the numeric gate below: a\n # best-effort miss on issue_number must not fail a run whose URL alone is\n # a complete, valid argument.\n gh issue view \"$url\" --json title,body,labels,comments,state,url,author\n else\n if ! printf '%s' \"$num\" | grep -qE '^[0-9]+$'; then\n echo \"No GitHub issue number found in: $req\" >&2\n echo \"This workflow fixes a GitHub issue; give it an issue number or URL.\" >&2\n exit 1\n fi\n if [ -n \"$repo\" ]; then\n # owner/repo#N states the repository explicitly; honour it.\n gh issue view \"$num\" --repo \"$repo\" --json title,body,labels,comments,state,url,author\n else\n gh issue view \"$num\" --json title,body,labels,comments,state,url,author\n fi\n fi\n depends_on: [parse-request]\n\n - id: classify\n prompt: |\n You are an issue classifier. Analyze the GitHub issue below and determine its type.\n\n ## Issue Content\n\n $fetch-issue.output\n\n ## Classification Rules\n\n | Type | Indicators |\n |------|------------|\n | bug | \"broken\", \"error\", \"crash\", \"doesn't work\", stack traces, regression |\n | feature | \"add\", \"new\", \"support\", \"would be nice\", net-new capability |\n | enhancement | \"improve\", \"better\", \"update existing\", \"extend\", incremental improvement |\n | refactor | \"clean up\", \"simplify\", \"reorganize\", \"restructure\" |\n | chore | \"update deps\", \"upgrade\", \"maintenance\", \"CI/CD\" |\n | documentation | \"docs\", \"readme\", \"clarify\", \"examples\" |\n\n Provide reasoning for your classification.\n depends_on: [fetch-issue]\n model: small\n allowed_tools: []\n output_format:\n type: object\n properties:\n issue_type:\n type: string\n enum: [\"bug\", \"feature\", \"enhancement\", \"refactor\", \"chore\", \"documentation\"]\n title:\n type: string\n reasoning:\n type: string\n required: [issue_type, title, reasoning]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 2: RESEARCH (parallel with PR template fetch)\n # ═══════════════════════════════════════════════════════════════\n\n - id: web-research\n command: archon-web-research\n depends_on: [classify]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 3: INVESTIGATE (bugs) / PLAN (features)\n # ═══════════════════════════════════════════════════════════════\n\n - id: investigate\n command: archon-investigate-issue\n depends_on: [classify, web-research]\n when: \"$classify.output.issue_type == 'bug'\"\n context: fresh\n\n - id: plan\n command: archon-create-plan\n depends_on: [classify, web-research]\n when: \"$classify.output.issue_type != 'bug'\"\n context: fresh\n\n # Bridge: ensure investigation.md exists for the implement step\n # archon-fix-issue reads from $ARTIFACTS_DIR/investigation.md\n # archon-create-plan writes to $ARTIFACTS_DIR/plan.md\n # This node copies plan.md → investigation.md when the plan path was taken\n - id: bridge-artifacts\n bash: |\n if [ -f \"$ARTIFACTS_DIR/plan.md\" ] && [ ! -f \"$ARTIFACTS_DIR/investigation.md\" ]; then\n cp \"$ARTIFACTS_DIR/plan.md\" \"$ARTIFACTS_DIR/investigation.md\"\n echo \"Bridged plan.md to investigation.md for implement step\"\n elif [ -f \"$ARTIFACTS_DIR/investigation.md\" ]; then\n echo \"investigation.md exists from investigate step\"\n else\n # Fail, do not warn. investigate/plan can \"succeed\" while producing no\n # artifact — an AI node that declines the task still exits 0, so the\n # refusal reads downstream as a completed investigation. This node holds\n # the only cheap deterministic view of that precondition, so it is where\n # the run has to stop, before implement spends a model on nothing.\n echo \"bridge-artifacts: neither investigation.md nor plan.md exists in \\$ARTIFACTS_DIR.\" >&2\n echo \"The investigate/plan phase produced no specification — implement has nothing to work from.\" >&2\n exit 1\n fi\n depends_on: [investigate, plan]\n trigger_rule: one_success\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 4: IMPLEMENT\n # ═══════════════════════════════════════════════════════════════\n\n - id: implement\n command: archon-fix-issue\n depends_on: [bridge-artifacts]\n context: fresh\n model: large\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 5: VALIDATE\n # ═══════════════════════════════════════════════════════════════\n\n - id: validate\n command: archon-validate\n depends_on: [implement]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 6: CREATE DRAFT PR\n # ═══════════════════════════════════════════════════════════════\n\n - id: create-pr\n prompt: |\n Create a draft pull request for the current branch.\n\n ## Context\n\n - **Issue**: $ARGUMENTS\n - **Classification**: $classify.output\n - **Issue title**: $classify.output.title\n\n ## Instructions\n\n 1. Check git status. If uncommitted changes exist, stage and commit ONLY source files that are part of the fix:\n - List them by name with `git add ...` — never `git add -A`, `git add .`, or `git add -u`\n - **Never commit** scratch / review / PR-body artifacts, even if they appear in `git status`:\n - `.pr-body.md`, `pr-body.md`, `*.scratch.md`, `*.tmp.md` at any path\n - `review/`, `*-report.md` at the repo root\n - Anything under `$ARTIFACTS_DIR`\n - Repo-local Archon telemetry: `.archon/artifacts/`, `.archon/logs/`, `.archon/state/` (local-only — never in git)\n - Verify with `git status --porcelain` that nothing scratch is staged before committing\n - If files you don't recognize as part of the fix appear modified or untracked, leave them alone\n 2. Push the branch: `git push -u origin HEAD`\n 3. Read implementation artifacts from `$ARTIFACTS_DIR/` for context:\n - `$ARTIFACTS_DIR/investigation.md` or `$ARTIFACTS_DIR/plan.md`\n - `$ARTIFACTS_DIR/implementation.md`\n - `$ARTIFACTS_DIR/validation.md`\n 4. Resolve the origin repo — in a fork clone, gh otherwise targets the upstream parent:\n `ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')`\n Then check if a PR already exists for this branch: `gh pr list --repo \"$ORIGIN_REPO\" --head $(git branch --show-current)`\n - If PR exists, skip creation and capture its number\n 5. Look for the project's PR template at `.github/pull_request_template.md`, `.github/PULL_REQUEST_TEMPLATE.md`, or `docs/PULL_REQUEST_TEMPLATE.md`. Read whichever one exists.\n 6. Create a DRAFT PR: `gh pr create --repo \"$ORIGIN_REPO\" --draft --base $BASE_BRANCH`\n - Title: concise, imperative mood, under 70 chars\n - Body: if a PR template was found, fill in **every section** with details from the artifacts. Don't skip sections or leave placeholders. If no template, write a body with summary, changes, validation evidence, and `Fixes #...`.\n - **PR body file location**: if you write the body to a file (e.g. for `--body-file`), the file MUST live at `$ARTIFACTS_DIR/pr-body.md` or under `/tmp/` — NEVER inside the worktree. Files like `.pr-body.md` at the repo root will be picked up by later commits.\n - Link to issue: include `Fixes #...` or `Closes #...`\n 7. Capture PR identifiers:\n ```bash\n ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')\n HEAD_BRANCH=$(git branch --show-current)\n PR_NUMBER=$(gh pr list --repo \"$ORIGIN_REPO\" --head \"$HEAD_BRANCH\" --state open --json number -q '.[0].number')\n if [ -z \"$PR_NUMBER\" ]; then\n echo \"No open PR found for branch $HEAD_BRANCH — PR creation failed\" >&2\n exit 1\n fi\n echo \"$PR_NUMBER\" > \"$ARTIFACTS_DIR/.pr-number\"\n PR_URL=$(gh pr view \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --json url -q '.url')\n echo \"$PR_URL\" > \"$ARTIFACTS_DIR/.pr-url\"\n ```\n depends_on: [validate]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 7: REVIEW\n # ═══════════════════════════════════════════════════════════════\n\n - id: verify-pr-base\n bash: |\n set -euo pipefail\n # Pin to the origin remote — in a fork clone, gh otherwise queries the upstream parent\n ORIGIN_REPO=$(git remote get-url origin | sed -E 's#^.*[:/]([^/]+/[^/]+)$#\\1#; s#\\.git$##')\n HEAD_BRANCH=$(git rev-parse --abbrev-ref HEAD)\n PR_NUMBER=$(gh pr list --repo \"$ORIGIN_REPO\" --head \"$HEAD_BRANCH\" --state open --json number -q '.[0].number')\n if [ -z \"$PR_NUMBER\" ]; then\n echo \"No open PR found for branch $HEAD_BRANCH\" >&2\n exit 1\n fi\n EXPECTED=\"$BASE_BRANCH\"\n ACTUAL=$(gh pr view \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --json baseRefName -q '.baseRefName')\n if [ \"$ACTUAL\" != \"$EXPECTED\" ]; then\n echo \"Base mismatch on PR #$PR_NUMBER: expected=$EXPECTED actual=$ACTUAL — re-targeting\" >&2\n gh pr edit \"$PR_NUMBER\" --repo \"$ORIGIN_REPO\" --base \"$EXPECTED\"\n else\n echo \"PR base verified: $EXPECTED\"\n fi\n depends_on: [create-pr]\n\n - id: review-scope\n command: archon-pr-review-scope\n depends_on: [verify-pr-base]\n context: fresh\n\n - id: review-classify\n prompt: |\n You are a PR review classifier. Analyze the PR scope and determine\n which review agents should run.\n\n ## PR Scope\n\n $review-scope.output\n\n ## Rules\n\n - **Code review**: ALWAYS run. This is mandatory for every PR. It also checks\n the PR against CLAUDE.md rules and project conventions.\n - **Error handling**: Run if the diff touches code with try/catch, error handling,\n async/await, or adds new failure paths.\n - **Test coverage**: Run if the diff touches source code (not just tests, docs, or config).\n - **Comment quality**: Run if the diff adds or modifies comments, docstrings, JSDoc,\n or significant documentation within code files.\n - **Docs impact**: Run if the diff adds/removes/renames public APIs, commands, CLI flags,\n environment variables, or user-facing features.\n\n Provide your reasoning for each decision.\n depends_on: [review-scope]\n model: small\n allowed_tools: []\n context: fresh\n output_format:\n type: object\n properties:\n run_code_review:\n type: string\n enum: [\"true\", \"false\"]\n run_error_handling:\n type: string\n enum: [\"true\", \"false\"]\n run_test_coverage:\n type: string\n enum: [\"true\", \"false\"]\n run_comment_quality:\n type: string\n enum: [\"true\", \"false\"]\n run_docs_impact:\n type: string\n enum: [\"true\", \"false\"]\n reasoning:\n type: string\n required:\n - run_code_review\n - run_error_handling\n - run_test_coverage\n - run_comment_quality\n - run_docs_impact\n - reasoning\n\n # Code review always runs — mandatory\n - id: code-review\n command: archon-code-review-agent\n depends_on: [review-classify]\n context: fresh\n\n - id: error-handling\n command: archon-error-handling-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_error_handling == 'true'\"\n context: fresh\n\n - id: test-coverage\n command: archon-test-coverage-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_test_coverage == 'true'\"\n context: fresh\n\n - id: comment-quality\n command: archon-comment-quality-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_comment_quality == 'true'\"\n context: fresh\n\n - id: docs-impact\n command: archon-docs-impact-agent\n depends_on: [review-classify]\n when: \"$review-classify.output.run_docs_impact == 'true'\"\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 8: SYNTHESIZE + SELF-FIX\n # ═══════════════════════════════════════════════════════════════\n\n - id: synthesize\n command: archon-synthesize-review\n depends_on: [code-review, error-handling, test-coverage, comment-quality, docs-impact]\n trigger_rule: one_success\n context: fresh\n\n - id: self-fix\n command: archon-self-fix-all\n depends_on: [synthesize]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 9: SIMPLIFY\n # ═══════════════════════════════════════════════════════════════\n\n - id: simplify\n command: archon-simplify-changes\n depends_on: [self-fix]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 10: REPORT\n # ═══════════════════════════════════════════════════════════════\n\n - id: report\n command: archon-issue-completion-report\n depends_on: [simplify]\n context: fresh\n", "archon-idea-to-pr": "name: archon-idea-to-pr\ndescription: |\n Use when: You have a feature idea or description and want end-to-end development.\n Input: Feature description in natural language, or path to a PRD file\n Output: PR ready for merge with comprehensive review completed\n\n Full workflow:\n 1. Create comprehensive implementation plan with codebase analysis\n 2. Setup branch and extract scope limits\n 3. Verify plan research is still valid\n 4. Implement all tasks with type-checking\n 5. Run full validation suite\n 6. Create PR with template, mark ready\n 7. Comprehensive code review (5 parallel agents with scope limit awareness)\n 8. Synthesize and fix review findings\n 9. Final summary with decision matrix -> GitHub comment + follow-up recommendations\n\n NOT for: Executing existing plans (use archon-plan-to-pr), quick fixes, standalone reviews.\n\nnodes:\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 0: CREATE PLAN\n # ═══════════════════════════════════════════════════════════════════\n\n - id: create-plan\n command: archon-create-plan\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 1: SETUP\n # ═══════════════════════════════════════════════════════════════════\n\n - id: plan-setup\n command: archon-plan-setup\n depends_on: [create-plan]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 2: CONFIRM PLAN\n # ═══════════════════════════════════════════════════════════════════\n\n - id: confirm-plan\n command: archon-confirm-plan\n depends_on: [plan-setup]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 3: IMPLEMENT\n # ═══════════════════════════════════════════════════════════════════\n\n - id: implement-tasks\n command: archon-implement-tasks\n depends_on: [confirm-plan]\n context: fresh\n provider: claude\n model: large\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 4: VALIDATE\n # ═══════════════════════════════════════════════════════════════════\n\n - id: validate\n command: archon-validate\n depends_on: [implement-tasks]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 5: FINALIZE PR\n # ═══════════════════════════════════════════════════════════════════\n\n - id: finalize-pr\n command: archon-finalize-pr\n depends_on: [validate]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 6-7: CODE REVIEW + FIX (shared building block)\n # Inlines archon-review-block: verify-pr-base -> review-scope -> sync ->\n # 5 parallel review agents -> synthesize -> implement-fixes.\n # ═══════════════════════════════════════════════════════════════════\n\n - id: review\n include: archon-review-block\n depends_on: [finalize-pr]\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 8: FINAL SUMMARY & FOLLOW-UP\n # ═══════════════════════════════════════════════════════════════════\n\n - id: workflow-summary\n command: archon-workflow-summary\n depends_on: [review]\n context: fresh\n", "archon-interactive-prd": "name: archon-interactive-prd\ndescription: |\n Use when: User wants to create a PRD through guided conversation.\n Triggers: \"create a prd\", \"new prd\", \"interactive prd\", \"plan a feature\",\n \"product requirements\", \"write a prd\".\n NOT for: Autonomous PRD generation without human input (use archon-ralph-generate).\n\n Interactive workflow that guides the user through problem-first PRD creation:\n 1. Understand the idea → ask foundation questions → wait for answers\n 2. Research market & codebase → ask deep dive questions → wait for answers\n 3. Assess technical feasibility → ask scope questions → wait for answers\n 4. Generate PRD → validate technical claims against codebase → output\n\nprovider: claude\ninteractive: true\n\nnodes:\n # ═══════════════════════════════════════════════════════════════\n # PHASE 1: INITIATE — Understand the idea\n # ═══════════════════════════════════════════════════════════════\n\n - id: initiate\n model: medium\n prompt: |\n You are a sharp product manager starting a PRD creation process.\n You think from first principles — start with primitives, not features.\n\n The user wants to build: $ARGUMENTS\n\n If the input is clear, restate your understanding in 2-3 sentences and confirm:\n \"I understand you want to build: {restated understanding}. Is this correct?\"\n\n If the input is vague or empty, ask:\n \"What do you want to build? Describe the product, feature, or capability.\"\n\n Then present the Foundation Questions (all at once — the user will answer in the next step):\n\n **Foundation Questions:**\n\n 1. **Who** has this problem? Be specific — not just \"users\" but what type of person/role?\n 2. **What** problem are they facing? Describe the observable pain, not the assumed need.\n 3. **Why** can't they solve it today? What alternatives exist and why do they fail?\n 4. **Why now?** What changed that makes this worth building?\n 5. **How** will you know if you solved it? What would success look like?\n\n Keep it conversational. Don't generate any PRD content yet.\n\n # ═══════════════════════════════════════════════════════════════\n # GATE 1: User answers foundation questions\n # ═══════════════════════════════════════════════════════════════\n\n - id: foundation-gate\n approval:\n message: \"Answer the foundation questions above. Your answers will guide the research phase.\"\n capture_response: true\n depends_on: [initiate]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 2: GROUNDING — Research market & codebase\n # ═══════════════════════════════════════════════════════════════\n\n - id: research\n model: medium\n prompt: |\n You are researching context for a PRD. Think from first principles —\n what already exists before proposing anything new.\n\n **The idea**: $ARGUMENTS\n\n **User's foundation answers**:\n $foundation-gate.output\n\n Research the landscape:\n\n 1. Search the web for similar products, competitors, and how others solve this problem\n 2. **Explore the codebase deeply** — find related existing functionality, APIs, UI components,\n database tables, and patterns. Read actual files, don't assume. Note exact file paths and\n what each file does.\n 3. Look for common patterns, anti-patterns, and recent trends\n\n **First principles rule**: Before suggesting anything new, verify what already exists.\n If there's an existing API endpoint, UI page, or component that partially solves the\n problem, note it explicitly. The best solution extends what exists, not replaces it.\n\n Present a summary to the user:\n\n **What I found:**\n - {Market insights — similar products, competitor approaches}\n - {What already exists in the codebase — specific files, endpoints, components}\n - {Key insight that might change the approach}\n\n Then ask the **Deep Dive Questions**:\n\n 1. **Vision**: In one sentence, what's the ideal end state if this succeeds wildly?\n 2. **Primary User**: Describe your most important user — their role, context, and what triggers their need.\n 3. **Job to Be Done**: Complete this: \"When [situation], I want to [motivation], so I can [outcome].\"\n 4. **Non-Users**: Who is explicitly NOT the target?\n 5. **Constraints**: What limitations exist? (time, budget, technical, regulatory)\n\n Does the research change or refine your thinking? Answer the deep dive questions.\n depends_on: [foundation-gate]\n\n # ═══════════════════════════════════════════════════════════════\n # GATE 2: User answers deep dive questions\n # ═══════════════════════════════════════════════════════════════\n\n - id: deepdive-gate\n approval:\n message: \"Answer the deep dive questions above (vision, primary user, JTBD, constraints). Add any adjustments from the research.\"\n capture_response: true\n depends_on: [research]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 3: TECHNICAL GROUNDING — Feasibility from what exists\n # ═══════════════════════════════════════════════════════════════\n\n - id: technical\n model: medium\n prompt: |\n You are assessing technical feasibility for a PRD.\n Think from first principles — start with what exists, not what you'd build from scratch.\n\n **The idea**: $ARGUMENTS\n **Foundation answers**: $foundation-gate.output\n **Deep dive answers**: $deepdive-gate.output\n\n **CRITICAL**: Explore the codebase by READING actual files. Do not guess or assume.\n For every claim you make about the codebase, cite the exact file and line.\n\n 1. **What already exists** that partially solves this problem?\n - Read existing API endpoints, DB queries, UI components\n - Note exact function names, table schemas, component names\n - What data is already being collected/stored?\n 2. **What's the smallest change** to the existing system that solves the core problem?\n - Prefer extending existing files over creating new ones\n - Prefer using existing endpoints over creating new ones\n - Prefer adding to existing UI pages over new pages\n 3. **What are the actual primitives** we need?\n - A new DB query? An existing one that needs a parameter?\n - A new component? Or an existing component that needs a prop?\n - A new endpoint? Or an existing endpoint that already returns the data?\n 4. **What's the risk?**\n - Where could this go wrong?\n - What assumptions need validation?\n\n Present a summary:\n\n **What Already Exists (verified by reading code):**\n - {endpoint/component/query} at `{file:line}` — {what it does}\n - {endpoint/component/query} at `{file:line}` — {what it does}\n\n **Smallest Change to Solve the Problem:**\n - {change 1}: {extend/modify} `{file}` — {what to do}\n - {change 2}: {extend/modify} `{file}` — {what to do}\n\n **Technical Context:**\n - Feasibility: {HIGH/MEDIUM/LOW} because {reason}\n - Key risk: {main concern}\n - Estimated phases: {rough breakdown}\n\n Then ask the **Scope Questions**:\n\n 1. **MVP Definition**: What's the absolute minimum to test if this works?\n 2. **Must Have vs Nice to Have**: What 2-3 things MUST be in v1? What can wait?\n 3. **Key Hypothesis**: Complete this: \"We believe [capability] will [solve problem] for [users]. We'll know we're right when [measurable outcome].\"\n 4. **Out of Scope**: What are you explicitly NOT building?\n 5. **Open Questions**: What uncertainties could change the approach?\n depends_on: [deepdive-gate]\n\n # ═══════════════════════════════════════════════════════════════\n # GATE 3: User answers scope questions\n # ═══════════════════════════════════════════════════════════════\n\n - id: scope-gate\n approval:\n message: \"Answer the scope questions above (MVP, must-haves, hypothesis, exclusions). This is the final input before PRD generation.\"\n capture_response: true\n depends_on: [technical]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 4: GENERATE — Write the PRD\n # ═══════════════════════════════════════════════════════════════\n\n - id: generate\n model: medium\n prompt: |\n You are generating a PRD from the user's guided inputs.\n\n **The idea**: $ARGUMENTS\n **Foundation answers**: $foundation-gate.output\n **Deep dive answers**: $deepdive-gate.output\n **Scope answers**: $scope-gate.output\n\n Generate a complete PRD file at `$ARTIFACTS_DIR/prds/{kebab-case-name}.prd.md`.\n\n First create the directory:\n ```bash\n mkdir -p $ARTIFACTS_DIR/prds\n ```\n\n **First principles rule**: Before writing the Technical Approach section, READ the\n actual codebase files you're referencing. Verify:\n - File paths exist\n - Function/component names are correct\n - API endpoints you reference actually exist (or note they need to be created)\n - DB table and column names match the schema\n - Event type names match the constants in the code\n\n The PRD must include ALL of these sections, filled from the user's answers:\n\n 1. **Problem Statement** — from foundation answers (who/what/why)\n 2. **Evidence** — from research findings and user's evidence\n 3. **Proposed Solution** — synthesized from all inputs. Prefer extending existing\n primitives over creating new ones.\n 4. **Key Hypothesis** — from scope answers\n 5. **What We're NOT Building** — from scope answers\n 6. **Success Metrics** — from foundation \"how will you know\" + scope\n 7. **Open Questions** — from scope answers\n 8. **Users & Context** — from deep dive (primary user, JTBD, non-users)\n 9. **Solution Detail** — MoSCoW table from scope must-haves, MVP definition\n 10. **Technical Approach** — from technical feasibility. MUST reference actual\n verified file paths, function names, and schemas. Mark anything unverified\n as \"needs verification\".\n 11. **Implementation Phases** — from technical breakdown, with status table\n and parallel opportunities\n 12. **Decisions Log** — key decisions made during the conversation\n\n **Rules:**\n - If info is missing, write \"TBD — needs research\" not filler\n - Be specific and concrete, not generic\n - Every file path in Technical Approach must be verified by reading the file\n - Prefer \"extend X\" over \"create new Y\" in implementation phases\n\n After writing the file, output the file path only — the validator will check it.\n depends_on: [scope-gate]\n\n # ═══════════════════════════════════════════════════════════════\n # PHASE 5: VALIDATE — Check technical claims against codebase\n # ═══════════════════════════════════════════════════════════════\n\n - id: validate\n model: medium\n prompt: |\n You are a technical validator checking a PRD for accuracy.\n\n Read the PRD file that was just generated. The generate node output the file path:\n $generate.output\n\n Find the PRD file — check `$ARTIFACTS_DIR/prds/` for the most recently created `.prd.md` file:\n ```bash\n ls -t $ARTIFACTS_DIR/prds/*.prd.md | head -1\n ```\n\n Read the entire PRD, then verify EVERY technical claim against the actual codebase:\n\n **Check 1: File paths** — For every file referenced in \"Technical Approach\" and\n \"Implementation Phases\", verify it exists. If it doesn't, note the correction.\n\n **Check 2: API endpoints** — For every endpoint mentioned, check if it already exists\n in `packages/server/src/routes/api.ts`. If it does, the PRD should say \"extend\" not \"create\".\n If the PRD proposes a new endpoint for data that an existing endpoint already returns,\n flag it.\n\n **Check 3: DB schemas** — For every table/column referenced, verify the actual names\n in the migration files or schema code. Check event type names against the\n `WORKFLOW_EVENT_TYPES` constant.\n\n **Check 4: UI components** — For every component referenced, verify it exists.\n If the PRD proposes a new page but an existing page already serves a similar purpose,\n flag it.\n\n **Check 5: Function/type names** — Verify function names, type names, and interface\n names are correct.\n\n After checking, if there are ANY corrections needed:\n 1. Edit the PRD file directly — fix incorrect names, paths, and references\n 2. Add a `## Validation Notes` section at the bottom documenting what was corrected\n\n If everything checks out, add:\n ```\n ## Validation Notes\n\n All technical references verified against codebase. No corrections needed.\n ```\n\n Output a summary of what was checked and corrected:\n\n ```\n ## PRD Validated\n\n **File**: `{prd-path}`\n **Checks**: {N} file paths, {N} endpoints, {N} DB references, {N} components\n **Corrections**: {count}\n {list corrections if any}\n\n To start implementation: `/prp-plan {prd-path}`\n ```\n depends_on: [generate]\n", "archon-issue-review-full": "name: archon-issue-review-full\ndescription: |\n Use when: User wants a FULL, COMPREHENSIVE fix + review pipeline for a GitHub issue.\n Triggers: \"full review\", \"comprehensive fix\", \"fix with full review\", \"deep review\", \"issue review full\".\n NOT for: Simple issue fixes (use archon-fix-github-issue instead),\n questions about issues, CI failures, PR reviews, general exploration.\n\n Full workflow:\n 1. Investigate issue -> root cause analysis, implementation plan\n 2. Implement fix -> code changes, tests, PR creation\n 3. Comprehensive review -> 5 parallel agents with scope awareness\n 4. Fix review issues -> address CRITICAL/HIGH findings\n 5. Final summary -> decision matrix, follow-up recommendations\n\nnodes:\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 1: INVESTIGATE\n # ═══════════════════════════════════════════════════════════════════\n\n - id: investigate\n command: archon-investigate-issue\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 2: IMPLEMENT\n # ═══════════════════════════════════════════════════════════════════\n\n - id: implement\n command: archon-implement-issue\n depends_on: [investigate]\n context: fresh\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 3-4: CODE REVIEW + FIX (shared building block)\n # Inlines archon-review-block: verify-pr-base -> review-scope -> sync ->\n # 5 parallel review agents -> synthesize -> implement-fixes.\n # ═══════════════════════════════════════════════════════════════════\n\n - id: review\n include: archon-review-block\n depends_on: [implement]\n\n # ═══════════════════════════════════════════════════════════════════\n # PHASE 5: FINAL SUMMARY\n # ═══════════════════════════════════════════════════════════════════\n\n - id: summary\n command: archon-workflow-summary\n depends_on: [review]\n context: fresh\n",