.workflows/solve-issue.yaml

@@ -1,5 +1,5 @@
 name: "solve-issue"
-description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds."
+description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds. Uses pnpm."
 roles:
   planner:
     description: "Analyzes issue and outputs a TDD test spec"
@@ -8,34 +8,64 @@ roles:
       - issue-analysis
       - planning
     procedure: |
-      On first run (no previous steps):
+      CRITICAL: First, determine which mode you are in by scanning the task prompt.
+      Choose EXACTLY ONE mode — do NOT default to Mode A if Mode B applies.
+
+      **How to choose:**
+      - If the prompt contains ANY of these keywords: "PR #", "PR#", "pulls/", "继续修复", "continue", "review feedback", "existing branch", "fix/", or mentions a branch name → **Mode B**
+      - If the prompt was forwarded from tester with fix_spec → **Mode C**
+      - Otherwise → **Mode A**
+
+      **Mode A — Fresh issue (first time, no existing PR):**
       1. Read the issue and all comments from Gitea using `tea issues <number> -r <owner/repo>`
       2. Look for project conventions files (CLAUDE.md, CONTRIBUTING.md, .cursor/rules/) in the repo
       3. Assess whether the issue has enough information to produce a test spec
       4. If insufficient info: comment on the issue via `echo "..." | tea comment <number> -r <owner/repo>` (skip if you already commented), then output $status=insufficient_info
       5. If sufficient: produce a detailed TDD test spec in markdown covering all scenarios
+      6. The test spec is stored in CAS automatically by the uwf pipeline (agents do not need to call `ocas put` directly)
+      7. Output **$status=ready** with plan hash and repoPath
 
-      On subsequent runs (bounced back by tester with fix_spec):
+      **Mode B — Continue on existing PR (prompt mentions PR, branch, or review feedback):**
+      YOU MUST output $status=continue (NOT ready) when in this mode.
+      1. Extract the PR number and branch name from the prompt
+      2. Read the PR and its review comments from Gitea: `tea pr <number> --comments -r <owner/repo>`
+      3. Read the existing issue for full context: `tea issues <number> -r <owner/repo>`
+      4. Look for project conventions files (CLAUDE.md, CONTRIBUTING.md, .cursor/rules/) in the repo
+      5. Produce a TDD test spec that ONLY covers the changes requested in the review — do NOT re-spec already-implemented features
+      6. The test spec is stored in CAS automatically by the uwf pipeline (agents do not need to call `ocas put` directly)
+      7. Find the existing worktree: `git worktree list` and locate the branch
+      8. Output **$status=continue** with plan hash, repoPath, branch name, and worktree path
+
+      **Mode C — Bounced back by tester (fix_spec):**
       1. Read the tester's output from the previous step to understand what's wrong with the spec
       2. Revise the test spec accordingly
+      3. The test spec is stored in CAS automatically by the uwf pipeline (agents do not need to call `ocas put` directly)
+      4. Output **$status=ready** with plan hash and repoPath
 
-      After producing the test spec:
-      1. Store it via `uwf cas put-text "<markdown content>"` and capture the returned hash
-      2. Put the hash in frontmatter.plan (required when $status=ready)
-      3. Set repoPath to the absolute path of the repository root
-    output: "Output a brief summary of the test spec. Set $status to ready (with plan hash and repoPath) or insufficient_info."
+      IMPORTANT: Extract the repo remote (owner/repo) from git:
+      ```bash
+      git remote get-url origin | sed 's|.*[:/]\([^/]*/[^.]*\).*|\1|'
+      ```
+      Store the result as repoRemote in your frontmatter output so downstream roles can use it.
+    output: "Output a brief summary of the test spec. Set $status to ready (fresh), continue (existing PR), or insufficient_info."
     frontmatter:
       oneOf:
-        - type: object
-          properties:
+        - properties:
             $status: { const: "ready" }
             plan: { type: string }
             repoPath: { type: string }
           required: [$status, plan, repoPath]
-        - type: object
-          properties:
+        - properties:
+            $status: { const: "continue" }
+            plan: { type: string }
+            repoPath: { type: string }
+            branch: { type: string }
+            worktree: { type: string }
+          required: [$status, plan, repoPath, branch, worktree]
+        - properties:
             $status: { const: "insufficient_info" }
-          required: [$status]
+            reason: { type: string }
+          required: [$status, reason]
   developer:
     description: "TDD implementation per test spec"
     goal: "You are a developer agent. You implement code changes following TDD — write tests first, then implementation."
@@ -51,32 +81,46 @@ roles:
       3. First time (no existing branch):
          - `git worktree add .worktrees/fix/<issue-number>-<short-slug> -b fix/<issue-number>-<short-slug> origin/main`
          - `cd .worktrees/fix/<issue-number>-<short-slug> && pnpm install`
-      4. If bounced back from reviewer or tester (branch already exists):
+      4. If continuing on existing branch (prompt says "Continue work on existing branch" or provides a worktree path):
+         - cd directly into the worktree path provided in the prompt
+         - `git fetch origin && git rebase origin/main`
+         - Do NOT create a new branch or worktree
+      5. If bounced back from reviewer or tester (branch already exists but no explicit worktree path):
          - cd into the existing worktree under `.worktrees/fix/<issue-number>-<short-slug>`
          - `git fetch origin && git rebase origin/main`
-      5. ALL subsequent work must happen inside the worktree directory.
+      6. ALL subsequent work must happen inside the worktree directory.
 
       Then implement TDD:
