Small fixes and minor tweaks pile up. Shipping each one the minute it’s requested means constant single-item patches that cost context-switching on both ends. The fix-up pool is the solution: requests accumulate in FIX_POOL.md at repo root until a batch is worth processing, then they go out as one coherent patch.
How it works
- You spot a small thing.Dim text somewhere, a typo, an unclear tooltip, a minor visual gap, a link pointing at the wrong anchor — anything that wouldn’t merit a dedicated patch on its own.
- Add it to the pool.Tell Claude “add this to the fix pool” with a short description. Claude appends it as a markdown checkbox entry in
FIX_POOL.md. No immediate action taken. - Pool fills up.Entries accumulate. The rough target is ~6–10 items, but either side can trigger processing earlier or later.
- Batch processing.You say “process the fix pool” (or similar). Claude works through every open item top-to-bottom, ticks them off as they land, mints a single retroactive
-<fix>letter under the touched historical Name at the end, and summarises. Completed items stay visible (ticked) in the file for a few patches as a brief history; they get removed whenever the file gets too long.
What belongs in the pool
- Cosmetic fixes — wording, colour, alignment, spacing.
- Copy corrections — stale text, language leaks (like the German leftovers in the mining calculator that were fixed the moment they were spotted, without the pool).
- Small UX improvements — a missing tooltip, a redundant confirmation dialog, a link that opens a new tab when it shouldn’t.
- Minor doc updates that don’t change semantics.
What doesn’t belong
- Anything that changes user-visible behaviour on something money-shaped (Stoicism ledger, backup flow, auth). Ship these deliberately, not in a batch.
- Anything that needs design discussion. The pool is for items whose implementation is obvious; if we need to debate what the fix should be, it goes on the roadmap instead.
- Security-relevant fixes. Those ship the moment they land, fresh-confirm flow regardless.
- Bugs that break something important. Same principle — ship immediately.
File format
FIX_POOL.md at repo root. Every open item is a GitHub-flavoured markdown unchecked checkbox with a short title, an optional file hint, and a note of the patch that spawned it. Processed items flip to checked; they stay in the file for ~3 patches as history, then get pruned.
# FIX_POOL.md
Small-patch queue. See /docs/fix-pool for the workflow.
## Open
- [ ] **Dim background on the owner pill in foreign rows.**
pages/admin/nodes/index.tsx — too dim on dark scheme.
(added v.H.1.19)
- [ ] **"Signed in as …" line duplicated.**
pages/admin/index.tsx header and footer both render it.
(added v.H.1.19)
## Recently processed
- [x] ~~Two German strings on /mining-calculator~~ (done v.H.1.19-a)
- [x] ~~Navbar link label "Admin console" → "Hub"~~ (done v.H.1.19-b)
How a batch is versioned
A batch does not open a new head node. It mints one retroactive fix— the next unused -<fix>letter — under the touched historical Name at its historical coordinate, following the canonical four-designator grammar v.<Release>.<Era>.<Name>-<fix>. The first batch over a Name that shipped with no fix mints -a, the next mints -b, and so on (lowercase-letter sequence, with carry). One -<fix> letter per batch regardless of item count; the changelog entry lists every item processed, so the per-item provenance survives. The active build currently stamps v.H.1.19. See the Versioning chapter for the full retroactive-fix model.
Escape hatch
The pool is a convenience, not a rule. Anything you want shipped immediately is shipped immediately — just say so. The point of the pool isn’t to delay, it’s to reduce the number of one-item patches when neither side needs urgency.
The file itself
FIX_POOL.md lives at the repo root alongside CHANGELOG.md. It’s committed to git so the pool state moves with the codebase.