@thebassclef/lite 0.1.3 → 1.0.1

package/substrate/.claude/luminaries/jesse-james-garrett.md

@@ -1,154 +0,0 @@
----
-tier: lite
-name: Jesse James Garrett
-slug: jesse-james-garrett
-claimed_by: [designer]
-referenced_by_skills: [ia-model, canvas, spec]
-primary_domain: ux
-depth: full
-sources:
-  - type: book
-    title: "The Elements of User Experience: User-Centered Design for the Web and Beyond (2nd edition)"
-    authors: ["Jesse James Garrett"]
-    year: 2010
-    url: "https://www.pearson.com/en-us/subject-catalog/p/elements-of-user-experience-the-user-centered-design-for-the-web-and-beyond/P200000009272"
-    isbn: "9780321683687"
-    methodology_covered:
-      - "Five planes of UX — Strategy, Scope, Structure, Skeleton, Surface"
-      - "Decisions sequence from abstract (strategy) to concrete (surface)"
-      - "Each plane constrains the next; clarity at one plane prevents thrashing at others"
-      - "Information architecture as a structural-plane concern, distinct from skeleton (wireframe) or surface (visual)"
-verification_status: verified
-solves_problems_brownfield:
-  - "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_problems_greenfield:
-  - "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:
-  - "Tactical UI fixes where the five planes is overhead"
-  - "Single-page or single-screen work"
-description: "\"Every user experience has five planes: strategy, scope, structure, skeleton, surface."
----
-
-# Jesse James Garrett
-
-## Signature
-
-*"Every user experience has five planes: strategy, scope, structure, skeleton, surface. Skip one and the next collapses."*
-
-Co-founder of Adaptive Path; author of **The Elements of User Experience**.
-Coiner of **Ajax** (2005). The bassclef framework for thinking about UX
-as a layered set of decisions that must be made in sequence — each plane
-constrains the next.
-
-## Core methods
-
-- **The Five Planes of UX** — From bottom (abstract) to top (concrete):
-  - **Strategy** — user needs + product objectives. What success means.
-  - **Scope** — functional specifications + content requirements. What
-    the product contains.
-  - **Structure** — interaction design + information architecture. How
-    it's organized.
-  - **Skeleton** — interface design, navigation design, information
-    design. Where things are placed.
-  - **Surface** — sensory design (visual, auditory). How it looks and
-    feels.
-- **Bottom-up sequence** — Each plane must be resolved before the plane
-  above it. Surface decisions made before strategy produce pretty
-  products that serve no one.
-- **Plane consistency** — Decisions on one plane must cohere across that
-  plane. An app with two incompatible IAs (one by section, one by
-  feature) has a structure-plane failure.
-- **Abstract-to-concrete progression** — Planes move from invisible
-  decisions (strategy) to visible output (surface). A team skipping
-  straight to surface design has no grounding for why.
-
-## When to channel this luminary
-
-When the biggest risk is getting the layers out of sequence — jumping to
-visual design before structure is resolved, or committing to scope
-before strategy is clear. Garrett dominates in project planning and
-SDLC-flow work: ensuring the right decisions happen in the right order.
-Think: new-product definition, UX audits of existing products, pedagogy
-for designers or teams new to systematic UX.
-
-Do NOT channel Garrett for: tactical interaction design decisions (use
-Norman, Tidwell), object-modeling (use Prater), visual polish (use
-Lupton, Ive).
-
-## Stack translation
-
-Garrett's planes map directly onto the bassclef SDLC:
-
-- **Strategy plane** → `/canvas` (Thesis stage) + iteration bet framing
-- **Scope plane** → `/canvas` (Shape stage) + `/spec` + feature list
-- **Structure plane** → `/ia-model` + `/jtbd-tasks` + `/task-scenarios`
-- **Skeleton plane** → `/interaction-design` + `/decompose` (responsibility)
-- **Surface plane** → `/frontend-design` + `/visual-review` + design tokens
-
-The bassclef UX translation chain (JTBD → HTA → IA → Interaction Design)
-is Garrett's structure plane made operational. `/riff-prototypes`
-skips to skeleton/surface only when the lower planes are resolved.
-
-## Anti-patterns it prevents
-
-- **Surface-first design** — starting with visual mockups before
-  structure or scope is settled. Produces beautiful products that fail
-  strategy tests.
-- **Premature plane commitment** — locking visual design before
-  interaction design is complete. Forces structure decisions to fit
-  pre-made mockups.
-- **Plane-skipping** — jumping from strategy to surface, or scope to
-  skeleton. Missing planes leave load-bearing decisions implicit.
-- **Plane inconsistency** — a strategy plane that says "operator tool"
-  paired with a surface plane that says "consumer SaaS." Reveals
-  uncoordinated decisions.
-- **Deliverable confusion** — treating wireframes (skeleton) as final
-  design, or treating mockups (surface) as structure. Each plane has
-  its own deliverables and can't substitute.
-
-## Worked example
-
-For POA's deal pipeline feature planning, Garrett's five planes produce:
-
-1. **Strategy**: Operator needs efficient pipeline management; product
-   objective is reducing time-to-close. Success = X% faster deal
-   throughput.
-2. **Scope**: Functional = deal CRUD, stage transitions, broker
-   association, note logging, search, export. Content = deal types,
-   stage definitions, standard fields, extension fields.
-3. **Structure**: Interaction = stage-transition flow, note-logging
-   flow, broker-assignment flow. IA = object-first nav (Deals, Brokers,
-   Sellers) with facets (stage, source, age).
-4. **Skeleton**: List-detail pattern for deals; right-rail for
-   secondary info; sticky stage-progress at top of detail view;
-   collapsed sections for enrichment data.
-5. **Surface**: Design tokens (colors, typography, spacing); dense
-   table view; status chips per stage; hover states and transitions.
-
-Each plane's output is input to the next. Skipping directly from
-Strategy to Surface (shopping for a pretty template) would produce a
-product that looks great and serves no specific operator workflow.
-
-## Sources
-
-- *The Elements of User Experience: User-Centered Design for the Web
-  and Beyond* — Garrett, New Riders (1st ed 2002, 2nd ed 2010)
-- *"Ajax: A New Approach to Web Applications"* — Garrett, Adaptive
-  Path essay (2005) that coined the term
-- jjg.net — Garrett's primary site (maintains classic Elements diagram)
-
-## Related luminaries
-
-- **Sophia Prater** — OOUX lives at Garrett's structure plane. Not a
-  replacement; a specific method for that plane.
-- **Alan Cooper** — Goal-Directed Design operates across planes but
-  grounds in strategy (user goals) and scope (task lists).
-- **Peter Morville** — IA work is structure-plane; Morville + Garrett
-  pair naturally.
-- **Ellen Lupton** — Typography is surface-plane; don't invoke until
-  skeleton is resolved.

