@thebassclef/lite 0.1.2 → 1.0.0

package/substrate/standards/user-story-invest.md

@@ -1,268 +0,0 @@
----
-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/substrate/standards/velocity-and-appetite.md

@@ -1,229 +0,0 @@
----
-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/substrate/standards/voice-input-pattern.md

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