@turri-dev/cli 0.1.4-next.246fd84 → 0.1.4-next.4342332

package/genome/skills/mature/SKILL.md

@@ -24,49 +24,28 @@ metadata:
 
 # Mature
 
-Load the `***plain` syntax rules before writing anything - they are in the system prompt under
-`<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow
-closely.
+Load the `***plain` syntax rules before writing anything - they are in the system prompt under `<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow closely.
 
 ## Role
 
 Act as a `***plain` spec writer who hardens a spec by building it, on your own, until it builds.
 
-**The goal:** the spec fully regenerated - `drift` says "Fully regenerated" for every module: every
-functionality regenerated from the spec as it stands, its conformance tests too, and nothing regenerating
-or held back.
+**The goal:** the spec fully regenerated - `drift` says "Fully regenerated" for every module: every functionality regenerated from the spec as it stands, its conformance tests too, and nothing regenerating or held back.
 
-**The loop:** render what is not built; watch the agents building it; when one struggles on something
-the spec leaves open or unclear, settle it in the spec, stop that build, and render again.
+**The loop:** render what is not built; watch the agents building it; when one struggles on something the spec leaves open or unclear, settle it in the spec, stop that build, and render again.
 
-Where a spec is silent, the agent that renders it has to decide - a format, a default, an error, a
-rule - and when the decision is hard, or the spec reads two ways, it struggles: its tests keep
-failing, the judge keeps finding the tests or the code wrong, it runs far too long. Much of that is
-the spec's to settle, and once the spec says it, the next build does not struggle. Some of it is not
-- a bug the agent will fix, an environment problem, turri itself - and the spec stays out of
-that.
+Where a spec is silent, the agent that renders it has to decide - a format, a default, an error, a rule - and when the decision is hard, or the spec reads two ways, it struggles: its tests keep failing, the judge keeps finding the tests or the code wrong, it runs far too long. Much of that is the spec's to settle, and once the spec says it, the next build does not struggle. Some of it is not
+- a bug the agent will fix, an environment problem, turri itself - and the spec stays out of that.
 
-You never ask the user: this runs on its own. Where the spec leaves a real choice, take the reading
-that best fits the rest of the spec, the intent it states and what the builds already did, write it,
-and record the decision for the report. You never change what the spec plainly means, never write the
-spec to match code that does something else, never add features, never touch generated code, and
-never edit a `.plain` file with the file tools once rendering has started - every change is a spec
-diff, with `write_spec_diff`.
+You never ask the user: this runs on its own. Where the spec leaves a real choice, take the reading that best fits the rest of the spec, the intent it states and what the builds already did, write it, and record the decision for the report. You never change what the spec plainly means, never write the spec to match code that does something else, never add features, never touch generated code, and never edit a `.plain` file with the file tools once rendering has started - every change is a spec diff, with `write_spec_diff`.
 
 ## Steps
 
 ### intake
 
-1. Find the spec: the `.plain` file(s) the user named, or the project's modules. Read them whole,
-   with their `import` and `requires` chains, and the project's `config.turri.yaml` (or the old
-   `config.yaml`, when there is no `config.turri.yaml`) and each stack's `config.turri.<stack>.yaml`.
-2. Run `validate` on each, and fix only what stops it parsing - with the file tools, while nothing
-   is built from it yet, otherwise with `write_spec_diff`.
-3. Make sure a build can start: the unit testing script (and, with conformance tests on, the
-   conformance testing script) turri finds. When one is missing, write it by following the
-   `implement-unit-testing-script` (or `implement-conformance-testing-script`) skill, for the stack the
-   spec's implementation reqs name. The static checks - formatter, linter, type checker - are part of
-   the unit testing script, as that skill writes it.
+1. Find the spec: the `.plain` file(s) the user named, or the project's modules. Read them whole, with their `import` and `requires` chains, and the project's `config.turri.yaml` (or the old `config.yaml`, when there is no `config.turri.yaml`) and each stack's `config.turri.<stack>.yaml`.
+2. Run `validate` on each, and fix only what stops it parsing - with the file tools, while nothing is built from it yet, otherwise with `write_spec_diff`.
+3. Make sure a build can start: the unit testing script (and, with conformance tests on, the conformance testing script) turri finds. When one is missing, write it by following the `implement-unit-testing-script` (or `implement-conformance-testing-script`) skill, for the stack the spec's implementation reqs name. The static checks - formatter, linter, type checker - are part of the unit testing script, as that skill writes it.
 
 Say in two lines what will be rendered, and go on.
 
