fix: address review feedback from xingyue

1. npm/npx → bun/bunx (project standard)
2. Fix tea CLI usage (tea comment + -r flag)
3. cursor-agent → coding (abstract capability)
4. Clarify committer inherits developer's worktree
5. Mark meta.plan required when status=ready
6. PR description must follow What/Why/Changes/Ref template
7. Note maxRounds loop protection in description

.workflows/solve-issue.yaml

@@ -1,5 +1,5 @@
 name: "solve-issue"
-description: "TDD-driven issue resolution for small, focused changes"
+description: "TDD-driven issue resolution for small, focused changes. Loop protection relies on engine maxRounds."
 roles:
   planner:
     description: "Analyzes issue and outputs a TDD test spec"
@@ -9,10 +9,10 @@ roles:
       - planning
     procedure: |
       On first run (no previous steps):
-      1. Read the issue and all comments from Gitea using `tea issues <number> --repo <owner/repo>`
+      1. Read the issue and all comments from Gitea using `tea issues <number> -r <owner/repo>`
       2. Read CLAUDE.md (or equivalent project conventions file) to understand coding standards
       3. Assess whether the issue has enough information to produce a test spec
-      4. If insufficient info: comment on the issue via `tea issues comment <number> "..."` (skip if you already commented), then output status=insufficient_info and terminate
+      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 and terminate
       5. If sufficient: produce a detailed TDD test spec in markdown covering all scenarios
 
       On subsequent runs (bounced back by tester with fix_spec):
@@ -21,7 +21,7 @@ roles:
 
       After producing the test spec:
       1. Store it via `uwf cas put "<markdown content>"` and capture the returned hash
-      2. Put the hash in meta.plan
+      2. Put the hash in meta.plan (required when status=ready)
     output: "Output a brief summary of the test spec. The full spec is stored in CAS — put its hash in meta.plan."
     meta:
       type: object
@@ -36,14 +36,14 @@ roles:
     description: "TDD implementation per test spec"
     goal: "You are a developer agent. You implement code changes following TDD — write tests first, then implementation."
     capabilities:
-      - cursor-agent
+      - coding
     procedure: |
       1. Read the test spec from CAS: `uwf cas get <plan hash>` (find the hash from the latest planner step's meta.plan)
       2. If bounced back from reviewer or tester: read the previous role's output to understand what needs fixing
       3. Write tests first based on the spec
       4. Implement the code to make tests pass
-      5. Ensure `npm run build` passes with no errors
-      6. Run `npm test` to verify all tests pass
+      5. Ensure `bun run build` passes with no errors
+      6. Run `bun test` to verify all tests pass
     output: "List all files changed and provide a summary of the implementation."
     meta:
       type: object
@@ -60,8 +60,8 @@ roles:
       - static-analysis
     procedure: |
       Hard checks (must all pass):
-      1. `npm run build` — no build errors
-      2. `npx biome check` — no lint violations
+      1. `bun run build` — no build errors
+      2. `bunx biome check` — no lint violations
       3. TypeScript strict mode — no type errors
 
       Soft checks (review against CLAUDE.md conventions):
@@ -87,7 +87,7 @@ roles:
     capabilities:
       - testing
     procedure: |
-      1. Run `npm test` for automated test verification
+      1. Run `bun test` for automated test verification
       2. Read the test spec from CAS: `uwf cas get <plan hash>` (find the hash from the latest planner step's meta.plan)
       3. Verify each scenario in the spec is covered and passing
       4. Determine outcome:
@@ -107,12 +107,13 @@ roles:
     goal: "You are a committer agent. You create a clean commit and push a PR linking the original issue."
     capabilities: []
     procedure: |
+      Note: You inherit the developer's worktree and branch. Do NOT create a new branch.
       1. Stage all changes: `git add -A`
       2. Commit with a descriptive message referencing the issue: `git commit -m "type: description\n\nFixes #N"`
       3. Push the branch: `git push -u origin <branch-name>`
          - If push hook fails: capture the error log in your output, mark hook_failed
       4. On push success: create a PR via `tea pr create --title "..." --description "..."`
-         - PR description must link the issue with `Fixes #N`
+         - PR description must follow the project template: What / Why / Changes / Ref sections, with `Fixes #N` in Ref
     output: "Report whether commit and PR creation succeeded. Include the PR URL on success or error log on failure."
     meta:
       type: object