The chip reads “Read first ↳” followed by a chapter link. It sits at the head of the chapter. It does not scroll, does not highlight as you move through the page, does not appear in a sidebar. It is static and inline.
P5 of the learning navigation spec (docs/specs/learning-hub/navigation.md, item N1) shipped as those chips. conventions.md carried the annotation “the single highest-value navigability fix” against N1 before a line of P5 code existed. The annotation held. Of the seven phases in the spec, P5 delivered more navigability per line of code than any other. Not because the implementation was complex. Because every other phase encoded where the reader was, and P5 encoded whether they were ready.
What the plan covered
Seven phases, P0 through P6. P2 shipped the hub track sections. That was the first visible navigation change and the first full run through the UI gate since hub v1. P4 shipped the in-chapter TOC: the “on this page” right rail, the subsystem’s one client island, with a live IntersectionObserver scroll-spy tracking position as the reader moves. The mockup for P4 (scratchpad/learning-toc-mockup.html) used the real IntersectionObserver logic and real chapter headings before a production line was written. P6 closed the spec with site-wide Pagefind search across the whole property, marking it SHIPPED P0–P6.
Each of those phases answers the same class of question: where are you, and where can you go?
P5 is a chip at the chapter head.
What the chip answers
The TOC answers “what’s on this page?” The track sections answer “how is this programme structured?” Site-wide search answers “where does this term appear across the site?” All structural questions. All questions about arrangement.
The chip answers: Am I ready to read this?
That is not a question about structure. It is a question about the reader’s current state relative to a document’s dependencies. A TOC cannot answer it. A breadcrumb cannot. A search index cannot. The only thing that answers it is an explicit statement, from the author, that a specific other document comes first. That statement is what N1 encodes.
That is what the devlog means by “unlike every other nav phase.” P2, P4, P6 extend the same model: help the reader orient within a structure that already exists. P5 adds a different layer. It encodes curriculum metadata: which chapters have dependencies, what those dependencies are.
The cost comparison
P4’s client island carries real implementation weight. A hydration boundary. An IntersectionObserver with threshold and root-margin configuration. Active-section state. Scroll events. CSS for the right rail. You build it once and it works across every chapter, but the initial cost is not trivial.
P5 is an inline element at the chapter head. The implementation is nearly nothing. The cost is not in the code. It is in the decision: which chapters carry the chip, and which do not. Someone has to know the dependency graph. The code is a transcription of that knowledge.
That is the reason the return is high. The code surface is minimal, but each chip encodes a curriculum decision that would otherwise require the reader to discover the dependency by failing to understand the chapter they are in. That failure mode is not recoverable. The reader loses the thread and does not return. The chip prevents it at near-zero implementation cost.
The gap structural navigation leaves
A site can have a complete TOC on every chapter, breadcrumbs at every level, full-text search across every document, and still leave a reader with no signal that they should not read this chapter before reading that one.
Structural navigation answers where. Prerequisite navigation answers when: not yet, go there first. Different information types entirely. Structural navigation scales with page count; prerequisite navigation scales with dependency count. On a learning site, those are not the same graph.
P4’s TOC is more visible than P5’s chip and more technically interesting. It is also less efficient as a navigability investment. It answers a question the reader has after they have already committed to the chapter rather than before.
How the plan closed
P6 closed the navigation spec with site-wide Pagefind search. The closeout work reconciled every tracking surface: conventions.md updated with per-item statuses across the M/E/N/S backlog, the programme given a living atlas. The backlog items now carry explicit ✅/⬜ markers so the next sprint starts from a documented state rather than from archaeology.
P6 is the largest phase by implementation surface. The sequencing was correct: structure first (P2, P4), then curriculum metadata (P5), then global discoverability (P6). Search across a hub with no structural navigation would be noise. Structural navigation without prerequisite metadata still leaves gaps. The order matters.
The priority annotation
The fact that conventions.md carried “the single highest-value navigability fix” against N1 before P5 shipped is the detail worth pulling out. It was a priority signal in the planning record, not a post-hoc claim. It was there because the author understood, at planning time, that the structural phases would not close the curriculum-dependency problem. The chips were not a late addition; they were the piece the structural work was building towards.
That ordering was correct: structure first, then intent. A “Read first ↳” chip on a chapter buried in an unnavigable hub does less work than the same chip on a chapter the reader can actually find. P2 and P4 built the context in which P5 became useful.
The maintenance cost
One thing the implementation cost conceals: the maintenance cost is not zero. As chapters change, prerequisites shift. A chip pointing to a chapter that no longer exists, or that has been superseded, is worse than no chip. It sends the reader somewhere wrong.
This is what makes the decision of which chapters carry chips a real design decision. It requires knowing the dependency graph and keeping that knowledge current as the curriculum evolves. The code is cheap. The knowledge upkeep is not.
P5 delivered the highest navigability per line of code because the lines of code were the cheapest part. The valuable work was the curriculum decision encoded in them, which is also the work that does not age well without active maintenance.
