sisyphi 1.2.1 → 1.2.11

package/dist/templates/agent-plugin/skills/humanloop/SKILL.md

@@ -1,148 +0,0 @@
----
-name: humanloop
-description: >
-  Read before calling `sis ask`. Triggers when surfacing multiple questions or decisions to the user, presenting work for review/sign-off, or proposing concrete alternatives. Covers when a deck beats chat, how to design options as real forks the user can pick between, how to bundle related questions into one deck, and how to submit via the Bash tool's `run_in_background` so you can end your turn while the user takes their time answering.
----
-
-# Talking to the user via decks
-
-`sis ask` posts a structured deck of questions to the user's dashboard inbox. They walk through it on their own time and you read structured JSON back. Use it instead of dumping a wall of questions into chat.
-
-This skill covers **what to put in a deck** and **how to invoke it**. Run `sis ask -h` for the CLI shape (file path, `--session`, the `poll` and `peek` subcommands).
-
-## Reach for a deck when
-
-- You have **2+ questions** to surface in one beat (bundle them into one deck).
-- You're presenting **work for review or sign-off** (a design, a plan, a completion summary).
-- You're choosing between **concrete alternatives** the user must pick.
-- The work will sit while the user thinks. Decks survive across cycles; chat does not.
-
-## Skip the deck when
-
-- It's a single, low-stakes question whose answer barely changes downstream work — just ask in chat.
-- You can settle the question yourself by reading code or running a tool. **Default to investigating before asking.**
-- The user is actively conversing with you — converting a live exchange into a deck adds friction.
-
-## How to invoke
-
-The CLI **always blocks** until the user resolves the deck (potentially 10+ minutes). Submit through the Bash tool with `run_in_background: true` and **end your turn**. Do not peek, poll, or output filler chat between submit and answer — the bash completion notification is the only signal you need; it will wake you with stdout ready to parse. Same pattern for orchestrator, sub-agents, and one-off Claude Code sessions.
-
-```
-Bash tool call:
-  command:           sis ask "$deck"
-  run_in_background: true
-```
-
-Stdout on completion is one line of JSON: `{responses: [{id, selectedOptionId?, freetext?}, ...], completedAt}`. Branch on each response by its interaction `id`.
-
-If you already hold an `askId` from a prior cycle (e.g. respawned mid-wait), `sis ask poll <askId>` blocks on it and `sis ask peek <askId>` returns status without blocking. Use these only for respawn-recovery — **never to monitor a deck you just submitted in the current turn**. See `sis ask -h`.
-
-## Designing interactions
-
-### Each option is a concrete path forward
-
-The user picks an option to commit to a direction. Each option should name a real path with its tradeoffs spelled out, grounded in *this* codebase. Sign-off decks branch differently per option ("looks good", "minor fixes", "moderate fixes", "scope rework" each route the orchestrator somewhere different). Decision decks present mutually exclusive directions with named consequences.
-
-<example type="good">
-```
-title: "Session store backend?"
-subtitle: "Auth needs persistent sessions across restarts"
-kind: decision
-options:
-  in-memory:  "In-memory map — simplest. Loses sessions on restart; single-process only."
-  redis:      "Redis — survives restart, supports horizontal scale. New ops dependency."
-  postgres:   "Reuse existing Postgres — no new infra; ~10ms read latency vs Redis ~1ms."
-  defer:      "Ship in-memory now, migrate later if scale becomes real."
-allowFreetext: true
-freetextLabel: "Different framing — describe it"
-```
-</example>
-
-<example type="bad">
-```
-title: "Happy with this design?"
-options:
-  1. Yes
-  2. No, start over
-  3. Maybe, with comments
-  4. (no option, just freetext)
-```
-"Happy?" names a feeling, not a fork. Options 3 and 4 both collapse to freetext, forcing the user to invent the actual decision. Rewrite as specific decisions about specific elements of the design.
-</example>
-
-### Use `allowFreetext: true` as a safety valve, not the primary input
-
-Freetext catches "anything else?" — opinions or context the options didn't anticipate. When freetext IS the answer you want, write a chat message instead.
-
-<example type="bad">
-```
-title: "Approve?"
-options:
-  1. Approve
-  2. Reject
-  3. Comment
-allowFreetext: true
-```
-A freetext form wearing option clothing. Either name what "reject" actually routes to (back to design? abandon? try a different framing?), or drop the deck and ask in chat.
-</example>
-
-### Bound option count to 2–4
-
-Above four, options become too granular for the user to weigh; below two, you've collapsed into a yes/no that's faster to ask in chat.
-
-### Ground options in what you've already gathered
-
-Each option label should reference specifics from the codebase, plan, or exploration you just did — file names, framework constraints, prior decisions. When you can't fill in specifics, investigate before asking.
-
-### One concern per interaction
-
-When two questions interact, give them separate `id` / `title` / `options` inside the same deck (see Bundling below). One interaction asks one thing.
-
-## `kind` — display hint
-
-| kind | use for |
-|---|---|
-| `decision` | fork in the road; user picks a path forward |
-| `validation` | sign-off on completed work |
-| `notify` | FYI; user acknowledges |
-| `context` | surfacing background that needs a response |
-| `error` | something went wrong; user picks a recovery |
-
-The dashboard uses `kind` for inbox icons and sort weight. Mis-tagging trains the user to ignore the icons. Pick the closest fit.
-
-## Bundling
-
-If you'd otherwise submit two decks in the same beat, merge them. One deck with multiple `interactions` is one context switch for the user; two decks is two.
-
-```bash
-deck="$SISYPHUS_SESSION_DIR/context/.ask-$(date +%s).json"
-cat > "$deck" <<'EOF'
-{
-  "title": "Phase 2 sign-off + follow-on decisions",
-  "interactions": [
-    {
-      "id": "approve-phase-2",
-      "title": "Phase 2 looks good?",
-      "kind": "validation",
-      "options": [...]
-    },
-    {
-      "id": "phase-3-scope",
-      "title": "Phase 3 scope?",
-      "kind": "decision",
-      "options": [...]
-    }
-  ]
-}
-EOF
-# Then invoke `sis ask "$deck"` via the Bash tool with run_in_background: true.
-# Each interaction returns its own selectedOptionId / freetext in output.responses[], indexed by id.
-```
-
-## Submission notes
-
-- The deck is validated at submit (precise errors — trust them).
-- `kind` is an enum: `notify` | `validation` | `decision` | `context` | `error`. No other values accepted (see the table above for which to pick).
-- `bodyPath` points at a markdown file instead of inlining the body in JSON. The path is resolved **relative to the deck JSON's directory** and must stay inside it (no `..`, no symlinks out, no absolute paths pointing elsewhere). Practical pattern: write the deck JSON next to its body file — e.g. both inside `$SISYPHUS_SESSION_DIR/context/` — and use a basename like `"completion-summary.md"`. Mutually exclusive with `body`.
-- On completion, stdout is one line of JSON: `{responses, completedAt}`. Parse `responses[]` and dispatch on each interaction's `id`.
-- See `sis ask -h` for the full CLI surface.

