The navigation plan shipped on Pagefind. Prerequisite chips were the higher-leverage fix.

The navigation spec at docs/specs/learning-hub/navigation.md closed on 3 July. P5 and P6 both merged the same day, and the document was annotated SHIPPED P0–P6. That was the correct end state. Both phases needed to ship.

The more useful number came from looking at the two branches afterward.

P5, on feat/learning-nav-p5-prereqs, shipped the N1 chips: “Read first ↳” at the chapter head. conventions.md had labelled this “the single highest-value navigability fix” before a line of implementation existed. B-037’s highest-priority trio was complete when P5 merged.

P6, on feat/learning-nav-p6-search, shipped site-wide Pagefind search: build-time indexing across the full property, a WASM client bundle, a UI component, and a mockup cycle with scratchpad/learning-search-mockup.html. It works. The final phase of a spec ships last, which is usually taken to mean it’s the most significant. That reading is wrong here.

The thesis the spec didn’t track explicitly: P5 delivered more navigability per line of code than P6. That inverts the usual assumption that discovery beats structure.

What the chip actually does

A prerequisite chip is static content. A relationship declared in the chapter data, rendered as a “Read first ↳ [target]” label at the chapter head. It fires at entry, before any content is consumed, before the reader has had a chance to be confused.

The question it answers is specific: am I ready for this chapter? That question has a known answer for each chapter. The chip makes the answer visible at exactly the right moment.

Search doesn’t answer that question. Search answers “where is X?” or “what covers Y?”. Those are retrieval problems, not orientation problems. Retrieval problems arise after orientation has failed. A reader who arrives at an advanced chapter without the prerequisites and doesn’t see a chip may eventually use search to locate the gap. The chip removes the need to search in the first place.

That’s the intervention difference. Structure acts at orientation time, discovery at recovery time. Orientation is earlier and cheaper.

The implementation asymmetry

P4 is the in-chapter “on this page” right-rail TOC. The devlog flags it as “the subsystem’s one client island.” It requires a live IntersectionObserver scroll-spy: JavaScript running in the browser on every page render. The devlog calls this out because every other navigation component in the programme is server-rendered or static. P4 is the exception.

P6 requires more. A Pagefind implementation covers: indexing every page at build time, shipping a WASM bundle to every visitor, maintaining a search UI component, and running through a mockup-first cycle. The scratchpad/learning-search-mockup.html is the record of that cycle. The implementation surface is material.

P5’s chips are static. The “Read first” label and the target are structure, not behaviour. No JavaScript on the client path. No indexing pass. No bundle. The chip renders with the chapter; it costs what the chapter costs.

Navigability per line of code is not a metric the spec tracked explicitly. The P5-versus-P6 comparison makes it concrete. Less infrastructure, higher precision, earlier in the reader’s decision loop. P5 wins on all three.

Why discovery doesn’t always beat structure

The operating assumption in navigation design is that search scales better than curated structure. A search index covers every page automatically as content grows; a structural navigation layer has to be maintained. That’s defensible for large content sets with low coherence, such as a news site or a documentation wiki with hundreds of independent articles.

The learning hub doesn’t have low coherence. It has a known learning order. Topics have prerequisites. Prerequisites have a canonical path through the programme. That structure exists whether or not it’s surfaced in the UI. P5 surfaces it.

When the structure is legible at chapter entry, many search queries don’t happen. A reader who sees “Read first ↳ Fundamentals” before an advanced chapter navigates to the fundamentals directly; they don’t type into a search box.

Search fills genuine gaps: cross-referencing, arriving mid-programme via an external link, finding a specific term in a dense chapter. These are edge cases relative to the base case of a reader progressing through the programme in order. P6 is not wasted work. It’s correctly scoped to the edge cases. The question was whether it was the highest-priority fix. The spec’s own label for N1 had answered that question before P6 was scoped.

Reading the programme stack

P0 through P6 built a navigation hierarchy. The intervention types, in retrospect:

P2 shipped hub track sections: programme orientation. Where are you in the full learning arc?
P4 shipped the in-chapter TOC: position orientation. Where are you in this chapter?
P5 shipped the prerequisite chips: readiness orientation. Should you be here at all?
P6 shipped search: recovery. Can you find what you’re looking for when the structure doesn’t surface it?

P5 sits second in that intervention stack, not fifth. It landed in the fifth phase because the spec sequenced by implementation complexity and interdependency: P2 needed to exist before P5 could reference track and chapter structure. The sequencing was correct for implementation. The priority order runs differently.

Readiness orientation is more expensive to lack than recovery. A reader who doesn’t know they’re missing a prerequisite will either slog through content they’re not ready for or leave. A reader who can’t find something via search can usually navigate to it through the hub. The failure modes aren’t symmetric.

Post-ship accounting

The closeout on 3 July reconciled every tracking surface. conventions.md carries per-item statuses across the M/E/N/S backlog, each item now marked ✅ or ⬜. A living atlas gives the programme a navigable single view.

The reconciliation also fixes the accounting. P6 shipped last, generated the most visible commit, closed the spec. In any normal writeup, search would be the headline. The accurate headline: the spec’s own label for N1, “the single highest-value navigability fix”, was correct, and N1 shipped as P5, not P6.

Structure before discovery. The chip before the search. The programme’s finding, stated plainly.

All writing