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

5. Reference

Emacs 29.3 (Org mode 9.6.15)