package/dist/templates/agent-plugin/skills/operator-memory/SKILL.md

@@ -1,64 +0,0 @@
----
-name: operator-memory
-description: Use right before the operator agent submits its final report. Provides guidance for updating the project-local operator memory at .sisyphus/agent-plugin/skills/operator/ — what to capture, where to put it (SKILL.md vs a new reference file), naming conventions, and what to skip. Defers to /authoring:skills for generic skill conventions (frontmatter, length budgets, structure).
-user-invocable: false
----
-
-# Updating operator memory
-
-You're about to submit. Spend a minute capturing what the next operator should not have to rediscover.
-
-The memory lives at `.sisyphus/agent-plugin/skills/operator/`:
-- `SKILL.md` — the high-level map of this app's surfaces and operations
-- per-task-family reference files alongside it (`auth.md`, `db-reset.md`, `checkout-flow.md`, etc.)
-
-## When to update (and when NOT to)
-
-The bar is **"will future operators benefit from this?"** Specifics:
-
-UPDATE when you discovered:
-- A repeatable operational procedure (login flow, db reset, seed step, environment toggle)
-- A surface that wasn't obvious (admin route, debug overlay, hidden flag, internal port)
-- A footgun you hit and worked around (race condition, ordering requirement, stale-cache trap)
-- A convention this app uses that differs from defaults (custom auth headers, non-standard ports, weird redirect chains)
-
-DON'T update when:
-- It's session-specific state (this user's email, this session's seeded data)
-- It's a one-off observation that won't reproduce
-- It's already covered (read existing files first — duplication is worse than nothing)
-- It's about the codebase, not about operating the app — that's the orchestrator's domain, not yours
-
-## SKILL.md vs a reference file
-
-**SKILL.md** is the high-level map. It answers "what surfaces does this app have, what are the most common operations, where do I find deep dives?" Keep it dense — under ~80 lines. Each entry is a line or two with a pointer.
-
-**A reference file** is the deep dive for one task family. It answers "exactly how do I do X step by step in this project". Each file has scope: `auth.md`, `db-reset.md`, `checkout-flow.md`, `feature-flags.md`.
-
-Decision rule:
-- New task family the operator might face → new reference file (and add a one-line entry to SKILL.md's Reference Files section).
-- Refinement to existing knowledge → update the existing reference file or SKILL.md.
-- A surface name you keep referencing → add it to SKILL.md's App Surfaces section once.
-
-## Naming conventions
-
-- Reference files: kebab-case, task-family scope, no `operator-` prefix (the directory already implies it), `.md` extension.
-- Good: `auth.md`, `admin-panel.md`, `db-reset.md`, `feature-flags.md`.
-- Bad: `operator-auth.md`, `flows.md`, `notes.md`, `stuff.md`.
-- One file per task family. If `auth.md` exists, append to it; don't create `auth-new.md` or `auth-2.md`.
-
-## How to update
-
-1. **Read first.** Open the current `SKILL.md` and any reference file you'll touch — orient before writing. Avoid duplicating what's already there.
-2. **Write/edit with the Write or Edit tool.** The directory already exists at `.sisyphus/agent-plugin/skills/operator/` (the hook scaffolds it on first run).
-3. **Keep prose dense.** The next operator pays in tokens for everything you write. If a step is obvious, omit it.
-4. **Register new reference files** by adding a one-line entry to `SKILL.md`'s "Reference files" section so they're discoverable.
-
-For frontmatter, length budgets, and general skill structure rules, invoke `/authoring:skills`. Don't reinvent those rules here — this skill only covers operator-specific guidance.
-
-## Examples
-
-**Discovered magic-link auth flow:** Create `auth.md` with the steps (email submit → check inbox → click link → cookie set). Add a one-liner to `SKILL.md` App Surfaces (`/login` — magic-link, see `auth.md`). Add to Common Operational Patterns (`Log in: see auth.md`).
-
-**Hit a stale-cache footgun:** The `/dashboard` route serves stale data for ~30s after a write because of an SWR cache. Add a single bullet to `SKILL.md` Known Footguns: `Dashboard SWR cache holds stale data ~30s after writes — hard refresh or wait`. No new reference file needed — it's a one-liner.
-
-**Found admin overlay:** `?admin=1` query param toggles an admin panel with seed/reset buttons. Add to `SKILL.md` App Surfaces: `Admin overlay: append ?admin=1 to any page; has seed/reset/feature-flag buttons`. If the overlay is rich enough to need step-by-step coverage, create `admin-panel.md` and link from there.

package/dist/templates/agent-plugin/skills/perspective-fanout/SKILL.md

@@ -1,115 +0,0 @@
----
-name: perspective-fanout
-description: >
-  Load when the problem-agent dialogue has produced enough substance to react to but conclusions haven't hardened — typically four or more turns in, with a framing solidifying. Provides the protocol for spawning eight perspective sub-agents in parallel, synthesizing their outputs, and presenting the synthesis back to the user via a render+deck pair. Available only at MEDIUM, HIGH, or XHIGH effort.
----
-
-# Perspective fanout
-
-Spawn the eight perspective lenses as parallel sub-agents to challenge convergence before the framing locks in. The agents operate from a shared problem statement so their outputs are directly comparable. After they return, synthesize and surface to the user — convergence, surprises, insights — as the seed for the next dialogue turn.
-
-## When to spawn
-
-- The conversation has substance to react to (typically four or more turns in)
-- A framing is starting to solidify
-- You want to challenge convergence, not rescue a stalled discussion
-- You have already formed your own take
-
-If the conversation is stalled, use a plateau-breaker instead — perspective fanout needs material to push against.
-
-## Before spawning: write the shared problem statement
-
-Two or three sentences, given verbatim to all eight agents:
-
-- What's happening (or not happening)
-- What's been considered so far (from your exploration and the user input)
-- What a good outcome looks like
-
-This shared framing is what makes the eight outputs comparable. Different framings produce different conversations and the synthesis collapses.
-
-## The eight lenses
-
-Spawn one sub-agent per lens, all in the background, in parallel:
-
-| Lens | Brief |
-|---|---|
-| First Principles | Strip away assumptions. What is the actual problem at its most fundamental level? |
-| User Empathy | Forget the code. What does the person using this actually need? |
-| Simplifier | What can be deleted, removed, or skipped? The best solution might be no solution. |
-| Systems Thinker | Zoom out. What are the second-order effects? What breaks downstream? |
-| Contrarian | Take the opposite position of whatever seems obvious. |
-| Time Traveler | Six months from now, what will we wish we had done? |
-| Adversarial | Assume the current approach is wrong. Find the flaw, the hidden assumption that breaks under stress. |
-| Precedent | Has this been solved before? In this codebase, in open source, in a different domain entirely? |
-
-Continue the conversation with the user while the agents run. Do not block.
-
-## Synthesis
-
-When the eight return, write to `$SISYPHUS_SESSION_DIR/context/perspective-synthesis.md` covering:
-
-- **Convergence** — where multiple lenses pointed the same direction (signal worth trusting)
-- **Surprises** — which perspective said something nobody else did (potential breakthroughs)
-- **Insights** — name each key finding in a memorable sentence the user can carry forward
-
-Then render in the side pane:
-
-```bash
-termrender --tmux "$SISYPHUS_SESSION_DIR/context/perspective-synthesis.md"
-```
-
-Bail on non-zero exit with the file path and exit code.
-
-## Surface to the user
-
-Issue the synthesis deck. No `${var}` shell assignments needed; angle-bracket placeholders are pre-substituted:
-
-- `<one-line convergence>` — where multiple lenses pointed the same direction
-- `<one-line surprise>` — what a single lens said that nobody else did
-
-```bash
-synth_deck="$SISYPHUS_SESSION_DIR/context/.ask-problem-synth-$(date +%s)-$$.json"
-cat > "$synth_deck" <<EOF
-{
-  "interactions": [{
-    "id": "problem-perspective-synth",
-    "title": "Lens synthesis",
-    "subtitle": "After 8 perspective agents",
-    "body": "## In the side pane\n\n- Synthesis rendered via termrender — scroll and react below.\n\n## What I'm hearing\n\n- <one-line convergence>\n- <one-line surprise>",
-    "kind": "decision",
-    "options": [
-      {"id": "breakthrough",    "label": "Breakthrough — this lens reframes it"},
-      {"id": "useful",          "label": "Useful but not load-bearing"},
-      {"id": "wrong-direction", "label": "Wrong direction — discard"},
-      {"id": "mixed",           "label": "Mixed — see freetext"}
-    ],
-    "allowFreetext": true,
-    "freetextLabel": "Which lens, what landed, what's still missing"
-  }]
-}
-EOF
-result=$(sis ask "$synth_deck") || { sis agent submit "Synthesis deck failed — deck: $synth_deck"; exit 1; }
-[ -n "$result" ] || { sis agent submit "Synthesis deck: empty result — deck: $synth_deck"; exit 1; }
-choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId // empty')
-notes=$(echo  "$result" | jq -r '.responses[0].freetext // ""')
-```
-
-## Routing after synthesis
-
-All four option ids return to the dialogue loop's turn-deck flow.
-
-- `breakthrough`, `useful`, `mixed` — carry the synthesis forward into the next turn's framing (the next turn deck body should reference what landed)
-- `wrong-direction` — discards the synthesis but does not exit the loop
-- `notes` flows into the next turn's framing regardless of `choice`
-
-**Increment the turn counter `N`** before issuing the next turn deck. Skipping the increment produces two consecutive `Turn N — <lens>` subtitles with the same N, breaking inbox scannability.
-
-## Failure handling
-
-- If more than four of eight agents return errors, surface partial results if any returned cleanly, otherwise bail
-- If `termrender --tmux` fails on the synthesis render, bail with file path and exit code
-- If the synthesis deck fails or returns empty, bail with the deck path
-
-## Body content rules
-
-The deck `body` field uses `##` headings, bullet lists, and bold only — no tables, no code fences, no termrender directives.

package/dist/templates/agent-plugin/skills/problem-document/SKILL.md

@@ -1,105 +0,0 @@
----
-name: problem-document
-description: >
-  Load when ready to draft `context/problem.md` — the thinking artifact that orients downstream agents (spec, plan, implement) to why the work exists. Provides design principles, the section vocabulary to pick from, and an anchor example showing the target style. Use this before writing the draft, not after.
----
-
-# Designing the problem document
-
-The problem document is a **thinking artifact**, not a spec. Its job is to orient downstream agents (spec, plan, implement) to *why* the work exists — what hurts, what's the non-obvious trick, what matters, what's risky — tightly enough that they can read the whole thing in under thirty seconds.
-
-## Design principles
-
-- **Scannable, not exhaustive.** A downstream agent reads this once before doing real work. It needs to walk away with the right mental model, not every detail of the conversation that produced it.
-- **Sections are a vocabulary, not a checklist.** Use the sections that earn their place for *this* problem. Skip ones that don't. Add ones that do. Different problems need different shapes.
-- **Each section answers a question a downstream agent would ask:** "What hurts? What's the trick? What are we building? Why is it tricky? What does done look like? What can't we do? What's still up in the air?" If a section doesn't answer one of those, cut it.
-- **Tables and bullets do the structural work; prose fills gaps where tables would feel forced.** A central decision shown as a 2-row table is worth ten sentences of paragraph.
-- **No alternatives section.** The forks you considered and rejected lived in the conversation — they don't need to live in the artifact. Downstream agents care about the path forward, not the paths not taken.
-- **Length follows from clarity, not from rules.** When the thinking is crisp, the document is short on its own. If a section feels like it wants more words, the answer is usually to tighten the thinking, not expand the section.
-
-## Section vocabulary
-
-Pick what earns its place; rename freely.
-
-- **The pain / what's wrong** — what hurts and why now
-- **Key insight** — the non-obvious understanding that reframes the problem
-- **What we're building** — the artifact(s) or change(s) the work produces
-- **Why it's tricky** — failure modes, mental traps, things that defeat the obvious approach
-- **What success looks like** — concrete outcomes, not metrics theater
-- **Constraints** — what bounds the solution (not assumptions, not anti-goals — actual bounds)
-- **Open questions** — unresolved choices the next phase needs to make
-
-## Anchor example
-
-This is the target style — terse, scannable, structured by what serves the content rather than by template:
-
-<example>
-# Session debugging is too expensive to do
-
-## The pain
-When a sisyphus session produces unexpected output, the maintainer can't
-cheaply learn from it. The choice is between re-teaching Claude the
-architecture every conversation, or doing manual archaeology across raw
-JSONL files. Both are expensive enough that the learning loop gets skipped
-entirely.
-
-## Key insight
-The data is already on disk — sisyphus just doesn't read it. Every agent's
-full transcript lives at `~/.claude/projects/<cwd>/<sessionId>.jsonl` with
-file touches, tokens, subagent spawns, and timing. The fix is a reader, not
-new instrumentation.
-
-## The two artifacts
-
-| What | Why it's needed |
-|---|---|
-| **Debugging toolkit** (CLI verbs) | Cheap "what happened in session X" lookups Claude can compose with grep/jq |
-| **Architecture skill** (SKILL.md) | A mental model Claude can pull when reasoning about sisyphus runtime — the novel multi-agent design defeats its priors |
-
-Useless apart, powerful together. The toolkit answers *what*; the skill
-answers *how to make sense of what*.
-
-## Why the skill matters
-
-Claude's failure modes when reasoning about sisyphus are predictable:
-- Treats the orchestrator as a long-running process with memory (it's
-  stateless, fork-per-cycle)
-- Conflates sisyphus-managed agents with Claude-Code-managed Task-tool
-  subagents
-- Misses that "completed" means three different things at three levels
-- Loses track of which channel agents communicate over
-
-These aren't undocumented — they're scattered across CLAUDE.md files framed
-as traps, not mental models. The skill is synthesis with decision heuristics,
-not new philosophy.
-
-## What success looks like
-
-- Maintainer says "investigate session X", Claude pulls the skill, runs a
-  couple of CLI queries, gives a grounded diagnosis citing real file paths
-  and JSONL evidence — no re-teaching
-- Same skill loads automatically for high-level architecture discussions,
-  not just debugging
-- Zero new instrumentation — derived from data already on disk plus a
-  one-line fix to complete an existing index
-
-## Constraints
-
-- Claude Code JSONL format isn't a stable contract — reader must degrade
-  gracefully if Anthropic changes it
-- Codex/OpenAI agents have no equivalent transcript — known blind spot,
-  not in scope
-
-## Open questions
-
-- Skill scope: one broad "sisyphus" skill (architecture + debugging) or
-  split into two?
-- Pre-fix sessions: accept they're harder to debug, or add an mtime-proximity
-  fallback in the reader?
-</example>
-
-Notice what this example *doesn't* have: no "Alternatives Considered," no "Assumptions" section, no "User Experience" header (folded into success), no "Anti-Goals." Each section earned its place because the content needed it. A different problem would skip "Why the skill matters" and add "Migration path" or "User flows" — whatever the content demands.
-
-## Bifurcation case
-
-If the conversation revealed that the scope contains **independent sub-problems** rather than one problem with sub-parts, do not write a unified `problem.md`. Instead, use the bifurcation-exit pattern from the agent prompt — the orchestrator handles re-entering discovery for each sub-problem.

package/dist/templates/agent-plugin/skills/problem-plateau-breakers/SKILL.md

@@ -1,83 +0,0 @@
----
-name: problem-plateau-breakers
-description: >
-  Load when the problem-agent dialogue loop signals the conversation has stalled — repeated circling, user freetext like "different angle" / "going nowhere" / "feels stuck", or the agent senses it has been chasing the same framing for several turns without traction. Provides four breaker-deck shapes (flip, zoom-out, zoom-in, name-tension) and the routing for each. Increments the turn counter and returns control to the dialogue loop.
----
-
-# Plateau-breaker decks
-
-When the conversation circles, the user wants a *different shape of question*, not another variation of the same one. Pick the breaker whose move matches the stall pattern, issue the deck, then resume the turn loop.
-
-## Pick the breaker type
-
-| Type | Use when | Move |
-|---|---|---|
-| `flip` | The conversation keeps assuming a position is correct | Embrace the opposite — what changes if we believed the inverse? |
-| `zoom-out` | The conversation is litigating details before establishing whether they matter | Step back — does this distinction even change the outcome? |
-| `zoom-in` | The conversation is trading abstractions without testing them against a real case | Pick a concrete scenario and see if the framing survives |
-| `name-tension` | Two values are being held in tension without naming the trade-off | Surface the tension itself as the question |
-
-Choose one per stall. Do not chain breakers — if a breaker doesn't unstick the conversation, the next one is the *next* stall, counted toward the repeated-stuck guard.
-
-## Issue the deck
-
-Required prior assignments before the heredoc:
-- `type` — one of `flip` / `zoom-out` / `zoom-in` / `name-tension`
-
-Angle-bracket placeholders (substitute literally before writing the heredoc):
-- `<observation>` — what the conversation has been circling
-- `<reframe>` — provisional alternative tied to the breaker type
-
-```bash
-type=flip  # or zoom-out / zoom-in / name-tension
-deck="$SISYPHUS_SESSION_DIR/context/.ask-problem-plateau-${type}-$(date +%s)-$$.json"
-cat > "$deck" <<EOF
-{
-  "interactions": [{
-    "id": "problem-plateau-${type}",
-    "title": "Plateau breaker",
-    "subtitle": "Plateau breaker — ${type}",
-    "body": "## Stalled\n\n- <observation>\n\n## Reframe\n\n- <reframe>",
-    "kind": "decision",
-    "options": [
-      <options for this type — see table below>
-    ],
-    "allowFreetext": true,
-    "freetextLabel": "Or describe the angle differently"
-  }]
-}
-EOF
-result=$(sis ask "$deck") || { sis agent submit "Plateau-breaker deck failed — type: $type — deck: $deck"; exit 1; }
-[ -n "$result" ] || { sis agent submit "Plateau-breaker deck: empty result — type: $type — deck: $deck"; exit 1; }
-choice=$(echo "$result" | jq -r '.responses[0].selectedOptionId // empty')
-notes=$(echo  "$result" | jq -r '.responses[0].freetext // ""')
-```
-
-## Per-breaker options
-
-Pre-substitute the matching row before writing the heredoc:
-
-| `type` | Options (id / label) |
-|---|---|
-| `flip` | `embrace-flipped` / "Embrace the flipped position" · `stick-original` / "Stick with original" · `merge-both` / "Merge both" |
-| `zoom-out` | `drop-doesnt-matter` / "Doesn't matter — drop" · `smaller-scope` / "Matters but smaller" · `matters-as-is` / "Matters as is" |
-| `zoom-in` | `scenario-breaks-it` / "This scenario breaks it" · `scenario-holds` / "Scenario holds" · `different-scenario` / "Different scenario" |
-| `name-tension` | `pick-side-A` / "Pick A" · `pick-side-B` / "Pick B" · `tension-itself` / "The tension itself is the problem" |
-
-## After the response
-
-Increment the turn counter `N` and return to the dialogue loop's turn-deck flow. The user's `choice` and `notes` flow into the next turn's framing.
-
-## Body content rules
-
-The deck `body` field uses `##` headings, bullet lists, and bold only — no tables, no code fences, no termrender directives. Violations fail `termrender --check` inside `parseDeck`.
-
-## Sanitize freetext on bail
-
-If you bail with the user's freetext in the message, sanitize it first:
-
-```bash
-safe_notes=$(printf '%s' "$notes" | tr -d '`$"\\')
-```
-
-Raw `"$notes"` in a shell-interpolated bail message is a defect.