Merge refactor/9-committer-agent-workflow: committer agent + forbid --author

This commit is contained in:
小橘 2026-04-29 11:09:12 +00:00
commit 85fac3158d
4 changed files with 13 additions and 10 deletions

View File

@ -78,7 +78,8 @@ workflows/<name>/
| `createCursorRole` | Needs file system access (code generation, planning) | planner, coder | | `createCursorRole` | Needs file system access (code generation, planning) | planner, coder |
| `createHermesRole` | Needs shell + tools (testing, reviewing) | tester, reviewer | | `createHermesRole` | Needs shell + tools (testing, reviewing) | tester, reviewer |
| `createLlmRole` | Pure LLM reasoning, no tools | analysis roles | | `createLlmRole` | Pure LLM reasoning, no tools | analysis roles |
| Direct `Role<Meta>` | No LLM needed, scripted logic | committer | | `createRole(hermesAdapter, …)` | Agent role with LLM + shell (branch/commit/push from thread context) | solve-issue committer, publish |
| Direct `Role<Meta>` | No LLM needed, scripted logic | thin wrappers only |
### Meta Convention ### Meta Convention
@ -87,7 +88,8 @@ Meta is a **routing signal only** — one boolean per role:
- `{ done: boolean }` — coder - `{ done: boolean }` — coder
- `{ approved: boolean }` — reviewer - `{ approved: boolean }` — reviewer
- `{ passed: boolean }` — tester - `{ passed: boolean }` — tester
- `{ success: boolean }` — committer - `{ committed: boolean }` — committer (solve-issue: branch created, pushed)
- `{ success: boolean }` — publish (PR opened)
### Standard Flow ### Standard Flow

View File

@ -22,16 +22,17 @@ In the thread, locate \`---SOLVE_ISSUE_PARSE---\` and \`---SOLVE_ISSUE_REPO---\`
## Steps (in order) ## Steps (in order)
1. \`cd\` to the repo **path** from SOLVE_ISSUE_REPO. 1. \`cd\` to the repo **path** from SOLVE_ISSUE_REPO.
2. Run \`git status\`. There should be **uncommitted** changes from implement. If the tree is clean with nothing to commit, set **committed** to false and explain. 2. Run \`git rev-parse --abbrev-ref HEAD\` and compare with **defaultBranch** from SOLVE_ISSUE_REPO. Implement leaves changes **uncommitted** on the default branch — you should be on that branch with a dirty working tree. If you are not on the default branch, or the tree is clean with nothing to commit when you expected changes, set **committed** to false and explain (avoids empty PRs from wrong state).
3. Create a feature branch (do not work on the default branch directly): 3. Run \`git status\`. There should be **uncommitted** changes from implement. If the tree is clean with nothing to commit, set **committed** to false and explain.
4. Create a feature branch (do not work on the default branch directly):
- Name: \`fix/<number>-<short-slug>\` for fixes, or \`feat/<number>-<short-slug>\` if the issue is clearly a feature. - Name: \`fix/<number>-<short-slug>\` for fixes, or \`feat/<number>-<short-slug>\` if the issue is clearly a feature.
- **number** from SOLVE_ISSUE_PARSE. - **number** from SOLVE_ISSUE_PARSE.
- **slug**: lowercase, hyphens only, short (from issue title words). - **slug**: lowercase, hyphens only, short (from issue title words).
- Example: \`git checkout -b fix/42-auth-timeout\` - Example: \`git checkout -b fix/42-auth-timeout\`
4. \`git add -A\` 5. \`git add -A\`
5. Write a **conventional commit** message (e.g. \`fix(scope): summary\` or \`feat(scope): summary\`) describing **what** changed and **why**, using the thread (plan + implement context). 6. Write a **conventional commit** message (e.g. \`fix(scope): summary\` or \`feat(scope): summary\`) describing **what** changed and **why**, using the thread (plan + implement context).
6. \`git commit -m "<message>"\` — use a single \`-m\` for a one-line message, or multiple \`-m\` for body paragraphs if needed. 7. \`git commit -m "<message>"\` — use a single \`-m\` for a one-line message, or multiple \`-m\` for body paragraphs if needed. Do **not** pass \`--author\` — always use the repo's local git config identity.
7. \`git push -u origin <branch-name>\` 8. \`git push -u origin <branch-name>\`
**committed=true** only if you created the branch, committed successfully, and **push** succeeded. **committed=true** only if you created the branch, committed successfully, and **push** succeeded.

View File

@ -13,7 +13,7 @@ Your cwd is the target repository.
2. Run the project **build** (\`pnpm build\`, \`npm run build\`, etc.) and fix issues until build passes. 2. Run the project **build** (\`pnpm build\`, \`npm run build\`, etc.) and fix issues until build passes.
3. Multi-step: if you cannot finish this round, explain why and set **done** to false. 3. Multi-step: if you cannot finish this round, explain why and set **done** to false.
Do **not** run \`git checkout -b\`, \`git add\`, \`git commit\`, or \`git push\`. Branching and commits are handled by the **committer** step after you finish. Do **not** run \`git checkout -b\`, \`git add\`, \`git commit\`, or \`git push\`. **Never** create commits on any branch — branching and commits are handled by the **committer** step after you finish.
Then close with JSON: Then close with JSON:
\`\`\`json \`\`\`json

View File

@ -23,7 +23,7 @@ Find \`---SOLVE_ISSUE_PARSE---\` and \`---SOLVE_ISSUE_REPO---\` in prior message
- **## What** one short paragraph: what this PR does - **## What** one short paragraph: what this PR does
- **## Why** one short paragraph: motivation / issue - **## Why** one short paragraph: motivation / issue
- **## Changes** bullet list of notable changes - **## Changes** bullet list of notable changes
- **## Ref** the issue link above - **## Ref** include one line \`Fixes #<number>\` (same \`number\` from SOLVE_ISSUE_PARSE; closes/links the issue where supported) **and** the issue URL \`https://<host>/<owner>/<repo>/issues/<number>\`
4. Create the PR with **tea** (not curl/fetch to Gitea): 4. Create the PR with **tea** (not curl/fetch to Gitea):
- \`tea pr create --repo <owner>/<repo> --base <defaultBranch> --head <branch> --title "<your meaningful title>" --body <your markdown body>\` - \`tea pr create --repo <owner>/<repo> --base <defaultBranch> --head <branch> --title "<your meaningful title>" --body <your markdown body>\`
- You may use a heredoc or a temp file for \`--body\` if the shell requires it; keep the four sections in the body. - You may use a heredoc or a temp file for \`--body\` if the shell requires it; keep the four sections in the body.