@@ -75,41 +54,16 @@ Say in two lines what will be rendered, and go on.
 Run cycles until the goal is met - or you are stuck - and at most twenty. Each cycle:
 
 1. **Check the goal**: `drift` for every module. All fully regenerated: the goal is met - go to the report.
-2. **Regenerate what is not regenerated**: `regenerate` for each module that is not - one that requires
-   another after the one it requires, modules that share nothing together. A module with builds still
-   running or queued is left to them.
-3. **Watch**: `watch_jobs`. It comes back when a build struggles, when all have finished, or when its
-   time is up - then call it again.
-4. **When a build struggles**, read what it has been through - its change, its last stages, the end of
-   its output - and `spec_findings` for what the builds have recorded. Then judge:
-   - **The spec's to settle** - the spec is silent where the build needs a decision (a format, a
-     default, an error and its message, a limit, an order, an edge case); it reads two ways; two of
-     its specs conflict; a test and the code disagree over something the spec never said. Write what
-     the spec should say as a spec diff (below), then `halt` the struggling build - its `job_id`, and
-     as `reason` what the spec now says - and `regenerate`, so it is regenerated from the clarified spec, and go
-     to the next cycle.
-   - **Not the spec's** - a bug the agent is working through, a missing tool or package, a flaky
-     service, turri itself. Leave the build to it, note it for the report, and keep watching.
-     Stopping it would throw its work away for nothing.
-5. **When the builds finish**, read `spec_findings`, and write into the spec every assumption about
-   what the software does that a user, a caller or a test can see - as the build assumed it, unless
-   that is not what the spec meant - so the next build does not have to guess. An assumption about how
-   it is built inside - a library, a file layout, a name - stays out. A diagnosis that says the fix is
-   in the spec is written; one that says code, environment or turri is noted. Then the next
-   cycle: what failed, and what the new diffs changed, is rendered again.
-
-**Writing a fix.** A git diff of the `.plain` file(s), paths from the project root, a few lines of
-context, with `write_spec_diff`. One diff per concern - a functionality's missing rules together, a
-concept and what it means together - never one diff for everything. Put each where it belongs: a rule
-of one functionality into its functional spec, a policy for many into `***implementation reqs***`, a
-term into `***definitions***`, following `add-concept`, `add-functional-spec` and
-`add-implementation-requirement` for how it is written. Each diff is built as it is written: what is left
-to build is worked out again from the spec - only what it changes is rendered again.
-
-**When you are stuck, stop.** The same functionality struggling three times after you clarified the
-spec for it is not something the spec can settle: stop maturing it, and report it. Two cycles in a
-row with nothing newly built and nothing newly settled: stop, and report what is open. Twenty cycles:
-stop, and report.
+2. **Regenerate what is not regenerated**: `regenerate` for each module that is not - one that requires another after the one it requires, modules that share nothing together. A module with builds still running or queued is left to them.
+3. **Watch**: `watch_jobs`. It comes back when a build struggles, when all have finished, or when its time is up - then call it again.
+4. **When a build struggles**, read what it has been through - its change, its last stages, the end of its output - and `spec_findings` for what the builds have recorded. Then judge:
+   - **The spec's to settle** - the spec is silent where the build needs a decision (a format, a default, an error and its message, a limit, an order, an edge case); it reads two ways; two of its specs conflict; a test and the code disagree over something the spec never said. Write what the spec should say as a spec diff (below), then `halt` the struggling build - its `job_id`, and as `reason` what the spec now says - and `regenerate`, so it is regenerated from the clarified spec, and go to the next cycle.
+   - **Not the spec's** - a bug the agent is working through, a missing tool or package, a flaky service, turri itself. Leave the build to it, note it for the report, and keep watching. Stopping it would throw its work away for nothing.
+5. **When the builds finish**, read `spec_findings`, and write into the spec every assumption about what the software does that a user, a caller or a test can see - as the build assumed it, unless that is not what the spec meant - so the next build does not have to guess. An assumption about how it is built inside - a library, a file layout, a name - stays out. A diagnosis that says the fix is in the spec is written; one that says code, environment or turri is noted. Then the next cycle: what failed, and what the new diffs changed, is rendered again.
+
+**Writing a fix.** A git diff of the `.plain` file(s), paths from the project root, a few lines of context, with `write_spec_diff`. One diff per concern - a functionality's missing rules together, a concept and what it means together - never one diff for everything. Put each where it belongs: a rule of one functionality into its functional spec, a policy for many into `***implementation reqs***`, a term into `***definitions***`, following `add-concept`, `add-functional-spec` and `add-implementation-requirement` for how it is written. Each diff is built as it is written: what is left to build is worked out again from the spec - only what it changes is rendered again.
+
+**When you are stuck, stop.** The same functionality struggling three times after you clarified the spec for it is not something the spec can settle: stop maturing it, and report it. Two cycles in a row with nothing newly built and nothing newly settled: stop, and report what is open. Twenty cycles: stop, and report.
 
 ### report
 
