dotfiles/claude/memory/project-arc-breadcrumb-spec-pending.md

---
name: ARC universal breadcrumb system — design spec session pending; sequenced AFTER
  type-pass
description: Steward identified 2026-05-01 that the breadcrumb system should appear
  for all content, not just about-enfilade pages. Current state has duplicated breadcrumb
  logic across 3 templates with inline encoding of parent destinations. Spec session
  deferred until after the type-pass; type-pass resolves which content types exist
  and their relationships, which is the substrate breadcrumb design needs.
type: project
originSessionId: 597aba4e-942b-4f20-8a89-3d801b14c971
permalink: claude-memory/project-arc-breadcrumb-spec-pending
---

# ARC universal breadcrumb system — pending

**Status:** Design spec session pending. Sequenced AFTER the corpus `type:` audit.

## Origin (2026-05-01)

While doing a small fix for missing breadcrumbs on `/bio/` and `/cv/`, steward noted: *"the breadcrumb system should appear for all content."* Then, after I sketched a unified-partial proposal, steward asked whether that was Prime-Directive-aligned. Honest answer surfaced three smells:

1. The lift to a unified partial requires answering content-typology questions that aren't answered yet (where does each type's breadcrumb point?). Doing it silently would be unauthorized scope expansion.
2. The proposal conflated three things: small fix (bio + cv), design pass (typology→parent), consolidation refactor (partial template).
3. *"Build what you will not need to rebuild"* argues against encoding wrong content-typology decisions today and rebuilding everything later when steward disagrees.

Steward's call: *"Ok, this sounds like we need to write a spec to do this correctly. Let's follow your suggestion for right now and then spend a focussed session designing the spec — the code should flow easily afterwards. And, now that I think of it, this should probably be done after the `type:` audit."*

## Sequencing locked

1. **Now (done 2026-05-01):** stopgap fix for bio + cv only — `enfilade-hidden: true` flag added to `collectEnfiladeIds` in site.hs; bio + cv route through about-page.html for breadcrumb but stay out of the enfilade door strip. Site.hs edit carries an explicit STOPGAP comment naming this deferral.
2. **Next: corpus `type:` audit** — reclassify Heliotrope → Meditation, Graffiti Girl → Reverie, Dec 23 dream → Reverie/Dream, Dec 22 half-light → Meditation, Death of a Hero → Hommage, Matthieu Taliesin → Heteronym, Vespers boundary, /now-page reclassify, etc. (per `project-arc-rework.md` 2026-04-20 + 2026-04-23 sections). Resolves *which types exist* and *what their relationships are*. Gated on MemPalace returning queryable + chamber-library mine completing.
3. **Then: breadcrumb spec session** — focused 2-3 hour design conversation. Walk through each content type, decide its parent. Open questions:
   - Does an essay-in-a-sequence breadcrumb to `/essays/` or to `/essays/after-the-reply/`?
   - Where does an `observation` breadcrumb to — `/observations/` or `/annals/`?
   - Chamber-attached pieces (with ⟐ apparatus) — to their content type or to `/chamber/`?
   - Does the homepage have one? Does `/annals/` (a listing page itself)?
   - How do bio + cv re-integrate cleanly when the unified system replaces the stopgap flag?
4. **Then: implementation** — single `templates/partials/breadcrumb.html`, class-to-parent map in site.hs as faithful encoding of the design decisions. Existing inline breadcrumbs in `post.html` / `about-page.html` / `sequence-index.html` get removed (preserve-don't-delete: archive the inline blocks with provenance). The `enfilade-hidden: true` stopgap is retired; bio + cv use the unified mechanism.

## About-enfilade siblings need consistent classification (added 2026-05-02)

While diagnosing why Hearth's body-block sidenote rendered roman-on-roman (against Bringhurst contrast), we found that `class: lex` in Hearth's frontmatter was firing the lex sidenote density-exception inappropriately. Surface fix shipped (SCSS selector narrowed from `article.lex .sidenote` to `article.lex .voice-block .sidenote` in commit `0abfe88`). But the deeper issue is **misclassification**: Hearth is an About-enfilade page (alongside Colophon, AldineXXI, Vignette, Attention, Tools, Now, plus Bio + CV) — it is not a lex-cluster page like posture / marks.

Steward verbatim 2026-05-02: *"The Hearth is an About page, like the rest of the enfilade ... and Colophon, AldineXXI, Vignette ... and the rest."*

Current state of About-enfilade `class:` assignments — scattered across the typology by accident of when each page was created (the About-enfilade-as-shape only became architecturally explicit in the 2026-04-27 enfilade-emergent session):

- Bio · CV — no `class:` (default)
- Colophon — `class: essay`
- Hearth — `class: lex` (now misclassified per above)
- AldineXXI · Vignette · Attention · Tools · Now — varied, need to be checked

**Type-pass scope expansion:** the audit should not only reclassify content-types (Heliotrope → Meditation, etc.) but also normalize the About-enfilade siblings — possibly under a new shared `class: door` (or `class: about-page`, or whatever serves) so the entire 8-door slate is consistent and a future enfilade addition has a predictable class to take. The reward: the SCSS narrowing for Hearth becomes unnecessary (Hearth would no longer be `article.lex` and would inherit base sidenote behavior naturally) — what is currently a hack at the SCSS layer dissolves at the data layer where it belongs.

Steward verbatim acknowledgment: *"the about pages (or whatever we will assign them as `type:`) need to be unified, this should make everything easier and then we can have the Hearth sidenotes render without a hack."*

## Adjacent architectural concerns to surface in the spec session

The steward's "is the enfilade system simple, consolidated, elegant?" question surfaced three smells worth addressing or naming-as-acceptable in the spec session:

1. **`enfilade-order: 0` does double duty** — both "position" and "hide-from-row." A new page wanting "hidden member" semantics has nowhere clean to live (which is why I had to add the `enfilade-hidden` flag as fourth field stopgap).
2. **Two parallel mechanisms.** `enfilade-*` (about) and `sequence_*` (After the Reply) do morally the same thing — gathered navigation by membership — with different vocabularies, different gather logic, different templates. Could be unified under one "collection" abstraction. Unifying is bigger work; declaring them as intentionally separate (different purposes despite morphological similarity) is also a valid call.
3. **Hardcoded pattern union in site.hs.** `aboutEnfiladeCtx` literally enumerates `pages/*.md ∨ chamber/index.md ∨ lares/index.md`. Each new enfilade-bearing tree requires a site.hs edit. Could be data-driven.

These don't have to be solved in the breadcrumb spec — but they sit adjacent and the spec session should at least name whether to include or defer them.

## Stopgap details (for later cleanup)

When the unified breadcrumb lands and the stopgap retires:

- Remove `enfilade-hidden: true` filter from `collectEnfiladeIds` in `site.hs`
- Remove the `enfilade-hidden: true` field from `content/pages/bio.md` and `content/pages/cv.md`
- Remove the `enfilade-name: "Bio"` from bio.md if the unified breadcrumb has its own label-override mechanism
- Verify bio + cv still get correct breadcrumbs under the new mechanism

## Cross-references

- Steward verbatim direction: this session 2026-05-01
- `project-arc-rework.md` — full ARC rework landscape including the type-audit work that gates this
- `project-after-the-reply-publication-state.md` — the closed sequence work that introduced the parallel `sequence_*` family
- `feedback-canonical-workstream-tracker-discipline.md` — read this file at /wake-up when ARC work is in scope