I'd sequenced Claralens the obvious way: start with the Evaluation Detail View. It's the heart of the product — the screen where a grade gets read, disputed, overridden. Build the heart first.
Then I wrote the object model down as a plain dependency list and argued with it. The heart fell apart.
You can't render a detail view without a template to score against. You can't author a template without detectors to assign into it — because a Checkpoint is a detector assigned to a template. The dependency chain runs the exact opposite of intuition:
Detector Library → Template Editor → Evaluation Detail View.
The most important screen in the product literally cannot exist until its foundations do. The "heart" ships last, not first.
I only caught this because I forced the model into a table before touching wireframes. In prose it was invisible — everything sounded shippable in any order. In a dependency list it was obvious in ten seconds.
Write the object model as a list and stress-test the order before you draw. It's a table you can rewrite in a minute or a set of wireframes you rebuild for a week.