The conventions.md file for the learning hub called the N1 "Read first →" chips the single highest-value navigability fix in the system. They shipped in Phase 5.
There were seven phases.
That ordering is the argument. Not a scheduling accident, not a prioritisation slip. The spec at docs/specs/learning-hub/navigation.md decomposed browsability into distinct failure modes, and the order those modes can be fixed in is partially a function of their dependencies on each other.
By today, all seven phases are marked SHIPPED. Four produced the most visible changes: course sidebar, in-chapter TOC, prerequisite chips, and site-wide Pagefind. Each closes a different kind of lost reader. None of them could carry that load alone.
Four kinds of lost
Before getting into the phases, it's worth naming what "browsability failure" actually means on a learning site, because the word covers different things.
Orientation failure. The reader is on a chapter page with no signal about where it sits in the course. Is this chapter 2 of 5 or 8 of 12? Is there a next chapter? They'd have to navigate back to the hub index to find out.
Local-nav failure. The reader is inside a long chapter and can't see its structure. Section headings exist in the DOM, but the reader has to scroll past content to discover them. The chapter's shape is hidden until it's already been read.
Sequencing failure. The reader lands on a chapter that assumes knowledge from earlier chapters. There's no signal about what those chapters are. They finish the chapter confused, and the confusion is not theirs to fix; the prerequisite information was never surfaced.
Recall failure. The reader remembers reading something but can't locate it. They have a vague topical memory ("there was something about this pattern in the TypeScript section") and no tool to act on it except manual scanning.
Each one produces a different behaviour: abandonment, confusion, context loss, or manual re-reading. They don't share a solution.
P3: the course sidebar
Orientation failure is the one the spec called the biggest browsability lift. P3, shipped on feat/learning-nav-p3-sidebar, closes it with a persistent course rail on every chapter page. The sidebar shows the full course structure and marks where you are. Always visible, always current.
The scope here is non-trivial. A persistent sidebar is a layout commitment that touches every chapter page. Getting it wrong at implementation costs considerably more than a mockup round, so P3 ran through the full UI gate per the standard process: interactive approval mockup before a line of component code. The mockup was the decision surface. The implementation was the execution of a decision already made.
P4: the in-chapter TOC
Orientation and local-nav look like the same failure until you're designing against both simultaneously. The sidebar tells you where your chapter sits in the course. It says nothing about where you are inside the chapter. Those are different problems.
P4 shipped on feat/learning-nav-p4-toc as the "on this page" right rail, closing N2 in the spec. The TOC is the navigation subsystem's one client island: the only component that cannot be a React Server Component because it needs to run IntersectionObserver in the browser to highlight the active section as the reader scrolls.
That constraint shaped the implementation approach. The mockup at scratchpad/learning-toc-mockup.html ran a live IntersectionObserver against real chapter content rather than dummy text. The approval gate wasn't checking the static layout; it was verifying that the scroll-spy actually behaved correctly before the island boundary was committed. The island pattern adds client-side weight that the rest of the system doesn't carry. The mockup step was the point at which that cost was explicitly accepted.
P5: the prerequisite chips
This is the one conventions.md named the single highest-value fix. The chips sit at the chapter head as N1 labels: "Read first → Chapter X, Chapter Y." They surface prerequisite dependencies before the reader has committed time to the content.
Sequencing failure is the worst category because the reader experiences it as their own comprehension failure, not a navigation failure. They can finish the chapter, feel confused, and have no reason to suspect that the missing context was navigational in origin. The chips' job is prevention, not recovery.
Why did they ship fifth rather than first, given that assessment?
The chips link to other chapters. For a chip to do useful work, the thing it points at needs to be reachable and spatially intelligible. The reader needs some model of where that prerequisite sits relative to where they are now. The course sidebar (P3) provides that model. A prerequisite chip pointing at Chapter 3 while you're reading Chapter 7 lands differently once you can see the full course rail beside you. Without the sidebar, the chip is a link. With the sidebar, it's an instruction.
P5 closed B-037's top three items in the navigation roadmap. The ordering was the plan.
P6: Pagefind
Recall failure is structurally different from the other three. The reader isn't lost in the course hierarchy; they're trying to retrieve something specific from memory. The recovery path without search is manual: navigate to the hub, identify the likely course, scan chapter titles, open chapters. That path is slow and often fails.
P6, shipped on feat/learning-nav-p6-search, installs Pagefind across the whole property, not just the learning hub. That scope decision is deliberate. A reader who has moved between the learning hub and the blog and the project write-ups shouldn't have to pick the right section before searching. Recall failure doesn't respect section boundaries; neither should the search index.
P6 is the final phase in the navigation spec. It closes the plan.
Why the order was the point
The case for shipping these as seven phases rather than one "nav update" rests on two claims: browsability failures are distinct, and the fixes have dependency relationships.
The distinctness shows in what each phase produces. A course sidebar doesn't help a reader with recall failure. Pagefind doesn't help a reader who can't see the chapter's internal structure. Prerequisite chips don't help a reader who has no sense of where they are in the course. Independent failures, independent solutions.
The dependencies are less obvious. The sidebar and the TOC share visual real estate on a chapter page, so they negotiate layout. Pagefind indexes the content of every phase's output, so the quality of search results depends on what earlier phases produced. The chips have a semantic dependency on the sidebar: without spatial context, a chip pointing at a prerequisite is less actionable.
The spec knew before P2 shipped that the chips were the fix with the biggest single impact. Shipping them in P5 wasn't a prioritisation trade-off. It was a recognition that impact is conditional on the infrastructure that supplies context. The sidebar provides that infrastructure. The sidebar shipped in P3.
The plan is complete. docs/specs/learning-hub/navigation.md is marked SHIPPED, P0 through P6, and the record is the spec.
