task-observer: bugfix-tdd updates from 2026-07-31 - #79
Conversation
Step 5 was a one-liner that said only "invoke /learn". Expand it to require climbing to the highest actionable principle, naming the enforcement artifact, and promoting high-blast-radius patterns into mechanical guardrails rather than leaving them in the learning inbox.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2f3c243333
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| **Climb to the highest actionable principle.** Don't stop at the symptom ("removed | ||
| field still referenced"). Ask which shared contract changed, who else could be | ||
| affected, and what the most general still-true rule is ("when a shared contract | ||
| changes, all consumers must update"). |
There was a problem hiding this comment.
Defer abstraction until the evidence supports it
For an isolated, low-risk bug with no established recurrence, this instruction now forces the agent to invent a general principle and guardrail. That contradicts the canonical learning contract in docs/ai/learning-system.md:18 and .agents/skills/learn/SKILL.md:105, which explicitly allows raw bugs to remain samples and calls for abstraction only after several examples or one high-risk incident with a clear prevention surface. Restore the conditional capture behavior or delegate the abstraction decision to /learn so one-off bugs do not pollute promoted guidance.
Useful? React with 👍 / 👎.
| **Promote high-blast-radius patterns** — bug classes that touch multiple | ||
| consumers, span layers, or could recur in future features — into `docs/ai/`, | ||
| shared helpers, ESLint restrictions, or contract tests rather than leaving them | ||
| only in the learning inbox. |
There was a problem hiding this comment.
Verify guardrail changes made after the test run
When a high-blast-radius bug leads to a shared-helper, ESLint, or contract-test change, this promotion occurs after Step 4 has already run the full suite, and Step 6 only summarizes, so the newly promoted code or configuration can be left unverified. This also conflicts with .agents/skills/learn/SKILL.md:188, which requires code and enforcement changes to receive TDD/review discipline. Either record these as follow-up prevention work during capture or add a verification/review step after promotion.
Useful? React with 👍 / 👎.
Target
skill: .agents/skills/bugfix-tdd/SKILL.md
Observations addressed
Generated by Claude Code