fix(prompts): surface finding-field caps + required plan fields + make-quality gate so models can comply

The gateway enforces constraints the role prompts never communicated:
- finding fields capped (file/expected/actual <=300, criterion/fix <=500, evidence <=2000); an oversized actual is rejected 'malformed' and the finding never reaches the dev, who reworks blind and loops. Caps now stated in qa/pr_reviewer/cell_pm/main_pm prompts.
- i_will_work_on requires technical_considerations + risks on a fresh claim (signature defaults to None); developer.md now says so.
- developer.md now requires running make quality (incl. markdown reflow) before open_pr/i_am_done — reflow failures on docs are the live CI blocker.
This commit is contained in:
Renn F
2026-08-02 00:09:18 +02:00
parent dba231474b
commit 628b925f40
5 changed files with 6 additions and 6 deletions
+2 -2
View File
@@ -24,7 +24,7 @@ Your task's `description` and the `parent_context` chain that arrives via `evide
| Verb | What it does | Preconditions |
|---|---|---|
| `give_me_work()` | Returns your highest-priority task or `idle`. | None. |
| `i_will_work_on(task_id, plan, steps)` | Claims a `pending`/`needs_revision` task; resumes a `claimed`/`in_progress` task you own. Auto-creates branch on first claim. **`plan` is REQUIRED** (narrative; `tracing_gap missing=['plan']` if absent). **On a FRESH claim `steps` is REQUIRED and gated** — a non-empty list of `{title, description}` where every `description` is **≥60 chars** saying what that step actually does. `steps` is your execution checklist AND your progress checklist: as you finish each, call `progress(task_id, plan_step=<step id/order>, message=...)` and the % is computed from the checklist for you. Thin/title-only steps are rejected. Example step: `{"title": "Edit README", "description": "prepend the smoke-test HTML comment above the H1, leaving the rest of the file untouched"}`. **On resume** (`claimed`/`in_progress` you own) pass `plan='resume: <next step>'`; steps are not re-required. | Task assigned to you (or unassigned and matches your role/team); journal `decision` recorded; non-empty `plan`; substantive `steps` on fresh claim. |
| `i_will_work_on(task_id, plan, steps)` | Claims a `pending`/`needs_revision` task; resumes a `claimed`/`in_progress` task you own. Auto-creates branch on first claim. **`plan` is REQUIRED** (narrative; `tracing_gap missing=['plan']` if absent). **On a FRESH claim `steps` is REQUIRED and gated** — a non-empty list of `{title, description}` where every `description` is **≥60 chars** saying what that step actually does. `steps` is your execution checklist AND your progress checklist: as you finish each, call `progress(task_id, plan_step=<step id/order>, message=...)` and the % is computed from the checklist for you. Thin/title-only steps are rejected. **On a fresh claim `technical_considerations` (non-empty list[str]) and `risks` (list of `{risk, mitigation}`) are also REQUIRED** — the gateway rejects a fresh claim missing them (`incomplete_input`); pass them as separate kwargs, not inside `plan`. On resume they are not re-required. Example step: `{"title": "Edit README", "description": "prepend the smoke-test HTML comment above the H1, leaving the rest of the file untouched"}`. **On resume** (`claimed`/`in_progress` you own) pass `plan='resume: <next step>'`; steps are not re-required. | Task assigned to you (or unassigned and matches your role/team); journal `decision` recorded; non-empty `plan`; substantive `steps` on fresh claim. |
| `commit(message)` | Makes the git commit, auto-prefixes `[task-id]`, records a progress entry. This is the ONLY way to commit — the gateway covers the actual git operation. | Task in `in_progress`; on your branch. |
| `open_pr(task_id)` | Push your branch and open a PR. Run after your last commit, before `i_am_done`. `open_pr` is the finish line for *creating* the PR; use `pr_update` if you need to edit metadata afterward. | Task assigned to you; at least one commit; no PR yet. |
| `pr_update(task_id, title?, body?, reviewers?)` | Update an existing PR's title, body, or reviewer list. Use after `open_pr` if you need to correct title/body or assign a reviewer. At least one field must be set. **Do NOT bash-shim `gh pr edit`** — that path is blocked; this verb is the gateway-native replacement. | Task has `pr_number`; you are the assignee (or your PM). |
@@ -53,7 +53,7 @@ When you respawn, your task is in some lifecycle status. The next call follows f
| `claimed` (your prior claim is intact, work not yet started) | `i_will_work_on(task_id, plan='resume: <what you'll do next>')` — composes claim+set_plan+start; resumes from `claimed` into `in_progress` |
| `in_progress`, no commits yet | `evidence(task_id)` to confirm scope → start editing → `commit(message)` |
| `in_progress`, edits made, not yet tested | run tests via `Bash` → on green, `commit(message)` |
| `in_progress`, satisfied with the work | `note(scope='reflect', text='...')``note(scope='handoff', text='<dev_notes: what you built, key changes, risks>')``open_pr(task_id)``i_am_done(task_id, notes='...')` |
| `in_progress`, satisfied with the work | `note(scope='reflect', text='...')``note(scope='handoff', text='<dev_notes: what you built, key changes, risks>')``open_pr(task_id)` **`make quality` must pass locally first (run it after your last commit; fix every failure, including the markdown reflow check, before submitting)** → `i_am_done(task_id, notes='...')` |
| `needs_revision` (QA/PR-gate/PM/CEO bounced you) | `evidence(task_id)` to read `revision_findings` (the structured findings, not just `qa_notes` prose) → `note(scope='decision', text='fix plan: <what + why, per finding>')``i_will_work_on(task_id, plan='...')` → fix each finding → `i_am_done(task_id, notes, resolved_findings=[{finding_id, commit, note}, ...])` naming every one you resolved |
| `blocked` | If you can't unstick yourself, `i_am_blocked(reason='...')` and let your PM resolve it. Do NOT try other verbs on `blocked`. |
| `paused` | `resume(task_id)` (transitions paused → in_progress; only valid when you own a paused task) |