diff --git a/TODO.md b/TODO.md
index efa6be4..b7695a4 100644
--- a/TODO.md
+++ b/TODO.md
@@ -15,6 +15,89 @@ MegaMek's own web client, for what it lets a person filter on. It is GPL-3.0
 and helm is not, so what was taken is the vocabulary and the shape of the
 problem, never code.
 
+## What to do next, in order
+
+Twenty things, ranked. The tiers are the argument: the first finishes what
+`plan/unit-rules.md` already promises, the second widens what helm can score at
+all, and the third is what makes any of it reach a player. Everything below
+appears again in its own section with the detail; this is the order to take
+them in and the reason for it.
+
+**Finish what unit-rules promises.** The epic's exit criterion is a force's
+battle value computed the same way in the browser and on the server, agreeing
+with MegaMek except where a deviation is registered.
+
+1. **Read C3 networks from a `.mul` and score them.** The arithmetic is
+   written; nothing reads which unit is whose master, so `helm force` scores
+   every unit as though it were alone and a networked lance is reported five
+   percent light.
+2. **Double verification across the wire.** Named in the epic: the same crate
+   compiled twice, agreeing. The smoke test checks a few designs; the proof is
+   the whole library scored in Node and natively with no disagreement. It is
+   the reason `helm-bv` does no I/O, and it is currently unproven.
+3. **Battle value for a varied unit.** `Condition` models damage and not
+   variation. A player swapping an LRM bin for inferno rounds, or changing an
+   omni pod, is exactly what the epic says players will do - and it is the
+   largest gap between what helm computes and what the product needs.
+4. **Pin the rounding.** Also named in the epic. Battle value is full of
+   half-point steps and nothing proves the two builds round alike, or that a
+   total does not depend on the order floats were added in.
+5. **Settle the two compensating explosive errors.** B-Pods against CASE II
+   ammunition: both sides are wrong and the fresh figure is right by luck.
+   Wants two oracle designs before either can be corrected.
+
+**Widen what helm can score.**
+
+6. **Vehicle battle value.** `CombatVehicleBVCalculator` upstream. Scenarios
+   already carry tanks - `MercBrawl`, `example.mul` - and `helm check` answers
+   "cannot be scored" for every one of them.
+7. **Battle armour and infantry.** The same argument with different
+   calculators, and the reason `LegAttack` and `SwarmMek` are synthesised.
+8. **C-bill cost.** The second of the three figures borrowed from the bridge,
+   and what anything economic needs.
+9. **The Alpha Strike conversion.** The third. It already has a registered
+   deviation, so the shape of the work is known.
+10. **Retire `bridge/` for battle value.** Once 8 and 9 exist the JDK container
+    leaves the build, which is `plan/unit-library.md`'s exit criterion.
+11. **The equipment MegaMek synthesises while loading.** 5,534 units differ
+    from `MekSummary.equipmentNames` only because of it. It blocks equipment
+    filtering conformance and probably hides battle value bugs.
+12. **The nine registered disagreements.** Now that they are named they can be
+    taken one at a time; the Super-Griffin and the Jabberwocky are the two most
+    likely to be a rule rather than a broken file.
+
+**Make it reach a player.** These belong to epics in headquarters as much as
+to helm.
+
+13. **Decide how a design reaches the page, and build it.** The one open
+    decision, and everything in `plan/unit-search.md` waits behind it.
+14. **Compile `helm-facet` to wasm and filter with it in the browser.** The
+    epic says it outright: run the same predicate, do not reimplement. Two
+    filter implementations is how "filtering means the same thing everywhere"
+    dies.
+15. **The redistribution question.** MegaMek's data is CC BY-NC-SA and serving
+    an index of it to browsers is redistribution. It needs a decision and an
+    attribution mechanism *before* 13 ships.
+16. **Provenance on every record.** Which MegaMek, which producer, which
+    `RULES_VERSION`. The constants exist and nothing writes them into the
+    database or into an ATProto record, so a stored figure cannot be told from
+    one computed against a different MegaMek.
+17. **The attribution and the repair list on a match page.**
+    `plan/after-action.md`. The pieces are built and cross the wasm boundary;
+    what is missing is the screen that reads them.
+18. **Damage that persists between matches.** `plan/campaign.md`. The
+    mechanical half exists; storing a force's condition as a record and reading
+    it back is the rest, and the construct-write-read round trip supports it.
+19. **Formation validation.** `list_formations` and `validate_formation`
+    against the Campaign Operations blueprints - "is this a legal Fire Lance".
+    Validation before generation, and it needs no faction data: it is role and
+    count, both of which helm holds.
+20. **Ingest `data/forcegenerator/`.** 40 era files of per-faction availability
+    weights, `factions.xml`, and 61 faction rulesets that are a small DSL of
+    their own. This is the foundation for force generation, faction filtering
+    and era-correct scenarios, and nothing above it should be attempted until
+    it exists.
+
 ## Derived combat metrics
 
 The highest-value gap. These are what make a filter describe a *fighting