writing-plans: keep the commit caveat out of the task template

This commit is contained in:
Drew Ritter
2026-07-20 02:55:09 -07:00
parent 2e11d4c79a
commit 374ea4f146

View File

@@ -127,9 +127,9 @@ Expected: PASS
git add tests/path/test.py src/path/file.py git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature" git commit -m "feat: add specific feature"
``` ```
````
Commit messages describe the change. Never mandate session boilerplate — trailers, bylines, model names — as a per-commit rule; what your session stamps on its commits is not a requirement of the work. Commit messages describe the change. Never mandate session boilerplate — trailers, bylines, model names — as a per-commit rule; what your session stamps on its commits is not a requirement of the work.
````
## No Placeholders ## No Placeholders
@@ -151,10 +151,7 @@ After writing the complete plan, look at the spec with fresh eyes and check the
**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug. **3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
**4. Constraint hygiene:** Does any Global Constraint mandate a per-commit **4. Constraint hygiene:** Does any Global Constraint mandate a per-commit cosmetic absolute, name the authoring model or session, or assert an environment fact (version floor, platform, path) you did not verify? Cut or verify it.
cosmetic absolute, name the authoring model or session, or assert an
environment fact (version floor, platform, path) you did not verify? Cut
or verify it.
If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task. If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.