The /cluster-fus engine
A backlog read one item at a time is a wall you never finish. This engine reads all of it, tags each item by type, and groups them into batches, so you see clusters worth a single pass instead of a hundred loose chores. It only ever suggests.
It is deliberately read-only; grouping is the whole job, executing is not. If you want it to start a batch itself, tell us why. Reply on LinkedIn.
How to read this map
Pick a stage to walk, or start at the top
The walkthrough, as text
Every stage of the interactive walkthrough above, as plain readable text. Each stage has its own link.
Stage 1Read the whole backlogBoth lists, all of it
Gather
The engine reads every follow-up there is: the ones tied to the current phase of work, and the cross-cutting ones that outlived any single phase. It starts from the complete picture, not a slice.
Read both backlog files, the phase-local follow-ups and the cross-cutting ones, before sorting anything.
What happens
The engine reads the live-state file's follow-up section and the separate cross-cutting backlog. Together those are every open item.
You can narrow it, one type, or one phase, but by default it takes the whole backlog, because a batch you can only see across both lists is exactly the kind grouping is meant to surface.
Who acts
- Read, tool: Reads both backlog files in full.
The rules
- Start from everything. The engine reads the complete backlog by default, since the useful clusters often span both lists.
In: An optional type or phase filter. Out: Every open follow-up, gathered.
Stage 2Tag every item by typeTagged or inferred
Classify
The engine reads each item's type tag. Items too old to carry one get a type inferred from their description against a fixed taxonomy, and the engine tracks which were tagged versus inferred, so you know what to retro-tag later.
Read each item's type tag; infer a type for the untagged ones from a fixed taxonomy, tracking which were inferred.
What happens
Every item is placed into one type from a fixed taxonomy: things like type-design, silent-failure, test-coverage, duplication, or security. Items that predate the tagging convention get a type inferred from their description.
The engine tracks tagged versus inferred so it can recommend a retro-tag pass, and it leaves frozen legacy location-IDs alone rather than rewriting them.
Who acts
- the engine, agent: Reads each item's tag or infers its type from the taxonomy.
The rules
- Infer the untagged, don't guess wildly. Old items get a type inferred from a fixed taxonomy, and the inference is flagged so it can be confirmed later.
In: The gathered backlog. Out: Every item classified by type.
Stage 3Group by type, apply the ruleFive, or two, or wait
Bucket
The engine groups the items by type and counts each group. Five or more of a type is a candidate for a single heavy sweep. Two to four is a light batch. A lone item isn't a batch yet, so it waits.
Group by type, count each cluster, and apply the batch rule: five-plus is a heavy sweep, two to four is a light batch, one waits.
What happens
Each type-cluster is sized against a simple rule: five or more like-type items is a cohesive multi-file sweep for the heavy pipeline; two to four is a batch for the light pipeline; a single item is not yet a batch.
If a cluster's items carry conflicting pipeline tags, the batch inherits the heavier one. A cluster that spans both backlog lists is noted, because that means the work crosses a phase boundary.
Who acts
- the engine, agent: Buckets by type and sizes each cluster against the batch rule.
The rules
- The batch thresholds. Five or more of a type is a heavy sweep; two to four is a light batch; one waits.
- Conflicts inherit the heavier. A cluster with mixed pipeline tags is treated as the heavier of them.
In: The classified items. Out: Type-clusters, each sized for a pipeline or left to wait.
Stage 4The scannable tableReady-first, orphans flagged
Report
The engine prints a table you can read at a glance: the batch-ready clusters first, each with its size and suggested pipeline, then the singles, then the items that need a retro-tag, and prominently, any orphans whose home phase is already closed.
A table ordered by batch-readiness: ready clusters with their pipeline, then singles, untagged, and orphaned items flagged.
What happens
The batch-ready clusters come first, each showing its type, its count, its suggested pipeline, and where its members live. Under them, the clusters that aren't batchable yet, and the items that were inferred and should be retro-tagged.
Orphans get surfaced prominently: an item whose home phase has already closed is a rule violation that needs a new home or a promotion to the cross-cutting backlog, and the engine will not let it hide in the pile.
Who acts
- the engine, agent: Prints the batch-readiness table with each cluster's members.
The rules
- Ready clusters first. The table is ordered most-batchable first, so the highest-leverage work is at the top.
- Orphans are surfaced, not buried. An item homed at a closed phase is flagged prominently for re-homing.
In: The sized clusters. Out: A scannable batch-readiness table.
Stage 5Name the highest-leverage batchOne suggestion, your call
Recommend
The engine ends by pointing at the single most worthwhile batch to run next, the largest cohesive cluster of open work, and names the exact pipeline and the items it would clear. Then it stops. Starting the batch is your decision.
Recommend the single highest-leverage batch and name its pipeline and members. It suggests; it never starts the run.
What happens
The recommendation is one line: the biggest cohesive cluster targeting open work, the pipeline it fits, and the items it would absorb, so you can start that run directly if you want.
That is the boundary. The engine is read-only from beginning to end; it groups and suggests, and the decision to run a batch is always yours.
Who acts
- the engine, agent: Recommends the single best batch to run next, then stops.
The rules
- One clear recommendation. The engine names the single highest-leverage batch, not a menu, so the next move is obvious.
- It never starts the run. Read-only to the end; you decide whether the recommended batch actually runs.
In: The batch-readiness table. Out: One recommended batch, with its pipeline and members.
Stage ✓A backlog you can act onClusters, not chaos
Bucketed
What you end with is a backlog seen as a handful of batches instead of a hundred loose items, with the best one to run next named for you. Nothing changed; everything got clearer.
The engine turns a wall of items into a short list of batches, without touching a single file.
What happens
Grouping like-type work is the thing that keeps a backlog from becoming unworkable, and doing it as a read-only pass means you can run it anytime without risk.
From here you pick a batch and hand it to the light or heavy pipeline, both of which have their own field guides. This engine just made the choice obvious.
The rules
- Clarity, not change. The engine's only product is a clearer view of the backlog; it never edits or executes.
In: A sprawling backlog. Out: A short list of batches and one clear next move.