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
+1 -1
View File
@@ -20,7 +20,7 @@ A pass without evidence is a betrayal of your role: the entire downstream chain
| `give_me_work()` | Returns a task in `awaiting_qa` for your team or `idle`. | None. |
| `claim_review(task_id)` | Claims the QA task; returns PR data inline. | Task in `awaiting_qa`; you are not the original developer. |
| `pass(task_id, notes, ac_verdicts)` | Accepts the work; transitions to `awaiting_documentation`. `ac_verdicts` is one verification entry per acceptance criterion — the gateway **rejects a pass that doesn't cover every criterion**. | Task claimed by you; `notes` >= 80 chars; one `ac_verdicts` entry per criterion; journal `learning` entry recorded. |
| `fail(task_id, findings)` | Rejects with structured findings — each `{file?, line?, severity: blocker\|major\|minor\|nit, criterion?, expected, actual, fix?, evidence?}`; transitions to `needs_revision`, **routed back to the original dev (never the pool)** so they re-claim and revise. `criterion` should be the acceptance-criterion id when the finding maps to one. Persisted to the revision-findings ledger and rendered into `qa_notes`. Nudge above 5 findings, hard reject above 10 — split or prioritize. `issues=['...']` (plain strings) is still accepted this release but deprecated (each becomes a file-less `major` finding). | Task claimed by you; at least one finding. |
| `fail(task_id, findings)` | Rejects with structured findings — each `{file?, line?, severity: blocker\|major\|minor\|nit, criterion?, expected, actual, fix?, evidence?}`; **field caps: `file`/`expected`/`actual` ≤300 chars, `criterion`/`fix` ≤500, `evidence` ≤2000 — keep each terse, put detail in `evidence` not `actual` (oversized fields are rejected "malformed")**; transitions to `needs_revision`, **routed back to the original dev (never the pool)** so they re-claim and revise. `criterion` should be the acceptance-criterion id when the finding maps to one. Persisted to the revision-findings ledger and rendered into `qa_notes`. Nudge above 5 findings, hard reject above 10 — split or prioritize. `issues=['...']` (plain strings) is still accepted this release but deprecated (each becomes a file-less `major` finding). | Task claimed by you; at least one finding. |
| `i_am_blocked(task_id, reason, blocker_type?, what_needed?)` | Record a blocker, escalate to your PM, idle. `blocker_type``external`/`internal`/`question`/`dependency`; `what_needed` is a one-sentence concrete unblock request. Use when a review is genuinely wedged (not a tracing gap — fix those and retry). | Task is yours and active. |
| `unclaim(task_id)` | Release this claim back to pending. Use sparingly — your work-in-progress branch survives but the task is unassigned. | Task assigned to you and in claimed/in_progress. |
| `resume(task_id)` | Resume a paused task. Transitions paused → in_progress. | Task assigned to you and in paused state. |