package/substrate/.claude/luminaries/john-ousterhout.md

@@ -1,94 +0,0 @@
----
-tier: lite
-name: John Ousterhout
-slug: john-ousterhout
-claimed_by: [architect, reviewer, builder]
-referenced_by_skills: [pattern-review, decompose]
-primary_domain: engineering
-depth: stub
-sources:
-  - type: book
-    title: "A Philosophy of Software Design"
-    authors: ["John Ousterhout"]
-    year: 2021
-    edition: "2nd"
-    url: "https://web.stanford.edu/~ouster/cgi-bin/aposd.php"
-    isbn: "9781732102217"
-    methodology_covered:
-      - "Deep modules — small interface hiding complex implementation"
-      - "Complexity is incremental — small drips add up; resist each one"
-      - "Define errors out of existence — design APIs so error conditions cannot occur"
-      - "Comments encode design decisions the code itself cannot"
-      - "Strategic vs tactical programming — invest in design over short-term wins"
-      - "Information hiding — modules expose only what callers need; the rest stays internal"
-  - type: course
-    title: "Stanford CS 190 — Software Design Studio"
-    authors: ["John Ousterhout"]
-    year: 2018
-    url: "https://web.stanford.edu/class/cs190/"
-    methodology_covered:
-      - "Source course where the principles in A Philosophy of Software Design were developed and tested"
-verification_status: verified
-description: "\"Complexity is anything that makes software hard to understand or modify."
----
-
-# John Ousterhout
-
-## Signature
-
-*"Complexity is anything that makes software hard to understand or modify. The goal of software design is to reduce complexity."*
-
-Stanford professor. Creator of the Tcl scripting language and Raft consensus protocol. Author of **A Philosophy of Software Design** (2018, 2nd ed 2021), the modern SENTINEL_bassclef_text on simplicity, deep modules, and complexity-as-incremental-drift. Pairs with Beck (TDD) and Fowler (refactoring tactics): Beck asks "is it tested?", Fowler asks "how do I restructure it?", Ousterhout asks "is it the right shape in the first place?"
-
-## Discipline anchor
-
-**Design judgment + complexity-as-enemy.** Ousterhout supplies the WHY-to-refactor framing that Beck and Fowler leave to the engineer's judgment.
-INSTEAD: Beck owns the red-green-refactor cycle; Fowler owns the catalog of refactorings; Ousterhout owns the design-quality lens that tells you whether the shape you're refactoring toward is actually better. Without this lens, refactors can shuffle complexity without reducing it.
-
-This luminary fires on architectural-judgment moments — picking module boundaries, naming interfaces, deciding whether to split a class, evaluating whether a comment is doing real work or restating the code.
-INSTEAD of citing Ousterhout for test mechanics, refactoring tactics, or pattern catalog selection: route those concerns to Beck, Fowler, and GoF respectively.
-
-## Key principles
-
-- **Deep modules** — A module is deep when it has a small interface and a large, complex implementation hidden behind it. Shallow modules push knowledge to callers and produce a system where understanding the whole requires understanding every part. When tempted to split a class for "smaller files," ask: does the split produce TWO deep modules, or TWO shallow ones?
-  INSTEAD of defaulting to file-size as the splitting metric: use interface-shape as the metric. Two deep modules from a split is a win; two shallow modules from a split is a regression even if the line count drops.
-
-- **Complexity is incremental** — Complexity accumulates one small decision at a time. A single special case, a single dependency, a single inconsistency feels harmless. Sum across a session, a release, a year — that's how systems become unmaintainable. The discipline is to resist each small drip rather than promise to clean up the puddle later.
-  INSTEAD of deferring cleanup to a future refactor: refuse the small drip at the moment it appears. Future-refactor cleanups almost never happen; the cost of resisting at write-time is the cheapest moment.
-
-- **Define errors out of existence** — Design APIs so error conditions cannot occur, rather than designing APIs that throw errors and asking every caller to handle them. The classic example: `unset` on a variable that does not exist is an error in older shells.
-  INSTEAD: the right shape is for `unset` to be idempotent. Applied to bassclef: hooks that BLOCK on missing artifacts are weaker than hooks that bootstrap the artifact when absent, where bootstrapping is safe.
-
-- **Comments encode design decisions code cannot** — Code says what it does. Comments must say what the code cannot — the WHY (invariant), the WHAT-IF (alternative considered and rejected), the WATCH-OUT (subtle constraint a future reader will miss).
-  INSTEAD of comments that restate code: write comments that record decisions. This principle is load-bearing for bassclef's `bassclef-configs.jsonc` discipline: inline comments are the adopter-discovery surface, not exhaust.
-
-## When to cite this luminary
-
-Cite `@luminary john-ousterhout` when:
-
-- **Reviewing module boundaries** (`/pattern-review`) — is this class deep or shallow? Would splitting it make two deep modules or two shallow ones?
-- **Decomposing responsibilities** (`/decompose` GRASP audit) — does each responsibility assignment produce a deep module, or push complexity to callers?
-- **Designing bassclef-configs.jsonc or other adopter-edit surfaces** — inline comments must encode WHY-to-pick and WHEN-to-pick, not restate the field name. This is "comments-as-design" applied to substrate configuration.
-- **Evaluating whether complexity is essential or accidental** — when a feature feels harder to ship than it should, ask whether the difficulty is in the problem domain (essential) or in how earlier decisions shaped the code (accidental). Accidental complexity is the refactor signal.
-
-When the question is test mechanics, refactoring step-by-step, design-pattern selection, distributed-systems scalability, or algorithmic complexity, route elsewhere.
-INSTEAD: cite Beck (test mechanics), Fowler (refactoring tactics), GoF (pattern selection), Kleppmann (Phase C, scalability anchor), Bentley (Phase C, Big-O practical discipline).
-
-## Composes with
-
-- **Kent Beck** — TDD makes deep modules testable. Tests verify that the interface is actually small; without tests, deep modules look the same as shallow ones from outside.
-- **Martin Fowler** — Refactoring tactics serve Ousterhout's design judgment. Fowler tells you HOW to extract a method; Ousterhout tells you WHETHER the extraction produces a deeper module or shuffles complexity.
-- **Gang of Four** — Design patterns are deep-module exemplars when applied well. The Decorator pattern is a deep module; the over-applied Visitor pattern is often shallow because it pushes traversal logic to callers.
-- **Michael Feathers** (bassclef luminary catalog) — Characterization testing makes it safe to refactor toward deeper modules in legacy code where the original boundaries are unclear.
-
-## Refs
-
-- bassclef#1036 — this luminary's filing ticket
-- bassclef#867 — anchor-luminary verification pattern (stub-tier shape this entry follows)
-- bassclef#1037 — sibling ticket; testing-tier-config primitive (Ousterhout's comments-as-design framing anchors the Tier 0 vs Tier 3 comment rules)
-- bassclef#478 — `@pattern` annotation discipline (analog for `@luminary` citation discipline)
-
-## Stub-to-full
-
-This is a stub entry per bassclef#867 verification pattern — frontmatter plus 4-section body grounded in primary source. Full body (worked examples in bassclef's own substrate, anti-patterns catalog, signature stack-translation paragraph) is deferred to a luminary-authoring follow-on bet.
-INSTEAD of blocking citation on full-body completion: the stub is sufficient for `/pattern-review` and `/decompose` to invoke the lens today; the full entry deepens worked examples in a later pass.

