@thebassclef/lite 0.0.1 → 0.1.0

package/substrate/standards/lite-manifest-schema-changes.md

@@ -0,0 +1,75 @@
+---
+tier: lite
+description: Chronological ledger of every lite-manifest schema change. Adopters read this before sync to know what shifted.
+---
+
+# Lite-manifest schema changes
+
+This ledger records every change to `standards/lite-manifest.schema.json` and to the shape of `<tier>-manifest.json` output. Adopters that consume the manifest read this file before every `bassclef-sync` run that crosses a version boundary. Each entry names the change type, the version bumps, the recommended downstream cure, and any retirement timeline.
+
+Sister to `standards/file-renames.json` (which tracks file-level renames). Same discipline shape at a different surface. Per `.claude/rules/lite-manifest-schema-change-discipline.md`.
+
+## Format
+
+Every entry follows this shape. Entries are newest-first for ease of scan.
+
+```
+### <SHORT TITLE> (<manifest_version bump>, <YYYY-MM-DD>)
+
+- **Change type:** field-add | field-remove | field-rename | content-remove | content-add | policy-change
+- **Fields:** <field names — comma-separated>
+- **Version bump:** vX.Y.Z → vA.B.C (reason)
+- **Rationale:** <link to issue / PR / body of the change>
+- **Downstream cure:** <what adopters need to do — usually nothing if optional-add; sometimes a code change if content shape shifts>
+- **Old shape retired:** <immediately | date | never (compat shim kept)>
+```
+
+Adopters MAY grep for the change type they care about. Adopter tooling MAY parse the ledger as flat markdown.
+
+## Retention
+
+Every entry stays in this file for the life of the manifest. Never pruned. When entries grow past ~30, split by year into archive files under `standards/lite-manifest-schema-changes-archive/YYYY.md` (not shipped yet — first split due when the year rolls over).
+
+---
+
+## Entries (newest first)
+
+### Content backfill: 96 skills gain problem + value + inputs + outputs (v1.5.0 → v1.5.1, 2026-09-07)
+
+- **Change type:** content-add
+- **Fields:** `problem`, `value`, `inputs`, `outputs` on 34 lite + 62 standard SKILL.md files (96 total; lite manifest ships 34 populated). Non-skill entries continue to omit these fields per Hoare H5 skill-surface guard.
+- **Version bump:** v1.5.0 → v1.5.1 (patch; content-only change, no schema shape shift)
+- **Rationale:** bassclef-web launches 2026-09-09 with a docs page that renders four new columns per skill card. Upstream fields shipped OPTIONAL in v0.37.0; this release ships the curated content. Extractor uses naive comma-split, so items avoid embedded commas by design (use "or"/"and" as connectors).
+- **Downstream cure:** No adopter code change needed. Renderers that already project the 4 fields (bassclef-web PR #271) now see populated content. Renderers that ignore unknown keys continue working. This release does not shift the schema — schema stays v1.6.0 in title description; manifest content version 1.5.0 → 1.5.1.
+- **Old shape retired:** Never. Non-skill entries continue to omit the 4 fields.
+- **Related tickets:** bassclef-upstream#1544 (also fixed same PR — /substrate-check symlink→file rewrite for npm-copy reality), bassclef-web#268 + #269 (closed downstream via v0.37.0 refresh).
+
+### 4-field add: inputs + outputs + problem + value (v1.5.0 → v1.6.0, 2026-09-07)
+
+- **Change type:** field-add
+- **Fields:** `inputs`, `outputs`, `problem`, `value` (all on entry — skill surface only)
+- **Version bump:** v1.5.0 → v1.6.0 (minor; adding OPTIONAL fields is backward-compatible per schema title description)
+- **Rationale:** bassclef-web#268 acceptance (docs.bassclef.dev needs 4 scan-anchors per lite skill card). Extractor upgrade in goal 2026-09-07c per `docs/iteration-bets/2026-09-07c-lite-manifest-schema-plus-extractor-plus-backfill-plus-ledger.md`. Fields ship OPTIONAL per Hoare H2 pre-mortem cure.
+- **Downstream cure:** No adopter code change needed. Parsers that ignore unknown keys continue working. Parsers that pin to exact `v1.5.0` string should loosen to a semver range like `>=1.5.0 <2.0.0` before v0.37.0 sync.
+- **Old shape retired:** Never. All prior entries stay valid (fields are OPTIONAL, not required).
+
+### upstream_commit content removed (v1.4.x → v1.5.0, 2026-09-06)
+
+- **Change type:** content-remove
+- **Fields:** `upstream_commit` (was at manifest top level, alongside `manifest_version` + `generated_at`)
+- **Version bump:** v1.4.x → v1.5.0 (minor; field removed at top level, not from entry shape)
+- **Rationale:** upstream sunj-labs/bassclef-upstream#1508 removed the field from manifest content because the value drifted between release cascade steps. Fix at commit `d20c0652` on main.
+- **Downstream cure:** bassclef-web scripts that read `upstream_commit` crashed at v0.36.0 sync (3 scripts). Cure at bassclef-web commit `c9a9da7` — derive the commit locally from `git -C <upstream> rev-parse HEAD` when the value is needed. bassclef-cli sync path had the same class; check for reads of `upstream_commit` before v0.37.0 pull.
+- **Old shape retired:** Immediately (field was removed with no compat shim). This retroactive entry documents the class that motivated the ledger discipline (per bassclef-web#269).
+
+## Related files
+
+- `standards/lite-manifest.schema.json` — the schema this ledger tracks
+- `standards/file-renames.json` — sister ledger at the file-rename surface
+- `.claude/rules/lite-manifest-schema-change-discipline.md` — methodology layer that enforces this ledger
+- `.claude/rules/we-dont-break-adopters.md` — ADR-031 parent discipline
+- `scripts/release-to-bassclef.sh` — release script that pre-flight-checks this ledger
+
+## Retirement condition
+
+This ledger retires only if bassclef stops shipping a lite manifest. Adopter count and schema change cadence may evolve; the discipline of documenting every change persists.

package/substrate/standards/luminary-problem-patterns.md

@@ -0,0 +1,481 @@
+---
+tier: lite
+description: "Auto-generated. Do not hand-edit. Re-run via: bash scripts/luminary-problem-patterns-aggregate.sh"
+---
+
+# Luminary problem-pattern catalog
+
+**Auto-generated.** Do not hand-edit. Re-run via:
+```
+bash scripts/luminary-problem-patterns-aggregate.sh
+```
+
+This index reads every `.claude/luminaries/*.md` file's frontmatter and
+extracts the `solves_problems_brownfield`, `solves_problems_greenfield`,
+and `anti_patterns` arrays. The agent reads this index when running
+`/luminary recommend` against a plain-English problem statement.
+
+## Coverage
+
+- **20 / 77** luminaries have problem-pattern frontmatter
+- Backfill tracker: `docs/luminary-problem-pattern-backfill.md`
+
+## Catalog (alphabetical by slug)
+
+### Aarron Walter (`aarron-walter`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Existing product feels functional but cold — users complete tasks without engagement
+- Microcopy is generic; brand voice doesn't come through
+- Empty states, error states, and waiting states feel like dead ends instead of moments
+
+**Solves (greenfield — 0→1 design):**
+- Designing a new consumer product where personality should differentiate from day one
+- Building microcopy + tone-of-voice as core design elements, not decoration
+- Planning a product where emotional engagement matters as much as task completion
+- Designing empty/error/waiting states as moments of brand expression in a fresh build
+
+**Anti-patterns (when NOT to channel):**
+- Regulated, clinical, or compliance-heavy surfaces — Walter is too playful
+- Power-tool or data-dense surfaces where personality slows the user down
+
+---
+
+### Abby Covert (`abby-covert`)
+
+- **Domain:** ux | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Content exists but users can't make sense of how it relates
+- Labels are inconsistent across surfaces; same thing has different names
+- Information architecture is a mess but team can't see it
+
+**Solves (greenfield — 0→1 design):**
+- Starting a content-heavy or knowledge-base product where taxonomy must precede screens
+- Designing IA before any UI for a multi-domain app
+- Building a sense-making system where labeling discipline is a first-class concern
+- Designing a product where 'naming things consistently' will be a recurring discipline
+
+**Anti-patterns (when NOT to channel):**
+- Single-screen or single-task tools
+- Pure visual or motion work
+
+---
+
+### Alan Cooper (`alan-cooper`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Existing UI exposes the system's structure when users want their workflow
+- Power users keep retracing the same multi-step path through the current UI
+- Persona research surfaces a goal but the existing UI optimizes for novice exploration
+- App is feature-rich but each user wants only one slice for their job
+
+**Solves (greenfield — 0→1 design):**
+- Designing a workflow-heavy app for returning users with named goals
+- Building a product where personas + scenarios should drive the UI before any screen sketch
+- Planning a tool for power users who need their job-specific slice surfaced from day one
+- Mid-complexity product where personas keep early design decisions grounded in real users
+
+**Anti-patterns (when NOT to channel):**
+- Truly simple consumer apps — Cooper overweights workflow modeling
+- First-launch novelty experiences — goal-directed assumes a returning user
+- Pure marketing or storytelling surfaces
+
+---
+
+### Anthropic frontend-design skill — BASELINE COMPOSES-WITH, NOT A LUMINARY
+
+Anthropic's `frontend-design` skill is the implicit baseline default adopters get from plain Claude. Bassclef's authoring skills (`/frontend-design`, `/riff-prototypes`, `/launch`, `/visual-review`) declare `composes_baseline: anthropic-frontend-design` in their frontmatter and extend the baseline with luminary-pair commitment, design tokens, and visual-review discipline.
+
+This baseline is not a luminary catalog entry; it ships with the upstream skill catalog Anthropic publishes. Bassclef extends; bassclef does not author the baseline. Adopters firing plain Claude (no bassclef substrate) inherit the baseline's typography + color + motion + spatial-composition guidance for free.
+
+See `.claude/skills/frontend-design/SKILL.md` for bassclef's baseline composition declaration and the specific extensions bassclef adds.
+
+---
+
+### Apple Human Interface Guidelines (HIG) (`apple-hig`)
+
+- **Domain:** visual | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Existing app fights iOS / macOS conventions instead of feeling native
+- Design has too many ideas competing for attention; restraint would clarify
+- Brand identity is overpowering platform conventions in the current UI
+- Polish is missing — corners, transitions, depth feel cheap
+
+**Solves (greenfield — 0→1 design):**
+- Designing an app for one specific Apple platform where native fit is a value
+- Building a product where restraint and platform conventions matter more than expression
+- Planning a polished consumer app on iOS / macOS / iPadOS
+- Designing for a platform whose users expect HIG-shaped affordances by default
+
+**Anti-patterns (when NOT to channel):**
+- Cross-platform brand-led design where native fit isn't the goal
+- Highly differentiated brand surfaces — Apple HIG forces convention over voice
+
+---
+
+### BJ Fogg (`bj-fogg`)
+
+- **Domain:** ux | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Users sign up but don't return; existing onboarding doesn't form a habit
+- Notifications fire but don't drive the right action
+- Existing onboarding tour overwhelms instead of landing a tiny first success
+
+**Solves (greenfield — 0→1 design):**
+- Designing a behavior-change product (fitness, habit, learning) where motivation × ability × trigger must align
+- Building an onboarding flow that lands a tiny first success on day one
+- Planning a product whose retention will depend on habit formation
+- Designing notification logic where the right trigger fires the right action from launch
+
+**Anti-patterns (when NOT to channel):**
+- Power-tool surfaces where the user already has motivation
+- B2B or compliance-heavy surfaces where behavior change isn't the goal
+
+---
+
+### Brad Frost (`brad-frost`)
+
+- **Domain:** visual | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Existing component library is a flat dump with gaps in mid-level molecules and organisms
+- Designers and engineers describe components inconsistently
+- Pattern library exists but doesn't compose into actual pages
+
+**Solves (greenfield — 0→1 design):**
+- Designing a fresh design system from atoms upward
+- Building a component hierarchy that will scale across many surfaces
+- Planning a system where pattern composition is a first-class discipline from day one
+- Designing a token + component + template + page taxonomy for a new product
+
+**Anti-patterns (when NOT to channel):**
+- Single-screen prototypes — atomic design is for systems
+- Marketing one-offs or campaign pages
+
+---
+
+### Dieter Rams (`dieter-rams`)
+
+- **Domain:** visual | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Existing design has accumulated features and visual elements that don't earn their place
+- Each component does too much; honest functional expression would simplify
+- Aesthetic feels dated because of decoration, not because of underlying function
+
+**Solves (greenfield — 0→1 design):**
+- Designing a product where less-but-better is the explicit value
+- Building a tool whose visual identity should follow function, not lead it
+- Planning a long-lived product where ruthless reduction will be a recurring discipline
+- Designing a fresh product where every element must justify its presence from day one
+
+**Anti-patterns (when NOT to channel):**
+- Maximalist or expressive brand surfaces
+- Storytelling or narrative-driven surfaces
+
+---
+
+### Don Norman (`don-norman`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Users keep clicking the wrong thing or missing a button; affordances are unclear
+- Interface error messages punish the user rather than help them recover
+- Mental model and system model have diverged — users predict wrong outcomes
+- Mode visibility is missing; users don't know what state they're in
+
+**Solves (greenfield — 0→1 design):**
+- Designing a new control surface where affordance language must be self-evident from first encounter
+- Building a tool whose error model should help users recover, not punish
+- Planning a product where mappings between control and effect must feel natural from day one
+- Designing a system where visibility of state is a first-class concern
+
+**Anti-patterns (when NOT to channel):**
+- Designs whose primary value is delight or emotional resonance — Norman optimizes for clarity, not joy
+- Highly abstract or conceptual UIs where direct manipulation isn't the model
+
+---
+
+### Edward Tufte (`edward-tufte`)
+
+- **Domain:** visual | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- UI shows many numbers or trends in compressed space and legibility is breaking down
+- Dashboard has accumulated decoration and chart-junk; signal is buried
+- Multi-dimensional data displays are letting one dimension drown out others
+- Users decode the chart before understanding the message
+
+**Solves (greenfield — 0→1 design):**
+- Planning a dashboard, financial report, or analytics UI that must show dense data clearly from day one
+- Designing a surface where multiple quantitative dimensions need to coexist without one drowning the others
+- Building a tool for domain experts who read data faster than narrative
+- Need small multiples or sparklines as the main display element in the new design
+
+**Anti-patterns (when NOT to channel):**
+- Sparse, narrative-heavy surfaces — Tufte over-compresses
+- Consumer-emotional or marketing surfaces — Tufte reads as cold
+- First-time onboarding flows — density assumes domain familiarity
+
+---
+
+### Ellen Lupton (`ellen-lupton`)
+
+- **Domain:** visual | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Page reads as a wall of undifferentiated text
+- Visual hierarchy is broken — every element claims equal importance
+- Typography is inconsistent across pages or feels chosen by accident
+- Reading rhythm is broken by mis-set line height, measure, or contrast
+
+**Solves (greenfield — 0→1 design):**
+- Designing a content-heavy product where reading rhythm is core to the experience
+- Setting type scale and hierarchy from scratch for a new brand or system
+- Planning a long-form or editorial surface where typeface choice carries voice
+- Building a fresh product where brand voice should come through in the typeface from day one
+
+**Anti-patterns (when NOT to channel):**
+- Pure data-density surfaces — Tufte is a better fit than Lupton
+- Engineering-internal tools where readability beats voice
+
+---
+
+### Erika Hall (`erika-hall`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Team is shipping based on assumptions, not evidence about users
+- Research is happening but findings don't reach decisions
+- Discovery work is being skipped because of velocity pressure
+
+**Solves (greenfield — 0→1 design):**
+- Starting a new product and need contextual inquiry to ground the thesis
+- Designing discovery research before any UI is sketched
+- Building a research practice into the team's discipline from day one
+- Designing a product where 'we don't know what users actually do' is the first risk to retire
+
+**Anti-patterns (when NOT to channel):**
+- Late-stage refinement work where research is already done
+- Engineering-only surfaces where users aren't directly relevant
+
+---
+
+### Google Material Design (`google-material`)
+
+- **Domain:** visual | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Existing component library lacks systematic spacing, color, type tokens
+- Cross-platform consistency is breaking; surfaces look like different products
+- Theming and dynamic color aren't working across user preferences
+
+**Solves (greenfield — 0→1 design):**
+- Designing a multi-surface system where systematic tokens and density tiers are needed from the start
+- Building cross-platform consistency without bespoke per-platform polish
+- Planning a product where theming + accessibility are core, not retrofitted
+- Designing component density tiers (compact / standard / comfortable) into the system from day one
+
+**Anti-patterns (when NOT to channel):**
+- Highly distinctive brand surfaces — Material genericizes
+- Premium or differentiated visual identity work
+
+---
+
+### Jakob Nielsen (`jakob-nielsen`)
+
+- **Domain:** ux | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Existing UI needs structured expert evaluation against usability heuristics
+- Usability violations are happening but team has no checklist to catch them
+- Standardization across the product matters but discipline is loose
+
+**Solves (greenfield — 0→1 design):**
+- Building a new product and want heuristic review baked into the design discipline
+- Designing checkpoints where heuristic evaluation can fire before user testing
+- Planning a product where standardization across surfaces will be a measurable goal
+- Setting up an evaluation framework for a product about to launch
+
+**Anti-patterns (when NOT to channel):**
+- Generative or first-pass design — Nielsen evaluates, doesn't ideate
+- Brand or emotional surfaces where heuristics miss the point
+
+---
+
+### Jenifer Tidwell (`jenifer-tidwell`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Common interaction in current UI is being reinvented when proven patterns exist
+- Designer is choosing novel solutions where well-known answers are better
+- Existing design lacks shared vocabulary for interaction choices across team
+
+**Solves (greenfield — 0→1 design):**
+- Composing a new app from proven interaction patterns instead of inventing each one
+- Need a vocabulary to communicate interaction choices to engineering on a fresh build
+- Building complex flows; want to compose from named patterns first, novel last
+- Designing a multi-flow product where interaction patterns must be consistent from day one
+
+**Anti-patterns (when NOT to channel):**
+- Bleeding-edge novel interactions — Tidwell catalogs proven patterns, not invents new ones
+- Pure visual or brand-driven surfaces
+
+---
+
+### Jesse James Garrett (`jesse-james-garrett`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Project mixes strategy, scope, structure, skeleton, and surface decisions in one conversation
+- Surface decisions are over-determining structural choices in the existing UI
+- Team can't agree on which decisions belong at which level
+
+**Solves (greenfield — 0→1 design):**
+- Starting a multi-surface product where the five planes should sequence design decisions
+- Building a UX strategy that decomposes work into orderable layers from day one
+- Planning a product where strategy precedes scope precedes structure precedes skeleton precedes surface
+- Designing a multi-month product where UX governance needs explicit decision-tier vocabulary
+
+**Anti-patterns (when NOT to channel):**
+- Tactical UI fixes where the five planes is overhead
+- Single-page or single-screen work
+-   - **Strategy** — user needs + product objectives. What success means.
+-   - **Scope** — functional specifications + content requirements. What
+-   - **Structure** — interaction design + information architecture. How
+-   - **Skeleton** — interface design, navigation design, information
+-   - **Surface** — sensory design (visual, auditory). How it looks and
+
+---
+
+### Luke Wroblewski (`luke-wroblewski`)
+
+- **Domain:** ux | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Existing form has many fields and abandonment is high
+- Mobile experience is desktop-first squeezed into small screens
+- Input types, validation, and progressive disclosure aren't optimized for thumbs
+
+**Solves (greenfield — 0→1 design):**
+- Designing a mobile-first product where forms are core to the value
+- Planning input surfaces where progressive disclosure must be designed from the start
+- Building for mobile users where thumb-zone economy matters
+- Designing form flows where staged input (now / later / never-asked) is a first-class concern
+
+**Anti-patterns (when NOT to channel):**
+- Read-only data display — Wroblewski is for input
+- Desktop-power-tool surfaces where mobile isn't primary
+
+---
+
+### Peter Morville (`peter-morville`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Users can't find content that exists in the product
+- Information architecture has no consistent labeling or hierarchy
+- Search returns results but not the RIGHT results
+- Navigation grew organically and now no one knows the full structure
+
+**Solves (greenfield — 0→1 design):**
+- Designing a content-heavy product where findability will be core from day one
+- Planning the IA before screens for a multi-section app
+- Building search + browse surfaces where wayfinding is a first-class concern
+- Designing a product for an audience where findability matters more than discoverability
+
+**Anti-patterns (when NOT to channel):**
+- Single-screen tools or focused workflows — Morville is for multi-page IA
+- Brand or marketing surfaces where wayfinding isn't the job
+
+---
+
+### Sophia V. Prater (`sophia-prater`)
+
+- **Domain:** ux | **Depth:** full
+
+**Solves (brownfield — existing UI):**
+- Existing multi-entity app where users mentally model objects but UI exposes screens or processes
+- Same entity appears in many flows but isn't unified as a concept
+- Navigation doesn't reflect the domain's noun structure
+
+**Solves (greenfield — 0→1 design):**
+- Designing a CRUD-heavy or domain-rich product where entity relationships should drive the UI
+- Planning IA from the domain model first, not from process flows
+- Building an app where users will mentally manipulate objects and the UI should match from day one
+- Designing a multi-entity product where consistent entity expression matters across surfaces
+
+**Anti-patterns (when NOT to channel):**
+- Process-driven workflows where actions matter more than objects
+- Single-entity tools or marketing surfaces
+
+---
+
+### Steve Krug (`steve-krug`)
+
+- **Domain:** ux | **Depth:** stub
+
+**Solves (brownfield — existing UI):**
+- Existing interface forces users to read or think more than the task warrants
+- User testing keeps surfacing the same friction points but team can't see them
+- Self-evident affordances are missing in the current UI; users hesitate before every click
+- Navigation, labels, and structure aren't immediately obvious
+
+**Solves (greenfield — 0→1 design):**
+- Designing a consumer or low-engagement product where 'don't make me think' is the bar
+- Building a new public-facing surface where usability is the core differentiator
+- Planning a tool that needs to be self-evident from first encounter
+- Designing a product whose audience will not invest effort to learn the interface
+
+**Anti-patterns (when NOT to channel):**
+- Power-user tools where complexity is the value
+- Domain-expert surfaces where 'don't make me think' undersells the user
+
+---
+
+## How `/luminary recommend` consumes this
+
+The agent reads this aggregate as one of its signal sources when ranking
+luminaries against an operator's plain-English problem statement. The
+modality of the operator's input (brownfield refactor vs greenfield
+concept) determines which array is matched:
+
+- Operator input mentions "existing UI", "current product", "today's
+  app" → match against `solves_problems_brownfield` arrays
+- Operator input mentions "designing", "planning", "building",
+  "0→1", "from scratch" → match against `solves_problems_greenfield`
+  arrays
+- Ambiguous input → match against both, weighted by signal strength
+
+`anti_patterns` always subtract from a luminary's score when the
+operator's input matches an entry — regardless of modality.
+
+## Schema (per luminary file)
+
+```yaml
+solves_problems_brownfield:
+  - "Plain-English symptom statement (~80 chars)"
+  - "..."
+solves_problems_greenfield:
+  - "Plain-English opportunity statement (~80 chars)"
+  - "..."
+anti_patterns:
+  - "When NOT to channel (Welch INSTEAD-block)"
+  - "..."
+```
+
+All three fields are optional during backfill (LR6 onward). A luminary
+with no problem-pattern frontmatter doesn't appear in this aggregate
+but remains in the catalog for `/luminary` browsing.