@thebassclef/lite 1.1.0 → 1.2.0-alpha.1

package/dist/lite/.claude/luminaries/ryan-singer.md

@@ -0,0 +1,113 @@
+---
+tier: lite
+name: Ryan Singer
+slug: ryan-singer
+claimed_by: [shaper]
+referenced_by_skills: [canvas, spec, sprint]
+primary_domain: shaping
+depth: full
+solves_problems_brownfield:
+  - "Work items enter the sprint without a clear scope boundary; scope expands as implementation reveals unknowns"
+  - "Teams estimate time required and are wrong predictably; the estimates create false confidence and real frustration"
+  - "Nobody decides which projects to work on in a principled way — the loudest voice or the oldest request wins"
+  - "Feature work runs indefinitely because there is no defined stopping condition"
+solves_problems_greenfield:
+  - "Designing a planning process for a small team that replaces estimation with explicit appetite"
+  - "Building a governance ritual (betting table) that makes scope decisions explicit and time-bounded"
+  - "Planning the first product cycle with a fixed time budget and variable scope"
+  - "Creating a progress visualization that distinguishes problem-understanding from execution"
+anti_patterns:
+  - "Large teams with formal dependency management — Shape Up is designed for small autonomous teams"
+  - "Regulated industries requiring fixed-scope fixed-time delivery (contracts, compliance milestones)"
+  - "Teams that need to coordinate tightly across multiple work streams — Shape Up optimizes for single-team autonomy"
+sources:
+  - type: book
+    title: "Shape Up: Stop Running in Circles and Ship Work That Matters"
+    authors: ["Ryan Singer"]
+    year: 2019
+    url: "https://basecamp.com/shapeup"
+    methodology_covered:
+      - "Appetite — a time budget, not an estimate; fixed time, variable scope"
+      - "Shaping — pre-work by senior people; sets appetite, problem, fat-marker solution sketch, and identified rabbit holes"
+      - "Betting table — governance ritual where shaped pitches are reviewed and chosen for the next cycle"
+      - "Hill chart — progress visualization distinguishing uphill (figuring it out) from downhill (executing)"
+      - "Cool-down — two weeks of unscheduled time after each six-week cycle"
+      - "Circuit breaker — project does not automatically roll into the next cycle; must be re-shaped and re-bet"
+  - type: website
+    title: "Felt Presence — Ryan Singer site"
+    authors: ["Ryan Singer"]
+    year: 2015
+    url: "https://feltpresence.com/"
+    methodology_covered:
+      - "Essays on product design and strategy; Singer's thinking beyond Shape Up"
+verification_status: verified
+description: "\"Appetite is a time budget, not an estimate."
+---
+
+# Ryan Singer
+
+## Signature
+
+*"Appetite is a time budget, not an estimate. We're not asking how long it will take. We're asking how much time it's worth. Fixed time, variable scope."* [ref:1]
+
+Author of **Shape Up: Stop Running in Circles and Ship Work That Matters** (2019, free at basecamp.com/shapeup) [ref:1]. Former product strategist at Basecamp. Every "appetite," "betting table," "cool-down," "fat marker sketch," "hill chart," and "circuit breaker" in bassclef's substrate traces directly to Singer's book. Shape Up is the process methodology bassclef runs on.
+
+## Core methods
+
+- **Appetite** — A time budget the team is willing to spend on a solution. Two standard sizes: Small Batch (2 weeks) and Big Batch (6 weeks). Appetite replaces estimation: instead of asking "how long will this take?" ask "how much time is it worth?" Variable scope fills the fixed time. When appetite runs out, the work ships in whatever state it is — scope is cut, not time extended. [ref:1]
+- **Shaping** — Pre-work done by senior people before a project is placed in the betting table. Shaping sets the appetite, defines the problem clearly, sketches a solution at fat-marker resolution (structural, not detailed), and explicitly identifies rabbit holes (known unknowns to fence off). Shaping output is a pitch — not a wireframe, not a spec, not a task list. [ref:1]
+- **Betting table** — The governance ritual where shaped pitches are reviewed and chosen for the next cycle. Nothing gets built without being shaped first and placed on the table. The team bets on pitches, not on feature requests. What's not on the table does not exist for this cycle. [ref:1]
+- **Hill chart** — Progress visualization that distinguishes two phases of work: uphill (figuring it out — problem is still being understood) and downhill (executing — the approach is clear). A project stuck on the uphill for too long is a risk signal. Hill charts make this visible at a glance. [ref:1]
+- **Cool-down** — Two weeks of unscheduled time after each six-week cycle. No new projects during cool-down. Time for bugfixes, exploration, addressing technical debt, and recovery. Cool-down is not optional; it is structural. [ref:1]
+- **Circuit breaker** — If a project reaches the end of its cycle without shipping, it does not automatically roll into the next cycle. The team must decide explicitly whether to shape it again and re-bet. This prevents runaway work. (Note: Singer's circuit breaker is a scope-management tool, not Nygard's electrical-pattern circuit breaker for production stability.) [ref:1]
+
+## When to channel this luminary
+
+When the primary risk is runaway scope, undefined stopping conditions, or a planning process that feels like continuous negotiation. Singer dominates iteration planning, appetite-setting, and the governance of what the team works on. Channel Singer at the shaping and betting stages — before any code is written. Pair with Christensen/Torres (discovery of what to shape), Cockburn (use case formalism for the shaped pitch), and Patton (story mapping for the scope slice).
+
+INSTEAD of channeling Singer for execution discipline: once the bet is placed and the team is in the cycle, Beck (TDD), Hunt & Thomas (DRY, tracer bullets), and Cockburn (walking skeleton) govern how the work is done. Singer governs what the team bets on and how it scopes the work before committing.
+
+## Stack translation
+
+In bassclef's SDLC:
+
+- **Appetite → iteration bets** — every iteration bet in `docs/iteration-bets/` has an `appetite` field (turns budget, time estimate). This is Singer's appetite operationalized.
+- **Shaping → `/canvas` + `/spec` + `/decompose`** — the shaping process runs as `/canvas` (thesis, problem framing) → `/spec` (acceptance criteria, scope boundaries) → `/decompose` (technical decomposition, rabbit holes identified). The output is a shaped pitch ready for the betting table.
+- **Betting table → `/sprint` and `/longrun`** — the betting table ritual runs at session start; `/sprint` reads the current bet and proposes the next one; `/longrun` runs the full cycle through multiple bets.
+- **Hill chart → issue labels + phase-state** — "figuring it out" phases (Inception, Elaboration) map to the uphill; "executing" phases (Construction) map to the downhill. The hill metaphor makes the SDLC phase transition intuitive.
+- **Cool-down → `/retro` + LinkedIn drafts** — bassclef's inter-iteration gap (between one bet closing and the next opening) is the cool-down. `/retro` runs; LinkedIn drafts are written; substrate improvements ship.
+
+## Anti-patterns it prevents
+
+- **Scope creep as feature** — a cycle that grows because "we discovered more work while building." Shape Up's response: cut scope to fit the appetite. If the discovery changes the problem fundamentally, stop, re-shape, and re-bet.
+  INSTEAD: scope cut is always in bounds; time extension is a violation of the fixed-time contract. [ref:1]
+- **Estimation theater** — story points, planning poker, velocity tracking. These optimize for predicting how long things take rather than deciding how much time they are worth. Singer rejects them: appetite is the input, not the estimate. [ref:1]
+- **Rabbit hole blindness** — starting a cycle without identifying the known unknowns. The shaping step explicitly names rabbit holes and fences them off. Unknowns discovered during execution that were foreseeable at shaping time are a shaping failure.
+- **Perpetual project** — a project that rolls from cycle to cycle without shipping because "it's not quite done." The circuit breaker prevents this: at cycle end, decide whether to re-bet. The project does not own the next cycle by default. [ref:1]
+
+## Worked example
+
+For POA's "deal staleness detection" feature:
+
+**Appetite**: Small Batch, 2 weeks. Reason: the solution space is well-understood and the technical implementation is straightforward. Not worth six weeks.
+
+**Shaping**: Problem is "operators lose track of which deals need attention." Solution sketch (fat marker): a "days since last contact" indicator on the deal table, with a threshold after which the deal is flagged visually. Rabbit hole: "how should the threshold be configured?" — fenced off: use a hardcoded 14-day default; make it configurable in a future bet.
+
+**Betting table pitch**: "Deal Staleness Indicator — 2-week Small Batch. Adds a visual age indicator to the deal table. Operators can see at a glance which deals have gone cold. Rabbit hole (configurable threshold) explicitly out of scope. Acceptance: a deal with no activity in 14+ days shows a visual flag in the deal table."
+
+**Hill chart at week 1**: the "figuring it out" phase — how is last-contact-date tracked? Is there an existing field? How do we handle deals with no contact history? These are uphill questions.
+
+**Hill chart at week 2**: downhill — approach is clear, implementation is in progress. If the team is still uphill at day 8 of 14, it is a risk signal that the shaping missed something.
+
+## Sources
+
+- *Shape Up: Stop Running in Circles and Ship Work That Matters* — Singer, Basecamp (2019, free at basecamp.com/shapeup) [ref:1]
+- feltpresence.com — Singer's site, essays on product and design [ref:2]
+- "Basecamp's Shape Up" — various Basecamp blog posts by Singer
+
+## Related luminaries
+
+- **Ryan Singer & Jason Fried / DHH** — Basecamp founders; Shape Up is the operational expression of their "It Doesn't Have to Be Crazy at Work" philosophy. Singer provides the methodology detail; Fried/DHH provide the cultural context.
+- **Clayton Christensen** — JTBD feeds the shaping step. Understanding the job before defining the appetite makes the shaped pitch more grounded.
+- **Alistair Cockburn** — Use cases and Shape Up pitches share structural rigor: both require clear problem framing before implementation. Cockburn's use case format is a strong input to a well-shaped pitch.
+- **Jeff Patton** — Story mapping and shaping pitches both demand holistic scope thinking. Singer prefers appetite-defined pitches; Patton prefers journey-organized maps. Both prevent random feature drops.

