@thebassclef/lite 0.1.2 → 1.0.0

package/substrate/.claude/hooks/whereami-utc-gate.sh

@@ -1,142 +0,0 @@
-#!/usr/bin/env bash
-# tier: lite
-# install-class: dual
-#
-# whereami-utc-gate.sh — PreToolUse hook that BLOCKs Edit|Write|MultiEdit
-# on docs/whereami.md when last_updated.at value does not end in Z (UTC).
-#
-# Wires per .claude/settings.json under hooks.PreToolUse with matcher
-# "Edit|Write|MultiEdit". Reads the tool's event JSON from stdin,
-# extracts the incoming content (content for Write; new_string for Edit
-# and MultiEdit), scans for last_updated.at timestamp values in both
-# YAML-frontmatter form (`at: <timestamp>` under `last_updated:` block)
-# and markdown-section form (`## Last updated` followed by a timestamp).
-# BLOCKs (exit 2) when any value carries a non-Z offset.
-#
-# Cure B side of #897; Cure A (sync-hook parser accepts both shapes for
-# grace window) shipped in bet 26e PR #917. Cure B is the write-time
-# gate; adopter grace window per ADR-031 through 2026-10-31 — Cure A
-# parser keeps working during migration.
-#
-# Ships as WU-4 of bet 2026-07-26g.
-#
-# Override: SKIP_WHEREAMI_UTC_GATE=1 (logged to stderr).
-#
-# Pairs with: .claude/rules/state-schema-validation.md (sister discipline
-#             at state-spine surface; this hook covers the whereami-
-#             specific UTC-Z constraint)
-
-set -u
-
-# === Override path ===
-
-if [ "${SKIP_WHEREAMI_UTC_GATE:-}" = "1" ]; then
-  echo "[whereami-utc-gate.sh] SKIP_WHEREAMI_UTC_GATE=1 — bypassing" >&2
-  exit 0
-fi
-
-# === Read PreToolUse event ===
-
-EVENT_JSON="$(cat 2>/dev/null || true)"
-if [ -z "$EVENT_JSON" ]; then
-  exit 0  # empty stdin → pass through (fail-soft per stdin contract)
-fi
-
-# Fail-soft on malformed JSON per sufficiency criterion 6
-TOOL_NAME="$(echo "$EVENT_JSON" | jq -r '.tool_name // empty' 2>/dev/null || echo "")"
-TARGET_PATH="$(echo "$EVENT_JSON" | jq -r '.tool_input.file_path // empty' 2>/dev/null || echo "")"
-
-# --- Tool filter: only Edit / Write / MultiEdit trigger ---
-case "$TOOL_NAME" in
-  Edit|Write|MultiEdit) ;;
-  *) exit 0 ;;
-esac
-
-# --- Path filter: only docs/whereami.md triggers ---
-if [ -z "$TARGET_PATH" ]; then
-  exit 0
-fi
-
-# Match either bare "docs/whereami.md" or an absolute path ending in it
-case "$TARGET_PATH" in
-  */docs/whereami.md|docs/whereami.md) ;;
-  *) exit 0 ;;
-esac
-
-# === Extract incoming content ===
-
-# Write uses .tool_input.content; Edit + MultiEdit use .tool_input.new_string
-CONTENT=""
-case "$TOOL_NAME" in
-  Write)
-    CONTENT="$(echo "$EVENT_JSON" | jq -r '.tool_input.content // empty' 2>/dev/null || echo "")"
-    ;;
-  Edit|MultiEdit)
-    CONTENT="$(echo "$EVENT_JSON" | jq -r '.tool_input.new_string // empty' 2>/dev/null || echo "")"
-    ;;
-esac
-
-if [ -z "$CONTENT" ]; then
-  exit 0  # nothing to validate
-fi
-
-# === Scan for non-Z last_updated.at values ===
-#
-# Two shapes to cover per Cure A parser scope:
-#
-# 1. YAML frontmatter (Shape B state-spine):
-#      last_updated:
-#        at: 2026-07-26T18:30:00Z
-#
-# 2. Markdown section (## Last updated form):
-#      ## Last updated
-#
-#      2026-07-26T18:30:00Z — session-end
-#
-# The scan pattern: any ISO-8601 timestamp of shape YYYY-MM-DDTHH:MM:SS
-# followed by a non-Z suffix (+HHMM, -HHMM, +HH:MM, -HH:MM). We do NOT
-# require the surrounding structure — a bare non-Z timestamp anywhere
-# in the whereami content is a BLOCK signal.
-
-NON_Z_MATCH=""
-
-# Regex catches: 2026-07-26T18:30:00+0100 / -0500 / +01:00 / -05:00
-NON_Z_PATTERN='[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}[+-][0-9]{2}:?[0-9]{2}'
-
-NON_Z_MATCH="$(printf '%s' "$CONTENT" | grep -oE "$NON_Z_PATTERN" | head -3 || true)"
-
-if [ -z "$NON_Z_MATCH" ]; then
-  exit 0  # all timestamps end in Z (or none present); pass
-fi
-
-# === BLOCK message ===
-
-echo "" >&2
-echo "============================================" >&2
-echo "🛑 WHEREAMI UTC GATE — BLOCKED 🛑" >&2
-echo "============================================" >&2
-echo "" >&2
-echo "File:  $TARGET_PATH" >&2
-echo "Tool:  $TOOL_NAME" >&2
-echo "" >&2
-echo "Found timestamp value(s) with non-Z (non-UTC) offset:" >&2
-echo "$NON_Z_MATCH" | sed 's/^/  /' >&2
-echo "" >&2
-echo "Spec: .claude/skills/session-end/SKILL.md L60 — \"Set last_updated" >&2
-echo "      to current UTC ISO-8601 timestamp.\"" >&2
-echo "" >&2
-echo "Cure: rewrite the value to end in Z. Get current UTC:" >&2
-echo "" >&2
-echo "  date -u +%FT%TZ" >&2
-echo "" >&2
-echo "Adopter grace window per ADR-031: Cure A parser (bet 26e PR #917)" >&2
-echo "accepts both Z and +HHMM through 2026-10-31. Cure B (this hook)" >&2
-echo "closes the write-time class so new writes stay UTC-Z." >&2
-echo "" >&2
-echo "Override (logged): SKIP_WHEREAMI_UTC_GATE=1 <command>" >&2
-echo "" >&2
-echo "Rule:  .claude/rules/state-schema-validation.md" >&2
-echo "Issue: bassclef-upstream#897 Cure B" >&2
-echo "============================================" >&2
-
-exit 2