@@ -117,10 +71,8 @@ A short account:
 
 - whether the goal was met - `drift` for every module, as it is now;
 - every cycle in a line: what was rendered, what struggled, what you did about it;
-- every decision you wrote into the spec - what it settles, what the spec now says, and the spec diff
-  job that renders it - with the ones where you chose between readings marked, for the user to check;
+- every decision you wrote into the spec - what it settles, what the spec now says, and the spec diff job that renders it - with the ones where you chose between readings marked, for the user to check;
 - what was not the spec's - code, environment, turri - with what the builds and diagnoses said;
 - what is still open, when you stopped before the goal.
 
-Then say that any further change is asked for in the conversation, as a spec diff: what is left to build
-is worked out again from the spec.
+Then say that any further change is asked for in the conversation, as a spec diff: what is left to build is worked out again from the spec.

package/genome/skills/refactor-module/SKILL.md

@@ -21,6 +21,8 @@ allowed-tools: [read, write, edit, bash, ls, grep, find]
 
 The refactoring is purely structural. The **combined behavior** of the resulting modules must be **identical** to the original module. No functional spec is added, removed, or weakened. The split is semantic — grouping related specs together — not behavioral.
 
+The spec is structural; the code is not. Once modules are split and specs move between them, the code already built no longer matches the module layout: specs move into modules the code was never built on, and no change to that code brings them in. **After a refactor, the whole requires chain is regenerated from scratch** — the existing code and conformance tests are taken out (their lineage keeps them) and every module is built again from the base of the chain upward. Say so up front: it is part of what the user agrees to (Phase 2e), and it is the last step of the skill (Phase 5).
+
 ## Input
 
 The `.plain` file to refactor, plus guidance from the user on the desired grouping (or ask the user to confirm your proposed grouping).
@@ -90,8 +92,9 @@ Summarize for the user:
 - Any new import module being created
 - Which concepts are exported from each module
 - Confirmation that all original specs are accounted for (none lost)
+- That the whole chain will be **regenerated from scratch** once the split is done: the code and conformance tests built so far are taken out (kept in the lineage) and everything is built again from the base module up — this takes as long and costs as much as building the original module did
 
-Get explicit user confirmation before proceeding.
+Get explicit user confirmation before proceeding — of the split and of regenerating from scratch.
 
 ## Phase 3 — Execute the Split
 
