The post-ship backlog pass started with conventions.md and a column of ⬜ symbols. The task was mechanical: mark each M/E/N/S item ✅ or leave it ⬜ against what had actually shipped across P0–P6. Most items resolved quickly. N1 got its tick without debate, but it carried a note worth pausing on: “the single highest-value navigability fix.”
That note predated the programme. It survived seven phases and two of the heaviest client-side builds the learning hub has seen.
The seven phases
docs/specs/learning-hub/navigation.md is now marked SHIPPED P0–P6. The sequence:
- P0: foundation wiring
- P1: breadcrumb
- P2: hub track sections + S1 JSON-LD structured data
- P3: prev/next chapter links
- P4: in-chapter “on this page” right rail with IntersectionObserver scroll-spy
- P5: prerequisite chips at the chapter head
- P6: site-wide Pagefind search
Sequenced by dependency, not estimated value. The planning doc had value opinions baked in. N1 as “highest-value” was one of them. The build order followed technical prerequisites, not a ranked value queue.
What the heavier phases looked like
P2 shipped on feat/learning-nav-p2-tracks. The first visible navigation change on the hub since the initial launch, and the first time the full UI gate ran on this programme: interactive mockup approved before a component was written. Track sections reshaped the hub’s information architecture at the page level. S1 JSON-LD added structured data. Two concerns, one branch, one gate.
P4 was the programme’s one client island. The hub is otherwise server-rendered; P4 introduced the only component that runs in the browser. The right rail (the “on this page” panel) uses a live IntersectionObserver to track the active heading as the user scrolls. Mockup at scratchpad/learning-toc-mockup.html with the observer wired against real heading structure, not stubbed. Shipped on feat/learning-nav-p4-toc, closing N2.
P6 was Pagefind: indexing the static build, wiring the search UI, handling query state across the whole property. Mockup at scratchpad/learning-search-mockup.html. Shipped on feat/learning-nav-p6-search. The final phase, and the one that put SHIPPED in the spec header.
P4 carries ongoing runtime overhead. P6 adds a build-time indexing step that runs on every deploy. Neither is a small engineering surface.
P5
P5 shipped on feat/learning-nav-p5-prereqs. The component: the N1 “Read first ↳” chip at the chapter head. Three words, a glyph, a link. No IntersectionObserver. No search index. No JSON-LD. No client JavaScript.
That is what “the single highest-value navigability fix” looked like in practice.
Why the designation survives
Improving on the earlier post that named the chip as the spec’s highest-value fix: the full-programme view makes the reasoning clearer.
P4 and P6 solve a navigability problem. If you’re in a chapter and want to know what else is on the page, the TOC rail answers it. If you can’t find the chapter, Pagefind surfaces it. Both are genuinely useful. Neither changes what you can understand once you’re in the chapter.
P5 solves a dependency problem. A learner who arrives at a chapter without the prerequisite isn’t facing a navigability gap. They’re facing a comprehension gap the content can’t fill. They’ll read the chapter, fail to follow it at the points where the prerequisite matters, and either push through with confusion or leave. The chip doesn’t help them navigate; it changes what they can learn.
The distinction is between making existing content more reachable and making existing content more usable. P4 and P6 do the former. P5 does the latter. On a learning hub, usability outranks reachability.
The spec wrote this down before any phase started. The programme confirmed it: the most technically modest phase was doing a different kind of work.
What a seven-phase programme reveals
Building sequentially across seven phases makes something visible that a single-phase post can’t: the gap between apparent weight and actual impact.
P4 is the programme’s heaviest component: the one client island, the one with browser-side state, the one with ongoing runtime cost. P6 is the programme’s most visible feature. Search is what users point at when they say “navigation.” Measured by engineering effort or visual prominence, P4 and P6 dominate.
P5 doesn’t appear in that accounting. It’s a link with a label, with no runtime behaviour to speak of. Users don’t point at it and say “navigation.” They follow it, or they don’t notice it’s there until they need it.
The lesson isn’t “smaller is better.” P0’s foundation wiring and P2’s track sections were necessary groundwork; skipping them wasn’t an option. The lesson is narrower: on a content navigation system, the highest-impact interventions tend to be the ones that surface structural properties the content already has but hasn’t declared. Prerequisite relationships are structural. P5 didn’t create a prerequisite; it surfaced one. Everything else the programme built (track sections, TOC rail, prev/next links, search) helps users move through content they can already access. P5 changed what content was accessible to them at the point they needed it.
Closeout
The programme is done. conventions.md carries per-item ✅/⬜ status across the M/E/N/S backlog. The spec header reads SHIPPED P0–P6. A living atlas gives the programme a navigable document so decisions don’t disappear into git history.
No operational follow-up. New navigability concerns route through conventions.md as fresh items.
The chip is three words and a glyph. It was the right place to put the work the programme couldn’t shortcut. The spec knew it before the build started. The programme confirmed it. This post is the receipt.