package/substrate/.claude/luminaries/alan-cooper.md

@@ -1,170 +0,0 @@
----
-tier: lite
-name: Alan Cooper
-slug: alan-cooper
-claimed_by: [designer]
-referenced_by_skills: [ia-model, jtbd-tasks, task-scenarios]
-primary_domain: ux
-depth: full
-sources:
-  - type: book
-    title: "About Face: The Essentials of Interaction Design (4th edition)"
-    authors: ["Alan Cooper", "Robert Reimann", "David Cronin", "Christopher Noessel"]
-    year: 2014
-    url: "https://www.wiley.com/en-us/About+Face%3A+The+Essentials+of+Interaction+Design%2C+4th+Edition-p-9781118766576"
-    isbn: "9781118766576"
-    methodology_covered:
-      - "Goal-Directed Design — design starts from user goals, not features or tasks"
-      - "Personas as design tools — composite archetypes derived from user research"
-      - "Scenarios — narrative descriptions of personas using the product to achieve goals"
-      - "Three categories of users: novice + intermediate + expert; design for the perpetual intermediate"
-  - type: book
-    title: "The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity"
-    authors: ["Alan Cooper"]
-    year: 1999
-    url: "https://www.pearson.com/en-us/subject-catalog/p/inmates-are-running-the-asylum-the-why-high-tech-products-drive-us-crazy-and-how-to-restore-the-sanity/P200000009296"
-    isbn: "9780672326141"
-    methodology_covered:
-      - "Programmer-driven design produces hostile interfaces"
-      - "Interaction designers as a distinct discipline, separate from engineering"
-      - "Persona origin — Cooper's first published articulation of the persona methodology"
-verification_status: verified
-solves_problems_brownfield:
-  - "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_problems_greenfield:
-  - "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:
-  - "Truly simple consumer apps — Cooper overweights workflow modeling"
-  - "First-launch novelty experiences — goal-directed assumes a returning user"
-  - "Pure marketing or storytelling surfaces"
-description: "\"Personas are precision tools — each one a research-grounded behavioral archetype, not a fictional user."
----
-
-# Alan Cooper
-
-## Signature
-
-*"Personas are precision tools — each one a research-grounded behavioral archetype, not a fictional user. Start with user goals and let personas carry you there."*
-
-"Father of Visual Basic"; founder of Cooper (the consultancy); author of
-**About Face** and **The Inmates Are Running the Asylum**. The bassclef
-voice on **Goal-Directed Design** and the proper use of personas as
-research artifacts.
-
-## Core methods
-
-- **Goal-Directed Design** — Start with user goals (what they want to
-  accomplish, at life/experience/end levels), then derive tasks, then
-  derive interface. Feature-first design inverts this and produces
-  feature-dense, goal-incoherent products.
-- **Personas as behavioral archetypes** — Built from interview pattern
-  analysis, not invented. Each persona represents a distinct goal set +
-  mental model + behavior pattern. A good product serves a primary
-  persona ruthlessly; secondary personas are served if it doesn't
-  compromise the primary.
-- **Three levels of goals** — Life goals (long-term aspirations),
-  experience goals (how the interaction should feel), end goals (what
-  they want to accomplish in this session). Life goals shape brand;
-  experience goals shape interaction; end goals shape task flow.
-- **Scenarios over requirements** — Describe the user in their context
-  pursuing their goal. A list of requirements decomposes; a scenario
-  holds the context that makes requirements make sense.
-- **Dancing bear anti-pattern** — When something is remarkable *that it
-  works at all*, we accept it despite being difficult to use. Enterprise
-  software especially. Cooper's insight: don't accept the dancing bear.
-
-## When to channel this luminary
-
-When the biggest risk is building the wrong thing for the wrong person.
-Cooper dominates when you have a target user population with distinct
-behavior patterns, when goals (not features) should drive the product,
-and when the risk of serving-everyone-badly is real. Think: operator
-tools where the primary user does this job all day, specialist tools
-where casual users will never be the target, B2B products with clear
-user roles.
-
-Do NOT channel Cooper as primary for: consumer products with vague
-personas, rapid prototyping where persona rigor is premature, projects
-where research budget doesn't support proper persona development (use
-lightweight JTBD instead).
-
-## Stack translation
-
-In a Next.js + Prisma operator tool:
-
-- **User goals → top-level nav** — If the primary persona's goal is
-  "move deals through pipeline efficiently," nav centers on deal flow,
-  not on feature taxonomy.
-- **Personas → role-based access + UI variants** — Actual personas
-  often map to auth roles (Operator vs Broker vs Viewer). Each role
-  gets a goal-optimized surface, not a feature-subset of a generic UI.
-- **Scenarios → key path tests** — Each scenario becomes an end-to-end
-  test that walks through the persona's goal. If the scenario breaks,
-  the product breaks for that persona.
-- **Primary persona dominance** — When Primary Persona and Secondary
-  Persona needs conflict, Primary wins. Tailwind variants, conditional
-  rendering, feature flags — all serve this.
-
-## Anti-patterns it prevents
-
-- **Self-referential design** — designing for ourselves because we're
-  easy to imagine. Cooper's rigor demands research-grounded personas.
-- **Generic "the user"** — vague singular user that's really an
-  amalgam of all users. Produces features for all, good-fit for none.
-- **Feature-driven roadmap** — building because the feature was
-  requested, not because it serves a persona's goal. Accumulates
-  feature bloat without coherent direction.
-- **Persona gallery** — fictional marketing personas dressed as UX
-  personas. Names, photos, and hobbies without behavioral grounding.
-  Useless for design decisions.
-- **Goal conflation** — treating "user wants to export to CSV" as a
-  goal. That's a task. The goal is "report to their manager." The task
-  could be replaced by a better path to the goal.
-
-## Worked example
-
-For POA's deal pipeline, Cooper's approach starts with:
-
-**Primary persona**: "Operator" — the person whose full-time job is
-managing deal flow. Life goal: become a successful PE operator.
-Experience goal: feel in control of their pipeline at a glance. End
-goals per session: advance stuck deals, respond to broker inbound, log
-new conversations, identify stalled opportunities.
-
-**Secondary persona**: "Broker" — external contact. Life goal: maximize
-commissions. Experience goal: trust the platform. End goals per session:
-submit new listings, see status on submitted deals, communicate with
-Operator.
-
-**Primary wins**: the main surface is optimized for Operator. Broker
-access is a narrow, focused interface (not the Operator UI with fewer
-permissions). Dashboards emphasize stuck/stalled deals (end-goal
-triggers) over total-deals-count (vanity metric).
-
-What Cooper would NOT produce: a generic "deal management platform"
-designed for "users." A feature-grid home page. A Broker UI that's
-just Operator UI with most nav items hidden.
-
-## Sources
-
-- *About Face: The Essentials of Interaction Design* — Cooper,
-  Reimann, Cronin, Noessel, Wiley (4th ed 2014) — the foundational text
-- *The Inmates Are Running the Asylum* — Cooper (1999, rev. 2004)
-- cooper.com — Cooper consultancy (now part of Designit)
-
-## Related luminaries
-
-- **Kim Goodwin** — Goodwin provides the operational method for
-  Cooper's Goal-Directed Design; pair them always.
-- **Sophia Prater** — OOUX starts with objects; Cooper with goals. Both
-  reject feature-first. Complementary at different layers.
-- **Teresa Torres** — Continuous Discovery updates Cooper's research
-  rigor for weekly cadence.
-- **Indi Young** — Mental models research at the thinking layer below
-  Cooper's behavioral archetypes.

