@thebassclef/lite 1.0.4 → 1.1.0

package/dist/lite/standards/user-story-invest.md

@@ -0,0 +1,268 @@
+---
+tier: lite
+description: Validation rules for user stories produced by /user-stories.
+---
+
+# User Story INVEST Standard
+
+Validation rules for user stories produced by `/user-stories`. INVEST
+(Bill Wake, 2003) is the bassclef heuristic for backlog-ready story
+quality. This standard codifies the rules + pass/warn/fail semantics.
+
+Skill: `.claude/skills/user-stories/SKILL.md`.
+Template: `templates/user-story-template.md`.
+
+## Why this standard exists
+
+User stories are conversation tokens, not specifications. Without
+quality gates, "story" devolves into "any sentence formatted with
+'As a / I want / So that.'" The result: bloated stories that take
+weeks, vague stories that can't be estimated, dependent stories that
+block release planning, technical-debt stories disguised as user
+value.
+
+INVEST is six load-bearing tests every story passes before it enters
+the backlog. Stories that fail multiple letters require rewrite.
+Stories that fail one letter get WARN with a path to resolution.
+
+## The six tests
+
+### I — Independent
+
+**Test**: Can this story ship to production without any other story
+shipping first?
+
+**Why**: dependent stories couple release planning. If A depends on
+B which depends on C, you can't ship A early or skip C. Independent
+stories let the team reorder, kill, or ship in any sequence.
+
+**Acceptable dependencies**:
+- Infrastructure that's already in place (no story dependency, just
+  platform reality)
+- Optional enhancement: "this story is BETTER if X is also shipped,
+  but ships valuable on its own"
+
+**Not acceptable**:
+- "Need US-002 before US-001 makes sense" — merge or resequence
+- Implicit dependencies hidden in acceptance criteria — surface them
+
+**Resolution if fail**:
+- Merge dependent stories into one
+- Resequence so the prerequisite ships as its own story first
+- Re-scope so this story doesn't NEED the prerequisite (deliver lesser
+  but standalone value)
+
+### N — Negotiable
+
+**Test**: Is this story a starting-point for conversation, or a
+contract that mandates exact wording?
+
+**Why**: stories are tokens for conversation between PO + dev + UX,
+not specs. A story that locks in "must be a left-side panel" loses
+the design negotiation that should happen at sprint planning. Stories
+say WHAT outcome the persona gets; teams negotiate HOW during
+implementation.
+
+**Acceptable**:
+- Constraints when they're load-bearing: "must be accessible per WCAG
+  AA" (this isn't negotiable for legal/ethical reasons, mark it
+  explicit)
+- Acceptance criteria that pin down outcomes (those ARE the contract)
+
+**Not acceptable**:
+- Implementation prescription in the story body (move to acceptance
+  criteria or out of story entirely)
+- "Must use [framework/library]" — that's an architecture decision,
+  not a story
+
+**Resolution if fail**:
+- Move prescriptive content to acceptance criteria
+- Move architecture/library mandates to ADRs
+- Rewrite story body in user-outcome terms
+
+### V — Valuable
+
+**Test**: Does the named persona get observable, demonstrable value
+when this story ships?
+
+**Why**: stories that exist for internal reasons (refactor, tech-debt,
+infrastructure) aren't user stories — they're technical tasks. They
+belong in a separate backlog or as enabler stories with explicit
+"this enables future user value" framing. Confusing tech-tasks with
+user-stories pollutes the backlog and obscures actual user work.
+
+**Acceptable**:
+- Direct value: persona uses the new behavior
+- Indirect value: persona experiences a quality improvement
+  (faster, more reliable, more secure)
+- Enabler value: explicit framing — "enables US-NNN which delivers
+  user value"
+
+**Not acceptable**:
+- "Refactor X" with no user-facing change
+- "Pay down tech debt in module Y" — this is a tech task
+- "Add observability" — unless persona is operator/SRE, this is
+  internal
+
+**Resolution if fail**:
+- Reclassify as tech-debt task; move to engineering backlog
+- Reframe as enabler story tied to a user-facing story
+- If genuinely user-valuable but value is hard to articulate, the
+  value isn't there — kill the story
+
+### E — Estimable
+
+**Test**: Can the team estimate this story (in story points,
+t-shirt size, or hours) within ~30 minutes of refinement?
+
+**Why**: unestimable stories indicate hidden complexity, missing
+context, or unfamiliar territory. Either the story needs more
+discovery (research spike), or it needs to be split until the parts
+are estimable.
+
+**Common reasons stories aren't estimable**:
+- Unknown technical territory (need spike)
+- Unclear acceptance criteria (need refinement)
+- Unknown user behavior (need research)
+- Too big to fit estimation in one head (split)
+
+**Resolution if fail**:
+- Schedule a research spike for unknowns (timeboxed, separate story)
+- Refine acceptance criteria
+- Split the story until parts are estimable
+
+### S — Small
+
+**Test**: Does this story fit in one iteration / sprint?
+
+**Why**: stories that span multiple sprints become epics. Epics are
+fine as containers but they're not stories. A story that takes 3
+weeks misses every benefit of incremental delivery — no early
+feedback, no early value, no early risk discovery.
+
+**Heuristic**: a story should be doable in 1-5 days by one or two
+developers with normal context. If 6+ days, split it.
+
+**Splitting strategies** (Patton, Cohn):
+- By workflow step (extract a single step into its own story)
+- By data type (one story per data variant)
+- By acceptance criterion (one criterion per story)
+- By user role (different personas as different stories)
+- By happy path vs. edge cases (ship happy path first, edges later)
+- By UI vs. backend (when independently shippable; risky if not)
+
+**Resolution if fail**: split. The most common letter to fail.
+
+### T — Testable
+
+**Test**: Are the acceptance criteria concrete enough to write
+automated tests against?
+
+**Why**: untestable stories ship as "looks done" — and "looks done"
+ships bugs. Acceptance criteria that read "works well" or "is
+intuitive" aren't testable. Criteria that read "loads in <2s on 4G"
+or "all form fields validate before submit" are.
+
+**Testable criteria**:
+- Pin specific observable behaviors
+- Include thresholds for non-functional concerns (performance, a11y)
+- Cover happy path + at least one edge case
+- Map to test types (unit / integration / e2e)
+
+**Not testable**:
+- "Looks good" / "feels fast" / "is intuitive"
+- "Standard behavior" without defining what standard means
+- Implementation assertions ("uses Redis cache") rather than behavior
+
+**Resolution if fail**: rewrite criteria. Each criterion = one test
+assertion. If you can't write the test, the criterion isn't done.
+
+## Pass / Warn / Fail semantics
+
+Per-story status is computed from the six tests:
+
+| INVEST score | Status | Meaning |
+|--------------|--------|---------|
+| 6 PASS | **PASS** | Backlog-ready |
+| 5 PASS / 1 WARN | **PASS-WARN** | Backlog-ready; resolve warning at refinement |
+| 4 PASS / 2 WARN | **WARN** | Refine before sprint planning |
+| ≤3 PASS or any FAIL | **FAIL** | Rewrite required |
+
+Aggregate iteration health:
+
+```markdown
+**INVEST aggregate**: N PASS / M PASS-WARN / K WARN / J FAIL
+**Backlog-ready ratio**: (PASS + PASS-WARN) / total
+```
+
+Target ratio: ≥85%. Below 70% = backlog-quality systemic issue
+(refinement discipline missing, scope confusion, persona inflation).
+
+## Validation procedure (`/user-stories validate`)
+
+`/user-stories validate` walks every story under `docs/user-stories/`
+(or `docs/user-stories/[iteration]/`) and reports per-story status.
+
+```markdown
+## Story validation — [iteration]
+
+| Story | I | N | V | E | S | T | Status | Notes |
+|-------|---|---|---|---|---|---|--------|-------|
+| US-001 | ✅ | ✅ | ✅ | ✅ | ⚠️ | ✅ | PASS-WARN | S: 5-day estimate at upper bound; consider split |
+| US-002 | ❌ | ✅ | ✅ | ✅ | ✅ | ✅ | FAIL | I: depends on US-005 not yet in backlog |
+| ... | ... | ... | ... | ... | ... | ... | ... | ... |
+
+**Aggregate**: 8 PASS / 3 PASS-WARN / 2 WARN / 1 FAIL
+**Backlog-ready ratio**: 11/14 = 79%  (below 85% target — refine)
+```
+
+## Traceability rules
+
+Every story carries a traceability block linking to upstream artifacts:
+
+| Field | Required? | When absent |
+|-------|-----------|-------------|
+| Persona | MUST | FAIL — every story names a persona slug |
+| JTBD | MUST | FAIL — story without JTBD is solution-looking-for-problem |
+| VPC entry | SHOULD | WARN — benefit clause is weaker without VPC grounding |
+| Use-case line | SHOULD when /use-case exists | WARN — coverage gap on use-case |
+
+A story with no JTBD trace is a **red flag**: it's likely a feature
+request from operator intuition rather than user need. Either find
+the JTBD (which means /jtbd-tasks needs another pass) or kill the
+story.
+
+## What this standard does NOT cover
+
+- **Story estimation methodology** (story points vs. t-shirt vs. hours)
+  — team choice, not standard concern
+- **Sprint composition rules** — separate concern (`/sprint` skill)
+- **Acceptance test format** — Given/When/Then BDD or assertion-style
+  both fine; team picks
+- **Task breakdown within a story** — implementation detail, not
+  story-level
+
+## Relationship to other standards + rules
+
+| Related | Connection |
+|---------|-----------|
+| `standards/persona-schema.md` | Personas referenced in `<As a>` clause must validate against schema |
+| `.claude/rules/artifact-ingestion.md` | Stories trace to upstream artifacts; same "cite before claim" discipline |
+| `standards/vpc-fit-validation.md` | VPC Pain-Relievers + Gain-Creators ground story `<benefit>` clause |
+| `.claude/skills/user-stories/SKILL.md` | The skill that produces stories validated by this standard |
+| `.claude/skills/spec/SKILL.md` | Downstream — spec consumes stories as input scope |
+
+## When to revisit
+
+- Backlog-ready ratio drops below 70% repeatedly (refinement issue OR
+  the standard is too strict)
+- A team consistently fails one letter (might indicate a process gap
+  worth surfacing, e.g., "always failing E means we don't have
+  estimation rigor")
+- New bassclef artifact upstream of stories (e.g., when /use-case
+  lands, traceability rule adds use-case-line as MUST when present)
+
+## Closes
+
+- bassclef #208 (paired with skill)
+- Part of follow-up to iteration `2026-04-19e-persona-vpc-promotions`

package/dist/lite/standards/velocity-and-appetite.md

@@ -0,0 +1,229 @@
+---
+tier: lite
+description: How work is estimated, measured, and calibrated in agent-driven SDLC.
+---
+
+# Velocity and Time Budget Standard
+
+How work is estimated, measured, and calibrated in agent-driven SDLC.
+
+(Formerly `Velocity and Appetite` per ADR-040 D1 rename 2026-07-17.
+The filename stays `velocity-and-appetite.md` for backward compat via
+`standards/vocabulary-migration.json`. Shape Up's original term is
+`appetite`; bassclef calls it "time budget" in operator-facing prose.)
+
+Based on Ryan Singer's Shape Up (Basecamp). Core insight: don't estimate
+how long things will take — set how much time you're willing to spend,
+then scope to fit. Fixed budget, variable scope.
+
+This matters more for agents than for humans. A human developer gets
+tired, checks the clock, pushes back on scope. An agent will happily
+expand forever. The time budget is the constraint that prevents infinite work.
+
+---
+
+## Feynman Explanation
+
+Imagine you're renovating a bathroom. The traditional approach: get an
+estimate ("it'll take 3 weeks"), then discover it takes 6. The Shape Up
+approach: "I'm willing to spend 2 weeks on this bathroom. What can I get
+done in 2 weeks?" Maybe you skip the heated floors. Maybe you use
+off-the-shelf tile instead of custom. The *scope flexes to fit the budget.*
+
+Now imagine the contractor is a robot that never gets tired and thinks
+every detail is equally important. Without a ceiling, it'll spend 3 weeks
+on grout patterns. That's an agent without a time budget. The time budget says: "you
+have 40 turns. Ship something real. Cut what doesn't fit."
+
+The magic is in the closeout. After the work, you write down: "I budgeted
+40 turns, it took 15." Next time something similar comes up, you budget 20.
+The system learns. After a few iterations, your estimates converge on
+reality — not because you got better at estimating, but because you have
+data.
+
+---
+
+## Key Terms
+
+### Round-trip (aka "turn")
+
+One round-trip: you send a message, the agent responds. That's one.
+This is the atomic unit of work in agent-driven development.
+
+A round-trip can be trivial ("read this file") or substantial ("implement
+the entire scoring module"). Not all round-trips are equal, but over
+enough iterations, round-trips-per-issue averages out into a useful signal.
+
+**Why round-trips, not hours?** Hours measure clock time, which is
+meaningless for agents. An agent that takes 3 minutes of wall time but
+50 round-trips of back-and-forth consumed more resources than one that
+took 10 minutes but 8 round-trips. Round-trips are the actual unit of
+consumption.
+
+**Notation**: The frontmatter field is `turns:` (Claude Code's internal
+term). Exact when known (`turns: 15`), approximate with tilde when
+estimated (`turns: ~40`). In prose and metrics output, use "round-trips"
+for clarity.
+
+### Time Budget
+
+(Bassclef's name for Shape Up's `appetite` concept per Ryan Singer + Basecamp.
+Renamed per ADR-040 D1 2026-07-17.)
+
+How many turns you're willing to spend on an iteration. The budget
+ceiling. Set *before* work begins in the iteration goal.
+
+The time budget is **not an estimate**. An estimate says "I think this will
+take 40 turns." The time budget says "I'm willing to spend 40 turns on this.
+If it can't fit in 40, descope or split."
+
+**How the time budget is set:**
+
+1. **By phase** — different phases consume turns at different rates:
+
+   | Phase | Typical time budget | Why |
+   |-------|-----------------|-----|
+   | Inception | 30–50 turns | Thinking artifacts (canvas, shaping) — more back-and-forth |
+   | Elaboration | 30–40 turns | Design + architecture — moderate depth |
+   | Construction | 20–30 turns per branch | Code + tests — focused, less ambiguity |
+   | Transition | 15–20 turns | Deploy + verify — mechanical |
+
+2. **By calibration** — closeout data from previous iterations:
+   - First iteration: use the phase defaults above. You're guessing.
+   - Second iteration: adjust based on the first closeout's delta.
+   - Third+ iteration: your estimates converge. Trust the data.
+
+3. **By scope complexity** — more files touched, more integration points,
+   more unknowns = higher time budget. But prefer splitting into multiple
+   smaller iterations over inflating a single time budget.
+
+4. **By confidence** — "I've done this exact thing before" = lower time budget.
+   "This is novel and uncertain" = higher time budget or spike first.
+
+**The rule**: when the time budget is exhausted, descope. Don't extend. If the
+work can't fit, the scope was wrong — split it, defer the tail, ship what
+fits. This is how fixed budget / variable scope works.
+
+### Actuals
+
+How many turns the work actually consumed. Measured at closeout from
+chronicle timing data (`turns` field in frontmatter).
+
+Actuals are always approximate — counting exact conversation turns is
+fragile. The value is in the *trend*, not the precision. A closeout
+that says "time budget 40, actual ~15" tells you the time budget was 2.5x
+too generous. That's useful even if the actual was really 18.
+
+### Delta
+
+The difference between the time budget and actuals, expressed as a percentage.
+
+```
+Delta = (Actuals - Time Budget) / Time Budget × 100
+```
+
+- **Negative delta** (e.g., -62%): under budget. Time budget was generous.
+  Next similar iteration: lower the time budget.
+- **Zero delta**: perfect calibration. Unlikely but ideal.
+- **Positive delta** (e.g., +30%): over budget. Scope was underestimated
+  or complexity was higher than expected. Check: was the scope too big,
+  or was there unexpected rework?
+
+### Iteration Goal
+
+(Bassclef's name for Shape Up's `iteration bet` per ADR-040 D1 rename 2026-07-17.
+The goal doc filename stays under `docs/iteration-bets/` for backward compat.)
+
+A scoped piece of work with a thesis, acceptance criteria, and time budget.
+The unit of planning. Lives at `docs/iteration-bets/YYYY-MM-DD-slug.md`.
+
+An iteration goal declares:
+- **What** we're building (scope)
+- **Why** it matters (risk retired, value proved)
+- **How much** we're willing to spend (time budget in turns + cost ceiling)
+- **How we'll know** it worked (acceptance criteria, lovability/viability signals)
+
+The goal metaphor comes from Shape Up's `bet` framing (Ryan Singer, Basecamp):
+you're wagering that this scope, at this time budget, will produce value.
+Sometimes you lose — the scope was wrong, the approach was wrong, or the
+time budget was too tight. That's information, not failure.
+
+### Closeout
+
+The section appended to an iteration goal when the work completes (or is
+explicitly abandoned). Records what actually happened vs what was planned.
+
+A closeout contains:
+- **Actuals vs time budget table**: turns, duration, issues closed — with deltas
+- **Gate compliance summary**: which gates fired, which were skipped, why
+- **Calibration notes**: what was over/underscoped, guidance for next time
+
+The closeout is the feedback loop. Without it, the time budget is just a guess
+that never improves. With it, each iteration makes the next estimate
+better.
+
+**When to write**: when all acceptance criteria are met (or explicitly
+deferred). Before the final chronicle. See `standards/sdlc-compliance.md`
+for the closeout format.
+
+### Velocity
+
+Issues closed per turns consumed, measured across iterations. Not a target
+to maximize — a diagnostic to understand.
+
+High velocity + low quality (many fix: branches after feat: branches) =
+shipping too fast, cutting corners. Low velocity + high quality (no
+rework) = possibly over-engineering, or just hard problems. The metrics
+script shows both together so you can read the signal.
+
+### Calibration
+
+The process of using closeout data to improve future time budget estimates.
+Not a manual exercise — it happens naturally when you read previous
+closeouts before setting the next time budget.
+
+**Calibration pattern**:
+1. First iteration: time budget 40 (guess from phase defaults)
+2. Closeout: actual 15, delta -62%. Note: "spec already existed"
+3. Second iteration (similar scope): time budget 20
+4. Closeout: actual 18, delta -10%. Converging.
+5. Third iteration: time budget 20 is now a validated default for this type
+
+The calibration notes in the closeout capture *why* the delta happened,
+not just the number. "Spec already existed" vs "unexpected schema migration"
+are both -62% but mean completely different things for future estimates.
+
+---
+
+## Relationship to Metrics
+
+The `scripts/metrics.sh --iteration` view aggregates closeout data across
+all iteration goals. The `--overall` view rolls up velocity, throughput,
+quality, and DORA into a single dashboard. Both read from artifacts that
+already exist — no separate tracking system.
+
+| Term | Where it lives | Who writes it |
+|------|---------------|---------------|
+| Time budget | Iteration goal (set at start) | Operator + agent during `/autonomous start` |
+| Turns | Chronicle frontmatter (`turns:` field) | Agent at session-end (Must tier) |
+| Actuals | Iteration goal closeout | Agent when iteration completes |
+| Delta | Iteration goal closeout (computed) | Agent when writing closeout |
+| Velocity | `scripts/metrics.sh --iteration` (computed) | Script, on demand |
+| Calibration | Closeout "calibration notes" section | Agent, informed by previous closeouts |
+
+---
+
+## What This Is Not
+
+- **Not story points.** Story points estimate relative complexity. The time budget
+  sets absolute budget. Points ask "how hard is this?" The time budget asks "how
+  much am I willing to spend?" Different question, different answer.
+
+- **Not time tracking.** Duration (minutes) is captured in chronicles for
+  context, but turns are the primary unit. An agent that finishes in 5
+  minutes but takes 50 turns consumed more than one that takes 30 minutes
+  but 10 turns.
+
+- **Not a productivity target.** "Increase velocity" is not a goal. The
+  goal is calibration — estimates that match reality. If velocity drops
+  because the work got harder, that's information, not a problem.

package/dist/lite/standards/voice-input-pattern.md

@@ -0,0 +1,119 @@
+---
+tier: lite
+description: How bassclef handles voice as input to skill dispatches.
+---
+
+# Voice Input Pattern
+
+How bassclef handles voice as input to skill dispatches. Phase V Hey-Alexa MVD uses macOS native dictation (Fn-Fn keyboard shortcut) into a Claude Code prompt. Hands-free voice listener is V2 (deferred).
+
+## When this fires
+
+Operator dictates intent into a Claude Code session instead of typing it. Skills downstream (especially `/preview-build`) treat the resulting text as voice-originated + apply tolerant intent extraction.
+
+## The pattern (V1 — MVD)
+
+### 1. Operator-side: macOS dictation
+
+Operator presses **Fn-Fn** on a Mac with dictation enabled (System Settings → Keyboard → Dictation → On). macOS captures audio + transcribes to the active text field.
+
+Operator speaks the intent. Operator releases Fn-Fn (dictation stops). Transcribed text appears in the Claude Code prompt input.
+
+Operator submits the prompt. The transcribed text flows to bassclef's skills like any text input.
+
+### 2. bassclef-side: voice-input mode
+
+`/launch` (and chained skills) accept the input. The transcribed text is treated as the operator's intent paragraph — conversational shape (fragments, restarts, filler) is preserved verbatim and flows through `/interpret-input` like any keyboard-typed text.
+
+The mode is signaled via:
+- Explicit flag: `/launch --voice-input` (operator dispatch convenience)
+- Auto-detection heuristics (optional V2): text shape suggests spoken vs typed origin
+
+V1 ships explicit flag only. Auto-detection is a polish-shelf concern.
+
+### 3. Downstream chain
+
+After the text lands, the rest of the pipeline is unchanged:
+
+```
+voice → text (macOS dictation)
+       ↓
+text → InputArtifact (/interpret-input — text mode)
+       ↓
+InputArtifact → variants (existing /launch Phase 4 — deterministic luminary round-robin)
+       ↓
+variant → repo (existing /build)
+       ↓
+repo → live URL (existing /launch-preview + Amplify)
+```
+
+The chain composes existing bassclef skills. Voice is a thin front-end on top.
+
+## The pattern (V2 — hands-free, future)
+
+Phase V's roadmap entry says "voice → Bandleader → polished output → live URL." V2 adds:
+
+- **Standalone voice listener** — daemon captures audio without Claude Code prompt step
+- **Whisper API or similar** — offline + accuracy beyond macOS dictation
+- **Bandleader orchestration** — voice → intent → multi-agent dispatch (Phase IV)
+- **Hands-free flow** — operator never touches keyboard during demo
+
+V1 (this standard) ships the MVD. V2 unblocks the full Phase V vision when Phase IV Bandleader lands.
+
+## Why macOS dictation for V1
+
+- **Already on operator's machine** — no new substrate primitive needed
+- **Works offline** (macOS local processing) — no API dependency
+- **Latency low** — real-time transcription
+- **Cross-app** — works in any text field including Claude Code's
+- **Operator already knows it** — Fn-Fn muscle memory
+
+The tradeoff: requires operator to press Fn-Fn (not hands-free). MVD accepts this trade.
+
+## Operator setup checklist (V1)
+
+Before the demo:
+
+- [ ] System Settings → Keyboard → Dictation → ON
+- [ ] Dictation language matches operator's spoken English
+- [ ] Test: press Fn-Fn in any text field; speak a short phrase; verify transcription
+- [ ] Claude Code session active in target directory
+- [ ] bassclef-sync has run (bassclef's substrate up-to-date in target repo)
+
+## Why bassclef core preserves the text as-is
+
+Bassclef core does not run intent extraction against an embedding model + LLM judge. The voice-transcribed text is treated as the operator's intent paragraph and passed through `/interpret-input` unchanged. Downstream phases use it the same way they use keyboard-typed text.
+
+Bassclef-private adopters who want intent-grounded matching can layer their own `/extract-intent` skill via `additionalDirectories` injection. That skill consumes the voice-originated text the same way it consumes typed text; tolerance for conversational shape (fragments, restarts) is the adapter's concern, not bassclef's.
+
+## What this does NOT cover
+
+- Voice in audio-only contexts (telephony, smart speakers) — V3+ scope
+- Multi-speaker scenarios (transcription disambiguation) — V3+
+- Languages other than operator's spoken language — V2+
+- Real-time streaming intent extraction — V2+ (today's pattern is batch: speak → submit → process)
+
+## Distinct from
+
+- `standards/bassclef-test-repos.md` — test ground for substrate validation; foobar exists for bassclef's tests, NOT as the demo target
+- `.claude/skills/launch/SKILL.md` — composes the input → variants chain; voice-input mode is an addition to existing surface
+
+## When this retires
+
+This standard retires if:
+- Hands-free voice listener (V2) replaces the Fn-Fn pattern as the primary mode
+- Phase IV Bandleader supersedes the operator-driven dispatch model
+- Bassclef evolves to a different voice-input convention
+
+Until V2 ships, this is SENTINEL_the_bassclef_V1_pattern for "speak out loud → app lands in cloud."
+
+## Sources read
+
+- `docs/iteration-bets/2026-05-12-phase-v-hey-alexa-mvd.md` — parent bet
+- `docs/roadmaps/2026-05-07-7-phase-staircase.md` Phase V entry (voice → app on live URL)
+- `.claude/skills/launch/SKILL.md` — downstream consumer of voice-originated text
+- bassclef#944 — Voyage matcher excision from bassclef core
+
+## Closes
+
+WU-1 of Phase V Hey-Alexa MVD bet. bassclef#944 cleared the embed+LLM coupling so voice-input mode now flows through bassclef core's deterministic luminary path.