@@ -162,6 +165,19 @@ For each new module:
 
 Read each new `.plain` file in full and present the final structure to the user for approval. If the user requests changes, apply them and re-verify.
 
+Validate each new module with `turri validate <module>.plain` (or the `validate` tool) before going on: a module that does not parse cannot be regenerated.
+
+## Phase 5 — Regenerate the Chain from Scratch
+
+The split moves specs between modules, so the code built from the original module cannot be patched into the new layout: the chain is regenerated from scratch. Do not try to keep or reuse the existing code, and do not regenerate only what looks changed — modules have moved, and a codebase built without a module it now requires has to be started over anyway.
+
+1. **Remind the user** what regenerating from scratch does — the code and conformance tests built so far are taken out, committed so the lineage keeps them, and the whole chain is built again from the base up — and that they already agreed to it in Phase 2e. Proceed only on that agreement.
+2. **Regenerate the tip of the chain from scratch, with its whole chain** — the last module, the one everything else is required by. From scratch for the tip alone is not enough: the modules below keep their code, and the tip starts from a copy of it, laid out for the old modules. With the whole chain, every module's code is taken out, the base's included, and the chain is built again from the bottom:
+   - in the chat: the `regenerate` tool on the tip's `.plain` file with `from_scratch: "chain"`, or `/regenerate <tip> from scratch, the whole chain`;
+   - on the command line: `turri regenerate <tip>.plain --from-scratch-chain`.
+3. **Modules that require the chain** (updated in 3d) are regenerated after it, from scratch too (`from_scratch: "module"`): the modules they require are not the ones their code was built on. When the tip's whole chain is regenerated, a module built on top of it is a chain of its own — regenerating it from scratch with its whole chain instead covers the tip's chain too, in one go.
+4. **The original module's codebase** (`plain_modules/<original-module>/`), when the original module was deleted or renamed, is no longer built from anything. Tell the user it is there; it is theirs to delete. Do not delete it unasked.
+
 ## Common Pitfalls
 
 ### Splitting too aggressively
@@ -179,9 +195,12 @@ This is a refactoring, not a rewrite. Spec text must be copied verbatim. If a sp
 ### Losing acceptance tests
 Acceptance tests are nested under their parent functional spec. When moving a spec to a new module, its acceptance tests must move with it.
 
+### Regenerating only what changed
+After a split the existing code was built for a module layout that no longer exists. Regenerating incrementally either stops at a codebase that has to be started over or builds on code laid out for the old modules. Regenerate the whole chain from scratch.
+
 ## Validation Checklist
 
-- [ ] User confirmed the split plan before execution
+- [ ] User confirmed the split plan before execution, including regenerating the whole chain from scratch
 - [ ] All original functional specs are present in exactly one new module — none lost
 - [ ] Spec text is identical to the original — no rewording
 - [ ] Acceptance tests moved with their parent specs
@@ -194,3 +213,6 @@ Acceptance tests are nested under their parent functional spec. When moving a sp
 - [ ] Original module removed or updated
 - [ ] Downstream modules (if any) updated to require the chain tip, plus any earlier chain modules whose exported concepts they reference
 - [ ] User approved the final result
+- [ ] Every new module validates
+- [ ] The tip of the chain regenerated from scratch with its whole chain, then any module that requires it
+- [ ] User told about the original module's leftover codebase, if there is one

package/genome/skills/spawn/SKILL.md

@@ -24,40 +24,21 @@ metadata:
 
 # Spawn
 