package/substrate/.claude/luminaries/alistair-cockburn.md

@@ -1,140 +0,0 @@
----
-tier: lite
-name: Alistair Cockburn
-slug: alistair-cockburn
-claimed_by: [architect, builder, shaper]
-referenced_by_skills: [decompose, spec, prototype-variants]
-primary_domain: architecture
-depth: full
-solves_problems_brownfield:
-  - "The system's business logic is tangled with database access, HTTP handling, and third-party calls — changing one requires understanding all"
-  - "Use cases are written as vague user stories that can't be used as acceptance tests"
-  - "The architecture works locally but fails at each deployment because no one tested the full wired path"
-  - "Every new feature requires touching the database, the service layer, and the API in one change — no independent seams"
-solves_problems_greenfield:
-  - "Designing a system where business logic can be tested without a running database or HTTP stack"
-  - "Planning the first end-to-end slice that proves the architecture before building any feature depth"
-  - "Writing use cases that serve as both requirements and acceptance test specifications"
-  - "Choosing a methodology weight that fits the team size and stakes — lightweight for small teams, heavier for safety-critical work"
-anti_patterns:
-  - "UI-only or data-layer-only work where hexagonal architecture is over-engineering for the scope"
-  - "Exploratory prototypes where formal use cases would slow down learning"
-  - "Teams that are fluent in BDD/TDD — the walking skeleton concept is built into their practice"
-sources:
-  - type: book
-    title: "Writing Effective Use Cases"
-    authors: ["Alistair Cockburn"]
-    year: 2000
-    url: "https://www.amazon.com/Writing-Effective-Use-Cases-Cockburn/dp/0201702258"
-    isbn: "0201702258"
-    methodology_covered:
-      - "Use case writing — title, primary actor, preconditions, main success scenario, extensions"
-      - "Goal levels — cloud, kite, sea level (user goals), fish, clam; write at sea level"
-      - "Use cases as both requirements and acceptance test specifications"
-  - type: book
-    title: "Agile Software Development: The Cooperative Game"
-    authors: ["Alistair Cockburn"]
-    year: 2006
-    url: "https://www.amazon.com/Agile-Software-Development-Cooperative-Game/dp/0321482751"
-    isbn: "0321482751"
-    methodology_covered:
-      - "Crystal methodology family — process weight matched to team size and criticality"
-      - "Walking skeleton — thin, real, end-to-end path before any feature depth"
-      - "Software development as a cooperative game of invention and communication"
-  - type: article
-    title: "Hexagonal Architecture (Ports and Adapters)"
-    authors: ["Alistair Cockburn"]
-    year: 2005
-    url: "https://alistair.cockburn.us/hexagonal-architecture/"
-    methodology_covered:
-      - "Ports and Adapters — business logic in the center, ports define interfaces, adapters implement them"
-      - "Driving vs driven adapters — test adapters on the driving side; real infrastructure on the driven side"
-      - "Business logic never imports infrastructure"
-  - type: website
-    title: "Alistair Cockburn primary site"
-    authors: ["Alistair Cockburn"]
-    year: 2000
-    url: "https://alistair.cockburn.us/"
-    methodology_covered:
-      - "Primary site for Hexagonal Architecture article and use case writing resources"
-verification_status: source_gap_flagged
-description: "\"Build the walking skeleton first — the thinnest possible end-to-end slice that exercises every architectural layer, every deploy step, every test layer, before adding any feature."
----
-
-# Alistair Cockburn
-
-## Signature
-
-*"Build the walking skeleton first — the thinnest possible end-to-end slice that exercises every architectural layer, every deploy step, every test layer, before adding any feature. Prove the architecture works; then add flesh."* [ref:2]
-
-Agile Manifesto signatory; originator of the Crystal methodology family; author of **Writing Effective Use Cases** (2000) [ref:1] and the **Hexagonal Architecture** (Ports & Adapters) pattern [ref:3]. The bassclef voice on behavior-driven requirements writing and on architecture that separates business logic from all infrastructure.
-
-<!-- SOURCE GAP: alistair.cockburn.us/hexagonal-architecture/ listed as [ref:3] could not be verified via HTTP fetch during audit (returned empty). URL is widely cited in the industry as the original source. If the page has moved, the SENTINEL_bassclef_URL is https://web.archive.org/web/2005*/https://alistair.cockburn.us/hexagonal-architecture/ as an archival fallback. -->
-
-## Core methods
-
-- **Walking skeleton** — Build one thin, real, end-to-end path through the entire system before adding any feature depth: UI → API → service → DB → tests → CI → deploy. The path must be trivial but real — not a mock or a stub at any layer. The skeleton proves the architecture holds. Then add flesh (features, complexity, error paths) on a proven foundation. [ref:2]
-- **Hexagonal Architecture (Ports & Adapters)** — Business logic lives in the center. Ports are interfaces the business logic defines: "I need a way to store a deal," "I need a way to send a notification." Adapters on the outside implement those interfaces with real infrastructure (Prisma, email providers, HTTP). The business logic never imports infrastructure. Tests inject test adapters; production injects real ones. [ref:3]
-- **Use case writing** — A use case has: title (goal), primary actor, preconditions, main success scenario (numbered steps), and extensions (alternate flows and failure cases). Cockburn's goal levels matter: cloud level (abstract goals), kite level (near goals), sea level (user goals — the target), fish level (sub-goals), and clam level (too detailed). Write use cases at sea level. [ref:1]
-- **Crystal methodology scaling** — Process weight should match team size and criticality. Crystal Clear (2-8 people, low stakes) is minimal. Crystal Orange (25-50 people, moderate stakes) is heavier. Crystal Red (10-20 people, high criticality) is heaviest. Rejects one-size-fits-all methodology: the right process is the lightest one that works for this team and these stakes. [ref:2]
-
-## When to channel this luminary
-
-When the primary risk is that business logic will be entangled with infrastructure, or that the first deployable slice has never been verified end-to-end. Cockburn dominates new system setup (walking skeleton is the first commit), service layer design (hexagonal separates business from infrastructure), and requirements writing for complex workflows (use cases at sea level). Pair with Evans (domain modeling for the center of the hexagon), Brown (C4 for documenting the resulting architecture), and Beck (TDD for the tests that plug into the hexagonal ports).
-
-INSTEAD of using Cockburn's use case formalism for simple CRUD features: a lightweight user story ("as a broker, I can submit a deal listing") is sufficient when the behavior has no branching extensions and no preconditions that matter. Use cases earn their weight when the behavior has multiple actors, multiple failure modes, or serves as an acceptance test specification.
-
-## Stack translation
-
-In Next.js + Prisma + TypeScript:
-
-- **Walking skeleton** — first PR on a new project: one route (`/api/deals`), one Prisma model (`Deal`), one React component (a deal card), one vitest test, one Playwright smoke test, wired CI/CD. No features yet. The skeleton proves the stack works end-to-end before any feature is built.
-- **Hexagonal Architecture** — business logic lives in `src/lib/domain/`; Prisma is an adapter in `src/lib/infrastructure/database/`; the domain defines interfaces (`DealRepository`) that infrastructure implements. Server actions call domain functions; domain functions call repository interfaces; tests inject fake repositories.
-- **Use cases → acceptance tests** — a Cockburn use case's main success scenario is a Playwright test script. Each step in the use case is an interaction. Each extension is a branch in the test. Use case writing and test writing become the same activity.
-- **Goal levels in backlog** — sea-level use cases become iteration bets; sub-goals (fish/clam level) become tasks within a bet. Keeps the betting table at the right altitude.
-
-## Anti-patterns it prevents
-
-- **Logic in the adapter** — business rules (deal qualification criteria, stage transition policies) coded inside the Prisma query or the Next.js route handler. These rules are invisible to unit tests, tangled with infrastructure, and duplicated when a new adapter (a worker, a CLI) needs the same rule.
-  INSTEAD: move the rule to the domain layer; the adapter calls the domain function, not the other way around.
-- **Test-the-infrastructure tests** — tests that spin up a real database and test that Prisma can write to it. These are infrastructure tests, not domain tests. Slow, brittle, and they test the wrong thing.
-  INSTEAD: test the domain with test adapters; test the infrastructure adapter in integration tests that stay in the integration tier.
-- **Flabby use cases** — use case main success scenarios that describe system internals ("the system updates the deal record in the database") rather than observable behavior ("the deal status changes to LOI and the broker is notified"). Cockburn's use cases are observable, not implementation-visible. [ref:1]
-- **No skeleton, all flesh** — starting a project by building feature depth before verifying the architectural path end-to-end. The first deployment fails in production because the path was never real until then.
-
-## Worked example
-
-For POA's deal stage transition feature:
-
-**Walking skeleton**: before building any stage-transition UI, build one thin path: a Next.js server action that changes a deal's status, a Prisma write that persists it, a React component that shows the new status, and a Playwright test that confirms the status change is visible after the action. This skeleton runs in CI. Then add the full transition policy, the validation rules, and the notification flow.
-
-**Hexagonal architecture**:
-- Port: `StageTransitionPolicy` interface — `canTransition(deal: Deal, targetStage: Stage): PolicyResult`
-- Adapter: `NdaRequiredPolicy` implements `StageTransitionPolicy` using domain logic (no Prisma, no HTTP)
-- Server action: calls `StageTransitionService.advance(dealId, targetStage)` — domain function that uses the policy interface
-- Test: injects `AlwaysAllowPolicy` or `AlwaysDenyPolicy` as test adapters; no DB required
-
-**Use case (sea level)**:
-- Title: Advance Deal to LOI
-- Actor: Operator
-- Preconditions: deal is in "Initial Contact" stage; operator is authenticated
-- Main success: operator selects LOI from stage menu → system validates NDA signed → system changes status → broker is notified → operator sees updated stage
-- Extension 2a: NDA not signed → system shows "NDA required" message → deal stage unchanged
-
-## Sources
-
-- *Writing Effective Use Cases* — Cockburn, Addison-Wesley (2000) [ref:1]
-- "Hexagonal Architecture" — Cockburn, alistair.cockburn.us (2005) — the original article [ref:3]
-- *Agile Software Development: The Cooperative Game* — Cockburn, Addison-Wesley (2006) [ref:2]
-- alistair.cockburn.us — primary site [ref:4]
-
-## Corrections applied
-
-Cloud Strategy publisher: no correction needed for Cockburn entry. Note: hexagonal architecture URL [ref:3] could not be HTTP-verified during audit but is the widely-cited bassclef source; flagged as source gap.
-
-## Related luminaries
-
-- **Eric Evans** — DDD provides the domain model that lives inside Cockburn's hexagon. Evans models the business concepts; Cockburn's ports protect them from infrastructure.
-- **Kent Beck** — Walking skeleton aligns with Beck's "make it work" step at architectural scale; TDD tests slot into hexagonal ports as test adapters.
-- **Jeff Patton** — User story mapping references Cockburn as a foundation; use cases and story maps are complementary at different resolution levels.
-- **Simon Brown** — C4 model documents the container-level architecture that hexagonal architecture structures. The hexagon's center and adapters map to C4 components.