package/dist/lite/.claude/luminaries/steve-krug.md

@@ -0,0 +1,168 @@
+---
+tier: lite
+name: Steve Krug
+slug: steve-krug
+claimed_by: [designer]
+referenced_by_skills: [visual-review, visual-qa, synthetic-user]
+primary_domain: ux
+depth: full
+agent_drafted: 2026-05-06
+operator_review_pending: true
+verification_status: verified
+sources:
+  - type: book
+    title: "Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability"
+    authors: ["Steve Krug"]
+    year: 2014
+    isbn: "978-0321965516"
+    url: "https://sensible.com/dont-make-me-think/"
+    methodology_covered: ["Don't Make Me Think principle", "trunk test", "web usability heuristics", "scanning vs reading behavior"]
+  - type: book
+    title: "Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems"
+    authors: ["Steve Krug"]
+    year: 2009
+    isbn: "978-0321657299"
+    url: "https://sensible.com/rocket-surgery-made-easy/"
+    methodology_covered: ["guerrilla usability testing", "Krug script methodology", "discount usability testing"]
+  - type: website
+    title: "sensible.com — Steve Krug"
+    authors: ["Steve Krug"]
+    url: "https://sensible.com"
+    methodology_covered: ["ongoing resources and commentary on usability"]
+solves_problems_brownfield:
+  - "Existing interface forces users to read or think more than the task warrants"
+  - "User testing keeps surfacing the same friction points but team can't see them"
+  - "Self-evident affordances are missing in the current UI; users hesitate before every click"
+  - "Navigation, labels, and structure aren't immediately obvious"
+solves_problems_greenfield:
+  - "Designing a consumer or low-engagement product where 'don't make me think' is the bar"
+  - "Building a new public-facing surface where usability is the core differentiator"
+  - "Planning a tool that needs to be self-evident from first encounter"
+  - "Designing a product whose audience will not invest effort to learn the interface"
+anti_patterns:
+  - "Power-user tools where complexity is the value (IDEs, trading platforms)"
+  - "Domain-expert surfaces where 'don't make me think' undersells the user"
+  - "Heavily customizable products where user investment in learning IS the relationship"
+description: "\"Don't make me think.\""
+---
+
+# Steve Krug
+
+## Signature
+
+*"Don't make me think."*
+
+Author of *Don't Make Me Think* (2000; 3rd ed 2014) — the canonical short book on web usability. Author of *Rocket Surgery Made Easy* (2009) — the practical guide to lightweight usability testing. Voice for **pragmatic, operator-accessible usability** and **instant-comprehension design**.
+
+Krug's signature contribution is **the trunk test** and the discipline of **guerrilla usability testing** — accessible, cheap, repeatable methods that any team can run any week. Where Nielsen articulates expert evaluation, Krug articulates the user's actual experience: did they hesitate? Did they read when they shouldn't have to? Did they wonder?
+
+For canonical, Krug is the pragmatic operator-friendly counterpart to Nielsen's expert-heuristics. Krug's guerrilla methods belong in `/synthetic-user` and `/visual-qa`; his "don't make me think" maxim belongs in every `/visual-review`.
+
+## Sources
+
+- *Don't Make Me Think: A Common Sense Approach to Web Usability* — Krug, New Riders (1st ed 2000, 2nd ed 2006, 3rd ed *Don't Make Me Think, Revisited* 2014)
+- *Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems* — Krug, New Riders (2009)
+- [sensible.com](https://sensible.com) — Krug's site, with usability test demo videos + scripts
+- Krug's workshops + conference talks (UX London, IxDA, etc.)
+
+## Core methods
+
+- **Don't make me think** — Every element should be obvious on sight; thought is cost users won't pay. Self-evident > self-explanatory > requires explanation. [ref:1]
+- **The trunk test** — Grab any page; can a user in 5 seconds answer: What site is this? What page am I on? What are the major sections? What can I do here? Where am I in the navigation hierarchy? If not, IA fails. [ref:1]
+- **First law of usability**: *Don't make me think* (instant comprehension wins).
+- **Second law of usability**: *It doesn't matter how many times I have to click, as long as each click is a mindless, unambiguous choice* (clicks are not the cost; thinking is the cost).
+- **Third law of usability**: *Get rid of half the words on each page, then get rid of half of what's left* (page copy is mostly noise; ruthless reduction reveals essence).
+- **Guerrilla usability testing** — 3-5 users, $50-100, one morning. Catches 80% of issues for 5% of the cost of formal studies. Test early, test often, test cheap. [ref:2]
+- **The Krug script** — A specific, refined script for guerrilla tests: orientation, tasks, debrief. Available open-source on Krug's site. [ref:2]
+- **Reservoir of goodwill** — Every confusing moment depletes it; every clear, easy moment refills it. Users will tolerate some friction if the goodwill reservoir is deep.
+
+## INSTEAD-block discipline
+
+| Anti-pattern | INSTEAD |
+|---|---|
+| "Users will read the help text" | Don't write help text; redesign the affordance so help isn't needed; make the obvious obvious |
+| "We'll explain this in onboarding" | Onboarding shouldn't be needed for the basic affordances; reserve onboarding for genuinely complex multi-step workflows |
+| "It's intuitive once you understand it" | Self-evident > requires-understanding; if it requires understanding, redesign or accept that it's a power-tool affordance |
+| Long copy on landing pages | Get rid of half the words; then half of what's left; users skim, they don't read |
+| Skipping user testing because "no time" | 3 users, one morning, $50; ALWAYS time; the alternative (shipping defects) is more expensive |
+| 30-user test for fix-stage product | 3-5 users catches 80% of issues; reserve large studies for late-stage / quantitative questions |
+| Custom navigation that "works once you know it" | Use platform conventions; users have learned other sites; meet them where they are |
+| Hiding primary actions behind menus / hamburgers | Primary actions visible by default; hide only secondary / advanced |
+| "Click here" as link text | Link text describes the destination ("Read the report" not "Click here") — makes scanning work, makes screen readers work |
+| Trunk test failed but rationalized away ("the user will figure it out") | Trunk test failure = redesign; user shouldn't have to figure it out |
+| Page with 5 competing CTAs | One primary CTA per page; secondary actions visually subordinate |
+| Navigation that requires reading to use | Navigation icons + labels tested for instant recognition; if a user has to read every label, the icons are decoration |
+
+## When to channel this luminary
+
+- Always — when designing or auditing a public-facing / consumer / low-engagement surface where users won't invest in learning
+- Especially — when the operator's complaint is "users get stuck" or "we keep getting the same support questions"
+- Pair with `jakob-nielsen` (heuristic evaluation) — Krug's guerrilla testing + Nielsen's heuristic review = full pre-launch usability discipline
+- Pair with `vitaly-friedman` (craft-first patterns) — Krug's "don't make me think" needs Friedman's craft to manifest in form/table/empty-state patterns
+
+Do NOT use this luminary alone for power-user / domain-expert / customizable products. Krug's discipline is consumer-grade; "don't make me think" undersells professionals who are paid to think.
+
+## Stack translation
+
+In React + Tailwind + accessible primitives:
+
+- **Self-evident affordances** → Buttons look like buttons (not styled-text); links look like links (underline + color shift on hover); inputs have visible borders; clickable items have hover states
+- **Trunk test on every page** → Every page should answer: site identity (logo top-left), page identity (h1), navigation context (breadcrumbs or active-nav state), available actions (primary CTA visible), where-am-I (active section in sidebar/nav)
+- **Navigation conventions** → Logo top-left links home; main nav top or left; primary CTA distinct visual weight; search where users expect (top-right or top-center)
+- **Reduce copy** → Audit every paragraph: what's the half I can cut? What's the half I can cut from the remainder? Page copy should be ruthless
+- **Primary action discipline** → One primary CTA per page; secondary actions in less-prominent button styles; tertiary actions as text links
+- **Link text** → Always describes destination; never "Click here" / "Learn more" alone (instead "Read the deployment guide")
+- **Predictable patterns** → Forms top-to-bottom, labels above; tables sortable; modals close with Esc + click-outside + X
+- **Guerrilla test fixture** → For dev environments, a `usability-test/` directory with Krug's script + 3 task scenarios; team runs whenever before-merge
+
+## Anti-patterns it prevents
+
+- **Self-explanatory drift** — every element requires a small amount of thought; cumulative cognitive cost exhausts users
+- **Help-text crutch** — design defects covered by tooltips and help articles; users miss the help, hit the defect, churn
+- **No usability testing** — 3-user test never run; defects ship; remediation post-launch is 10x cost
+- **Long-copy landing pages** — paragraphs of marketing prose; users skim, miss the point, bounce
+- **Custom navigation** — designer's clever idea; users trained by the rest of the web; mismatch causes hesitation everywhere
+- **Hidden primary actions** — primary CTA buried behind hamburger menu; conversion suffers; users don't realize the action exists
+- **Trunk-test failure ignored** — page doesn't pass the 5-second comprehension test; team rationalizes; users don't bother
+
+## Worked example
+
+For canonical's hypothetical landing page (canonical.dev):
+
+Krug's prescription:
+- **Trunk test**: in 5 seconds, can a senior engineer answer:
+  - What site is this? → "canonical" wordmark top-left, large
+  - What is this? → h1 hero — "The shared methodology for solo builders building durable software with AI" (one sentence; user vocabulary)
+  - What can I do here? → Primary CTA: "Try it →"; Secondary: "How it works"; Tertiary text-link: "View on GitHub"
+  - Where am I in the hierarchy? → Single-page landing; top nav: Why / How / Roadmap (3 items, not 8)
+- **Reduced copy**: Hero is 1 sentence (not 3 paragraphs); each section is ≤2 sentences before evidence/example; cut every "leverage", "synergy", "best-in-class"
+- **Self-evident affordances**: Primary CTA is a button (filled, contrasting color); secondary is button (outlined); tertiary is text-link with underline
+- **Navigation discipline**: Top nav 3 items; logo links home; no hamburger needed at desktop; mobile hamburger for the same 3 items
+- **Predictable patterns**: Pricing where users expect (Pricing in nav); FAQ at bottom; contact + social bottom-footer
+- **Guerrilla test fixture**: 3 scripted tasks: "Find out what canonical does"; "Find out how to start"; "Find out who built it"; goal is each task ≤30 seconds
+
+What this luminary catches that "make a marketing site" misses: the trunk-test discipline, the copy-reduction ruthlessness, the conventional-navigation discipline, the one-primary-CTA discipline, the guerrilla-testable scope.
+
+## How to use in canonical's chain
+
+In `/visual-review`:
+- Trunk test as a required check item; pages that fail = block merge until redesigned
+- Copy-reduction prompt: "what's half? what's half of half?"
+- Self-evident-affordance check: every interactive element passes "obvious-without-reading-label" test
+
+In `/visual-qa`:
+- Krug's guerrilla-test script + 3 task scenarios per UI surface; runs before each release
+- 3 users; 30-min total; findings filed as substrate-defect or product-defect tickets
+
+In `/synthetic-user`:
+- Krug's task-script discipline informs synthetic-user persona journeys; synthetic users follow the same script form
+
+## Related luminaries
+
+- **Jakob Nielsen** — NNG co-founder; Krug's guerrilla testing + Nielsen's heuristic evaluation = paired pre-launch discipline
+- **Don Norman** — Affordance theory underlies Krug's "self-evident"; Krug operationalizes Norman for the operator
+- **Vitaly Friedman** — Craft-first patterns; Friedman's discipline manifests Krug's "don't make me think" in form/table/empty-state shapes
+- **Susan Weinschenk** — Cognitive science backing; Weinschenk's research grounds Krug's intuitions
+- **Erika Hall** — Pragmatic research; Hall + Krug share the "ship guerrilla discipline" stance
+- **Aarron Walter** — Voice + microcopy; Walter's discipline complements Krug — both believe in ruthless brevity
+- **Sophia Prater** — OOUX; Prater's object-driven IA serves Krug's trunk test (clear hierarchy = trunk-testable)

package/dist/lite/.claude/luminaries/tony-ulwick.md

@@ -0,0 +1,134 @@
+---
+tier: lite
+name: Tony Ulwick
+slug: tony-ulwick
+claimed_by: [product-manager, shaper]
+referenced_by_skills: []
+primary_domain: product
+depth: full
+solves_problems_brownfield:
+  - "Product roadmap is built from feature requests instead of measured customer outcomes"
+  - "Team cannot articulate which customer outcomes are most underserved by the current product"
+  - "Job stories are missing from the spec; user stories carry behavior but not context or motivation"
+  - "Prioritization debates collapse into opinions because nobody has quantified which outcomes matter most"
+solves_problems_greenfield:
+  - "Designing the first version of a product where outcome statements should drive the feature set"
+  - "Choosing a market entry point by finding the job step where outcomes are most undersatisfied"
+  - "Authoring requirements as job stories so the spec carries situation + motivation alongside behavior"
+  - "Building an opportunity algorithm to score where to invest first based on customer-rated importance and satisfaction"
+anti_patterns:
+  - "Pure technology exploration where customer outcomes are deliberately undefined"
+  - "Highly personal consumer products where the unit of measurement (outcome statements) does not fit the use case"
+  - "Stable mature categories where the question is execution, not where to invest next"
+sources:
+  - type: book
+    title: "What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services"
+    authors: ["Anthony W. Ulwick"]
+    year: 2005
+    url: "https://www.amazon.com/What-Customers-Want-Outcome-Driven-Breakthrough/dp/0071408673"
+    isbn: "0071408673"
+    methodology_covered:
+      - "Outcome statements — structured sentences naming direction, metric, object, and contextual clarifier"
+      - "Opportunity algorithm — Importance + max(Importance − Satisfaction, 0)"
+      - "Outcome-Driven Innovation (ODI) — anchoring product investment to customer-measured outcomes"
+  - type: book
+    title: "Jobs to Be Done: Theory to Practice"
+    authors: ["Anthony W. Ulwick"]
+    year: 2016
+    url: "https://www.amazon.com/Jobs-Be-Done-Theory-Practice/dp/0990576744"
+    isbn: "0990576744"
+    methodology_covered:
+      - "Job map (8 universal steps) — Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, Conclude"
+      - "Jobs are stable; solutions change — anchoring strategy to outcomes across technology shifts"
+      - "Job stories — When [situation], I want to [motivation], so I can [outcome]"
+  - type: website
+    title: "Jobs-to-be-Done resource site"
+    authors: ["Tony Ulwick"]
+    year: 2016
+    url: "https://jobs-to-be-done.com/"
+    methodology_covered:
+      - "Outcome-Driven Innovation framework, outcome statement templates, opportunity algorithm reference"
+  - type: journal_article
+    title: "Turn Customer Input into Innovation"
+    authors: ["Anthony W. Ulwick"]
+    year: 2002
+    url: "https://hbr.org/2002/01/turn-customer-input-into-innovation"
+    methodology_covered:
+      - "Original ODI article introducing the opportunity algorithm to a wider business audience"
+verification_status: verified
+description: "\"Customers do not want features. They want outcomes. Define the outcome with a metric and a baseline. Then ask whether the current product delivers that outcome — and rank where…"
+---
+
+# Tony Ulwick
+
+## Signature
+
+*"Customers do not want features. They want outcomes. Define the outcome with a metric and a baseline. Then ask whether the current product delivers that outcome — and rank where it does not. That ranking is your product roadmap."* [ref:1]
+
+Tony Ulwick (*What Customers Want* [ref:1] + *Jobs to Be Done: Theory to Practice* [ref:2]) operationalized Christensen's JTBD theory into Outcome-Driven Innovation (ODI). Where Christensen provided the frame ("people hire products to make progress"), Ulwick provided the measurement engine: outcome statements, importance + satisfaction scoring, the opportunity algorithm. The two compose; Ulwick makes JTBD actionable.
+
+## Core methods
+
+- **Outcome statements** — A structured sentence: "[direction of improvement] the [metric] of [object of measurement] [contextual clarifier]." Example: "Minimize the time it takes to identify which deals need attention today." Outcome statements are testable; feature ideas are not. They survive technology change because they describe what customers want done, not how. [ref:1]
+- **Opportunity algorithm** — Score each outcome statement on importance (how much customers care) and satisfaction (how well the current solution delivers). Opportunity = Importance + max(Importance − Satisfaction, 0). Outcomes with high importance and low satisfaction are the highest-leverage product investments. Outcomes with high importance and high satisfaction are competitive moats; do not de-prioritize them. Outcomes with low importance are noise. [ref:4]
+- **Job map (8 universal steps)** — Every job decomposes into Define + Locate + Prepare + Confirm + Execute + Monitor + Modify + Conclude. Mapping a job at this level surfaces which steps the current product covers and which steps customers complete with workarounds, other tools, or pain. Friction at any step is an opportunity. [ref:2]
+- **Jobs are stable; solutions change** — The job a customer is trying to get done does not change much across decades. The product that helps them get it done changes often. Anchoring strategy to the job (and to outcome statements derived from it) gives the product a stable target across feature pivots, platform shifts, and competitive entries. [ref:2]
+
+## When to channel this luminary
+
+Channel Ulwick when product strategy needs to move from feature requests + opinion-based prioritization to measurement-based investment. The signal is: the team is debating which features to build next without a quantified view of which customer outcomes are most underserved.
+
+Channel Ulwick when authoring a product spec where requirements must carry situation + motivation alongside behavior. Job stories preserve the why behind each requirement; user stories alone collapse it.
+
+INSTEAD of channeling Ulwick for UX surface decisions: once the job + outcome statements + opportunity scores are clear, Cooper (personas + goal-directed design) and Norman (affordances + interaction) drive how the product surface helps customers reach the prioritized outcomes.
+
+## Stack translation
+
+In bassclef's SDLC:
+
+- **Outcome statements feed `/canvas`** — the Thesis stage names the outcome statement (not the feature) the product targets. Outcome carries the metric; the metric drives acceptance.
+- **Opportunity algorithm feeds backlog scoring** — each backlog item is tagged with the outcome it serves. Importance + satisfaction scores drive the prioritization rank. Underserved outcomes win.
+- **Job map feeds `/ia-model`** — the 8-step structure suggests information surfaces and navigation flows. Steps where the current product covers nothing are net-new screen candidates.
+- **Job stories feed `/spec`** — every spec section opens with the job story format: "When [situation], I want to [motivation], so I can [expected outcome]." The "so I can" links to the prioritized outcome statement.
+
+## Anti-patterns it prevents
+
+- **Feature-as-requirement** — writing requirements as "Add a deal staleness indicator" without naming the outcome. Ulwick would rewrite: "Minimize the time it takes for the operator to identify which deals need attention today." Now the requirement is testable + survives implementation choice. [ref:1]
+- **Unscored prioritization** — picking what to build based on the loudest voice in the room. Ulwick's algorithm removes the debate: importance and satisfaction are measured, the opportunity score ranks the work, the room decides only the cutoff line. [ref:4]
+- **Outcome confusion** — confusing customer outcomes (what the customer wants) with business outcomes (what the company wants). The opportunity algorithm runs on customer outcomes; business outcomes constrain the cutoff but do not change the ranking.
+- **One-off interview synthesis** — running customer interviews without a structured outcome inventory. The team gathers anecdotes but cannot compare outcomes across customers. Ulwick's interview protocol produces measurable outcome statements that aggregate across the customer pool.
+
+## Worked example
+
+For POA's product strategy applied to deal management:
+
+**Job identified (Christensen frame)**: Operators are hired to advance the pipeline so they can deploy capital.
+
+**Job map applied (Ulwick 8-step)**:
+
+| Step | Outcome statement | Importance | Satisfaction | Opportunity |
+|---|---|---:|---:|---:|
+| Locate | Minimize the time to find deals that fit the thesis | 9 | 3 | 15 |
+| Prepare | Minimize the time to assemble the financials for a candidate deal | 8 | 5 | 11 |
+| Monitor | Minimize the time to know which deals need attention today | 9 | 2 | 16 |
+| Confirm | Minimize the time to verify a deal meets criteria before LOI | 7 | 6 | 8 |
+| Modify | Minimize the effort to update the pipeline when a deal stalls | 6 | 4 | 8 |
+
+The opportunity algorithm ranks Monitor (16) and Locate (15) as the highest-leverage investments. Prepare (11) is the third candidate. The team builds in that order; Confirm + Modify are noted as competitive parity work.
+
+**What ODI rules out**: building broker CRM features (broker relationship management is a different job and is not on this customer's outcome map). Without ODI scoring, broker CRM might win attention via stakeholder pressure. With scoring, the absence of any broker-related outcome statement on the customer side makes the cutoff clear.
+
+## Sources
+
+- *What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services* — Ulwick, McGraw-Hill (2005) [ref:1]
+- *Jobs to Be Done: Theory to Practice* — Ulwick, IDEA BITE Press (2016) [ref:2]
+- jobs-to-be-done.com — Ulwick's Outcome-Driven Innovation framework, outcome statement templates, opportunity algorithm reference [ref:3]
+- *Turn Customer Input into Innovation* — Ulwick, Harvard Business Review (2002) — the original ODI article that introduced the opportunity algorithm [ref:4]
+
+## Related luminaries
+
+- **Clayton Christensen** — Theoretical frame for JTBD. Christensen names the job + the milkshake insight; Ulwick measures the outcomes underneath the job. Channel Christensen first to identify the job, then Ulwick to score where to invest.
+- **Teresa Torres** — Weekly continuous discovery cadence. Torres's opportunity-solution tree composes with Ulwick's outcome statements: outcomes anchor the tree, weekly interviews refresh importance + satisfaction scores.
+- **Ryan Singer** — Shape Up appetite + betting table. Outcome scores feed the betting table directly: high-opportunity outcomes earn higher appetite.
+- **Alan Cooper** — Once outcome statements are prioritized, Cooper's personas + goal-directed design translate them into UX surfaces. Cooper's goals map closely to Ulwick's outcome statements.
+- **Jeff Patton** — User story mapping's backbone maps cleanly to the 8-step job map. Patton's story slices operationalize Ulwick's outcome prioritization at sprint scope.

package/dist/lite/.claude/rules/arc-level-orientation-before-leaf.md

@@ -0,0 +1,60 @@
+---
+tier: lite
+description: "/sprint and /longrun prep walk the active goal's parent_bet chain UP TO THE ROOT before proposing scope."
+---
+
+# Parent-Goal Walk Before Scope Pick
+
+> **Vocabulary note (2026-07-24, ADR-040 D1 rename table):** "arc" is being renamed to "thread" across bassclef prose per goal 2026-07-24c #849. The marker directory `state/markers/thread-walk/` is a symlink to `state/markers/arc-walk/`; both paths resolve during the grace window through 2026-10-31. Adopter-facing prose in this rule now prefers "thread" and "parent-goal walk"; historical mentions of "arc" and "arc-walk" in commit history, chronicle titles, and older docs still parse.
+
+`/sprint` and `/longrun prep` walk the active goal's parent_bet chain UP TO THE ROOT before proposing scope. Walking one level only drops parent_drivers, open acceptance, and out_of_scope items from every goal beyond the immediate parent. Multi-day threads run 5-10 goals deep; ancestor context disappears when the walk is one-level.
+
+The rule mechanizes the memory `feedback_arc_level_orientation_before_leaf` filed 2026-06-20 plus the bassclef#1347 fix shipped 2026-06-20h. Closes a 7-bet-deep arc failure observed on session 2026-06-20: agent typed `/longrun`, narrowed to the leaf ticket (bassclef#1268), missed 30+ in-flight items across the parent arc — 10 paused steps of bet 2026-06-18a, 12 still-open audit-drop tickets, 3 new tickets filed earlier the same day.
+
+## When this rule fires
+
+Two surfaces:
+
+1. **Skill-invocation surface** — Any session running `/sprint` orientation OR `/longrun prep` Step 0.6 + Step 1 on a feature branch with an active iteration goal.
+2. **Artifact-edit surface** (added per bassclef-upstream#300, 2026-06-23) — Any `Edit | Write | MultiEdit` PreToolUse on `docs/iteration-bets/*.md`. The agent can reshape WUs, update time budget, or absorb new scope into a goal doc; the gate fires on the artifact-write boundary regardless of whether `/longrun prep` or `/sprint` was invoked. Mechanical layer: `.claude/hooks/bet-doc-gate.sh` (composes with sister #21 produces/consumes substantive check).
+
+## What the rule requires
+
+Before proposing scope, walk the parent chain recursively:
+
+1. Read `docs/iteration-bets/<active-bet>.md` frontmatter.
+2. Read `parent_drivers`, open `acceptance` items, and `out_of_scope` from the active goal.
+3. If `parent_bet:` is set, read that goal's frontmatter. Add its `parent_drivers` + open `acceptance` + `out_of_scope` to the union.
+4. Repeat step 3 on the parent's `parent_bet`, then grandparent's `parent_bet`, until `parent_bet` is null or missing.
+5. If any goal in the chain has `parent_roadmap:` set, read that roadmap's `last_event` + `next_pending` (per bassclef#337 state spine accessors).
+6. Surface the unioned drivers + open acceptance + out_of_scope items in `/longrun prep` output BEFORE proposing scope-shape candidates. The shape candidates must frame the ARC, not just the leaf.
+
+The mechanical surface for this rule:
+
+- `.claude/skills/longrun/SKILL.md` Step 0.6 + Step 1 — procedure language
+- `.claude/skills/sprint/SKILL.md` — orientation procedure (sister surface, separately ticketed)
+- `.claude/hooks/session-reflection.d/55-orientation-gate.sh` — SessionStart layer; BLOCKED message displays the chain so the agent sees ancestor lineage before touching the per-branch orientation marker
+- `.claude/hooks/bet-doc-gate.sh` — Artifact-edit layer (PreToolUse Edit|Write|MultiEdit on `docs/iteration-bets/*.md`); BLOCKs when the parent-goal walk marker missing at `state/markers/thread-walk/<goal-slug>.marker` (which symlinks to `state/markers/arc-walk/<goal-slug>.marker` during the grace window through 2026-10-31); composes with sister #21 produces/consumes substantive check. Closes bassclef-upstream#300.
+
+## Cycle protection
+
+Cap the walk depth at 20 ancestors. Break on a repeated slug. Cycles in `parent_bet` chains are unexpected today (no bet declares its descendant as parent) but the cap defends against future drift + bad-data edge cases.
+
+## Override path
+
+`SKIP_ORIENTATION_GATE=1 <command>` — logged via trace-helper per `.claude/rules/blocked-items.md`. Use rarely. Examples of legitimate overrides:
+
+- Single-bet sessions where the goal is the arc root (no parent_bet ever existed)
+- Read-only sessions where no scope proposal is being made
+- Emergency rescue when the hook itself is broken
+
+INSTEAD of overriding for routine work: read the chain. The cost is small (one frontmatter read per ancestor), the benefit compounds across every future arc.
+
+## Composes with
+
+- `.claude/rules/blocked-items.md` — BLOCK protocol the orientation-gate hook fires
+- `.claude/rules/artifact-ingestion.md` — "Sources read" block discipline applied at the chain-walk level
+- `.claude/rules/plan-enumeration-needs-value-props.md` — sister at choice-presentation surface
+- `.claude/rules/wu-sequencing-compounds.md` — sister at intra-shape WU discipline (bassclef#1348)
+- `.claude/skills/longrun/SKILL.md` Step 0.6 + Step 1 — primary surface this rule extends
+- `.claude/hooks/session-reflection.d/55-orientation-gate.sh` — mechanical layer

package/dist/lite/.claude/rules/architect-review-discipline.md

@@ -0,0 +1,71 @@
+---
+tier: lite
+description: Every architect-review run MUST exercise both methods — static comprehension AND dynamic verification.
+---
+
+# Architect-Review Discipline
+
+Every architect-review run MUST exercise both methods — static comprehension AND dynamic verification. The bet 24c architect-review (2026-06-24) shipped a thorough comprehension-side audit but missed the mechanism-fidelity class because runtime verification was structurally absent. The recursive Act phase (`architecture/audits/2026-06-27-audit-method-blind-spot.md`) named the gap; this rule mechanizes the fix.
+
+This rule is the methodology layer. The mechanical layers: the architect-review SKILL.md amendment (mandatory two-method procedure step) + per-stack siblings under `standards/architect-review-discipline/<stack>.md` (concrete verification suite per `tech_stack.kind`).
+
+## When this rule fires
+
+Every invocation of `/architect-review`. Auto-loaded via `additionalDirectories`. Mandatory check before the review's "Commit the review document" step.
+
+## What this rule requires
+
+Before committing any architect-review report:
+
+1. **Static comprehension** completed — every artifact in scope read; classified per 6M fishbone (per @luminary kaoru-ishikawa). Comprehension lenses primary: @luminary frederick-brooks (conceptual integrity) + @luminary linus-torvalds (adopter-compatibility stance).
+
+2. **Dynamic verification** completed — verification suite per the per-stack sibling at `standards/architect-review-discipline/<stack>.md` invoked. Verification lenses primary: @luminary michael-feathers (characterization tests) + @luminary kent-beck (TDD) + @luminary saltzer-schroeder (complete mediation).
+
+3. **Both methods' findings appear in the report** — separately classified. The report's "Verification step performed" column per finding (per `standards/architect-review-discipline.md` § "Output coverage criterion" — A4 from recursive Act phase) makes the method visible per row.
+
+4. **Per-stack sibling exists** — for `tech_stack.kind: substrate`, the sibling at `standards/architect-review-discipline/substrate.md` (ships bet 27c WU-9.55). For other stacks, the sibling ships per `bassclef-upstream#418` per-stack rollout.
+
+5. **Lens-set declaration in audit frontmatter** — the audit's `luminaries.primary` field declares the primary lens set up front. The actual lens set used in the report MUST match the declaration. Declaration mismatch is a methodology failure per A3 from recursive Act phase.
+
+## Anti-patterns
+
+These shapes fail this rule.
+
+**Architect-review ships with comprehension-side findings only.** Bet 24c failure pattern; the audit-method blind spot the recursive Act phase named. Cure: invoke the verification suite per the per-stack sibling; add findings to the same report.
+
+**Lens-set declaration in frontmatter does not match actual lens set used.** Methodology failure per A3. Cure: amend the frontmatter to match what was actually applied, OR amend the report to match the declared lenses.
+
+**Report findings table has no "Verification step performed" column.** Output coverage criterion (A4) violation. Cure: add the column; populate per finding.
+
+**Per-stack sibling missing for the stack under review.** No verification suite to invoke; the second method cannot run. Cure: file a `/promote bassclef-evolution` request for the stack; defer the review OR invoke whatever verification IS available + note the gap in the report.
+
+**INSTEAD** of skipping verification when the suite is incomplete: invoke what exists, document what does not, file the cure ticket. Per `.claude/rules/blocked-items.md`, silence is not deferral.
+
+## Composes with
+
+- `.claude/rules/substrate-as-system.md` — sister tenet (bet 27c WU-9) — the system the architect-review verifies
+- `.claude/rules/mechanism-fidelity.md` — sister discipline (bet 27c WU-9) — 7-label classification used by the verification suite
+- `.claude/rules/cold-adopter-harness-discipline.md` — the harness IS one verification surface for adopter-observable substrate
+- `.claude/rules/iteration-bet-brief-completeness.md` — lens-set declaration discipline extends to goal docs (A3)
+- `.claude/skills/architect-review/SKILL.md` — the SKILL this rule extends (two-method procedure step)
+- `standards/architect-review-discipline.md` (bet 27c WU-2 — universal framework)
+- `standards/architect-review-discipline/substrate.md` (bet 27c WU-9.55 — substrate sibling)
+- `standards/mechanism-fidelity.md` (bet 27c WU-2 — verification chain spec)
+- ADR-035 substrate-as-system + 9-surface hook taxonomy
+- `architecture/audits/2026-06-27-audit-method-blind-spot.md` (bet 27c WU-7.5 — recursive Act phase that motivates this rule)
+- `architecture/audits/2026-06-27-mechanism-fidelity.md` (bet 27c WU-6 — empirical evidence)
+- `architecture/audits/2026-06-24-closeout.md` (bet 24c audit; this rule's predecessor whose method gap is named here)
+- `lib/mechanism-fidelity.sh` (bet 27c WU-3) — verification chain shared deep module
+- `.claude/skills/audit-rule-mechanism-fidelity/SKILL.md` (bet 27c WU-4) — operator-invocable audit
+- `scripts/cold-adopter-harness-sync.sh` Shape d (bet 27c WU-5) — per-PR gate
+- @luminary michael-feathers — verification-side anchor (full luminary upgrade per step-9.6 — cross-references substrate-as-system tenet)
+- @luminary kent-beck — TDD anchor; tests pin contracts
+- @luminary saltzer-schroeder — complete mediation
+- @luminary w-edwards-deming — Act phase (this rule operationalizes A1-A4)
+- @luminary kaoru-ishikawa — recursive 6M fishbone (this rule operationalizes the fishbone applied to audit method itself)
+
+## Override
+
+`SKIP_ARCHITECT_REVIEW_DISCIPLINE=1 <command>` — for genuine one-shot review runs where verification is structurally impossible (e.g., reviewing a frozen historical snapshot). Logged via trace-helper.
+
+INSTEAD of overriding routinely: invoke the verification suite per the per-stack sibling. The cost is bounded by the suite's scope; the discipline holds across every future review.