The P2 branch — feat/learning-nav-p2-tracks — was the first navigation change to go through the full UI gate since the learning hub launched. Before a single line of code changed, there was an interactive approval mockup. Track sections and a JSON-LD breadcrumb do not sound like work that warrants a design review. They are structural scaffolding. But P2 triggered the gate because the spec required it, and working through the requirement made something visible: the hub was missing a structural layer that no amount of content would supply.
That was 2 July. By 3 July, P5 had shipped — the prerequisite chips, the “Read first ↳” items at each chapter head that conventions.md had already named the single highest-value navigability fix. By 9 July, the static-next-cpanel course was complete: eight chapters, 8/8 published.
Improving on the single-chip framing in the previous navigation write-up: P5 alone established that prerequisite chips were the highest-leverage individual fix. P2 and the completed course together show why the backlog kept filing that bottleneck under content instead of navigation.
What the backlog said
The learning hub backlog uses four priority tiers: M (must), E (essential), N (nice), S (stretch). Through most of the hub’s life, M and E held content items — more chapters, more tracks, more worked examples. Navigation items sat in N and S. Worth doing eventually. Not blocking anything. Not the bottleneck.
That categorisation was wrong.
What P2 moved
Track sections group related chapters visually and semantically. Before P2, the hub listed chapters as a flat sequence. A reader arriving for the first time had no signal about which chapters belonged to which track — whether they were starting a beginner flow or an intermediate one, whether the chapter they wanted was three items down or ten.
The S1 JSON-LD breadcrumb shipped alongside P2. It communicates hierarchy to search engines: a crawlable signal that this chapter belongs to this course belongs to this hub. A chapter page without it is technically reachable but opaque to structured discovery. Both changes are invisible to a reader already on a chapter page. Both matter enormously to a reader trying to find one.
The UI gate surfaced something else. Building the approval mockup forced a clear answer to questions about section grouping and visual hierarchy that the backlog had never required an answer to. The questions weren’t new. They had just never been blocking.
What P5 moved
The prerequisite chip is “Read first ↳” at a chapter head. Three words and a downward arrow.
It carries sequencing information the chapter content itself cannot supply. A reader who lands on chapter 4 of static-next-cpanel via search has no way of knowing whether chapter 3 is a hard dependency or optional context. Without the chip, they navigate blind or they leave. With it, the decision takes three seconds.
conventions.md had already named N1 the single highest-value navigability fix before P5 went in. That assessment held. P5 landed on feat/learning-nav-p5-prereqs. The chip is now the chapter-head standard across the hub.
The content side
On 9 July, static-next-cpanel went from zero to 8/8 published. The first three chapters came out of a multi-agent ultracode Workflow drafting from the curriculum spec. Chapters 4–8 followed the same day on a second run.
The content is real and grounded: the unoptimized flag on next/image (required for static export — the default optimiser assumes a server is present), LiteSpeed .htaccess rewrite rules for trailing-slash handling, the 404.html static fallback, the GitHub Actions workflow pushing via FTP to cPanel.
A complete course. The hub needed it. It also landed into a hub that now had track sections to contextualise it, prerequisite chips to sequence it, and structured data to surface it. The content was the visible deliverable. The navigation was what made the deliverable reachable.
Shipping those eight chapters without P2 and P5 first would have been correct work in the wrong order.
Why the backlog got it wrong
Content is legible. A new chapter adds a row, covers a topic, can be pointed at. A track section is a grouping signal. A prerequisite chip is a three-word label. Neither shows up in a chapters-published counter.
So the backlog defaults to content. Navigation debt compounds quietly until something forces it into view. In this case that something was a separate navigation spec — docs/specs/learning-hub/navigation.md — extracted from the general backlog into its own phased plan with its own priority tier.
Without the extraction, P2 and P5 would still be sitting in N, waiting for enough content items to clear before anyone looked at them. The spec gave navigation items a path to shipping on their own terms. That is the corrective mechanism. Not a different backlog tool. A different backlog question: does this item affect how readers find content, or what content exists to find?
After the close-out
Post-ship housekeeping on 3 July: reconcile every tracking surface, write per-item statuses into conventions.md, produce a navigable living atlas for the navigation programme. The M/E/N/S backlog now carries ✅/⬜ per item.
What the housekeeping surfaced: the items with the most leverage were not the content items. Track sections, prerequisite chips, and a JSON-LD breadcrumb moved further with less than eight chapters of course content.
The course chapters covered ground that needed covering. The navigation items unlocked ground already covered. Those are not the same kind of work, and the backlog had been treating them as if they were.
What changes in the categorisation
One re-filing rule. When a backlog item affects how a reader finds, sequences, or contextualises content — not what the content covers — it is a navigation item. It belongs in a navigation spec, not the content backlog. It does not sit in N or S because it produces no visible deliverable. It goes in M or E because it is load-bearing infrastructure for the content that already exists.
The diagnostic question: “Does this help readers find what they have, or give them more to find?” The first kind ships before the second.
The backlog had those two in the wrong order for most of the hub’s life. The navigation spec corrected it. The 3 July close-out wrote that correction into the tracking permanently.
