@thebassclef/lite 1.0.3 → 1.1.0

package/dist/lite/.claude/luminaries/alistair-cockburn.md

@@ -0,0 +1,140 @@
+---
+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/dist/lite/.claude/luminaries/amazon-pr-faq.md

@@ -0,0 +1,34 @@
+---
+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/dist/lite/.claude/luminaries/andreas-zeller.md

@@ -0,0 +1,74 @@
+---
+tier: lite
+name: Andreas Zeller
+slug: andreas-zeller
+claimed_by: [builder, reviewer]
+referenced_by_skills: [diagnose]
+primary_domain: engineering
+depth: stub
+sources:
+  - type: book
+    title: "Why Programs Fail: A Guide to Systematic Debugging"
+    authors: ["Andreas Zeller"]
+    year: 2009
+    url: "https://www.whyprogramsfail.com/"
+    isbn: "9780123745156"
+    methodology_covered:
+      - "Systematic debugging — every hypothesis has a test"
+      - "Delta Debugging — shrink a failing input to the minimum change"
+      - "Causal chain reasoning — walk from symptom to root cause via states"
+      - "Scientific method applied to bugs — observe, hypothesize, predict, test"
+  - type: online
+    title: "The Debugging Book"
+    authors: ["Andreas Zeller"]
+    year: 2024
+    url: "https://www.debuggingbook.org/"
+    methodology_covered:
+      - "Delta Debugging algorithms in Python — runnable code"
+      - "Statistical debugging — probability that a line contributes to failure"
+      - "Automatic fault localization — tools that point at suspect code"
+      - "Dynamic slicing — trace which statements influenced the buggy value"
+verification_status: draft
+description: "\"Every hypothesis has a test. Delta Debugging shrinks the failing input to its minimum. Debugging as science.\""
+---
+
+# Andreas Zeller
+
+## Signature
+
+*"Every hypothesis has a test. Every test either confirms or falsifies.
+Debugging is science."*
+
+Professor at CISPA Helmholtz Center. Author of **Why Programs Fail**
+(2005/2009) and **The Debugging Book** (online, 2024). Invented
+**Delta Debugging** — the algorithm that automatically shrinks a
+failing input to the minimum change that reproduces the fault. Zeller
+is the bassclef voice on systematic, provable debugging.
+
+## Core methods
+
+- **Scientific method for bugs** — observation → hypothesis →
+  prediction → experiment → refined hypothesis. Every step written down.
+- **Delta Debugging** — bisect the difference between passing and
+  failing inputs (or versions or configs). O(log n) shrinks to the
+  minimum failure-inducing change.
+- **Causal chain from symptom to root** — walk backwards through
+  program states. Each state either causes the next failure or does not.
+- **Anomalies over intuition** — pattern-match against the difference
+  between what's true when it fails and what's true when it passes.
+
+## When bassclef uses this lens
+
+- Any "worked at SHA X, fails at SHA Y" bug — Delta Debugging bisects
+  the commit range.
+- Any test that fails under condition A but passes under condition B —
+  Delta Debugging on the config diff.
+- `/diagnose` skill Five Whys — Zeller's causal-chain framing keeps
+  each "why" as a testable hypothesis.
+- Any complex multi-variable failure — force each hypothesis to name
+  its falsification predicate before running the experiment.
+
+## Depth
+
+Stub. Build-out tracked at bassclef-upstream#TBD. Sources — the 2009
+Morgan Kaufmann book plus the free online debugging book.

package/dist/lite/.claude/luminaries/ash-maurya.md

@@ -0,0 +1,121 @@
+---
+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.

package/dist/lite/.claude/luminaries/bill-buxton.md

