@thebassclef/lite 0.1.0 → 0.1.3

package/substrate/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/substrate/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.

package/substrate/standards/worktree-management.md

@@ -0,0 +1,211 @@
+---
+tier: lite
+description: Defines the lifecycle for git worktrees in autonomous agent sessions.
+---
+
+# Worktree Management Standard
+
+Defines the lifecycle for git worktrees in autonomous agent sessions.
+Worktrees enable parallel branch work but create operational hazards when
+agents crash, hit rate limits, or exhaust context without cleanup.
+
+This standard applies whenever agents use `git worktree add` — whether
+in parallel autonomous mode or manual multi-branch work.
+
+---
+
+## Worktree Lifecycle
+
+```
+CREATE → WORK → COMMIT → PR → CLEANUP
+```
+
+Every worktree must complete this lifecycle. A worktree that skips CLEANUP
+leaves a branch lock, consumes disk, and confuses the next session.
+
+---
+
+## Pre-Session Audit (MUST — session start)
+
+Before creating any new worktrees, audit existing ones:
+
+```bash
+git worktree list
+```
+
+For each worktree that is not the main working tree:
+
+1. **Check if prunable**: `git worktree list` shows `prunable` for worktrees
+   whose directory no longer exists
+2. **Check age**: if the worktree is from a previous session (different date
+   or session ID), it is stale
+3. **Check for uncommitted work**: `git -C <worktree-path> status` — if dirty,
+   the previous agent died mid-work
+
+### Stale worktree resolution
+
+| State | Action |
+|-------|--------|
+| Prunable (directory gone) | `git worktree prune` — safe, just cleans metadata |
+| Clean (no uncommitted changes) | `git worktree remove <path>` — safe to remove |
+| Dirty (uncommitted changes) | Commit as `chore: wip — recovered from stale worktree`, then remove |
+| Branch has open PR | Remove worktree, leave PR open for review |
+| Branch has no PR and no useful commits | Remove worktree, delete branch |
+
+Present stale worktrees to the operator at session start. In orchestrator-gated
+mode, auto-clean prunable and clean worktrees; prompt for dirty ones.
+
+The session-start hook should surface stale worktrees. If it doesn't, the
+agent checks manually.
+
+---
+
+## Creating Worktrees
+
+### Naming convention
+
+```
+.claude/worktrees/<slug>
+```
+
+Where `<slug>` matches the branch's short description. Example:
+`feature/100-stack-1-worktree-mgmt` → `.claude/worktrees/worktree-mgmt`
+
+### Creation checklist
+
+1. Verify the branch doesn't already exist: `git branch --list <name>`
+2. Create from main (not from another worktree's branch):
+   ```bash
+   git worktree add .claude/worktrees/<slug> -b <branch-name>
+   ```
+3. Record the worktree in the stack manifest if one exists
+4. Never `cd` into the worktree — use `git -C <path>` for all operations
+
+### Why never `cd` into a worktree
+
+If the agent's working directory is inside a worktree and the worktree is
+removed (by cleanup, crash recovery, or another agent), the shell's cwd
+becomes invalid. All subsequent commands fail with "Unable to read current
+working directory." This was observed in POA parallel run 2026-04-07.
+
+Instead:
+```bash
+# Good — run from main working tree
+git -C .claude/worktrees/my-feature add .
+git -C .claude/worktrees/my-feature commit -m "feat: description"
+
+# Bad — changes cwd, creates cleanup hazard
+cd .claude/worktrees/my-feature
+git add .
+```
+
+---
+
+## File Watcher Conflicts
+
+### Problem
+
+Dev servers (Next.js, Vite), linters (ESLint watch mode), formatters
+(Prettier watch), and IDE file sync tools monitor the filesystem. When a
+worktree agent writes a file, watchers may:
+
+- Revert the file to their cached state
+- Trigger a rebuild that overwrites agent output
+- Lock files that the agent needs to write
+
+### Mitigation
+
+Before creating worktrees for parallel work:
+
+1. **Stop all file watchers**: dev server, lint --watch, test --watch
+2. **Check for processes holding files**:
+   ```bash
+   lsof +D <worktree-path> 2>/dev/null
+   ```
+3. **If watchers can't be stopped** (e.g., IDE integration), document in
+   the stack manifest that this branch is not parallel-safe
+
+The `/autonomous start` boot sequence should check for running dev servers
+and warn before spawning parallel agents.
+
+### IDE-specific notes
+
+- **VS Code**: File watcher is aggressive. If the worktree is inside the
+  project directory (which `.claude/worktrees/` is), VS Code will watch it.
+  Consider creating worktrees outside the project directory for parallel runs.
+- **Cursor/JetBrains**: Similar behavior. Same mitigation.
+
+---
+
+## Cleanup Protocol (MUST — before session end)
+
+Every agent that creates a worktree MUST clean it up before exiting.
+This is part of the graceful exit protocol (see `standards/graceful-exit.md`).
+
+### Normal cleanup (work complete, PR open)
+
+```bash
+git worktree remove .claude/worktrees/<slug>
+```
+
+If the branch was merged, also delete the branch:
+```bash
+git branch -d <branch-name>
+```
+
+### Abnormal cleanup (agent dying, context exhaustion)
+
+If the agent knows it's about to die (context pressure, rate limit, budget):
+
+1. Commit any in-progress work: `git -C <worktree-path> commit -am "chore: wip"`
+2. Push the branch: `git -C <worktree-path> push -u origin <branch>`
+3. Remove the worktree: `git worktree remove <path>`
+4. Note in checkpoint: "worktree cleaned, branch pushed, PR not yet open"
+
+If the agent dies without cleanup (crash, kill, timeout), the next session's
+pre-session audit handles recovery.
+
+### Cleanup order
+
+When multiple worktrees exist:
+
+1. Remove worktrees with merged PRs first (safest)
+2. Remove worktrees with open PRs next (work is preserved in the PR)
+3. Remove worktrees with unpushed work last (commit and push first)
+
+---
+
+## Rate Limit Awareness
+
+Parallel worktree agents multiply API request rate against the same account
+quota. This was observed in POA 2026-04-07: 3 agents = 3x RPM pressure,
+causing 429 errors.
+
+### Mitigations
+
+| Strategy | When to use |
+|----------|------------|
+| Sequential mode | Default. Zero rate limit risk. Recommended for most work. |
+| Staggered starts | If parallel: delay 30s between agent spawns |
+| Reduced context | Send only relevant files to each agent, not full repo |
+| Fewer parallel agents | Max 2 concurrent for most account tiers |
+
+### Rate limit detection
+
+If an agent receives a 429 or rate limit error:
+
+1. Do NOT retry immediately — this makes it worse
+2. Wait the duration specified in the Retry-After header (or 60s default)
+3. If rate limits persist after 3 retries: save state, report to operator,
+   recommend switching to sequential mode
+
+---
+
+## Relationship to Other Standards
+
+| Standard | Relationship |
+|----------|-------------|
+| `standards/graceful-exit.md` | Worktree cleanup is a MUST gate in exit protocol |
+| `standards/branch-stacking.md` | Stack manifest tracks worktree branches |
+| `.claude/rules/cost-governance.md` | Rate limit cost of parallel worktrees |
+| `strategy/agent-choreography.md` | Orchestrator manages worktree lifecycle in parallel mode |

package/substrate/templates/chronicle-template.md

@@ -0,0 +1,75 @@
+---
+tier: lite
+session_id: {YYYY-MM-DD}-{HHMM}
+project: {active project}
+agent: personal
+status: completed
+tags: [relevant, tags]
+started_at: {ISO 8601 — from session-end hook or /tmp/claude-session-timing-*}
+ended_at: {ISO 8601 — from session-end hook or current time}
+duration_minutes: {exact from hooks, or approximate as fallback}
+turns: {approximate, e.g., ~40}
+closes: [{list of issues closed, e.g., "#37", "#42"}]
+---
+
+# Session: {Title}
+
+## Entry State
+- State before this session
+
+## Work Done
+- Bullet points of accomplishments
+- Reference commits + PRs by SHA / number
+
+## Decisions Made
+- Key decisions with rationale
+
+## Open Threads
+- What's unfinished or needs follow-up
+- (most important section — what the next session reads first)
+
+## Key Files Changed
+- List of files created or modified
+
+## Gate Evidence
+
+**MUST be populated.** This section is the authoritative input for the
+5-session gate-compliance counter. An empty/missing section reads as
+"no data" and silences the compliance signal.
+
+Auto-populate from gate markers (run before writing the chronicle):
+
+```bash
+BRANCH_SLUG=$(git branch --show-current | tr '/' '-')
+[ -f "state/markers/temperance/${BRANCH_SLUG}.marker" ] && echo "temperance: yes"
+[ -f "state/markers/diagnose/${BRANCH_SLUG}.marker" ] && echo "diagnose: yes"
+[ -f "state/markers/verify/${BRANCH_SLUG}.marker" ] && echo "verify: yes"
+# For multi-branch sessions, iterate over each branch worked.
+```
+
+| Gate | Fired | Evidence | Outcome |
+|------|-------|----------|---------|
+| Temperance | {yes/no/n/a} | {marker path or "session-level (longrun)" or n/a reason} | {PASS / N/A — reason} |
+| Diagnosis | {yes/no/n/a} | {marker path; "n/a — not a fix/ branch"; or "trivial — [cause]"} | {root cause / n/a} |
+| Tests | {yes/no/n/a} | {N unit, M integration; or "n/a — docs only"} | {pass count / n/a} |
+| Verify | {yes/no/n/a} | {marker path; or "n/a — docs only"} | {PASS / N/A — reason} |
+
+### Gate skip justifications
+
+If any gate shows `no` without a valid `n/a` reason, that's a compliance
+failure (per `standards/sdlc-compliance.md`). Valid skip reasons:
+
+- **n/a** — gate doesn't apply (e.g., diagnosis on a feature branch)
+- **Degraded mode** — infrastructure unavailable; note workaround
+- **Assessed as trivial** (diagnosis only) — cause was immediately obvious; state it
+
+Invalid reasons: "ran out of time", "will do later", bare "no" with no rationale.
+
+## Promotable Patterns
+
+Did this session produce a novel diagnostic, workaround, or workflow
+improvement worth shipping to other repos? If yes:
+
+- {Pattern name}: {one-sentence description} → /promote candidate
+
+Then run /promote before session-end.