package/substrate/.claude/luminaries/amazon-pr-faq.md

@@ -1,34 +0,0 @@
----
-tier: lite
-name: Amazon PR/FAQ
-slug: amazon-pr-faq
-claimed_by: [shaper, product-manager]
-primary_domain: shaping
-depth: stub
-description: "\"Write the press release first. If it doesn't excite, don't build.\""
----
-
-# Amazon PR/FAQ
-
-## Signature
-
-*"Write the press release first. If it doesn't excite, don't build."*
-
-Amazon's internal methodology for product definition. Write a mock
-press release + customer FAQ BEFORE building. If the announcement
-doesn't compel, the product isn't worth building.
-
-## Core methods
-
-- **Mock press release** — 1-page release for a hypothetical future launch.
-  Customer benefits stated clearly, no jargon.
-- **FAQ** — anticipated customer questions + internal stakeholder
-  questions + teardown-worthy concerns. Forces early clarity.
-- **Working backward** — define customer experience first, then
-  derive requirements, then design.
-
-## Sources
-
-- Jeff Bezos 2015 shareholder letter (references the practice)
-- *Working Backwards* — Bryar, Carr (2021) — primary text on PR/FAQ practice
-- *The Amazon Way* — Rossman (2014)

package/substrate/.claude/luminaries/ash-maurya.md

