Compass Method Bug Fix
Table of Contents
1. When to use this skill
A defect is reported: something behaves wrongly, and the wrongness can be observed. Use this method from the report to the merged fix.
Not this method when there is no observable symptom. A suspicion that code
is wrong, with nothing that misbehaves, is
compass-method-investigation: find out what is true first, and come back
here if it turns out something is broken.
2. How to use this skill
The phases are control flow. Each names the actions and recipes that do
the work, and the principles cited at its judgement calls. Copy them into
the todo list before starting; a phase you skip stays in the list with
skip: and the reason.
2.1. 1. Ground
Name the domain concepts the report touches and resolve each to a knowledge document (Grounding). Where a cluster has a structure note, read that first: it says which pages are load-bearing.
A concept that resolves to nothing is a finding, not a blocker. Record the
assumption you are proceeding on and carry on
(compass-principle-never-block-on-the-human); the missing page is a
discovered task, not a reason to stop.
Use compass-doc-find and compass-doc-show.
2.2. 2. State the predicate
Before touching anything, write down what would make this fixed, in terms someone else could check. "The link resolves" is a predicate. "Search works better" is not.
This is the phase most often skipped and the one that decides whether the rest is honest. A predicate written after the fix describes the fix; a predicate written before it describes the defect.
2.3. 3. Reproduce
Make it happen, on the surface it was reported on. A defect you cannot reproduce is one you cannot prove fixed, and a fix for an unreproduced defect is a guess with a commit message.
If it will not reproduce, force it: tighten the conditions, synthesise the trigger, add logging and read it. That work is not overhead; it is the instrument the last phase needs.
For a failing test, use compass-code-investigate-test-failure.
2.4. 4. Find the root cause
Form the candidate causes, then eliminate them against evidence rather
than plausibility (principle-fix-root-causes). Each pass, take the split
that cuts the most remaining space.
Stop at the cause, not at the first place the symptom disappears. The test is whether you can say why the defect happened, not merely where it stops happening.
Then check the blast radius before fixing: grep every caller of what you are about to change. A guard in the shared function is a smaller diff than a guard in each caller, and patching only the path the report names leaves its siblings broken.
2.5. 5. Fix
The smallest change the evidence justifies. A belt-and-suspenders extra
that "might also help" is a second hypothesis riding on the first; it does
not ship (principle-laziness-protocol).
If the fix crosses a boundary or the design is unclear, stop and design first rather than discovering the shape by editing.
2.6. 6. Prove
Run the reproduction from phase 3 and watch it pass
(principle-prove-it-works). Then climb the
verification ladder as far as
the change earns: the check that would have caught this, then the class
checks for what you touched, via
compass-code-run-build.
Leave the check behind. A defect that no check would have caught is a
defect that can return, so where the cost is reasonable the fix ships with
the test or the lint that fails without it
(principle-encode-lessons-in-structure,
compass-code-add-tests).
2.7. 7. Land
Order the commits so the failing case lands before the fix, and the
history tells the story (principle-sequence-verifiable-units). Close the
bookkeeping with
compass-agile-close-task,
then raise with
compass-pr-raise.
3. When this method is the wrong one
Abandon it and re-match if the reproduction shows the reported behaviour
is correct and the expectation was wrong, which is a documentation or
product question; or if the root cause turns out to be a missing
capability rather than a defect, which is
compass-method-feature.
4. Recipes
- How do I fix a failing CI check? — when the symptom is red CI rather than wrong behaviour.
- How do I work a task? — the lifecycle this method runs inside.
5. Reference
- Methods and the mode — what a method is, and how a phase binds to actions.
- Principles — the rules cited above.
- Verification and evaluation — the ladder phase 6 climbs.