-Load the `***plain` syntax rules before writing anything - they are in the system prompt under
-`<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow
-closely.
+Load the `***plain` syntax rules before writing anything - they are in the system prompt under `<plain-rules>`; read `genome/rules/<name>.md` for the full text of any rule you need to follow closely.
 
 ## Role
 
-Act as a `***plain` spec writer who decides. The only output is `.plain` specification files and
-the project's testing scripts and config - never code. Code is generated from the specs into
-`plain_modules/`, read-only; never write or edit it. Say everything in terms of specs: "I'll put
-this in the spec."
+Act as a `***plain` spec writer who decides. The only output is `.plain` specification files and the project's testing scripts and config - never code. Code is generated from the specs into `plain_modules/`, read-only; never write or edit it. Say everything in terms of specs: "I'll put this in the spec."
 
-The user tells you what they want, once, and which stack to build it on - or leaves that to you.
-Everything else is yours to choose, on best effort: the architecture, the tests, the features and
-their order, every rule a feature needs - and the stack, when the user leaves it to you. Choose what
-a careful engineer would for this intent - common, well supported, simple - and say what you chose.
-Never ask about any of the rest. The user corrects it afterwards in the conversation,
-where every change is a spec diff and the queued builds are reworked around it.
+The user tells you what they want, once, and which stack to build it on - or leaves that to you. Everything else is yours to choose, on best effort: the architecture, the tests, the features and their order, every rule a feature needs - and the stack, when the user leaves it to you. Choose what a careful engineer would for this intent - common, well supported, simple - and say what you chose. Never ask about any of the rest. The user corrects it afterwards in the conversation, where every change is a spec diff and the queued builds are reworked around it.
 
-Read what is already there first: an existing `.plain` file, `config.turri.yaml` (or the old
-`config.yaml`, with no `config.turri.yaml`), `template/`,
-`test_scripts/`. What the project already settled - a stack, a template, a testing script, a
-`conformance-tests:` decision - is kept, not chosen again.
+Read what is already there first: an existing `.plain` file, `config.turri.yaml` (or the old `config.yaml`, with no `config.turri.yaml`), `template/`, `test_scripts/`. What the project already settled - a stack, a template, a testing script, a `conformance-tests:` decision - is kept, not chosen again.
 
 ## Reference
 
 - Templates go in `template/`; import paths omit the `template/` prefix. Resources go in `resources/`.
-- Generated code lands in `plain_modules/<module>/code/`, conformance tests in
-  `plain_modules/<module>/tests/` (both read-only).
-- One module, unless the intent needs two stacks - a web frontend and an API backend. Then two
-  modules side by side, neither requiring the other, sharing what they both mean through one
-  imported module in `template/`. Each is on a stack of its own, whose testing scripts are named in
-  `config.turri.<stack>.yaml` beside `config.turri.yaml` (`unittests-script:`, `conformance-tests-script:`) -
-  `config.turri.backend.yaml`, `config.turri.frontend.yaml`. A stack is chosen, never worked out: tell the
-  user to choose one with `/stack <stack>` (`--stack <stack>` on the command line) before building its part.
+- Generated code lands in `plain_modules/<module>/code/`, conformance tests in `plain_modules/<module>/tests/` (both read-only).
+- One module, unless the intent needs two stacks - a web frontend and an API backend. Then two modules side by side, neither requiring the other, sharing what they both mean through one imported module in `template/`. Each is on a stack of its own, whose testing scripts are named in `config.turri.<stack>.yaml` beside `config.turri.yaml` (`unittests-script:`, `conformance-tests-script:`) - `config.turri.backend.yaml`, `config.turri.frontend.yaml`. A stack is chosen, never worked out: tell the user to choose one with `/stack <stack>` (`--stack <stack>` on the command line) before building its part.
 
 ## Steps
 
@@ -65,99 +46,33 @@ Read what is already there first: an existing `.plain` file, `config.turri.yaml`
 
 Find out what the user wants to build - the only thing you ask about.
 
-If what the user has already said answers it, do not ask again. Otherwise ask one open question with
-`ask_user` and `free_form: true`: what should it do, and for whom? Ask at most two follow-ups, and
-only when the answer leaves open something that changes what gets built - what kind of software it
-is (a web app, an API, a CLI), or what the first version must do. Never ask about testing, structure
-or details: those are yours.
-
-Then the stack - the one technical question, because it has to be one this machine can build: the
-agents use its toolchains and install none, so a Go project on a laptop without Go stops at its first
-build. `<toolchains on this machine>`, in your instructions, says which languages it can build now.
-When the user already named a stack - a language, a framework - take it; when it is in a language the
-machine lacks, say what to install first and that `turri doctor` checks it, and ask whether to wait for
-that or choose another. Otherwise ask one `ask_user` question: first `You choose`, then the standard
-library's stacks for the kind of software it is (the stdlib rule, in `<plain-rules>`, lists them - for
-an API the backend stacks, for a command-line tool the CLI ones) - only those in a language the machine
-can build now; the "Something else…" that `ask_user` adds takes a stack of the user's own. A product of two kinds - a web app and its API - is one question a module. `You choose` leaves it
-to you, as the groundwork step says.
-
-Then state the brief back in five short bullets - the problem, the primary user, what they can do
-with it, what makes the first version useful, and what the first version leaves out - with the stack
-in a line under them (the user's, or `chosen when it is built` when it is left to you) - and ask one
-`ask_user` question with the options `Build it` and `Change something`, the brief passed whole as its
-`context`: the dialog shows only the question, its options and its `context`. On a change, fold it in and
-ask again. Write nothing to disk in this step.
+If what the user has already said answers it, do not ask again. Otherwise ask one open question with `ask_user` and `free_form: true`: what should it do, and for whom? Ask at most two follow-ups, and only when the answer leaves open something that changes what gets built - what kind of software it is (a web app, an API, a CLI), or what the first version must do. Never ask about testing, structure or details: those are yours.
+
+Then the stack - the one technical question, because it has to be one this machine can build: the agents use its toolchains and install none, so a Go project on a laptop without Go stops at its first build. `<toolchains on this machine>`, in your instructions, says which languages it can build now. When the user already named a stack - a language, a framework - take it; when it is in a language the machine lacks, say what to install first and that `turri doctor` checks it, and ask whether to wait for that or choose another. Otherwise ask one `ask_user` question: first `You choose`, then the standard library's stacks for the kind of software it is (the stdlib rule, in `<plain-rules>`, lists them - for an API the backend stacks, for a command-line tool the CLI ones) - only those in a language the machine can build now; the "Something else…" that `ask_user` adds takes a stack of the user's own. A product of two kinds - a web app and its API - is one question a module. `You choose` leaves it to you, as the groundwork step says.
+
+Then state the brief back in five short bullets - the problem, the primary user, what they can do with it, what makes the first version useful, and what the first version leaves out - with the stack in a line under them (the user's, or `chosen when it is built` when it is left to you) - and ask one `ask_user` question with the options `Build it` and `Change something`, the brief passed whole as its `context`: the dialog shows only the question, its options and its `context`. On a change, fold it in and ask again. Write nothing to disk in this step.
 
 ### groundwork
 
-Set up everything the first build needs, on your own, with the ordinary file tools - no questions,
-nothing built, and `write_spec_diff` not used.
-
-1. **The module and its stack.** Create the `.plain` file (and the template, when it helps), with
-   its frontmatter, and write the stack into `***implementation reqs***`: the language, the
-   framework, storage, the architecture and layout - one requirement per fact, at the right scope,
-   the shared ones on the template. The stack is the user's, when they named or chose one; left to
-   you, choose what fits the intent - a mainstream stack, with the fewest moving parts - in a language
-   this machine can build now (`<toolchains on this machine>`). Follow
-   `genome/rules/impl-reqs.md`. When the standard library has a template
-   for it - a backend, a frontend, a command-line tool or a library (the stdlib rule, in `<plain-rules>`) -
-   import that template and write only what the module needs beyond it.
-2. **Unit tests.** A `:UnitTests:` requirement - the framework, and how they are run - unless the
-   imported stack already sets it, and the unit testing script, for the stack's test framework. Keep one turri already finds (named in `config.turri.yaml`, or the one
-   `run_unittests*.sh` in the root or `test_scripts/`); otherwise write
-   `test_scripts/run_unittests_<language>.sh` by following the `implement-unit-testing-script`
-   skill. Never link it from the specs. The script runs the stack's static checks with the unit
-   tests - the formatter in check mode, the linter, the type checker - and they count as the tests do.
-3. **Conformance tests: off**, so each feature is built fast. Keep a `conformance-tests:` decision
-   the project's config already holds - `config.turri.yaml`, or the old `config.yaml`. Otherwise write `conformance-tests: false` into
-   `config.turri.yaml`, changing nothing else in it - a project with only a `config.yaml` has it copied
-   to `config.turri.yaml` first, and `config.yaml` is never written - and write no `***test reqs***`, import no standard library
-   conformance template, and write no conformance testing script.
-   Only when the user asked for conformance tests, turn them on instead: `conformance-tests: true`,
-   the `***test reqs***` - `:ConformanceTests:` requirements for the framework, how the tests reach
-   the software (a subprocess, HTTP against a server they start, the public entry point), setup and
-   outside services, and the command that runs the suite, following `genome/rules/test-reqs.md`, or
-   the stack's standard library conformance template imported when the stack is from it -
-   and `test_scripts/run_conformance_tests_<language>.sh`, by following the
-   `implement-conformance-testing-script` skill, unless turri already finds one.
-
-Run `validate` on every module you wrote, and fix what it finds. Then say in a few lines what you
-chose - the stack, the architecture, the tests - and carry on. Do not ask for confirmation.
+Set up everything the first build needs, on your own, with the ordinary file tools - no questions, nothing built, and `write_spec_diff` not used.
+
+1. **The module and its stack.** Create the `.plain` file (and the template, when it helps), with its frontmatter, and write the stack into `***implementation reqs***`: the language, the framework, storage, the architecture and layout - one requirement per fact, at the right scope, the shared ones on the template. The stack is the user's, when they named or chose one; left to you, choose what fits the intent - a mainstream stack, with the fewest moving parts - in a language this machine can build now (`<toolchains on this machine>`). Follow `genome/rules/impl-reqs.md`. When the standard library has a template for it - a backend, a frontend, a command-line tool or a library (the stdlib rule, in `<plain-rules>`) - import that template and write only what the module needs beyond it.
+2. **Unit tests.** A `:UnitTests:` requirement - the framework, and how they are run - unless the imported stack already sets it, and the unit testing script, for the stack's test framework. Keep one turri already finds (named in `config.turri.yaml`, or the one `run_unittests*.sh` in the root or `test_scripts/`); otherwise write `test_scripts/run_unittests_<language>.sh` by following the `implement-unit-testing-script` skill. Never link it from the specs. The script runs the stack's static checks with the unit tests - the formatter in check mode, the linter, the type checker - and they count as the tests do.
+3. **Conformance tests: off**, so each feature is built fast. Keep a `conformance-tests:` decision the project's config already holds - `config.turri.yaml`, or the old `config.yaml`. Otherwise write `conformance-tests: false` into `config.turri.yaml`, changing nothing else in it - a project with only a `config.yaml` has it copied to `config.turri.yaml` first, and `config.yaml` is never written - and write no `***test reqs***`, import no standard library conformance template, and write no conformance testing script. Only when the user asked for conformance tests, turn them on instead: `conformance-tests: true`, the `***test reqs***` - `:ConformanceTests:` requirements for the framework, how the tests reach the software (a subprocess, HTTP against a server they start, the public entry point), setup and outside services, and the command that runs the suite, following `genome/rules/test-reqs.md`, or the stack's standard library conformance template imported when the stack is from it - and `test_scripts/run_conformance_tests_<language>.sh`, by following the `implement-conformance-testing-script` skill, unless turri already finds one.
+
+Run `validate` on every module you wrote, and fix what it finds. Then say in a few lines what you chose - the stack, the architecture, the tests - and carry on. Do not ask for confirmation.
 
 ### product
 
 Write the product, feature by feature, as spec diffs - on your own, without asking.
 
-1. **Plan the features** from the brief, in build order: the smallest useful thing first, then
-   what builds on it, up to what the first version must do - and nothing it leaves out. Each
-   feature is one functional spec a render can build in one go (well under 200 lines of code),
-   language-agnostic, and explicit about its interface where it has one. A feature too big for
-   that is two.
-2. **The description first.** A one-sentence product description in the frontmatter, as the first
-   spec diff.
-3. **Then one spec diff per feature**, in order, holding everything that feature needs across
-   sections: the concepts it introduces, into `***definitions***` - defined in the same change as
-   the functional spec that first uses them, following `add-concept`; a technology-free policy it
-   states, into `***implementation reqs***`; and its functional spec, following
-   `add-functional-spec`. Decide its edge cases, validation rules and permissions yourself, the way
-   the intent implies, and write them into the spec.
-4. **Write each with `write_spec_diff`** - a git diff of the `.plain` file(s): `diff --git
-   a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of context,
-   paths from the project root. It applies the change and queues its render spec diff job - with
-   conformance on, its conformance tests follow it. Go straight on to the next feature -
-   never wait for a build. Never change a `.plain` file in this step by any other means.
-
-The step is done only once every feature you planned is written, one spec diff each. Never stop
-part-way to ask whether to go on, or which feature comes next: nobody answers in this step, and the
-skill ends when your turn does - so a question here leaves the product unwritten.
-
-Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the
-file.
-
-End with the handover, in a few lines: the features in build order, the jobs they were queued as,
-that conformance tests are off unless they were asked for (turning them on later is one line in
-`config.turri.yaml`, `conformance-tests: true`, with the test reqs and the script added in the
-conversation), and what the user can do now - try each feature as its build lands (ask to try it, and the chat
-deploys it), and ask for any change in the conversation. A feature added, changed or dropped is one
-spec diff, and what is left to build is worked out again from the spec.
+1. **Plan the features** from the brief, in build order: the smallest useful thing first, then what builds on it, up to what the first version must do - and nothing it leaves out. Each feature is one functional spec a render can build in one go (well under 200 lines of code), language-agnostic, and explicit about its interface where it has one. A feature too big for that is two.
+2. **The description first.** A one-sentence product description in the frontmatter, as the first spec diff.
+3. **Then one spec diff per feature**, in order, holding everything that feature needs across sections: the concepts it introduces, into `***definitions***` - defined in the same change as the functional spec that first uses them, following `add-concept`; a technology-free policy it states, into `***implementation reqs***`; and its functional spec, following `add-functional-spec`. Decide its edge cases, validation rules and permissions yourself, the way the intent implies, and write them into the spec.
+4. **Write each with `write_spec_diff`** - a git diff of the `.plain` file(s): `diff --git a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of context, paths from the project root. It applies the change and queues its render spec diff job - with conformance on, its conformance tests follow it. Go straight on to the next feature - never wait for a build. Never change a `.plain` file in this step by any other means.
+
+The step is done only once every feature you planned is written, one spec diff each. Never stop part-way to ask whether to go on, or which feature comes next: nobody answers in this step, and the skill ends when your turn does - so a question here leaves the product unwritten.
+
+Correct a change you find wrong once written with a diff and `fixes_earlier`, never by editing the file.
+
+End with the handover, in a few lines: the features in build order, the jobs they were queued as, that conformance tests are off unless they were asked for (turning them on later is one line in `config.turri.yaml`, `conformance-tests: true`, with the test reqs and the script added in the conversation), and what the user can do now - try each feature as its build lands (ask to try it, and the chat deploys it), and ask for any change in the conversation. A feature added, changed or dropped is one spec diff, and what is left to build is worked out again from the spec.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.4-next.246fd84",
+  "version": "0.1.4-next.4342332",
   "license": "MIT",
   "type": "module",
   "repository": {