golem15/msd-core
4
0
Fork 0
Code Issues 1 Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix: reconcile planner action contract (#3326)

Browse Source 
* fix: reconcile planner action contract

The deep_work_rules workflow block was stronger than the planner agent contract: it required verbatim context copies and self-sufficient action text, so planners were incentivized to inline implementation code. Bound action content to directive prose with concrete identifiers, allow behavior/test acceptance criteria, and pin the cross-file contract with a regression test. Closes #3320.

* chore: add changeset for planner contract fix
This commit is contained in:
Tom Boucher
2026-05-09 19:27:36 -04:00
committed by GitHub
parent b5d15fe45d
commit cbc18f5e3e
4 changed files with 112 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
get-shit-done/workflows/plan-phase.md
View File

@@ -878,22 +878,24 @@ Every task MUST include these fields — they are NOT optional:
- Any file whose patterns, signatures, types, or conventions must be replicated or respected
2. **`<acceptance_criteria>`** — Verifiable conditions that prove the task was done correctly. Rules:
- Every criterion must be checkable with grep, file read, test command, or CLI output
- Every criterion must be checkable as a source assertion, behavior assertion, test command, or CLI output
- NEVER use subjective language ("looks correct", "properly configured", "consistent with")
- ALWAYS include exact strings, patterns, values, or command outputs that must be present
- Include exact strings, patterns, values, command outputs, or observable behavior where that is the right proof
- Examples:
- Code: `auth.py contains def verify_token(` / `test_auth.py exits 0`
- Behavior: `POST /api/auth/login returns 200 + httpOnly JWT cookie for valid credentials`
- Config: `.env.example contains DATABASE_URL=` / `Dockerfile contains HEALTHCHECK`
- Docs: `README.md contains '## Installation'` / `API.md lists all endpoints`
- Infra: `deploy.yml has rollback step` / `docker-compose.yml has healthcheck for db`
3. **`<action>`** — Must include CONCRETE values, not references. Rules:
- NEVER say "align X with Y", "match X to Y", "update to be consistent" without specifying the exact target state
- ALWAYS include the actual values: config keys, function signatures, SQL statements, class names, import paths, env vars, etc.
- If CONTEXT.md has a comparison table or expected values, copy them into the action verbatim
- The executor should be able to complete the task from the action text alone, without needing to read CONTEXT.md or reference files (read_first is for verification, not discovery)
- Include concrete identifiers and reference values: config keys, function signatures, SQL table names, class names, import paths, env vars, endpoint paths, etc.
- If CONTEXT.md has a comparison table or expected values, copy only the target identifiers/values needed to remove ambiguity
- Do not include full file contents, fenced code blocks, or complete implementations in `<action>`
- The executor should understand the intended target state from `<action>` and use `<read_first>` files for current implementation details, patterns, and source-of-truth context
**Why this matters:** Executor agents work from the plan text. Vague instructions like "update the config to match production" produce shallow one-line changes. Concrete instructions like "add DATABASE_URL=postgresql://... , set POOL_SIZE=20, add REDIS_URL=redis://..." produce complete work. The cost of verbose plans is far less than the cost of re-doing shallow execution.
**Why this matters:** Executor agents work from the plan text. Vague instructions like "update the config to match production" produce shallow one-line changes. Concrete instructions like "add DATABASE_URL, set POOL_SIZE=20, add REDIS_URL, and read config/runtime.ts before editing" produce complete work without turning the planner into the executor.
</deep_work_rules>
<quality_gate>
@@ -901,8 +903,8 @@ Every task MUST include these fields — they are NOT optional:
- [ ] Each plan has valid frontmatter
- [ ] Tasks are specific and actionable
- [ ] Every task has `<read_first>` with at least the file being modified
- [ ] Every task has `<acceptance_criteria>` with grep-verifiable conditions
- [ ] Every `<action>` contains concrete values (no "align X with Y" without specifying what)
- [ ] Every task has `<acceptance_criteria>` with behavior, test-command, CLI, or source assertions
- [ ] Every `<action>` contains concrete identifiers without fenced code blocks or full implementations
- [ ] Dependencies correctly identified
- [ ] Waves assigned for parallel execution
- [ ] must_haves derived from phase goal