@nurix/etna 0.19.0 → 0.19.2

package/data/harnesses/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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/etna/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]

package/data/harnesses/etna/skills/brainstorm/templates/references.md

@@ -1,28 +0,0 @@
-# References
-
-This file collects **external prior art** — repos, docs, papers, talks — with one-line pointers to what we use each for. Reference implementations beat invented solutions: if someone has already solved the problem you're about to design, the right move is to link it here and use it, not re-derive.
-
-References are not bookmarks. Every entry should answer the question "what specific pattern, idea, or implementation do we lift from this?" A reference without that grounding decays into noise. If you can't write the one-line "what we use it for", you probably don't need the entry.
-
-References to **source materials** copied into `./plan/sources/` during the session also live here — point at the local copy, not the original location. This keeps the brainstorm self-contained.
-
-When a referenced thing changes (renames, moves, deprecation), **update or remove the entry**. A stale reference that no longer points at what the description claims is worse than no reference — it teaches the reader to distrust the file.
-
----
-
-## Internal repos / paths
-
-- `~/path/to/repo` — [what pattern we borrow]
-- `~/path/to/another` — [what pattern we borrow]
-
-## Source materials (this session)
-
-- `./plan/sources/[file]` — [original location, why it's relevant]
-
-## External docs
-
-- `https://example.com/foo` — [what we use it for]
-
-## Papers / talks
-
-- [Title] — [link or citation] — [the specific idea we're applying]

package/data/harnesses/etna/skills/brainstorm/templates/rejected.md

@@ -1,33 +0,0 @@
-# Rejected alternatives
-
-This file captures **paths that were considered and rejected**, with the reason for rejection. Its purpose is to prevent re-litigation: when someone proposes the same alternative six weeks later, this file answers "we already looked at that; here's why we didn't go that way."
-
-Each entry needs four load-bearing parts: **Considered** (what was proposed, in concrete terms), **Evidence on the table** (what prior art, findings, or arguments were in front of the decider when they declined — this is what separates an informed rejection from an unexamined one), **Rejected because** (the specific reason — "didn't fit" is useless to future-you; name the constraint, the cost, the risk), and **Re-evaluate if** (what would need to change for the rejected path to become viable again). The re-evaluate field stops the rejection from looking permanent when it isn't — most rejections are scope-conditional, not absolute.
-
-This file is **eager**, not lazy (the memory contract): it materializes the moment the user knowingly declines a presented option, in the same turn — an informed rejection that lives only in the transcript is a leak.
-
-This is one of the four places inside the brainstorm folder where past tense and "we considered X" framing is permitted (the others: `decisions.md`, `references.md`, git history). The whole point of this file is to capture the path-not-taken so future architects don't have to re-discover it.
-
-If circumstances change and a rejected path becomes attractive again, **do not silently revive it**. Add a new question to `questions.md` that references the rejection here, and resolve it explicitly. The new decision can override the rejection — but it should override, not pretend the rejection never happened.
-
----
-
-## R1 — [Rejected option]
-
-**Considered.** [What was proposed.]
-
-**Evidence on the table.** [The prior art, findings, or arguments in front of the decider at the moment of declining — cite the evidence note or basis file if one carries it.]
-
-**Rejected because.** [The reason. Be specific.]
-
-**Re-evaluate if.** [What would change to make this viable.]
-
-**Came up during.** [Q-number or D-number for context.]
-
----
-
-## R2 — [Rejected option]
-
-(same format)
-
----

package/data/harnesses/etna/skills/brainstorm/templates/source-of-truth.md

@@ -1,49 +0,0 @@
-# [Thing] — source of truth
-
-> This is a **source-of-truth doc**: the standing, canonical reference for [thing]. Write it like a
-> README — present tense, reader-first, the thing described as it _is_. It is **not a plan** (no steps,
-> status, or sequencing — those go to `docs/history/plans/`) and **not the brainstorm record** (no
-> `Q-N`/`D-N` codes, no "Why / How to apply" ledger, no rejected alternatives — those stay in the harvested
-> record at `docs/history/brainstorms/{topic}/` and any ADs). One document; if a section outgrows it, link out, don't sprawl.
->
-> **Placement.** In a repo with a feature-doc system this lands as `docs/features/{slug}.md` and carries
-> that system's frontmatter (`owns:` / `module:` / `keywords:` / `status:`). Cross-cutting → `docs/architecture/{slug}.md`.
-> No doc taxonomy → a `Readme.md` at the topic's home.
-
-## What it is
-
-[One paragraph, present tense: what the thing is, what it does, who uses it. Distilled from `thesis.md`.]
-
-## How it works
-
-[The model — entities, relationships, the main flow — lifted from `domain-model.md` into plain,
-reader-first description. Prose and tables; a diagram only if it earns its tokens.]
-
-## Parts
-
-[One row per component / module / piece: name · role · what it owns · what it depends on.]
-
-| Part | Role | Owns | Depends on |
-| --- | --- | --- | --- |
-|  |  |  |  |
-
-## Why it's shaped this way
-
-[The load-bearing decisions, folded into present-tense rationale — "the index is single-writer because
-concurrent writes corrupted it," not "we decided X over Y." No decision codes, no options-considered
-table. The full rationale and the roads not taken live in the brainstorm record and ADs — cite them,
-don't reproduce them.]
-
-## Constraints & non-goals
-
-[Accepted tradeoffs phrased as current fact ("a 5-second lag is accepted for predictable throughput")
-and what is explicitly out of scope.]
-
-## Open questions
-
-[One line pointing at `docs/history/brainstorms/{topic}/questions.md` if any remain open. Omit if none.]
-
----
-
-_Distilled from `docs/history/brainstorms/{topic}/`. That record holds the rationale, the rejected alternatives,
-and the provenance for everything above._

package/data/harnesses/etna/skills/brainstorm/templates/state.md

@@ -1 +0,0 @@
-STATE: open MODE: dump COMPLEXITY: medium SESSION STARTED: YYYY-MM-DD SESSION CLOSED: CURRENT TOPIC: (one line — updated on every topic shift) LAST SYNC: never SYNC IN FLIGHT: no

package/data/harnesses/etna/skills/brainstorm/templates/tech.md

@@ -1,23 +0,0 @@
-# Tech
-
-This file holds the **technology choices** for the idea. It is seeded at bootstrap from the harness's opinionated stack (e.g. `.claude/rules/general.md` recommended-packages table) when one exists — those rows arrive as defaults, not decisions.
-
-Its job afterward is to be a **lens**: when a conversation move conflicts with a row here, the sync (or the skill, in the moment) surfaces it — _"you just proposed local component stores; the stack says Redux Toolkit — deviating or steering back?"_ A confirmed deviation gets recorded below with its why; an unconfirmed conflict becomes an open question.
-
-## Stack
-
-| Layer        | Choice             | Source                      |
-| ------------ | ------------------ | --------------------------- |
-| [e.g. UI]    | [react ^19]        | harness default             |
-| [e.g. state] | [@reduxjs/toolkit] | harness default             |
-| [layer]      | [choice]           | decided this session — D[n] |
-
-## Deviations
-
-Each deviation from a harness default carries a why:
-
-### [Choice] instead of [default]
-
-**Why.** [Constraint, requirement, or incident that justifies the deviation.]
-
-**Scope.** [Whole project, or only a named module/surface.]

package/data/harnesses/etna/skills/brainstorm/templates/thesis.md

@@ -1,21 +0,0 @@
-# Thesis
-
-This file is the **running narrative of what we are designing** — the single place a cold reader (or the next session) goes to understand the idea as it currently stands. It is rewritten freely as the idea evolves; it always describes the _current_ shape, never the journey (writing posture per `build.md`'s mode).
-
-Keep it prose-first. If a section outgrows this file at high complexity, it may move to a numbered deep-dive doc (`01-foo.md`) at the session root with a one-line pointer left here.
-
-## What this is
-
-[2–5 paragraphs. What the thing is, who it's for, what it does. Distilled from the basis at `start` and kept current by the loop.]
-
-## Aspect map
-
-The thinking dimensions for _this_ idea — proposed by the skill from the basis, edited by the user at `start`. The sync agent audits coverage against this list: an aspect with no content anywhere becomes an open question.
-
-- [ ] [aspect — e.g. users & jobs]
-- [ ] [aspect — e.g. domain model]
-- [ ] [aspect — e.g. architecture]
-- [ ] [aspect — e.g. tech]
-- [ ] [aspect — e.g. risks]
-
-Check an aspect only when it has real content in the pillars, not when it has merely been mentioned.