Reading a review like the teamThe pre-push checklist
No narration yet
Module 9 · Lesson 112 min

The pre-push checklist

You now know the ideas. The last skill is reading your own diff the way a Fusion reviewer will, before you push. These are the highest-severity, highest-frequency checks distilled from the anti-pattern list. Run them mentally on any domain change and you'll catch most of what review would.

The checklist (severity in the anti-patterns doc)
#25Any `new` on a domain type outside its own file? Use the Create factory
#5Any public Validate* on a domain object? Fold it into the action method
#8Any exception for invalid input, or a discard arm returning a default? Use Result; make the discard throw
#6Reads and writes in one class, or AsNoTracking next to SaveChanges? Split QueryStore / Repository
#24Any Service/Manager/Provider in a name? Rename by behaviour
#36Any `.Result`/`.Wait()`/`.GetAwaiter().GetResult()`, or a CancellationToken with `= default`? Go async, make the token required

Two more that aren't mechanical but are worth a deliberate glance. Anti-pattern #29: any new user-facing behaviour needs a feature flag, defaulting on, since Fusion deploys trunk-based to a shared environment. And anti-pattern #32: if you're reaching for a second guard, latch, or manual write-back to patch the same concern, stop, that's the signal the foundation is wrong, not a thing to add more of.

Practice

Try it yourself

Do

Run the checklist on the capstone blob

Apply the list to real slop. Look back at the capstone's NoteService blob (it's in the course capstone).

Tick every step to confirm you did it.

Recall

The foundation smell

Anti-pattern #32, the meta-rule.

You're about to add a second guard clause, a latch, or a manual cache write-back to patch a behaviour that already has one workaround. What does that signal, per the anti-patterns?