@@ -1,121 +0,0 @@
----
-tier: lite
-name: Ash Maurya
-slug: ash-maurya
-claimed_by: [product-manager, shaper]
-referenced_by_skills: [lean-canvas, canvas, value-prop, value-prop-canvas]
-primary_domain: product
-depth: full
-sources:
-  - type: book
-    title: "Running Lean: Iterate from Plan A to a Plan That Works (3rd edition)"
-    authors: ["Ash Maurya"]
-    year: 2022
-    url: "https://www.oreilly.com/library/view/running-lean-3rd/9781098108762/"
-    isbn: "9781098108779"
-    methodology_covered:
-      - "Lean Canvas — nine-box business model adapted from Business Model Canvas for early-stage startups"
-      - "Problem-Solution Fit + Product-Market Fit progression"
-      - "Continuous innovation framework — experiment + measure + learn cycles"
-      - "Customer Factory + customer-development discipline"
-  - type: book
-    title: "Scaling Lean: Mastering the Key Metrics for Startup Growth"
-    authors: ["Ash Maurya"]
-    year: 2016
-    url: "https://www.penguinrandomhouse.com/books/541557/scaling-lean-by-ash-maurya/"
-    isbn: "9781591847267"
-    methodology_covered:
-      - "Customer Factory metrics framework — Acquisition + Activation + Retention + Revenue + Referral"
-      - "Modeling business as a system of metrics; identifying the bottleneck stage"
-      - "Scaling discipline distinct from initial-product-market-fit discipline"
-  - type: blog_post
-    title: "Leanstack — Ash Maurya methodology site"
-    authors: ["Ash Maurya"]
-    year: 2025
-    url: "https://www.leanfoundry.com/"
-    methodology_covered:
-      - "Primary venue for Lean Canvas + Running Lean methodology updates"
-      - "Continuous Innovation Framework deeper articulation"
-verification_status: verified
-description: "\"Document your Plan A, then identify the riskiest parts of your plan, and systematically test your plan.\""
----
-
-# Ash Maurya
-
-## Signature
-
-*"Document your Plan A, then identify the riskiest parts of your plan, and systematically test your plan."*
-
-The lean-shaping luminary for early-stage business model validation. Author of *Running Lean* and *Scaling Lean*. Creator of the **Lean Canvas** — a 9-box adaptation of Osterwalder's Business Model Canvas, optimized for entrepreneurs working under high uncertainty.
-
-Lean Canvas asks "does the business model hold together at all" before the product team asks "what should we build." Dunford's positioning answers a different question (who is this for and why is it different); Pichler's product canvas answers another (what is the product shape). The three compose; they do not substitute for each other.
-
-## Sources
-
-- *Running Lean* — 1st edition 2010, 2nd edition 2012, 3rd edition 2022. The bassclef Lean Canvas reference.
-- *Scaling Lean* (2016) — Maurya's later work on growth metrics + Customer Factory model
-- [leanstack.com](https://leanstack.com) — Maurya's company; templates + courses
-- [practicetrumpstheory.com](https://blog.leanstack.com) — Maurya's blog; "What is the Right Fill Order for the Lean Canvas?" is the load-bearing piece for `/lean-canvas`
-- `.claude/skills/lean-canvas/SKILL.md` — operationalizes Maurya's framework into agent dispatch
-- `.claude/skills/canvas/SKILL.md` — sibling product canvas (Pichler); composes downstream after Lean Canvas validates the business model
-- `.claude/luminaries/lean-product-canvas.md` — Dan Olsen's Product-Market Fit Pyramid; complementary, not duplicate
-
-## Core methods
-
-- **Lean Canvas — 9 boxes on one page.** Problem → Customer Segments → Unique Value Proposition → Solution → Channels → Revenue Streams → Cost Structure → Key Metrics → Unfair Advantage. Forces concise articulation; 20-minute first pass.
-- **Plan A vs Plan B.** Lean Canvas captures Plan A — the current best guess. Riskiest assumptions get tested; Plan A becomes Plan B when reality refuses to match. Iteration is the design, not failure.
-- **Riskiest-assumption-first validation.** Each box contains beliefs. Beliefs classify as leap-of-faith / anecdotal observation / fact-with-evidence. The riskiest leap-of-faith is the next thing to validate — not the next thing to build.
-- **Desirability → Viability → Feasibility.** When validating an idea (not generating one), test Problem + Customer Segments + UVP first (desirability), Channels + Revenue + Key Metrics second (viability), Solution + Cost + Unfair Advantage third (feasibility). Starting with Solution creates Innovator's Bias — you write Problem statements that justify the Solution you already wanted.
-- **Customer Factory model** (from *Scaling Lean*). Treat the business as a factory that converts strangers into customers. Acquisition → Activation → Retention → Revenue → Referral (AARRR, attributed to Dave McClure, adopted by Maurya). Key Metrics box maps to factory stages.
-- **20-minute snapshot rule.** First pass takes 20 minutes. Boxes can be blank. Iterate every week or after every meaningful customer conversation. The canvas is a thinking tool, not a deliverable.
-
-## INSTEAD-block discipline
-
-Every "Don't" in lean validation gets a concrete substitute. Per `.claude/rules/context-engineering.md`.
-
-| Anti-pattern | INSTEAD |
-|---|---|
-| Spending months writing a business plan | Spend 20 minutes filling a Lean Canvas; refine weekly |
-| "We have no competitors" in Unfair Advantage | Name the closest existing alternative (in-house build, manual workaround, adjacent tool); your unfair advantage is what makes you sticky once they switch |
-| Solving the wrong problem because Solution came first | Start with Problem + Customer Segments; if you must start with Solution, flag the Innovator's Bias risk and revisit Problem critically after first pass |
-| Vanity metrics (registered users, page views) in Key Metrics | Customer Factory stage rates (activation rate, retention curve, referral coefficient). Each metric maps to a factory transition. |
-| Generic UVP ("the best X for Y") | One specific sentence a target customer would forward to a peer. If the target customer wouldn't share it, the UVP isn't done. |
-| Building before validating riskiest assumption | Identify the riskiest leap-of-faith; design the smallest experiment that resolves it; run it before building. |
-| Treating the canvas as a deliverable | Treat it as a thinking surface. Update it after every customer conversation. Old canvases are historical record, not failure. |
-
-## When to channel
-
-- `/lean-canvas` invocations (any mode) — Maurya's 9-box framework IS the skill's structural backbone
-- `/canvas` Stage 1 (Thesis) — if the business model is unclear, run Lean Canvas first; Pichler's product canvas inherits validated assumptions
-- `/value-prop` invocations — UVP box of Lean Canvas is the input to Dunford's positioning framework
-- `/value-prop-canvas` — Strategyzer Value Proposition Canvas is the Lean Canvas Problem + UVP + Customer Segments boxes expanded; compose Lean Canvas first for business model fit, VPC second for product-market fit
-- Iteration shaping — when a bet's scope feels uncertain, the riskiest-assumption-first lens cuts to the actual validation work
-
-## Composition pairs
-
-- **Maurya + Dunford** — Lean Canvas validates the business model; Dunford's positioning sharpens the UVP box into a market-ready claim. Maurya answers "does it hold together"; Dunford answers "how do we say it."
-- **Maurya + Pichler (lean-product-canvas)** — Maurya validates the business model first; Olsen's Product-Market Fit Pyramid then guides product detail (target customer → needs → value prop → feature set → UX). Different focal lengths.
-- **Maurya + Osterwalder (Strategyzer)** — Strategyzer's Business Model Canvas is upstream of Lean Canvas; Maurya adapted it for early-stage uncertainty. For mature businesses, Strategyzer; for new bets, Maurya.
-
-## Distinct from
-
-- **Dunford** — positioning, not business model. Once the business model holds together, Dunford makes the message sharp.
-- **Olsen (lean-product-canvas)** — Product-Market Fit Pyramid, not business model. Once the business model holds, Olsen guides product shape.
-- **Pichler (canvas)** — product canvas (Vision → Target → Stand-Out → Big Picture → Critical Questions). Product-detail-level; assumes the business model already holds.
-- **Cockburn** — use cases at the system level; not strategy-level. Different altitude.
-
-## Why this luminary exists in the catalog
-
-Three product-strategy luminaries were already in bassclef's catalog:
-
-- April Dunford — positioning (the message)
-- Dan Olsen (lean-product-canvas) — Product-Market Fit Pyramid (the product detail)
-- Roman Pichler (canvas) — product canvas (the product vision)
-
-None of them answers the upstream question: **does the business model hold together at all?** Maurya's Lean Canvas is the missing piece. For bassclef's growth-loop strategy specifically, the "Revenue Streams" + "Key Metrics" boxes need to be reframed for audience/credibility accrual rather than dollar revenue — Maurya's framework accepts this reframing because the underlying question (which assumptions are riskiest) is general.
-
-INSTEAD of "build the product, hope the business model emerges," Maurya's discipline forces explicit business-model articulation upfront — and explicit identification of the riskiest assumption that needs testing before more building.
-
-## Closes
-
-Backs the new `/lean-canvas` skill (filed 2026-05-25). Corrects the prior gap where the catalog had Olsen for Product-Market Fit Pyramid but no luminary for Lean Canvas itself.