The chip says three things: “Read first”, an arrow, and a chapter title. It sits at the head of a chapter page, before the content starts. If you haven’t read the prerequisite, you’ll see it immediately. If you have, you’ll skip past it in a glance. That is the entire implementation surface of Phase 5 — the N1 prerequisite chip — and it is the phase conventions.md called “the single highest-value navigability fix” in the learning hub plan.
Seven phases shipped between 2 and 3 July 2026. This one had the smallest footprint. It also had the highest return on orientation.
The plan
The navigation spec at docs/specs/learning-hub/navigation.md laid out seven phases, P0 through P6. The phases I shipped in this sprint were P2 through P6 — five phases across two days, all merged and live.
Each phase had a scope:
- P2 — hub track sections and S1 JSON-LD structured data. The first visible change to the hub itself, but it required schema markup authored to spec and a build step to validate it.
- P3 — course sidebar on every chapter page. The spec’s own label: “biggest browsability lift.” Every chapter page now carries the persistent course rail. That means a layout-level component with chapter-list data at render time.
- P4 — in-chapter table of contents. The devlog called it “the subsystem’s one client island.” It was the only phase that required client-side JavaScript: an IntersectionObserver scroll-spy to track the active heading as you read. One
use clientboundary, one JS bundle contribution, hydration on every chapter page. - P5 — prerequisite chips. Three words, an arrow, a link.
- P6 — site-wide Pagefind search. Build-time index generation across the whole property, a search UI, a query runtime.
Read that list against the thesis. P4 required a React client island. P3 needed a layout-level component backed by chapter data. P6 needed Pagefind integrating across every page in the build. P2 needed schema markup. P5 needed a chip.
Why the chip is high-leverage
Improving on the earlier piece about P5: that article established what the chip is and that the spec named it the highest-value fix. This one is about why — specifically, why it is the highest-return phase when measured against what the other six cost.
Navigation phases fail in two directions. The first failure: you build something structurally complete but irrelevant to the orientation problem. A course sidebar tells you what exists; it does not tell you what to read first. A TOC shows you the structure of the current chapter; it does not tell you whether you’re in the right chapter. The second failure: you build something that solves orientation but carries enough implementation weight that bugs compound and maintenance accumulates.
P5 solves one problem with minimal implementation surface: it tells a reader, at the first moment they land on a chapter page, whether they’re starting in the right place. No other phase in the plan solves that problem. The chip is not a substitute for P3 or P4 — both of those are essential for different reasons — but P5 is the only phase that addresses prerequisite ordering, and it does it without JavaScript, without data fetching beyond the chapter’s own frontmatter, without additional build complexity.
What “unlike every other nav phase” means in practice
The devlog for P5 noted it was unlike every other navigation phase. That clause is doing specific work.
P4 is the clearest contrast. An IntersectionObserver scroll-spy requires a client boundary in Next.js: use client, hydration, JS delivered to the reader’s browser. It’s the right call for the in-chapter TOC — active-heading tracking needs the DOM — but it is an observable page-weight decision with runtime implications.
P5 is static. The chip reads the prerequisite from frontmatter, renders a link, applies a CSS class. Server component. No hydration. No JS bundle contribution. No client-side state. The implementation surface is close to zero relative to the other phases.
The browsability delivered per line of code — measured as reader orientation problems solved against implementation complexity — is higher for P5 than for any other phase in the seven-phase plan. The evidence is the contrast between what each of the other phases required and what each one solved, set against what P5 required and what it solved.
The lesson in the sequencing
The spec named P5 as the highest-value fix before the build started. That matters. It was not a discovery made by comparing implementation difficulty after the fact. The spec author identified prerequisite orientation as the core unsolved problem in the hub’s navigability — the thing a reader most needs to know that no other navigation surface tells them — and then noted that the fix was a chip.
The phases shipped in order: P2, P3, P4, P5, P6. P5’s position in that sequence is not accidental. The phases before it build the structural skeleton — track sections, course rail, TOC — and P5 drops in on top of that skeleton cleanly, because the skeleton is already providing the chapter list and the per-chapter metadata. The prerequisite link in the chip comes from frontmatter that already exists. P5 has no novel data requirements. It threads one relationship through infrastructure the earlier phases built.
That is the efficiency. Not that P5 is simple in isolation. It is simple because the preceding phases made it simple.
After P6
P6 closed the plan. docs/specs/learning-hub/navigation.md now reads SHIPPED P0–P6. The seven-phase plan is complete.
Pagefind indexes the whole property at build time. The implementation is heavier than P5 by an order of magnitude: search UI, query runtime, build-time index generation across every page. The browsability return is site-wide rather than chapter-level. Different scope, different cost, justified.
The observation holds: the phase that required the most careful problem identification — naming precisely what orientation gap a chapter-head chip could close — cost the least to build. Most navigation improvements in this plan solved structural problems: how you move between chapters, how you know where you are in a course. P5 solved an orientation problem: how you know where to start. Structural problems need structural implementations. Orientation problems, identified precisely enough, need almost nothing.
Out of scope: whether the chip’s current form is optimal. The spec named the problem; the build confirmed it ships. Refinement is a future sprint.