-      6. Read the test spec from CAS: `uwf cas get <plan hash>` (find the hash from the planner's output in your task prompt)
+      6. Read the test spec from CAS: `ocas get <plan hash>` (find the hash from the planner's output in your task prompt)
       7. If bounced back from reviewer or tester: read the previous role's feedback in your task prompt
       8. Write tests first based on the spec
       9. Implement the code to make tests pass
       10. Ensure `pnpm run build` passes with no errors
       11. Run `pnpm test` to verify all tests pass
 
+      After implementation, before reporting done:
+      12. Add a changeset file (`.changeset/<short-slug>.md`) with correct bump type:
+          - `patch` for bug fixes, internal refactors, test-only changes
+          - `minor` for new features, new CLI commands, new API surfaces
+          - `major` for breaking changes
+          List every affected package in the changeset frontmatter.
+      13. Update documentation if the change affects user-facing behavior:
+          - `README.md` — usage examples, feature descriptions
+          - `.cards/` — architecture decision records (if applicable)
+          - CLI prompt subcommand output (if CLI help text changes)
+          - CLI `--help` text (if flags/commands are added or changed)
+
       If you cannot complete the implementation (e.g. the issue is too complex, blocked by external factors,
       or repeated attempts fail), set $status=failed with a reason.
     output: "List all files changed and provide a summary. Set $status to done (with branch/worktree), or failed (with reason)."
     frontmatter:
       oneOf:
-        - type: object
-          properties:
+        - properties:
             $status: { const: "done" }
             branch: { type: string }
             worktree: { type: string }
           required: [$status, branch, worktree]
-        - type: object
-          properties:
+        - properties:
             $status: { const: "failed" }
             reason: { type: string }
           required: [$status, reason]
@@ -104,19 +148,25 @@ roles:
       - No `console.log` in production code
       - No dynamic imports in production code
 
+      Documentation & changeset checks:
+      6. Changeset exists in `.changeset/` with correct bump type (`patch`/`minor`/`major`) and lists all affected packages
+      7. If the change is user-facing, documentation is updated:
+         - `README.md` reflects new/changed behavior
+         - `.cards/` architecture cards updated if design decisions changed
+         - CLI prompt subcommand output updated (if it generates skill/reference content)
+         - CLI `--help` text matches new flags/commands
+
       Only review standards compliance. Do NOT test functionality.
       If rejecting, you MUST explain the specific reason in your output.
     output: "Explain your decision with specific file/line references. Set $status to approved (with branch/worktree) or rejected (with comments)."
     frontmatter:
       oneOf:
-        - type: object
-          properties:
+        - properties:
             $status: { const: "approved" }
             branch: { type: string }
             worktree: { type: string }
           required: [$status, branch, worktree]
-        - type: object
-          properties:
+        - properties:
             $status: { const: "rejected" }
             comments: { type: string }
             worktree: { type: string }
@@ -130,7 +180,7 @@ roles:
       The worktree path is provided in your task prompt. cd into it first.
 
       1. Run `pnpm test` for automated test verification
-      2. Read the test spec from CAS: `uwf cas get <plan hash>` (find the hash from the planner step in the thread history)
+      2. Read the test spec from CAS: `ocas get <plan hash>` (find the hash from the planner step in the thread history)
       3. Verify each scenario in the spec is covered and passing
       4. Determine outcome:
          - passed: all scenarios verified, tests pass
@@ -139,19 +189,16 @@ roles:
     output: "Report test results per scenario. Set $status to passed (with branch/worktree), fix_code (with report), or fix_spec (with report)."
     frontmatter:
       oneOf:
-        - type: object
-          properties:
+        - properties:
             $status: { const: "passed" }
             branch: { type: string }
             worktree: { type: string }
           required: [$status, branch, worktree]
-        - type: object
-          properties:
+        - properties:
             $status: { const: "fix_code" }
             report: { type: string }
           required: [$status, report]
-        - type: object
-          properties:
+        - properties:
             $status: { const: "fix_spec" }
             report: { type: string }
           required: [$status, report]
@@ -178,13 +225,11 @@ roles:
     output: "Include PR URL on success or error log on failure. Set $status to committed (with prUrl) or hook_failed (with error)."
     frontmatter:
       oneOf:
-        - type: object
-          properties:
+        - properties:
             $status: { const: "committed" }
             prUrl: { type: string }
           required: [$status, prUrl]
-        - type: object
-          properties:
+        - properties:
             $status: { const: "hook_failed" }
             error: { type: string }
           required: [$status, error]
@@ -193,8 +238,9 @@ graph:
     new: { role: "planner", prompt: "Analyze the issue and produce an implementation plan." }
     resume: { role: "planner", prompt: "Review the previous run output and continue the work." }
   planner:
-    insufficient_info: { role: "$END", prompt: "Insufficient information to proceed; end the workflow." }
+    insufficient_info: { role: "$SUSPEND", prompt: "信息不足，需要补充：{{{reason}}}" }
     ready: { role: "developer", prompt: "Implement the TDD test spec (CAS hash: {{{plan}}}) in repo {{{repoPath}}}." }
+    continue: { role: "developer", prompt: "Continue work on existing branch {{{branch}}} at worktree {{{worktree}}}. Implement the revised TDD test spec (CAS hash: {{{plan}}}) in repo {{{repoPath}}}. Do NOT create a new branch or worktree — cd into the existing worktree and work there." }
   developer:
     done: { role: "reviewer", prompt: "Review branch {{{branch}}} at {{{worktree}}} for code standards compliance." }
     failed: { role: "$END", prompt: "Developer failed: {{{reason}}}. Ending workflow." }