@nurix/etna 0.18.23 → 0.18.24

package/data/harnesses/mobile/skills/brainstorm/SKILL.md

@@ -1,152 +0,0 @@
----
-name: brainstorm
-description: Thinking-partner session for designing software. Invoked ONLY by explicit slash commands `/brainstorm start` and `/brainstorm stop` — never auto-invoke on natural-language phrases like "let's plan", "let's design", or "let's think through X". Entry requires a basis (a reference document or a one-shot brain dump); drip-fed action items are rejected as too small. Runs one constant loop (distill → abstract → sync → record) across four modes (dump / interview / probe / converge), under a memory contract: the session folder is the only memory — both sides of the conversation are captured, distilled, self-contained. Coherence = zero open questions after a fresh pillar sync. Pillar count scales with a complexity dial; refuses production code outside the session folder while open.
-argument-hint: "start | stop"
----
-
-# Brainstorm
-
-Think with the user, then file — never the reverse. The artifacts exist to serve the conversation; the conversation never exists to populate artifacts. But the conversation is mortal — context compacts, sessions end — so the session folder is the **only memory**: everything the session produces lives there, distilled, or it doesn't survive (see **The memory contract**). The constant across every scale of idea is **the loop**; everything else — pillar count, ceremony, exit artifacts — scales with complexity.
-
-## The loop — every turn, every mode
-
-1. **Distill.** Fold what the user just said into the pillars, in _their_ framing, during the same turn.
-2. **Abstract.** Name the latent structure they implied but didn't state — entities and relationships ("an account has many leads" → `domain-model.md`), invariants, principles, terms. Offer at most one abstraction per exchange; it's a contribution, not a lecture.
-3. **Sync.** Keep the pillars consistent with each other and with the basis (see **The sync agent**).
-4. **Record.** The user's words land in the pillars in the turn they arrive — never accumulated for a session-end dump. Your own substance — analyses, diagnoses, recommendations with their reasoning, definitions, informed rejections — is on disk **by the next sync dispatch** at the latest; the dispatch-time filing checklist makes that mechanical (the memory contract, rule 1; **The sync agent**).
-
-Modes change _who drives_ and _how much gets asked_. The loop never stops.
-
-## The memory contract
-
-Write as if the transcript is already deleted — it will be. The folder must let a reader with zero context reconstruct the *thinking*, not just index the conclusions.
-
-1. **Both-sides capture.** Facilitator substance is session knowledge: any analysis, causal diagnosis, recommendation-with-reasoning, or definition delivered in chat lands in the folder **by the next sync dispatch** — that is the batch point; there is no other. The dispatch-time filing checklist (see **The sync agent**) is the forcing function. Test: if a chat message is still the only place a piece of knowledge lives when a sync dispatches, the contract was violated.
-2. **Distilled, never verbatim.** Capture is interpretation, not stenography: name the claim, the reasoning, and the implication. Record the general point and cite examples as examples — never promote one example into the frame. (Integrity copies demanded by rule 4 — printed enumerations, cited excerpts — are not stenography; the ban is on transcript-pasting.)
-3. **Evidence notes.** Research and analysis produced *during* the session — audits, studies, comparisons — land as dated files in `<folder>/evidence/` (from `templates/evidence.md`): what was examined, the distilled findings, and which question or decision each feeds. `basis/` holds frozen *inputs* only; the two never mix.
-4. **No naked pointers.** A pillar may not lean on anything undefined in-folder: an enumeration cited by number gets printed once; a term gets a one-line gloss or a glossary entry; an external citation carries an excerpt of its substance. A reader must never need the transcript or an external file to parse a pillar.
-5. **Eager rejections.** When the user knowingly declines an option you presented, materialize `rejected.md` then and there — the option *and the evidence it was declined against*. A deliberate call must never read later as an unexamined one.
-
-**After compaction:** re-enter from the folder alone (`state.md` first). Anything you still "remember" that isn't on disk is a leak — file it immediately.
-
-## Modes
-
-| Mode | Who drives | When | Behavior |
-| --- | --- | --- | --- |
-| **dump** | user | idea is in their head | No questions mid-stream. Distill live. After each chunk, reflect back: the shape, contradictions, implications. Distillation + reconciliation **is** active listening — never sit silent. |
-| **interview** | skill | idea is fuzzy | Question batches of 2–3 via `AskUserQuestion`, scoped to **one aspect at a time**. Distill each answer immediately. Questions derive from the basis and the pillars — never from a template inventory. |
-| **probe** | skill | idea is drafted, needs stress | Challenge it: flaws, edge cases, conflicts with `tech.md` / `doctrine.md` / the domain model. Each finding becomes a question (`Raised by: probe`) — file it and move on; don't demand resolution. |
-| **converge** | shared | closing in | Burn down open questions. `AskUserQuestion` allowed for picks. Each resolution → a decision with **Why** + **How to apply**, or an explicit park (backlog / non-goals). Ends with a mandatory fresh sync. |
-
-**Switching** is an explicit user word ("let me dump", "ask me questions", "poke holes", "let's converge"). On a strong signal — the user starts monologuing mid-interview, or answers every probe with "I haven't thought about it" — **offer** the switch in one line. Never seize it. Announce every shift in plain English: _"Switching to probe — I'll push on the sync-layer design. Say 'park' anytime."_
-
-## `start`
-
-First, consult the two indexes — never scan folders. `docs/research/Readme.md` lists **active** sessions; `docs/history/brainstorms/Readme.md` lists **harvested** ones. Match the topic against both: an active match → resume it (§3, reusing its folder); a harvested match → surface that prior exploration and ask whether to reopen it (move the folder back to `docs/research/{topic}-brainstorming/`) or branch a fresh topic; no match → a new session. Then:
-
-### 1. The entry gate
-
-A session needs substance before it opens. Ask for a **basis**: a reference document (path or URL), or a one-shot brain dump of the whole idea, right now, in prose.
-
-- Basis arrives → copy/save it into `<folder>/basis/` and proceed.
-- The user offers drip-sized input — a bug fix, a single button, small action items — say this skill is the wrong tool, recommend stopping, and **do not open the session** unless the user explicitly overrides.
-- No basis and no dump → no session.
-
-### 2. Read the basis, propose the frame
-
-Distill the basis _first_ — this seeds `thesis.md` and the initial questions. Then one `AskUserQuestion` batch:
-
-- **Complexity** — low / medium / high. The skill proposes from the basis; the user confirms. This sets the default pillar surface (see **Pillars**) and ceremony depth.
-- **Build mode** — "Is this greenfield, or are we changing something that exists?" (greenfield / brownfield / hybrid). The answer lands in `build.md` and opens or closes its execution sections — migration strategy and gotchas are brainstorm-phase concerns; surfacing them in plan mode is too late.
-- **Mode** — "Where is this idea right now — fully in your head (dump it), half-formed (I'll interview), or drafted and needing stress (I'll probe)?"
-
-Then propose the **aspect map**: the thinking dimensions for _this specific idea_ (e.g., for a product: users/jobs, domain model, architecture, tech, risks; for a small tool: behavior, interface, failure modes). Derive it from the basis — there is no fixed list. The user edits it; write it into `thesis.md`. The map is the coverage source for the sync audit.
-
-### 3. Bootstrap
-
-Session folder: `docs/research/{topic}-brainstorming/` — a **committed** design record, one folder per design topic (slug the topic; confirm it in one line). Add a row to the `docs/research/Readme.md` index. Resume an existing topic by reusing its folder if it already holds a `state.md`. The record lives here while the session is active; on close **and** harvest it moves to `docs/history/brainstorms/{topic}/` as the provenance the exit artifacts distil from (see `stop` and `exit-artifacts.md`). Create only the pillars the complexity calls for, from `templates/` (never overwrite existing files; if a template is missing, create the file from the field lists in **Pillars**). `basis/` holds the frozen inputs; `evidence/` materializes on the first session-produced analysis (memory contract, rule 3). Write top-level `state.md`:
-
-```
-STATE: open
-MODE: dump | interview | probe | converge
-COMPLEXITY: low | medium | high
-SESSION STARTED: <ISO date>
-CURRENT TOPIC: <one line>
-LAST SYNC: <ISO datetime or never>
-SYNC IN FLIGHT: no
-```
-
-Initial questions come from the basis distillation **only** — contradictions in the dump, gaps the aspect map exposes. Never interview to fill empty templates.
-
-## Pillars — substance first, lazy by default
-
-| Pillar | Holds | Exists |
-| --- | --- | --- |
-| `thesis.md` | What we're designing — running narrative, kept current + the aspect map | always |
-| `questions.md` | The **single convergence currency** — every unresolved design call, whoever raised it | always |
-| `decisions.md` | Resolved calls with **Why** + **How to apply** | always |
-| `build.md` | How the work gets executed: build mode (greenfield default / brownfield / hybrid), migration strategy, gotchas, rollout. Greenfield closes the execution sections; brownfield opens them | always |
-| `domain-model.md` | Entities, relationships, cardinalities, state ownership | medium+ |
-| `tech.md` | Stack choices, seeded from harness rules (e.g. `.claude/rules/general.md`) at bootstrap; deviations recorded with whys | medium+ |
-| `doctrine` / `glossary` / `non-goals` / `backlog` / `rejected` / `references` / `milestones` | as their templates describe | **lazy** — materialize on first real content, any complexity. `rejected` is the exception: the memory contract makes it **eager** — it materializes the moment an option is knowingly declined |
-
-The complexity dial sets _defaults_, not a cage: any lazy pillar materializes mid-session the moment the conversation produces content for it, and at **low** complexity the always-four may even live as sections of a single file if the user prefers.
-
-**Question entries** (`questions.md`): self-contained full prose in the user's framing, plus —
-
-- **Raised by.** user | sync | probe
-- **Closes when.** What resolution looks like — a pick, a confirmed fact, an accepted risk. Every question must be closeable.
-- **Options / Lean / Claude's take** — optional; _Claude's take_ remains opt-in (only when the user asks for a recommendation).
-
-**Decision entries** (`decisions.md`): append-only; **Decision**, **Why**, **How to apply**, **Resolves Q-N**. There is no tentative/committed state machine. Reversing a decision = append a new decision that names what it reverses, mark the old entry "Reversed by D-M", and let the next sync handle the ripples.
-
-## The sync agent
-
-The background reconciler that replaces ceremony with consistency. **One sync in flight at a time; queue at most one behind it.**
-
-**When:** after a distillation batch lands substantive pillar writes (at the turn break, not mid-sentence); mandatorily on entering converge and at `stop`; on demand. At **low** complexity, run it inline yourself; at **medium+**, dispatch a background `general-purpose` agent **on Opus** (`model: "opus"` — pillar reconciliation is quality-critical, so never a smaller model; and never the main-loop frontier model, whose session budget belongs to the conversation), with read/write access to the session folder only. Exception at any complexity: the `stop` sync's self-containment pass always dispatches the context-free agent — an inline reader with full conversational context cannot cold-read, because it already knows every undefined term.
-
-**The filing checklist — before every dispatch.** The sync agent cannot see the conversation, so the orchestrator runs the transcript-side half itself, immediately before dispatching: list your substantive contributions since the last sync — analyses, diagnoses, recommendations with reasoning, definitions, rejections — and file any that aren't on disk (evidence note, decision rationale, glossary line, rejected entry). Only then dispatch. A sync dispatched over unfiled substance audits an incomplete record and stamps it green.
-
-**Contract — audit exactly five sources:**
-
-1. **Cross-pillar contradiction** — thesis vs domain model vs decisions vs doctrine vs build (a decision that implies migration work with no `build.md` entry is a contradiction).
-2. **Aspect coverage** — any aspect on the map with no content anywhere → emit a question.
-3. **Basis drift** — does the thesis still agree with `basis/`? Divergence is fine if decided; accidental divergence → emit a question.
-4. **Tech conflicts** — anything that violates `tech.md` without a recorded deviation.
-5. **Self-containment** — read as the stranger you are: undefined terms, pointer-only references, enumerations cited by number but never printed, evidence a pillar leans on that no file carries, decided-vs-open ambiguity, citations of artifacts that no longer exist. Also the reverse direction: an evidence note nothing consumes gets a scribe-note in the report — never a question; filing an insight must never push the session away from coherent. The sync agent is dispatched context-free — it **is** the cold reader the memory contract writes for.
-
-**Output:** direct pillar edits for **scribe-calls**, new questions for **design-calls**, and a one-line report.
-
-**The line:** a _scribe-call_ is anything whose resolution doesn't change the design — wording, annotations, obvious bookkeeping, printing a missing enumeration, glossing an undefined term. Just do it; list it in the report (the user can veto). A _design-call_ is anything whose resolution changes the idea — file it as a question (`Raised by: sync`) and move on. **Never** interrupt the conversation to ask "apply now or defer?" — file and continue.
-
-**The report is the status line.** Deliver it at the next natural turn break:
-
-> Sync: 4 edits applied · 2 new questions · **6 open** · untouched aspects: risks
-
-There is no separate dashboard, no scheduled checkpoint. This line is the only ambient convergence pressure the skill applies.
-
-## Coherence
-
-```
-coherent ⇔ open_questions == 0 ∧ last sync ran after the last pillar write
-```
-
-Zero means _"audited against the five sources and clean"_ — never _"nothing came to mind."_ Don't declare the idea coherent on any other basis. Distance-to-coherent is always visible in the sync report; the **user** decides when to converge and when to close. The skill never says "let's decide now."
-
-## `stop`
-
-1. Run a final sync (wait for any in-flight sync first). It audits all five sources — self-containment included, so the record is verified standalone-readable exactly when it is about to become the only survivor of the session.
-2. **Coherent** → say so and proceed. **Questions open** → list them plainly (English first, codes in parentheses) and offer per question: resolve now (mini-converge) / park explicitly (backlog or non-goals, with reason) / leave open and stop anyway — the folder keeps full state and resumes exactly where it left off. Flag parked **self-containment** gaps distinctly: parking one means the record ships not fully standalone.
-3. **Publish exit artifacts** — see `exit-artifacts.md`. Offer the choice (`AskUserQuestion`, multi-select): a **source of truth** (one consolidated README-style doc — the standing reference for the thing designed), **plans** (executable work → `docs/history/plans/`), and/or **harvest into the living docs** (conclusions dispersed by scope into ADs — architecture decisions — the domain model, the backlog). The session record is **kept** (committed) whichever you pick — it is the provenance every artifact traces back to and the seed the next session resumes from.
-4. Write `STATE: closed` + one-line reason. If the harvest is complete (conclusions dispersed into the living docs), **move** the folder from `docs/research/{topic}-brainstorming/` to `docs/history/brainstorms/{topic}/` and update both indexes — drop its row from `docs/research/Readme.md`, add it to `docs/history/brainstorms/Readme.md`. If the session is only paused (questions parked, more to come), leave it in `docs/research/` and update its index row's status. Print: _"Run `/brainstorm start` to resume."_
-
-## Conduct — holds for the whole session
-
-1. **Speak English; codes live in files.** In conversation, name every pillar item by what it _is_ in plain words. Append the code in parentheses only when traceability needs it (_"…can a user change answer depth? (tracked as Q6)"_). Never lead with a bare `Q3`/`D7`. The user is not looking at the files.
-2. **No production code outside the session folder.** Illustrative load-bearing snippets are fine inside it (`samples/` or fenced in pillars). If asked for production code: offer a sketch inside the folder, or `/brainstorm stop` first.
-3. **The writing posture comes from `build.md`'s mode.** Greenfield: every pillar describes the system as it _will be_, present tense, as though the chosen design was always the plan — no migration vocabulary, no phantom history (banned list in `templates/build.md`). Brownfield/hybrid: migration vocabulary is legitimate, and `build.md` is its home; other pillars still describe the _target_ state.
-4. **`AskUserQuestion` appears in exactly four places:** the intake frame batch, interview mode, converge picks, and the `stop` exit-artifact pick. Everywhere else: prose.
-5. **Suggested, never seized.** Mode shifts, abstractions, probes — one offer each, accept refusal without re-litigating.
-6. **Nothing lives only in the transcript.** Questions are the only convergence currency — flaws, gaps, contradictions, uncovered aspects funnel into `questions.md` or they don't exist. The memory contract extends the same law from pending work to **knowledge**: analyses, reasoning, definitions, and rejections funnel into the folder or they don't exist.
-7. **No auto-invocation.** Only `/brainstorm start` and `/brainstorm stop` enter or leave a session. Read `state.md` at the start of every turn while a session folder exists.