@@ -0,0 +1,210 @@
+---
+tier: lite
+name: Bill Buxton
+slug: bill-buxton
+claimed_by: [designer]
+referenced_by_skills: [prototype-variants, interaction-design, prototype-gallery]
+primary_domain: ux
+depth: full
+agent_drafted: 2026-05-06
+operator_review_pending: true
+verification_status: verified
+sources:
+  - type: book
+    title: "Sketching User Experiences: Getting the Design Right and the Right Design"
+    authors: ["Bill Buxton"]
+    year: 2007
+    isbn: "978-0123740373"
+    url: "https://www.elsevier.com/books/sketching-user-experiences/buxton/978-0-12-374037-3"
+    methodology_covered: ["fidelity ladder", "sketching vs prototyping distinction", "three-panel storyboarding", "champion-challenger principle"]
+  - type: website
+    title: "billbuxton.com"
+    authors: ["Bill Buxton"]
+    url: "https://billbuxton.com"
+    methodology_covered: ["ongoing research and practice commentary"]
+solves_problems_brownfield:
+  - "Team jumps to high-fidelity prototypes without exploring alternatives"
+  - "First idea ships because nothing else was generated to compare it to"
+  - "Sketches and prototypes are conflated; divergent exploration is skipped"
+  - "Interactive prototypes lock in design decisions before exploration is done"
+solves_problems_greenfield:
+  - "Establishing a prototype-discipline practice from day one"
+  - "Designing a process where divergent exploration precedes convergent refinement"
+  - "Building a team where sketching is the gateway, not a perfunctory step"
+  - "Planning a workflow where fidelity ladder is enforced (sketches before wireframes before mockups before interactive)"
+anti_patterns:
+  - "Trivial design tasks where sketching overhead exceeds value"
+  - "Pure copy / microcopy work where sketching isn't the lens"
+  - "Teams that already have strong divergent-exploration habits"
+description: "\"Get the design right, and the right design.\""
+---
+
+# Bill Buxton
+
+## Signature
+
+*"Get the design right, and the right design."*
+
+Sketching pioneer. Author of *Sketching User Experiences: Getting the Design Right and the Right Design* (2007). The canonical voice on **fidelity discipline** — knowing when low-fi serves, when hi-fi misleads, and why most teams skip sketching to their detriment.
+
+Buxton's signature contribution is the **two-phase model of design**: divergent (get the right design — explore many alternatives) → convergent (get the design right — refine the chosen one). Most teams collapse the phases or skip divergent entirely; the result is one-solution thinking. Buxton's method forces the divergent phase visible.
+
+For canonical, Buxton is the variant-discipline luminary — the framework justifying `/riff-prototypes` and `/launch`'s emphasis on multiple variants per direction. Without Buxton's fidelity ladder, teams jump to interactive prototypes too fast, lock in answers that should have stayed exploratory.
+
+## Sources
+
+- *Sketching User Experiences: Getting the Design Right and the Right Design* — Buxton, Morgan Kaufmann (2007) — primary
+- [billbuxton.com](https://billbuxton.com) — primary site, ongoing essays
+- *Sketching User Experiences: The Workbook* — Greenberg / Carpendale / Marquardt / Buxton (2011) — applied exercises
+- Conference talks: CHI, IxDA (publicly archived; YouTube)
+- Adjacent: *Sketching Interfaces* — Bill Verplank (peer); *Designing Interactions* — Bill Moggridge (1990s peer)
+
+## Core methods
+
+- **Sketching vs prototyping** — [ref:1]
+  - **Sketches**: divergent, disposable, exploratory, fast, ambiguous-by-design
+  - **Prototypes**: convergent, refined, testable, slow, specific
+  - Teams that conflate them skip the divergent phase entirely and produce one-solution thinking
+  - The discipline is to recognize which mode you're in
+
+- **Fidelity ladder** — Stages of refinement: [ref:1]
+  1. **Sketches** (paper, whiteboard, low-fi digital) — many; cheap; exploratory
+  2. **Wireframes** (more structured; still flexible)
+  3. **Mockups** (visual fidelity; not interactive)
+  4. **Interactive prototypes** (clickable; close to final)
+  5. **Production** (real code, real data)
+  - Each rung answers different questions; climbing too fast locks in the wrong answer
+
+- **Three-panel comic storyboarding** — Forces interaction thinking, not just screen thinking: [ref:1]
+  1. Context (where + when + who)
+  2. Action (what the user does)
+  3. Reaction (what the system does + how user responds)
+  - Three-panel form is Buxton's signature; richer than wireframe, lighter than prototype
+
+- **Reprise / theme-and-variations** — Generate MANY variations of a sketch before committing. Quantity over quality early; quality emerges from the comparison. The N-th sketch is often the strongest because the first N-1 cleared the obvious answers.
+
+- **The right design vs designing right** — Different problems:
+  - "The right design" is divergent (which direction?); answered by exploration + variation
+  - "Design it right" is convergent (how do we execute?); answered by refinement + iteration
+  - Both are necessary; collapsing them produces "the well-executed first idea" which is rarely the strongest
+
+- **Cost-of-iteration ratio** — Sketches cost $1; wireframes $10; prototypes $100; production $1,000. Wrong answers caught at sketch stage are 1000x cheaper than caught in production. Sketch-first economics are decisive.
+
+## INSTEAD-block discipline
+
+| Anti-pattern | INSTEAD |
+|---|---|
+| Jumping to interactive prototype | Stage at the sketch rung first; generate 10-20 sketches; pick 2-3 to wireframe; 1 to prototype |
+| Sketches conflated with prototypes | Distinguish: sketches divergent + cheap + disposable; prototypes convergent + invested. Both have place; not interchangeable |
+| Skipping divergent phase | Force divergent: "give me 10 sketches before any of you starts on a prototype" — rule produces variation that quality-emerges-from |
+| One sketch → one wireframe → one prototype | Many sketches → fewer wireframes → fewer prototypes; ratio narrows by stage; divergent phase bears the variation |
+| Three-panel comic skipped for "just wireframes" | Three-panel forces interaction thinking; wireframes alone capture screen state but not user-system dialogue |
+| Sketches polished | Sketches stay rough — pencil + paper + iterate fast; polishing too early kills the exploratory mode |
+| Stakeholders shown low-fi sketches | Stakeholders shown high-fi only when ready; show low-fi internally, hi-fi externally; Buxton's *Sketching* book has 50 pages on this |
+| Hi-fi prototype before research | Hi-fi at prototype rung; sketches inform research; prototypes test research findings; sequence matters |
+| Climbing fidelity ladder too fast | Each rung answers questions the prior rung CAN'T; if you're answering a sketch-question with a prototype, you spent 100x what you needed to |
+| Single-variation prototype | Even at prototype rung, generate 2-3 variations; comparison reveals strengths the single-variant misses |
+| Treating prototyping as commitment | Prototypes are still iterable; not yet committed to production; Buxton's discipline keeps them flexible |
+| Buxton method without storyboards | Storyboards (three-panel comic) are part of Buxton's method; skipping reduces the method to wireframing |
+
+## When to channel this luminary
+
+- Always — when designing or planning a non-trivial design effort where exploration matters
+- Especially — when teams default to high-fidelity prototypes without divergent exploration
+- Pair with `dan-saffer` (microinteractions) — Saffer's microinteractions live at Buxton's prototype rung
+- Pair with `jenifer-tidwell` (UI patterns) — Tidwell provides vocabulary for post-sketch refinement; Buxton provides pre-pattern exploration
+- Pair with `golden-krishna` (no-interface) — Both push against screen-first thinking; Buxton via sketching, Krishna via no-screen-default
+
+Do NOT use this luminary alone for trivial design tasks (overhead exceeds value), pure copy / microcopy work (wrong lens), or teams with strong divergent-exploration habits already (overhead).
+
+## Stack translation
+
+Method, not implementation; translates to canonical artifacts:
+
+- **Sketches** → Pencil + paper or low-fi digital (Excalidraw / FigJam); committed to `docs/sketches/<feature-slug>/N.png`; many; not polished
+- **Three-panel comic storyboards** → Per major user flow; committed to `docs/storyboards/<feature-slug>.md`; markdown with embedded sketches
+- **Wireframe artifact** → `docs/wireframes/<feature-slug>.md` per chosen sketch direction; structural-only
+- **Mockup artifact** → `docs/mockups/<feature-slug>/` per chosen wireframe; visual fidelity
+- **Interactive prototype** → `public/prototypes/<feature-slug>/variant-<X>/` per chosen mockup; HTML/React; close-to-final
+- **Production** → `src/` integration; reviewed against prototype per `prototype-production-coupling.md`
+- **Variation discipline at each rung** → 10-20 sketches → 2-5 wireframes → 2-3 mockups → 2-3 prototypes; narrowing ratio per rung
+- **`/riff-prototypes` skill** → Direct operational descendant of Buxton's "reprise / theme-and-variations" — generates multiple prototypes against a brief
+- **`/launch` skill** → Composes the full sketch → wireframe → mockup → prototype chain; fidelity ladder enforced
+
+## Anti-patterns it prevents
+
+- **One-solution thinking** — first idea = shipped idea; alternatives never explored; better answers missed
+- **Premature high-fidelity** — interactive prototype built before sketch exploration; investment locks in suboptimal direction
+- **Polished sketches** — exploratory mode dies; sketches become wireframes-with-attitude; divergent phase lost
+- **Storyboards skipped** — wireframes alone capture state but not interaction; user-system dialogue not designed
+- **Stakeholder confusion** — stakeholders shown low-fi internally to ill effect; or shown only hi-fi and feel "deciding too late"
+- **Sketches treated as commitment** — exploratory output treated as proposal; team commits to half-thought directions
+- **Variation only at top of ladder** — variations explored in sketch; from wireframe onward single-track; loses post-sketch refinement opportunities
+
+## Worked example
+
+For canonical's hypothetical "operator-roadmap mobile view" feature:
+
+Buxton's prescription:
+
+**Phase 1 — Sketches** (15 minutes; 12 sketches):
+- 12 quick sketches of "what does the operator see when they open canonical on phone?"
+- Variations: list view / card view / Kanban / timeline / dashboard / spatial / conversational / 3D / minimal-status / detail-first / etc.
+- All on paper / Excalidraw; rough, fast, disposable
+
+**Phase 2 — Three-panel storyboards** (30 minutes; 4 storyboards):
+- Pick 3-4 promising sketch directions
+- Three-panel storyboard per: Context (operator at coffee shop, phone in hand) → Action (opens canonical) → Reaction (sees state, decides what to do)
+- Reveals which directions support the actual use case
+
+**Phase 3 — Wireframes** (1 hour; 2 wireframes):
+- Pick 2 storyboard directions
+- Structural wireframes (Excalidraw or Figma low-fi)
+
+**Phase 4 — Mockups** (2-4 hours; 2 mockups):
+- Both wireframes get visual mockups; same brand tokens; varying composition
+
+**Phase 5 — Interactive prototypes** (1 day; 2 prototypes):
+- Both mockups become clickable prototypes (`/riff-prototypes` outputs)
+- Both deployed; champion-challenger comparison
+
+**Phase 6 — Production** (after operator picks):
+- Single chosen direction goes to production via `/launch` chain
+
+**Cost-of-iteration economy**:
+- Wrong direction caught at sketch (Phase 1): 15 min
+- Wrong direction caught at storyboard (Phase 2): 30-45 min
+- Wrong direction caught at wireframe (Phase 3): 1-2 hours
+- Wrong direction caught at prototype (Phase 5): 1-2 days
+- Wrong direction caught in production: 1-2 weeks
+- Buxton's discipline saves the latter cost by catching at the former rungs
+
+What this luminary catches that "design the mobile view" misses: the divergent-then-convergent sequence; the variation discipline at each rung; the storyboard step (interaction thinking); the cost-of-iteration economy; the multi-variant prototype rung.
+
+## How to use in canonical's chain
+
+In `/riff-prototypes`:
+- Direct application of Buxton's reprise / theme-and-variations
+- Multi-variant output enforces divergent phase
+- Operator picks among variants → convergent
+
+In `/launch`:
+- Composes sketch → wireframe → mockup → prototype chain
+- Phase ordering enforces fidelity ladder
+
+In `/canvas`:
+- Canvas Build Sequence section can include sketches at lowest fidelity
+- Storyboards capture interaction thinking before spec
+
+In `/spec`:
+- Spec references which prototype direction won; cites the divergent options + decision rationale
+
+## Related luminaries
+
+- **Jenifer Tidwell** — UI patterns provide post-sketch vocabulary; Buxton provides pre-pattern exploration
+- **Dan Saffer** — Microinteractions at high-fidelity rung; Buxton's ladder leads to Saffer's territory
+- **Golden Krishna** — No-interface thinking; both push against screen-first; Buxton via fidelity ladder, Krishna via no-screen-default
+- **Don Norman** — Foundational interaction design; Buxton's storyboards apply Norman's principles
+- **Bill Moggridge** — Peer; *Designing Interactions* covers similar ground
+- **canonical's `/riff-prototypes` skill** — Direct operational descendant
+- **canonical's `/launch` skill** — Direct operational descendant (full ladder)