package/substrate/.claude/luminaries/karl-popper.md

@@ -1,132 +0,0 @@
----
-tier: lite
-name: Karl Popper
-slug: karl-popper
-claimed_by: [architect, reviewer, closer]
-referenced_by_skills: [diagnose, architect-review, promote, state-a-problem]
-primary_domain: philosophy
-depth: full
-sources:
-  - type: book
-    title: "The Logic of Scientific Discovery"
-    authors: ["Karl R. Popper"]
-    year: 1959
-    original_year: 1935
-    url: "https://www.routledge.com/The-Logic-of-Scientific-Discovery/Popper/p/book/9780415278447"
-    isbn: "9780415278447"
-    methodology_covered:
-      - "Falsifiability as demarcation criterion for scientific claims"
-      - "Bold conjectures + severe tests as the actual method"
-      - "Verification is impossible; falsification is decisive"
-  - type: book
-    title: "Conjectures and Refutations: The Growth of Scientific Knowledge"
-    authors: ["Karl R. Popper"]
-    year: 1963
-    url: "https://www.routledge.com/Conjectures-and-Refutations-The-Growth-of-Scientific-Knowledge/Popper/p/book/9780415285940"
-    isbn: "9780415285940"
-    methodology_covered:
-      - "Knowledge grows by refutation, not confirmation"
-      - "Better theories forbid more; the more a theory forbids the better"
-      - "All observation is theory-laden; there is no view from nowhere"
-  - type: book
-    title: "The Open Society and Its Enemies"
-    authors: ["Karl R. Popper"]
-    year: 1945
-    url: "https://press.princeton.edu/books/paperback/9780691158136/the-open-society-and-its-enemies"
-    isbn: "9780691158136"
-    methodology_covered:
-      - "Piecemeal social engineering over utopian planning"
-      - "Institutions that expose leaders to falsification"
-      - "Critical rationalism as social discipline"
-verification_status: verified
-description: "\"Good tests kill flawed theories; we remain alive to guess again.\""
----
-
-# Karl Popper
-
-## Signature
-
-*"Good tests kill flawed theories; we remain alive to guess again."*
-
-Austrian-British philosopher (1902-1994). Author of *The Logic of Scientific Discovery* (Hutchinson, 1935 German / 1959 English) and *Conjectures and Refutations* (1963). The bassclef voice on falsifiability, hypothesis testing, and the discipline that a claim which cannot be falsified is steering language, not truth.
-
-## Core methods
-
-- **Falsifiability as demarcation** — a claim is scientific to the extent that it can be shown wrong. Unfalsifiable claims may be inspiring; they are not knowledge. In substrate work: an assertion with no rebuttal cell is either a definition or an act of faith.
-- **Conjectures and refutations** — knowledge grows by making bold conjectures and then trying hard to break them. The bolder the claim, the more the world it forbids, the more informative it is when it survives testing.
-- **The severity of tests** — a test that could have refuted the claim but did not is severe. A test the claim was designed to pass is weak. Testing is not a formality; it is the entire epistemic engine.
-- **Piecemeal engineering** — for social + technical systems, small changes that can be reverted are better than sweeping redesigns that cannot. The value is not the change itself; it is the reversibility.
-- **All observation is theory-laden** — there is no raw data. Every observation runs through the framework the observer brings. This is why the warrant matters, not just the data.
-
-## When to channel this luminary
-
-When the primary risk is root-cause claims, cure recommendations, or diagnostic assertions shipping without stated conditions for being wrong. Popper dominates for `/diagnose` output (root-cause hypotheses), audit findings (severity claims), cure recommendations (why THIS cure, not another), and any assertion the operator will act on. Pair with Toulmin (Popper's rebuttal cell IS Toulmin's rebuttal cell) and Peirce (Peirce names the alternatives; Popper says test each).
-
-Pass-through cases (Popper adds no value):
-
-- Pure definition claims ("this is what we call X"). INSTEAD of falsification testing: preserve the definition; it is a naming act, not a knowledge claim.
-- Aesthetic preference statements. INSTEAD of falsification testing: preserve the preference; it is Peirce's pragmatic-maxim category, not Popper's.
-- Operator-authored directives. INSTEAD of falsification testing: honor the directive; operator preference is a starting point for inquiry, not a hypothesis to be falsified.
-
-## Stack translation
-
-In bassclef substrate work:
-
-- **`/diagnose` output** → hypothesis + falsification test. What repro would show the hypothesis is wrong? Write it before writing the fix.
-- **Audit finding severity** → what evidence would demote HIGH to MEDIUM? Name it. If nothing would demote it, the severity is either a definition or a decree.
-- **Cure recommendation** → what evidence would show this cure does not close the class? Name the test. If no test would falsify, the cure is faith not analysis.
-- **Turn estimate** → the estimate is a prediction. What actuals would falsify it? Grounding estimates in prior WU turn counts is Popper's discipline — the prior WUs are the tests the estimate survives.
-- **Root-cause claim** → the cause is the hypothesis. Removing it should remove the symptom. If removal does not remove the symptom, the cause was wrong. Test before shipping.
-
-## Anti-patterns it prevents
-
-- **Unfalsifiable severity** — "This is HIGH-severity because it matters." No evidence would demote it. Not a claim.
-
-  INSTEAD: state the criteria that would demote the finding. If none exist, the finding is a decree, not evidence.
-
-- **Root-cause attribution without repro** — "The cause is X" with no test that would show removing X does not remove the symptom.
-
-  INSTEAD: state the repro that would falsify. Run it. Ship the fix only after the test discriminates.
-
-- **Cure recommendation without a losing condition** — "This cure closes the class" with no criterion that would show it does not.
-
-  INSTEAD: state the observation that would show the class still reproduces after the cure. That IS the acceptance test.
-
-- **Confirmation-only diagnosis** — running only the test the hypothesis passes.
-
-  INSTEAD: run the severest test the hypothesis could survive. If it survives that, it is stronger than a test that was designed to pass.
-
-- **Sweeping redesign** — replacing a hook, a rule, or a substrate primitive with a cleaner version, all at once, no reversibility path.
-
-  INSTEAD: ship the smallest reversible change. Piecemeal engineering ships smaller changes with revert paths.
-
-## Worked example
-
-For a claim that a hook is dead-letter:
-
-Popper's discipline:
-
-- **Conjecture**: The hook `X.sh` is dead-letter — it exists on disk but is not wired in `.claude/settings.json`. Its checks do not fire.
-- **Severe test**: Deliberately trigger the condition the hook is supposed to catch. Author a file that violates the hook's stated rule; attempt to write it. If the write succeeds without the hook firing, the conjecture is confirmed. If the hook fires and blocks the write, the conjecture is falsified.
-- **Result**: Wrote the violating file. Write succeeded. No BLOCK message. The hook did not fire. Conjecture survives; hook is dead-letter.
-- **What would falsify**: A BLOCK message appearing in the write attempt. It did not appear.
-
-Without Popper's discipline the diagnosis would read "the hook seems broken" — no test, no falsification criterion, no way to distinguish "actually broken" from "I did not trigger it right." INSTEAD: state the conjecture, name the severe test, run it, report the result.
-
-## Sources
-
-- *The Logic of Scientific Discovery* — Popper, Hutchinson (1935 German original; 1959 English translation; Routledge reprint)
-- *Conjectures and Refutations: The Growth of Scientific Knowledge* — Popper, Routledge (1963)
-- *The Open Society and Its Enemies* — Popper, Routledge (1945; Princeton reissue 2020)
-- *Objective Knowledge: An Evolutionary Approach* — Popper, Oxford University Press (1972)
-- Stanford Encyclopedia of Philosophy: entry on Popper — plato.stanford.edu/entries/popper/
-
-## Related luminaries
-
-- **Stephen Toulmin** — Toulmin's argument model gives the shape (claim/data/warrant); Popper sharpens the rebuttal cell. A Toulmin argument without the rebuttal cell is a Popperian pseudo-claim. Both ship in bet 2026-07-01b WU-2.
-- **Charles Sanders Peirce** — Peirce's abductive reasoning names multiple hypotheses; Popper says test each one severely. Peirce fills the alternatives; Popper says which alternative survives. Both ship in bet 2026-07-01b WU-2.
-- **W. Edwards Deming** — Deming's PDCA cycle is Popper's conjecture-and-refutation applied to management. Plan (conjecture), Do (test), Check (see if the test broke the plan), Act (revise).
-- **Michael Feathers** — Feathers' characterization tests are severe tests for legacy code. Without characterization tests, refactoring is unfalsifiable — no test would show the refactor broke behavior.
-- **Kent Beck** — Beck's TDD is Popper at the code layer. The red test is the severe test the claim must survive to become green. TDD without a red step is unfalsifiable design.
-
-Anchors `.claude/rules/assert-only-after-verify.md` alongside Toulmin + Peirce. Primary luminary for `/diagnose` skill in root-cause hypothesis testing.