package/data/harnesses/mobile/skills/brainstorm/exit-artifacts.md

@@ -1,66 +0,0 @@
-# Exit artifacts
-
-What `/brainstorm stop` publishes from a closed session. The session record is **kept
-either way** — committed provenance, never a scratchpad. Exit artifacts copy the session's _conclusions_
-outward into the form the work needs; the record stays as the source they trace back to — and, once
-harvested, moves from `docs/research/{topic}-brainstorming/` to `docs/history/brainstorms/{topic}/`.
-
-At `stop`, after the final sync, **offer the artifact choice** (`AskUserQuestion`, multi-select — a session
-can publish more than one):
-
-| Artifact | Use when the outcome is… | Lands in | Voice |
-| --- | --- | --- | --- |
-| **Source of truth** | a standing reference — "what this thing **is**" | the repo's feature/architecture doc home, else a topic `Readme.md` | README — present tense, reader-first (`templates/source-of-truth.md`) |
-| **Plans** | work to execute — "what to **build**, in what order" | one or more `docs/history/plans/YYYY-MM-DD-{slug}.md` (Status: Draft) | plan — steps, sequencing, status |
-| **Harvest into living docs** | findings that belong inside an existing doc system | dispersed by scope (table below) | matches each destination |
-
-A session commonly emits a **source of truth** for the thing designed _and_ **plans** for building it.
-Picking "source of truth" does **not** also disperse headlines across the doc tree — that is what "harvest"
-does; pick it too if you want both the one-doc reference and the integrated headlines.
-
-## Source of truth
-
-One consolidated, README-style document — the canonical reference for the thing designed. Distil every
-pillar into it: `thesis.md` → what it is; `domain-model.md` → how it works + parts; `decisions.md` →
-present-tense rationale (no `D-N` codes, no options-considered — those stay in the record and ADs);
-`non-goals.md` + accepted tradeoffs → constraints; still-open questions → a one-line pointer back to the
-record. Template: `templates/source-of-truth.md`.
-
-Place it at the repo's canonical home for that kind of knowledge: a feature/system → `docs/features/{slug}.md`
-(carry the doc system's `owns:` / `module:` / `keywords:` / `status:` frontmatter); cross-cutting →
-`docs/architecture/{slug}.md`; no doc taxonomy → a `Readme.md` at the topic's folder. One document — if a
-section outgrows it, link out rather than sprawl.
-
-## Plans
-
-One or more executable plan docs in `docs/history/plans/` (Status: Draft), authored to the `documentation`
-skill's §8 Plan template. Source: the `thesis.md` narrative for scope, `build.md` for migration strategy /
-gotchas / rollout (execution content is plan content, not architecture). Split by deliverable, not by pillar
-— one plan per cohesive unit of work.
-
-## Harvest into living docs
-
-A structured diff between the session pillars and the live docs, dispersed by scope. Modules are labels,
-not folders — a finding scoped to one module still lands in `docs/architecture/` and names the module in prose.
-
-| Session source | Destination |
-| --- | --- |
-| Decisions (any scope) | one AD per decision subject → `docs/architecture/decisions/AD-NNN-{slug}.md` (`documentation` skill AD template; `status:` frontmatter is the lifecycle source of truth; rejected alternatives → the AD's Options Considered table). A decision that revises an already-recorded subject does **not** mint a new AD — update that AD's body in place and append the revision to its Decision Changelog |
-| `domain-model.md` | `docs/architecture/domain-model.md`; note any IA / cross-cutting contract change there — the `boundary` skill reads it from source at the next plan check |
-| Doctrine / glossary / rejected | `docs/architecture/{domain-model,glossary}.md`, or the relevant AD |
-| `tech.md` deviations | `docs/architecture/references.md` or the relevant AD |
-| `non-goals.md` / `references.md` | `docs/architecture/{non-goals,references}.md` |
-| `backlog.md` | `docs/history/backlog.md` (P0–P3) |
-| Still-open questions | `docs/architecture/open-questions.md`, each with a _Resolution lands in_ pointer |
-
-Append a changelog entry at `docs/history/changelog/YYYY-MM-DD-brainstorm-{slug}.md` listing what was published where.
-
-## After publishing — move the record to history
-
-**Move `docs/research/{topic}-brainstorming/` → `docs/history/brainstorms/{topic}/`, and update both
-`Readme.md` indexes** (drop the row from `docs/research/Readme.md`, add it to
-`docs/history/brainstorms/Readme.md`). The exit artifacts now carry the distilled conclusions; the record
-itself is **kept** — never deleted — but as harvested provenance it belongs under `docs/history/brainstorms/`:
-a traceable source for every published headline, and the seed the next `/brainstorm start` on this topic
-resumes from. A session that is only **paused** (not harvested) stays in `docs/research/`. Retire a topic's
-folder by hand only when the design line is truly dead.

package/data/harnesses/mobile/skills/brainstorm/templates/backlog.md

@@ -1,39 +0,0 @@
-# Backlog
-
-This file is the **forward-looking list of deferred-but-planned items** — work the team intends to build, but not in the current scope. It complements `non-goals.md` (which holds the scope-creep guards: things we are **not** building) and `rejected.md` (which holds paths we considered and chose against). Use the right pillar:
-
-| Pillar | Semantics |
-| --- | --- |
-| `backlog.md` (this file) | "We **will** build this, just **later**." Deferred to a known future milestone. Roadmap forward. |
-| `non-goals.md` | "We deliberately are **not** building this." Scope guard. May never be built. |
-| `rejected.md` | "We considered this path and chose another." Past-tense alternative. |
-
-If you can't tell which file an item belongs in, ask: _"Is the plan to build this eventually?"_ If yes → backlog. If no but could change → non-goals. If we already weighed it against an alternative → rejected.
-
-Backlog items carry four load-bearing fields. **Target milestone** names the future bucket (`v1.1`, `M2`, `TBD`); **Why deferred** explains the reason it isn't in the current scope (commonly: scope cut, depends on something else, waiting for user feedback, lower priority than current work); **Scope** sketches what the item actually includes — enough that a future planner can pick it up cold; **Re-evaluate when** is the trigger that promotes it from backlog to active work.
-
-When a backlog item is promoted (its milestone comes due), **delete it from this file** and either (a) seed a new round of intake questions in `questions.md` for the new scope, or (b) move the spec into a plan doc if the design is already mostly clear. Don't strikethrough, don't leave a "(promoted)" marker — same hygiene as resolved questions and triggered non-goals.
-
-If a backlog item turns out to be unworkable or unneeded, move it to `rejected.md` (not deleted silently) with the reason.
-
----
-
-## B1 — [Title]
-
-**Target milestone.** [v1.1 / M2 / TBD]
-
-**Why deferred.** [The reason it isn't in current scope. Be specific: "scope cut to ship M0 by Q3"; "depends on X landing first"; "waiting for user feedback on whether this is actually needed"; "lower priority than the M0 critical path".]
-
-**Scope.** [What this item actually includes when it eventually gets built. Sketch enough that a future planner can pick it up cold. Bullet points are fine.]
-
-**Depends on.** [Optional. Other backlog items, milestones, or upstream features that need to land first. Drop the field if nothing.]
-
-**Re-evaluate when.** [The trigger that promotes this from backlog to active work. Tie to a milestone boundary, a metric, or an external event.]
-
----
-
-## B2 — [Title]
-
-(same format)
-
----

package/data/harnesses/mobile/skills/brainstorm/templates/build.md

@@ -1,37 +0,0 @@
-# Build
-
-This pillar holds **how the work gets executed** — decided during brainstorming, not deferred to plan mode. Migration constraints and execution gotchas discovered late invalidate designs; surfacing them here, while the design is still fluid, is the point.
-
-At `start` the skill asks: _"Is this greenfield, or are we changing something that exists?"_ The answer sets **Mode** below and opens or closes the execution sections. The sync agent treats this file as a contradiction source — a decision that implies migration work with no entry here raises a question.
-
-## Mode
-
-`greenfield` _(default)_ | `brownfield` | `hybrid`
-
-- **greenfield** — nothing built yet: no production deploys, no users, no legacy code. The execution sections below are closed — mark them _Not applicable (greenfield)_. **Writing posture:** all pillars describe the system as it _will be_, in present tense, as though the chosen design was always the plan. Banned: "replaces" / "supersedes" / "previously" / "formerly" / "no longer" / "originally proposed" / `~~strikethrough~~` / "(resolved)" markers — the reader has no past, so don't reference one. Past tense lives only in `decisions.md`, `rejected.md`, `references.md`, and git history.
-- **brownfield** — the idea changes a system that already exists. All sections below are live, and migration vocabulary — "replaces", "currently", "migrate from" — is legitimate and load-bearing **in this file**. Other pillars still describe the _target_ state in present tense; the journey from here to there lives here.
-- **hybrid** — a new surface attached to a live system (a new module in a shipping product). The sections below apply to the seams only: integration points, shared state, contract changes. The new surface itself follows greenfield posture.
-
-## Current state
-
-_(brownfield/hybrid)_ What exists today, as relevant to the change. Link code paths or docs rather than restating them.
-
-## Target state
-
-One or two orienting sentences — cross-reference `thesis.md` rather than duplicating it.
-
-## Migration strategy
-
-How we get from current to target: phases, order of operations, coexistence windows, rollback points. Harvest routes this section into the implementation plan.
-
-## Gotchas
-
-Execution hazards known _now_, before plan mode — each one a bullet with why it bites:
-
-- [e.g. data backfill must run before the new index exists, or reads 404 during the window]
-- [e.g. auth cutover can't be phased — sessions are shared, it's all-or-nothing]
-- [e.g. the event consumer is not idempotent; dual-write window will double-process]
-
-## Rollout & risks
-
-Sequencing, feature flags, kill switches, and the failure modes each phase accepts.

package/data/harnesses/mobile/skills/brainstorm/templates/decisions.md

@@ -1,29 +0,0 @@
-# Decisions
-
-This file is the **append-only ledger of resolved decisions**, with the reasoning future-you needs to judge edge cases.
-
-Load-bearing fields:
-
-- **Decision** — what was decided, in one or two sentences.
-- **Why** — the motivation: a constraint, an incident, a deadline, a stakeholder ask. Without the _why_, decisions decay into rules no one understands.
-- **How to apply** — when and where this decision shapes future work. Name the files, layers, or situations where it kicks in.
-
-There is no tentative/committed state machine. A decision is a decision the moment it's written; the next sync handles its ripples. **Reversing** a decision = append a new decision that names what it reverses, add a one-line `Reversed by D-M (YYYY-MM-DD)` note to the old entry, and let the sync raise questions for anything downstream.
-
-This ledger is one of the places where past tense is permitted (with `rejected.md`, `references.md`, `build.md`'s execution sections, and git history).
-
----
-
-## D1 — [Title]
-
-**Decision.** [What was decided.]
-
-**Why.** [The motivation future-you needs.]
-
-**How to apply.** [Where this rule kicks in — be specific.]
-
-**Resolves.** Q1 (deleted from `questions.md`).
-
-**Alternatives considered.** _(optional — reference `rejected.md` if substantial)_
-
-**Reverses.** _(only when this decision reverses an earlier one — name it and say what changed)_

package/data/harnesses/mobile/skills/brainstorm/templates/doctrine.md

@@ -1,31 +0,0 @@
-# Doctrine
-
-This file holds **stable principles that pre-answer future questions**. When a new question arises during a brainstorm, check here first — the doctrine may already settle it without a full debate.
-
-Doctrine entries should be **rare and durable**. They are not preferences ("I like Postgres") and not one-off picks ("we picked Temporal for this project"). They are statements that apply across many decisions: _"we never self-host stateful services in M0–M3 because operating burden outweighs cost savings at our scale."_ A doctrine that gets revised every other week isn't doctrine — it's a preference in disguise. Demote it to `decisions.md`.
-
-Add to doctrine only when a principle has either (a) been validated across multiple decisions in this project or others, or (b) is imposed from outside (compliance, vendor lock-in, team size) and won't change without a major shift. Doctrine pre-empts argument; if you're not confident the principle will hold for the next six months, don't write it here.
-
-Each entry carries **Principle** (the one-line statement), **Why** (the reason this is principle, not preference — often a past incident, a hard constraint, or an accepted tradeoff), and **Applies when** (the triggers, so a reader recognizes "ah, this is a doctrine question" rather than re-debating from scratch). An optional **Exceptions** field is allowed but suspicious — if a principle has many exceptions, it's mis-stated.
-
-Examples of real doctrine entries from past projects: _"Temporal IS the trace — no separate APM tool."_ — _"No Terraform; deploys are wrangler + GitHub Actions only."_ — _"Secrets only via wrangler, never in code or env files."_ — _"Buy-not-build for non-core capabilities until paying-customer signal justifies otherwise."_
-
----
-
-## P1 — [Principle name]
-
-**Principle.** [One-line statement of the rule.]
-
-**Why.** [The reason this is a principle, not a preference. Often a past incident, a hard constraint, or a tradeoff the team has already accepted.]
-
-**Applies when.** [Triggers — situations where this principle should be invoked.]
-
-**Exceptions.** [Optional. Cases where the principle deliberately does not apply. If you find yourself listing many exceptions, the principle is probably mis-stated.]
-
----
-
-## P2 — [Principle name]
-
-(same format)
-
----

package/data/harnesses/mobile/skills/brainstorm/templates/domain-model.md

@@ -1,25 +0,0 @@
-# Domain model
-
-This file holds the **information architecture** of the idea: entities, relationships, cardinalities, and who owns what state. This is where facts like "an account has many leads" land the moment they're said — they are neither principles (`doctrine.md`) nor terms (`glossary.md`), and they must not be lost to the transcript.
-
-The loop's _abstract_ step feeds this file: when the user implies structure without naming it, propose the entry here.
-
-## Entities
-
-### [Entity]
-
-[One paragraph: what it is, what state it owns, where it lives (client / server / external system).]
-
-## Relationships
-
-| From | To | Cardinality | Notes |
-| --- | --- | --- | --- |
-| Account | Lead | 1 : N | [e.g. leads cannot transfer between accounts — see D3] |
-
-Cardinality changes are design changes — when one shifts, expect the sync to raise questions against routing, storage, and milestones.
-
-## Invariants
-
-Rules the model must always satisfy, stated as present-tense facts:
-
-- [e.g. Every lead belongs to exactly one account at any point in time.]

package/data/harnesses/mobile/skills/brainstorm/templates/evidence.md

@@ -1,24 +0,0 @@
-# Evidence — [what was examined]
-
-This file is a **session-produced analysis** — research, an audit, a study, a comparison — captured under the memory contract: distilled findings, not a log. One file per analysis, dated, in `<session>/evidence/`. (`basis/` is for frozen *inputs* the session started from; evidence is what the session itself produced.)
-
-Every evidence note should **feed** something — a question it informs, a decision it grounds, or, for free-floating insight, the thesis aspect it belongs to. The sync agent notes unconsumed evidence in its report as a scribe-note, never a question — filing an insight must never push the session away from coherent.
-
-Write for a reader with zero context: define terms, print the numbers, excerpt sources. Distill — name the claim, the reasoning, the implication; never paste transcripts or raw tool output.
-
----
-
-**Date.** YYYY-MM-DD
-
-**Examined.** [What was analyzed and how — the sources, the method, one or two lines.]
-
-**Feeds.** [Q-N / D-N — or `aspect: <name>` from the thesis map when no specific question or decision consumes it yet.]
-
-## Findings
-
-- [Distilled finding 1 — the claim, with the number/citation that carries it.]
-- [Distilled finding 2.]
-
-## Implication
-
-[What this means for the design — one short paragraph. If it changes a lean or closes an option, say so and point at the question/decision entry that records it.]

package/data/harnesses/mobile/skills/brainstorm/templates/glossary.md

@@ -1,20 +0,0 @@
-# Glossary
-
-This file collects **terms with project-specific meaning** — words whose definition in this project diverges from their general industry sense, or whose meaning is short and opaque enough that re-explaining it across docs wastes time.
-
-The glossary exists to prevent the quietest and most expensive kind of design drift: two collaborators using the same word for different things. By the time you notice — usually mid-implementation — the cost of resolving the ambiguity is much higher than the cost of writing the entry that would have prevented it. So when you catch yourself saying "by X I mean…" for the second time, add the entry.
-
-Do **not** catalog every term. Add to the glossary only when:
-
-- A term has been used to mean two different things in the same session.
-- A term's meaning here diverges from the standard industry sense (e.g., `subscriber` meaning a webhook destination rather than a pub/sub consumer).
-- A short term names a specific concept that would otherwise need re-defining across docs (e.g., a node category name, an internal product term).
-
-Entries are intentionally terse: one term, one line of meaning. Long explanations belong in plan docs or `decisions.md`.
-
----
-
-| Term | Meaning |
-| --- | --- |
-| (example: `studio`) | the canonical task queue for non-publish work — see `04-runtime.md` |
-| (example: `subscriber`) | a webhook destination registered against an event kind, distinct from a `webhook` which is the inbound side |

package/data/harnesses/mobile/skills/brainstorm/templates/milestones.md

@@ -1,43 +0,0 @@
-# Milestones
-
-This file holds **sequencing only** — what ships in what order, with the dependencies that justify the order. Scope of each milestone lives in the plan docs; this file is the schedule.
-
-Every milestone names three things: a **Goal** (one line — what this milestone proves or unlocks), **Depends on** (the prior milestones, or "nothing" for M0), and **Open questions** (Q-numbers from `questions.md` that must be resolved before this milestone can start). The open-questions list is what makes a milestone "ready to start" — when the list is empty, the milestone is unblocked.
-
-The **Ships** field captures the concrete artifact: "auth + empty dashboard deployed to staging" is useful; "MVP foundation" is not. Concrete ship definitions make it visible when a milestone has crept.
-
-Order matters and the order is enforced by `Depends on`. If you ever notice that M3 could ship before M2, the sequencing is wrong — fix it here. Milestones do not exist to chunk work into nice-sized bites; they exist to make dependency order explicit so the team can parallelize what's parallelizable and serialize what isn't.
-
-When a milestone ships, do **not** mark it "complete" with a strikethrough or "(shipped)" marker. The plan docs for that milestone should already describe the steady state in present tense; the milestone entry stays here as schedule, not as history. (Git tags and PR history capture "what shipped when" — this file is forward-looking.)
-
----
-
-## M0 — [Name]
-
-**Goal.** [One-line — what this milestone proves or unlocks.]
-
-**Depends on.** Nothing (this is the start).
-
-**Open questions.** Q1, Q2, Q3 — see `questions.md`.
-
-**Ships.** [Concrete deployed artifact.]
-
----
-
-## M1 — [Name]
-
-**Goal.** [One-line.]
-
-**Depends on.** M0.
-
-**Open questions.** Q4, Q5 — see `questions.md`.
-
-**Ships.** [Concrete deployed artifact.]
-
----
-
-## M2 — [Name]
-
-(same format)
-
----

package/data/harnesses/mobile/skills/brainstorm/templates/non-goals.md

@@ -1,17 +0,0 @@
-# Non-goals
-
-This file is the **explicit list of things we are not building** in the current scope, with the reason for each. It is the mirror of the scope described in `thesis.md`: where the thesis says "this is what we're building", non-goals say "this looked plausible but is deliberately out". Distinguish it from `backlog.md` (things we _will_ build, just later) — a non-goal may never be built.
-
-Non-goals carry real weight. Every entry here is a constraint that future decisions should respect — a scope-creep guard. The reason field is load-bearing: without it, a non-goal looks like an arbitrary "no" that future-you will second-guess at the first complication. With the reason, future-you knows whether the non-goal still holds when circumstances change.
-
-Each non-goal should include a **Re-evaluate when** clause where applicable. Non-goals are not permanent vows; they are scope decisions tied to current constraints. When the constraint changes (a customer signs in a new region, a competitor ships the feature, infrastructure costs drop), the non-goal may move into scope. The re-evaluate clause names the trigger so the team doesn't carry a stale non-goal forever.
-
-At milestone boundaries, scan this file. If a non-goal's re-evaluate trigger has fired, fold the item into scope (`thesis.md`, or `backlog.md` if it's planned-but-later) and delete the non-goal entry here — do not strikethrough, do not leave a "(promoted)" marker.
-
----
-
-- **No multi-region writes in M0.** _Reason:_ cost > benefit until 3+ paying customers in distinct regions. _Re-evaluate when:_ second paying customer signs in a non-primary region.
-
-- **No mobile app.** _Reason:_ product hypothesis is desktop-first; no validated mobile demand. _Re-evaluate when:_ >20% of dashboard sessions are mobile UA.
-
-- (add more here)

package/data/harnesses/mobile/skills/brainstorm/templates/plan-doc.md

@@ -1,61 +0,0 @@
-# NN — [Domain name]
-
-> This is a **plan doc**, not a pillar. It describes one domain of the system (e.g., runtime, storage, ingress) in present tense, as if the chosen design were always the plan. Plan docs do not host their own "open questions" sections — those live in `pillars/questions.md`. Plan docs do not narrate the design journey — that lives in `pillars/decisions.md` and `pillars/rejected.md`. Plan docs describe what the system is.
->
-> Number plan docs sequentially: `01-foo.md`, `02-bar.md`, ... Each plan doc owns one domain. If a section grows past ~500 lines, split it into two plan docs rather than letting it sprawl.
->
-> Cross-reference other plan docs with `see 04 §3.2` — pointer, not duplicated content.
-
----
-
-## On versioning iterations
-
-If this plan doc goes through a substantial rewrite (decision reversal, structural shift, ≥3 sections change together), preserve the evolution by saving a new version as `NN-domain-v0.X.md` rather than overwriting. Examples:
-
-```
-01-architecture-v0.1.md       ← initial draft
-01-architecture-v0.2.md       ← second draft after architecture change
-01-architecture-v0.3.md       ← current draft (the one to read)
-```
-
-Each version stays in the folder. Readers can follow v0.1 → v0.2 → v0.3 in order to see exactly how the design evolved. The current version's top-of-file frontmatter or first line notes its status:
-
-```markdown
-# 01 — Architecture (v0.3)
-
-> **Status:** Current draft. Supersedes v0.1 and v0.2. v0.4 will narrow content.
-```
-
-Skip versioning for small edits (typos, single-section polish, find-and-replace). The versioning pattern is for substantial rewrites that warrant a separate readable artifact.
-
-The `stop` step in the brainstorm offers to prune older versions if you want to simplify the final handoff. Keeping them preserves the design rationale across long sessions; pruning them produces a clean steady-state.
-
----
-
-## 1. What this is
-
-[One paragraph in present tense describing what this domain is, what it does, and who depends on it. No "we decided" framing, no comparisons to alternatives.]
-
-## 2. Components
-
-[Subsystems, services, or modules inside this domain. Each gets a subsection with: name, role, what it owns, what it depends on. Diagrams are OK if they help.]
-
-## 3. Interfaces
-
-[How other domains interact with this one. APIs, queues, events, file formats. Stable contracts only — speculative ones go in `pillars/questions.md`.]
-
-## 4. Constraints accepted
-
-[Tradeoffs that shape the design. Phrased as current fact: "we accept a 5-second lag for predictable throughput", not "we considered streaming but chose batch".]
-
-## 5. Future scope (optional)
-
-[Cleanly labelled phase-2 ideas. Not framed as migrations. Skip the section if there's nothing here.]
-
----
-
-## Open questions for this domain
-
-See [`pillars/questions.md`](./pillars/questions.md): Q-N, Q-M, ...
-
-(One line, never more. The plan doc never hosts question bodies.)

package/data/harnesses/mobile/skills/brainstorm/templates/questions.md

@@ -1,36 +0,0 @@
-# Open Questions
-
-This file is the **single convergence currency** of the session. Every unresolved design call lives here and only here — whether the user raised it, the sync agent found it, or a probe surfaced it. Plan docs and pillars never host their own questions; they link back here.
-
-The session is **coherent** exactly when this file is empty after a fresh sync. That makes hygiene load-bearing:
-
-- Every entry must be **closeable** — the `Closes when.` field says what resolution looks like. Vague musings are not questions; distill them until they're closeable or leave them in the conversation.
-- Only **design-calls** belong here — items whose resolution changes the idea. Editorial bookkeeping is the sync agent's job, applied directly and noted in its report.
-- A resolved question is **deleted** (its decision lives in `decisions.md`). A parked question is deleted too, with an explicit entry in `backlog.md` or `non-goals.md`. No strikethrough, no "(resolved)" markers.
-
-Each question is **self-contained**: full text in the user's framing, readable without opening another doc. Group under `## Category` headers when the list grows past ~10.
-
-IDs are `QN`, stable while open, never reused after deletion.
-
----
-
-## Q1 — [Title in the user's words]
-
-**Question.** [Full prose — paraphrase what the user said, or state the contradiction/gap the sync found. Repeat context; a future reader should need nothing else.]
-
-**Raised by.** user | sync | probe
-
-**Closes when.** [What resolution looks like — a pick between options, a confirmed fact, an accepted risk.]
-
-**Options.** _(optional — only when named by the user or entering converge)_
-
-- A. [one line]
-- B. [one line]
-
-**Lean.** _(optional — the user's lean, never the skill's)_
-
-**Claude's take.** _(opt-in only — write only when the user asks for a recommendation on this question; delete if it goes stale)_
-
-**Resolution lands in.** _(optional)_ [pillar or doc + section]
-
-**Blocks.** _(optional)_ [milestone or other Q-numbers]