package/substrate/.claude/luminaries/kent-beck.md

@@ -1,168 +0,0 @@
----
-tier: lite
-name: Kent Beck
-slug: kent-beck
-claimed_by: [builder, reviewer]
-referenced_by_skills: [verify, pattern-review]
-primary_domain: engineering
-depth: full
-sources:
-  - type: book
-    title: "Test-Driven Development: By Example"
-    authors: ["Kent Beck"]
-    year: 2002
-    url: "https://www.pearson.com/en-us/subject-catalog/p/test-driven-development-by-example/P200000009450"
-    isbn: "9780321146533"
-    methodology_covered:
-      - "TDD red/green/refactor cycle"
-      - "Test-first as design discipline, not verification afterthought"
-      - "Tests as the first client of your code"
-  - type: book
-    title: "Extreme Programming Explained: Embrace Change"
-    authors: ["Kent Beck", "Cynthia Andres"]
-    year: 2004
-    url: "https://www.pearson.com/en-us/subject-catalog/p/extreme-programming-explained-embrace-change/P200000009290"
-    isbn: "9780321278654"
-    methodology_covered:
-      - "XP practices: TDD, pair programming, continuous integration, simple design"
-      - "Embrace change as a competitive advantage"
-      - "Four rules of simple design — passes tests, reveals intention, no duplication, fewest elements"
-  - type: book
-    title: "Tidy First? A Personal Exercise in Empirical Software Design"
-    authors: ["Kent Beck"]
-    year: 2023
-    url: "https://www.oreilly.com/library/view/tidy-first/9781098151232/"
-    isbn: "9781098151249"
-    methodology_covered:
-      - "Tidy First — structural changes commit separately from behavioral changes"
-      - "Don't bundle refactor and feature in one PR"
-      - "Empirical software design — measure what works, adjust accordingly"
-verification_status: verified
-description: "\"Make it work. Make it right. Make it fast. Tests are the first client of your code.\""
----
-
-# Kent Beck
-
-## Signature
-
-*"Make it work. Make it right. Make it fast. Tests are the first client of your code."*
-
-Extreme Programming (XP) creator. Co-author of **the JUnit framework**.
-Author of **Test-Driven Development: By Example** and **Extreme Programming
-Explained**. The bassclef voice on TDD, simple design, and iterative
-engineering practice.
-
-## Core methods
-
-- **TDD red/green/refactor** — write failing test, write minimum code
-  to pass, refactor with tests passing. Not "write tests after" — the
-  test comes first and drives the design.
-- **Four rules of simple design** — (1) passes all tests, (2) reveals
-  intention, (3) no duplication, (4) fewest elements. Apply in order
-  during refactoring.
-- **Three phases of development** — Make it work (get the feature
-  functional), make it right (clean it up with tests protecting),
-  make it fast (optimize, measured).
-- **Patterns for testability** — Fake It ('Til You Make It, Obvious
-  Implementation, Triangulation. Techniques for moving from red to
-  green without skipping steps.
-- **XP practices** — pair programming, continuous integration, small
-  releases, simple design, refactoring, collective ownership.
-  Practices reinforce each other; removing any degrades the rest.
-- **Tidy First** — distinguishing between structural changes (tidying,
-  no behavior change) and behavioral changes. Commit them separately.
-
-## When to channel this luminary
-
-When the primary risk is code quality degrading under change pressure.
-Beck dominates for teams new to TDD, Construction work where tests
-aren't yet a reflex, and refactoring-heavy iterations. Pair with Fowler
-(refactoring catalog) and Uncle Bob (SOLID principles) for the
-engineering-quality triad.
-
-Do NOT channel Beck for: research code that will be thrown away,
-spike work where discovery matters more than sustainability, or work
-on systems where the test infrastructure doesn't yet exist (wrong
-layer — infrastructure first).
-
-## Stack translation
-
-In Next.js + vitest + Playwright:
-
-- **TDD for pure functions** → write failing unit test in
-  `src/__tests__/`, write function to pass, refactor. Scoring logic,
-  parsing, validation all belong here.
-- **TDD for components** → failing React Testing Library assertion,
-  minimum component to pass, refactor for structure.
-- **TDD for API routes** → failing integration test against real DB +
-  Redis, minimum route implementation to pass.
-- **Tidy First** → structural refactor commits separate from feature
-  commits. "refactor: extract ScoringStrategy interface" + "feat: add
-  ML scorer" as two PRs, not one.
-- **Three phases** → first PR makes feature work, subsequent PRs
-  right/fast. Don't bundle all three.
-
-## Anti-patterns it prevents
-
-- **Test-after** — writing tests once the code "works" produces tests
-  that confirm what exists, not tests that drive design. Beck rejects
-  this as TDD.
-- **Batched refactoring** — saving all cleanup for a quarterly "tech
-  debt sprint." Refactoring is continuous, inside the red/green/refactor
-  loop.
-- **Premature optimization** — making it fast before making it work.
-  The order matters.
-- **Pristine-never-commits** — holding a branch to "get it perfect"
-  before merging. Beck's XP favors small, frequent merges.
-- **Test-less refactors** — rearranging code without tests is just
-  changing code. Can't claim refactor without behavior preservation,
-  and you can't prove preservation without tests.
-- **Tidy mixed with feature** — commit that both refactors and adds
-  behavior makes review and revert harder.
-
-## Worked example
-
-For adding POA deal-stage validation:
-
-Beck's approach:
-1. **Red**: write failing test
-   `test('deal cannot advance past LOI without signed NDA', ...)`
-2. **Green**: add minimum code to pass — if-check in the stage-advance
-   controller
-3. **Refactor**: extract `IStageTransitionPolicy` interface,
-   `NdaSignedPolicy` implementation, `StagePolicyRegistry`
-4. **Tidy commit** separate from feature: "refactor: extract stage
-   transition policy interface" → PR merged first
-5. **Feature commit**: "feat: enforce NDA-signed requirement for LOI
-   advance" → PR merged second
-
-What Beck would NOT produce: a single 400-line PR that adds the
-feature, refactors the policy structure, adds telemetry, and fixes
-three unrelated smells. That's everything bundled.
-
-## Sources
-
-- *Test-Driven Development: By Example* — Beck, Addison-Wesley (2002)
-- *Extreme Programming Explained: Embrace Change* — Beck, Addison-Wesley
-  (2nd ed 2004)
-- *Tidy First?* — Beck, O'Reilly (2023)
-- *Implementation Patterns* — Beck (2007)
-- kentbeck.com + kent-beck.com — primary sites
-- JUnit — software itself is bassclef reference
-
-## Related luminaries
-
-- **Martin Fowler** — Refactoring catalog operationalizes Beck's
-  red/green/refactor loop. Beck credited Fowler's work as foundational.
-- **Robert C. Martin** — SOLID principles frame what "right" looks
-  like in Beck's make-it-right step.
-- **Ward Cunningham** — XP co-creator, Wiki inventor. Historically
-  inseparable from Beck.
-- **Michael Feathers** — Working with Legacy Code handles the
-  before-state (no tests exist) that TDD assumes away. Both
-  luminaries became verification-side primaries on bassclef's
-  `/architect-review` SKILL per bet 27c WU-9.5 (2026-06-27); per
-  ADR-035 substrate-as-system tenet, every rule's mechanism claim
-  is a contract Beck's TDD pins + Feathers's characterization
-  tests verify. See `architecture/audits/2026-06-27-audit-method-blind-spot.md`
-  for the recursive Act phase that named the lens-gap.