@turri-dev/cli 0.1.4-next.318a98a → 0.1.4-next.5a8c6e5

package/genome/skills/brood/references/intent.md

@@ -1,11 +1,8 @@
 # the intent phase — What is the intent?
 
-Extract the user's intent before creating files or decomposing the product into specifications.
-Keep this phase short. Ask exactly five core questions, one at a time, and do not write to disk.
+Extract the user's intent before creating files or decomposing the product into specifications. Keep this phase short. Ask exactly five core questions, one at a time, and do not write to disk.
 
-The harness has already asked the first question of this phase: how many questions the stack and
-product phases may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it
-again; this phase's own questions are not capped by it.
+The harness has already asked the first question of this phase: how many questions the stack and product phases may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it again; this phase's own questions are not capped by it.
 
 ## Questions
 
@@ -15,8 +12,7 @@ again; this phase's own questions are not capped by it.
 4. **Success criterion** — What observable result would make the first version useful?
 5. **Initial boundary** — What should the first version deliberately leave out?
 
-Ask one focused follow-up only when an answer is too vague to summarize. Do not explore features,
-entities, technology, architecture, or testing yet; those belong to later phases.
+Ask one focused follow-up only when an answer is too vague to summarize. Do not explore features, entities, technology, architecture, or testing yet; those belong to later phases.
 
 ## Intent brief
 
@@ -28,8 +24,4 @@ Summarize the answers in five short bullets:
 - Observable success criterion
 - Initial boundary and explicit exclusions
 
-Ask the user to confirm or correct the brief with one `ask_user` question, the five bullets passed whole as its
-`context` - the dialog shows only the question, its options and its `context`. The intent phase finishes only after
-explicit confirmation.
-Carry the confirmed brief into the stack and product phases so their questions refine it instead of restarting intent
-discovery.
+Ask the user to confirm or correct the brief with one `ask_user` question, the five bullets passed whole as its `context` - the dialog shows only the question, its options and its `context`. The intent phase finishes only after explicit confirmation. Carry the confirmed brief into the stack and product phases so their questions refine it instead of restarting intent discovery.

package/genome/skills/brood/references/product.md

@@ -1,101 +1,49 @@
 # the product phase — What does it do?
 
-The whole product interview, in one phase, walked **feature by feature** - not section by
-section. There is no pass that fills in the definitions and then another that writes the
-functional specs. Each question is about the product: a feature, a step in a flow, a rule.
-Its answer becomes one spec change that touches whatever sections that answer needs - the
-concepts the feature introduces, a policy it needs, its functional spec - and every spec change
-is built the moment it is written.
+The whole product interview, in one phase, walked **feature by feature** - not section by section. There is no pass that fills in the definitions and then another that writes the functional specs. Each question is about the product: a feature, a step in a flow, a rule. Its answer becomes one spec change that touches whatever sections that answer needs - the concepts the feature introduces, a policy it needs, its functional spec - and every spec change is built the moment it is written.
 
 Carry the confirmed intent brief and the settled stack in. Do not restart either.
 
 ## How many questions
 
-The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best
-judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level walks
-all the topics below: light in a few broad questions - the features and their order in one, what
-they do end to end in another, with what fits the brief proposed for the person to confirm or
-correct; thorough in narrow ones, a feature, rule or edge case each. The level limits the
-questions, never the spec changes:
-
-- **Every answer is a spec change**, at every level: written with `write_spec_diff` and built at
-  once, before the next question - `ask_user` refuses the next question until it is. A broad
-  answer covering several features is a change for each.
-- **What the questions leave open is yours** - the details under a broad answer, and everything
-  still open once the questions are over (the cap reached, or `end_questions` called). Each
-  feature, edge case and rule you decide is its own spec change, written with `write_spec_diff`
-  with no answer needed before it, and said in one line. Write as many as the product needs.
-  Decide from the intent brief and the answers so far; leave out what they do not call for rather
-  than invent scope.
+The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level walks all the topics below: light in a few broad questions - the features and their order in one, what they do end to end in another, with what fits the brief proposed for the person to confirm or correct; thorough in narrow ones, a feature, rule or edge case each. The level limits the questions, never the spec changes:
+
+- **Every answer is a spec change**, at every level: written with `write_spec_diff` and built at once, before the next question - `ask_user` refuses the next question until it is. A broad answer covering several features is a change for each.
+- **What the questions leave open is yours** - the details under a broad answer, and everything still open once the questions are over (the cap reached, or `end_questions` called). Each feature, edge case and rule you decide is its own spec change, written with `write_spec_diff` with no answer needed before it, and said in one line. Write as many as the product needs. Decide from the intent brief and the answers so far; leave out what they do not call for rather than invent scope.
 
 ## One question, one answer, a spec change, a render
 
 Every iteration is exactly this, at every questioning level:
 
-1. **Ask one question** with `ask_user`, about the product: a feature, its trigger and outcome,
-   one of its edge cases or rules, the next step of a flow - as broad as the level says. Never bundle two, and never ask about
-   a spec section ("what concepts are there?", "what reqs apply?") - ask about what the product
-   does, and let the answer decide which sections change.
+1. **Ask one question** with `ask_user`, about the product: a feature, its trigger and outcome, one of its edge cases or rules, the next step of a flow - as broad as the level says. Never bundle two, and never ask about a spec section ("what concepts are there?", "what reqs apply?") - ask about what the product does, and let the answer decide which sections change.
 2. **Turn the answer into a spec change** - one for each feature it covers - everything it calls for, across sections:
-   - a concept the feature introduces, into `***definitions***`, following `add-concept`, defined
-     in the same change as the functional spec that first uses it;
+   - a concept the feature introduces, into `***definitions***`, following `add-concept`, defined in the same change as the functional spec that first uses it;
    - a technology-free policy the answer states, into `***implementation reqs***`;
-   - the functional spec for the feature, or the change to one already written, following
-     `add-functional-spec`.
-   Write it as 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 unchanged context. Paths
-   are relative to the project root.
-3. **Write it with `write_spec_diff`.** It applies the diff and starts a render spec diff job for
-   it in the same call - whatever the change touches, a definition alone included. Write every
-   change the answer calls for before the next question - `ask_user` refuses it until then - and
-   any you decide yourself beside them. Move straight on to the next question; never wait for a
-   build.
-
-**One answer, at least one change.** A follow-up about the same feature - an edge case, a
-validation rule - is its own answer and its own change to that feature's spec. An answer that
-describes two features is two changes, both written before the next question. A change never
-carries both an answer and something you decided: what you decide is a change of its own.
-
-**Fix contradictions in place.** When a later answer refines or contradicts something already
-written, write the correction as its own diff with `fixes_earlier` set, before the next
-question. It is rendered like any other change.
-
-**Never edit the `.plain` files with `write` or `edit` in this phase.** A change that does not
-go through `write_spec_diff` is a change nothing renders.
+   - the functional spec for the feature, or the change to one already written, following `add-functional-spec`. Write it as 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 unchanged context. Paths are relative to the project root.
+3. **Write it with `write_spec_diff`.** It applies the diff and starts a render spec diff job for it in the same call - whatever the change touches, a definition alone included. Write every change the answer calls for before the next question - `ask_user` refuses it until then - and any you decide yourself beside them. Move straight on to the next question; never wait for a build.
+
+**One answer, at least one change.** A follow-up about the same feature - an edge case, a validation rule - is its own answer and its own change to that feature's spec. An answer that describes two features is two changes, both written before the next question. A change never carries both an answer and something you decided: what you decide is a change of its own.
+
+**Fix contradictions in place.** When a later answer refines or contradicts something already written, write the correction as its own diff with `fixes_earlier` set, before the next question. It is rendered like any other change.
+
+**Never edit the `.plain` files with `write` or `edit` in this phase.** A change that does not go through `write_spec_diff` is a change nothing renders.
 
 ## What a change may contain
 
-- **`***definitions***`** - the concepts the change needs, each defined before, or in the same
-  change as, what first uses it.
-- **`***functional specs***`** - at most one new functionality per change: ≤200 lines of code
-  change, language-agnostic, in chronological build order, externally explicit where it has an
-  interface.
-- **`***implementation reqs***`** - only technology-free policy: an error-handling or retry
-  policy, an ordering guarantee, a data-format rule. The technology was settled in the stack
-  phase; an answer that needs a new technology is a stack answer - note it and steer back.
+- **`***definitions***`** - the concepts the change needs, each defined before, or in the same change as, what first uses it.
+- **`***functional specs***`** - at most one new functionality per change: ≤200 lines of code change, language-agnostic, in chronological build order, externally explicit where it has an interface.
+- **`***implementation reqs***`** - only technology-free policy: an error-handling or retry policy, an ordering guarantee, a data-format rule. The technology was settled in the stack phase; an answer that needs a new technology is a stack answer - note it and steer back.
 
-Leave the `***test reqs***` as the testing phase wrote them, and write no `***acceptance tests***`.
-With conformance on, every change is built with its conformance tests - from the test reqs as they
-stand.
+Leave the `***test reqs***` as the testing phase wrote them, and write no `***acceptance tests***`. With conformance on, every change is built with its conformance tests - from the test reqs as they stand.
 
 ## Topics (in order)
 
-1. **Product description** - propose a one-sentence description from the confirmed intent brief,
-   state it back in one line, and write it into the frontmatter as the first change.
-2. **Features, one at a time, in build order** - the smallest thing that is useful first, then
-   what builds on it. For each feature: one question for what triggers it and what comes out,
-   then one per edge case, validation rule or permission that is not obvious. Each answer is a
-   change: the first brings the feature's concepts and its functional spec; the follow-ups refine
-   them. A feature too large for one functional spec is split *with the user* - that is the next
-   question.
-3. **User flows** - walk the product from the user's side: what happens first, what next, and at
-   each decision point. Each missing step is a feature, taken the same way.
-4. **User interface (optional)** - skip entirely if there is none. Otherwise per screen or
-   interaction: what the user sees and what it does, still language- and framework-agnostic.
+1. **Product description** - propose a one-sentence description from the confirmed intent brief, state it back in one line, and write it into the frontmatter as the first change.
+2. **Features, one at a time, in build order** - the smallest thing that is useful first, then what builds on it. For each feature: one question for what triggers it and what comes out, then one per edge case, validation rule or permission that is not obvious. Each answer is a change: the first brings the feature's concepts and its functional spec; the follow-ups refine them. A feature too large for one functional spec is split *with the user* - that is the next question.
+3. **User flows** - walk the product from the user's side: what happens first, what next, and at each decision point. Each missing step is a feature, taken the same way.
+4. **User interface (optional)** - skip entirely if there is none. Otherwise per screen or interaction: what the user sees and what it does, still language- and framework-agnostic.
 5. **Anything else** - anything the user wants to add or change that has not been covered.
 
 ## Reporting builds
 
-Report each build result between questions, in one sentence. A failed build does not stop the
-interview - note it and carry on, unless it shows the spec itself is wrong, in which case fix
-the spec with a diff and `fixes_earlier`.
+Report each build result between questions, in one sentence. A failed build does not stop the interview - note it and carry on, unless it shows the spec itself is wrong, in which case fix the spec with a diff and `fixes_earlier`.

package/genome/skills/brood/references/stack.md

@@ -2,14 +2,7 @@
 
 Gather the technical stack **and** the project's structure/architecture. This phase affects only `***implementation reqs***`, and ends with the unit testing script every build needs — the rest of testing comes later. Run the core loop from `SKILL.md` for each topic below, in order: ask, then write the requirement into the `.plain` file with the ordinary file tools. Nothing is built in this phase. When the user has no preference, propose a sensible default that fits earlier answers and ask them to confirm.
 
-The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best
-judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level reaches
-all the topics, in order: light in a few broad questions - the stack, say, then storage and
-outside services together, then the remaining constraints, each with what fits the brief
-proposed; thorough a topic or two a question, with follow-ups. Every topic left unasked once the
-questions are over gets the default that fits the intent brief and the answers so far, written as a
-requirement like any other and named as your choice in the closing summary. The unit testing script
-is written whatever the level.
+The questioning level caps this phase's questions (light 3, medium 5, thorough 10, or best judgement - `SKILL.md`, "How many questions"), and so sets how broad each is. Every level reaches all the topics, in order: light in a few broad questions - the stack, say, then storage and outside services together, then the remaining constraints, each with what fits the brief proposed; thorough a topic or two a question, with follow-ups. Every topic left unasked once the questions are over gets the default that fits the intent brief and the answers so far, written as a requirement like any other and named as your choice in the closing summary. The unit testing script is written whatever the level.
 
 ## Author target for this phase
 
@@ -22,27 +15,12 @@ Do **not** add `***test reqs***` or `***acceptance tests***` in this phase — t
 
 ## First: a stack from the standard library
 
-Before the topics, settle what kind of software each module is - a backend, a frontend, a
-command-line tool, a library - and offer the standard library's stacks for that kind (the stdlib
-rule, in `<plain-rules>`, lists them) that this machine can build: `<toolchains on this machine>`, in
-your instructions, says which languages it can build now. The agents use its toolchains and install
-none, so a stack in a language it lacks stops at its first build. Ask with `ask_user`: those stacks
-as options, the one that fits earlier answers first, and "Something else…" for a stack of the user's
-own. A stack the user names 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.
-
-- **A stack from the standard library.** Import it into the module's frontmatter as
-  `stdlib/<kind>/<stack>`, and read the templates it brings: the stack, its `stdlib/lang/<language>`
-  and its kind's `common` - the folder is in the stdlib rule. They settle topics 1, 2 and 5, error handling and
-  logging in topic 6, and the unit-test framework in topic 8: do not ask about those, and write no
-  requirement that restates them. Say in one line what the stack settles - its language, framework,
-  layout, how it reports errors and logs - so the user knows what they chose. Then walk only topics
-  3, 4, 6 (what the stack leaves open), 7, and the unit testing script in 8.
-- **Something else.** Walk every topic below. When the language is one the standard library has, its
-  `stdlib/lang/<language>` template can still be imported for the language-wide conventions.
-
-A user who wants something the stack settles done differently - another framework, another layout -
-has chosen something else: an import cannot be taken back in part.
+Before the topics, settle what kind of software each module is - a backend, a frontend, a command-line tool, a library - and offer the standard library's stacks for that kind (the stdlib rule, in `<plain-rules>`, lists them) that this machine can build: `<toolchains on this machine>`, in your instructions, says which languages it can build now. The agents use its toolchains and install none, so a stack in a language it lacks stops at its first build. Ask with `ask_user`: those stacks as options, the one that fits earlier answers first, and "Something else…" for a stack of the user's own. A stack the user names 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.
+
+- **A stack from the standard library.** Import it into the module's frontmatter as `stdlib/<kind>/<stack>`, and read the templates it brings: the stack, its `stdlib/lang/<language>` and its kind's `common` - the folder is in the stdlib rule. They settle topics 1, 2 and 5, error handling and logging in topic 6, and the unit-test framework in topic 8: do not ask about those, and write no requirement that restates them. Say in one line what the stack settles - its language, framework, layout, how it reports errors and logs - so the user knows what they chose. Then walk only topics 3, 4, 6 (what the stack leaves open), 7, and the unit testing script in 8.
+- **Something else.** Walk every topic below. When the language is one the standard library has, its `stdlib/lang/<language>` template can still be imported for the language-wide conventions.
+
+A user who wants something the stack settles done differently - another framework, another layout - has chosen something else: an import cannot be taken back in part.
 
 ## Topics (in order)
 

package/genome/skills/brood/references/testing.md

@@ -1,56 +1,25 @@
 # the testing phase — How is what was built checked from the outside?
 
-Decide whether the project has conformance tests, and if it does, say in `***test reqs***` how they
-are written and run, and give it the script that runs them. This comes before the product phase, and
-nothing here is built: a change to the test reqs is not a spec diff, so it is written with the
-ordinary file tools, never `write_spec_diff`. What is settled here is what every build of the
-product phase follows - with conformance on, each spec change is built with its conformance tests.
-Run the core loop for each topic below, in order: ask, then write. When the user has no preference,
-propose a default that fits the stack and the intent brief and ask them to confirm.
-
-Conformance tests are black-box tests written from the spec: for each functional spec, tests that
-run the built software from the outside - as a command, over HTTP, through its public entry point -
-and check it does what the spec says, kept apart from the spec's acceptance tests. The harness runs
-the whole suite after every spec change, so they catch one change breaking another. They cost time
-and tokens on every build.
+Decide whether the project has conformance tests, and if it does, say in `***test reqs***` how they are written and run, and give it the script that runs them. This comes before the product phase, and nothing here is built: a change to the test reqs is not a spec diff, so it is written with the ordinary file tools, never `write_spec_diff`. What is settled here is what every build of the product phase follows - with conformance on, each spec change is built with its conformance tests. Run the core loop for each topic below, in order: ask, then write. When the user has no preference, propose a default that fits the stack and the intent brief and ask them to confirm.
+
+Conformance tests are black-box tests written from the spec: for each functional spec, tests that run the built software from the outside - as a command, over HTTP, through its public entry point - and check it does what the spec says, kept apart from the spec's acceptance tests. The harness runs the whole suite after every spec change, so they catch one change breaking another. They cost time and tokens on every build.
 
 ## Author target for this phase
 
-- `***test reqs***` - one `:ConformanceTests:` requirement per fact, on the template if one exists
-  (shared by every module), otherwise on the module. Follow `genome/rules/test-reqs.md`.
-- `config.turri.yaml` at the project root - the `conformance-tests:` decision. Change only that key, and
-  create the file if there is none; everything else in it stays as it is. When the project has only a
-  `config.yaml`, copy it to `config.turri.yaml` first - and each `config.<name>.yaml` to
-  `config.turri.<name>.yaml` - and write the copy: `config.yaml` may be another tool's, and is never
-  written.
+- `***test reqs***` - one `:ConformanceTests:` requirement per fact, on the template if one exists (shared by every module), otherwise on the module. Follow `genome/rules/test-reqs.md`.
+- `config.turri.yaml` at the project root - the `conformance-tests:` decision. Change only that key, and create the file if there is none; everything else in it stays as it is. When the project has only a `config.yaml`, copy it to `config.turri.yaml` first - and each `config.<name>.yaml` to `config.turri.<name>.yaml` - and write the copy: `config.yaml` may be another tool's, and is never written.
 - `test_scripts/` - the conformance testing script.
 
 Write no `***acceptance tests***`, no functional specs and no `***implementation reqs***` here.
 
 ## Topics (in order)
 
-1. **Conformance on or off** - ask it explicitly, with what it costs and what it catches; it is a
-   recorded decision, never an inference. Ask it even when `config.turri.yaml` already has
-   `conformance-tests:` - offer what it says as the first option. Write it to `config.turri.yaml` as `conformance-tests: true` or
-   `conformance-tests: false`. Off: say that no conformance tests will be written or run until it
-   is turned on, and go to the end of the phase.
-2. **Framework** - e.g. pytest, JUnit, Jest, Go's `testing`; one that fits the stack. Author it as a
-   `:ConformanceTests:` requirement.
-3. **How the tests reach the software** - as a subprocess of the CLI, over HTTP against a server the
-   tests start, through the public entry point it exports. Author it.
-4. **Setup and outside services** - fixtures, test data, databases, third-party APIs: started for
-   real, faked, or mocked at the boundary. Author each decision as its own requirement.
+1. **Conformance on or off** - ask it explicitly, with what it costs and what it catches; it is a recorded decision, never an inference. Ask it even when `config.turri.yaml` already has `conformance-tests:` - offer what it says as the first option. Write it to `config.turri.yaml` as `conformance-tests: true` or `conformance-tests: false`. Off: say that no conformance tests will be written or run until it is turned on, and go to the end of the phase.
+2. **Framework** - e.g. pytest, JUnit, Jest, Go's `testing`; one that fits the stack. Author it as a `:ConformanceTests:` requirement.
+3. **How the tests reach the software** - as a subprocess of the CLI, over HTTP against a server the tests start, through the public entry point it exports. Author it.
+4. **Setup and outside services** - fixtures, test data, databases, third-party APIs: started for real, faked, or mocked at the boundary. Author each decision as its own requirement.
 5. **How the whole suite is run** - the one command that discovers every test. Author it.
-6. **The conformance testing script** - if turri already finds one (named by
-   `conformance-tests-script:` in `config.turri.yaml`, or the one `run_conformance_tests*.sh` in the
-   project root or in `test_scripts/`), check it runs the suite the way the test reqs now say, and
-   keep it. Otherwise write `test_scripts/run_conformance_tests_<language>.sh` with
-   `implement-conformance-testing-script`, to match the test reqs. Never link it from the specs.
-   If `test_scripts/` would hold two of a kind, name the one to use in `config.turri.yaml`. In a
-   project whose parts are on different stacks, name each stack's script in its own
-   `config.turri.<stack>.yaml` (`conformance-tests-script:`), and tell the user to choose the stack
-   with `/stack <stack>` (`--stack <stack>` on the command line) before building that part.
+6. **The conformance testing script** - if turri already finds one (named by `conformance-tests-script:` in `config.turri.yaml`, or the one `run_conformance_tests*.sh` in the project root or in `test_scripts/`), check it runs the suite the way the test reqs now say, and keep it. Otherwise write `test_scripts/run_conformance_tests_<language>.sh` with `implement-conformance-testing-script`, to match the test reqs. Never link it from the specs. If `test_scripts/` would hold two of a kind, name the one to use in `config.turri.yaml`. In a project whose parts are on different stacks, name each stack's script in its own `config.turri.<stack>.yaml` (`conformance-tests-script:`), and tell the user to choose the stack with `/stack <stack>` (`--stack <stack>` on the command line) before building that part.
 7. **Anything else** - anything about testing the user wants to add or change.
 
-Run `validate` on every module you changed. The product phase's first build needs the test reqs
-and the conformance testing script both there: without them it stops before it starts.
+Run `validate` on every module you changed. The product phase's first build needs the test reqs and the conformance testing script both there: without them it stops before it starts.

package/genome/skills/bud/SKILL.md

@@ -28,27 +28,17 @@ metadata:
 
 # Bud
 
-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 adding one feature to specs that already exist - and, usually, to
-code already built from them, or being built. The only output is changes to `.plain` files, and
-every one of them is a **spec diff**: a git diff of the `.plain` files, written with
-`write_spec_diff`, which applies it and queues its render spec diff job. Never write code, and never
-change a `.plain` file by any other means. Frame every message in terms of specs: "I'll add this to
-the spec."
+Act as a `***plain` spec writer adding one feature to specs that already exist - and, usually, to code already built from them, or being built. The only output is changes to `.plain` files, and every one of them is a **spec diff**: a git diff of the `.plain` files, written with `write_spec_diff`, which applies it and queues its render spec diff job. Never write code, and never change a `.plain` file by any other means. Frame every message in terms of specs: "I'll add this to the spec."
 
-This is `brood`'s product phase, scoped to one feature, on top of what is there: the stack,
-the testing setup and every earlier feature are settled - read them, build on them, restart none.
+This is `brood`'s product phase, scoped to one feature, on top of what is there: the stack, the testing setup and every earlier feature are settled - read them, build on them, restart none.
 
 ## How many questions
 
-The first question of the intent phase is the harness's own, not yours: how many questions the
-**product** phase may ask. The level sets how many questions there are and so how broad each is -
-never what they cover:
+The first question of the intent phase is the harness's own, not yours: how many questions the **product** phase may ask. The level sets how many questions there are and so how broad each is - never what they cover:
 
 | level | product questions | each question |
 | --- | --- | --- |
@@ -57,123 +47,56 @@ never what they cover:
 | thorough | at most 10 | narrow: one trigger, rule or edge case, with follow-ups on the ones that matter |
 | best judgement | as many as you judge the feature needs | as broad or as narrow as each part needs |
 
-The intent phase is not capped. Follow-ups count; the closing confirmation - asked with
-`confirms_phase: true` - does not. Past the cap `ask_user` refuses the question. To stop sooner, or
-under best judgement once the feature is settled enough to build, call `end_questions`.
+The intent phase is not capped. Follow-ups count; the closing confirmation - asked with `confirms_phase: true` - does not. Past the cap `ask_user` refuses the question. To stop sooner, or under best judgement once the feature is settled enough to build, call `end_questions`.
 
-The level limits the questions, never the spec changes. **Every answer is a spec change**, whatever
-the level: written with `write_spec_diff` and built at once, before the next question - `ask_user`
-refuses the next one until it is. A broad answer that covers several behaviours is several changes,
-and you write them all. What the questions leave open - the details of a light answer, what is left
-once they are over - is yours to decide, as a careful engineer would, in the light of the brief: each
-decision a spec change of its own, written with `write_spec_diff` with no answer needed before it,
-and said in one line. The closing summary names every decision you made yourself, so the
-confirmation is where the person can change it.
+The level limits the questions, never the spec changes. **Every answer is a spec change**, whatever the level: written with `write_spec_diff` and built at once, before the next question - `ask_user` refuses the next one until it is. A broad answer that covers several behaviours is several changes, and you write them all. What the questions leave open - the details of a light answer, what is left once they are over - is yours to decide, as a careful engineer would, in the light of the brief: each decision a spec change of its own, written with `write_spec_diff` with no answer needed before it, and said in one line. The closing summary names every decision you made yourself, so the confirmation is where the person can change it.
 
 ## Question style
 
-- Ask with `ask_user`, one question per call, as broad as the level says, and pass `options` so
-  the user picks rather than types - concrete choices, plus the free-form catch-all the tool adds. Reserve `free_form: true`
-  for a genuinely open question.
-- Ask about the product - a trigger and its outcome, an edge case, a rule, a permission, a step of
-  a flow - never about a spec section ("which concepts?", "what reqs?"). Let the answer decide which
-  sections change.
-- Shape each question so any plausible answer maps to one spec change. Bad: "How should it work?"
-  Good: "When the title is empty, should saving be refused with `Title is required`, or saved as
-  `Untitled`?"
-- Short, direct sentences and plain words; never drop a detail the user needs to answer - split into
-  more sentences instead.
+- Ask with `ask_user`, one question per call, as broad as the level says, and pass `options` so the user picks rather than types - concrete choices, plus the free-form catch-all the tool adds. Reserve `free_form: true` for a genuinely open question.
+- Ask about the product - a trigger and its outcome, an edge case, a rule, a permission, a step of a flow - never about a spec section ("which concepts?", "what reqs?"). Let the answer decide which sections change.
+- Shape each question so any plausible answer maps to one spec change. Bad: "How should it work?" Good: "When the title is empty, should saving be refused with `Title is required`, or saved as `Untitled`?"
+- Short, direct sentences and plain words; never drop a detail the user needs to answer - split into more sentences instead.
 
 ## Steps
 
 ### intent
 
-The harness has asked how many questions the product phase may ask before this phase starts; its
-note beside these instructions gives the answer. Do not ask it again.
+The harness has asked how many questions the product phase may ask before this phase starts; its note beside these instructions gives the answer. Do not ask it again.
 
-Read `references/intent.md` and ask its five core questions one at a time with `ask_user`. Ask at
-most one focused follow-up when an answer is too vague to summarize. If what the user has already
-said answers a question, confirm it in one line instead of asking.
+Read `references/intent.md` and ask its five core questions one at a time with `ask_user`. Ask at most one focused follow-up when an answer is too vague to summarize. If what the user has already said answers a question, confirm it in one line instead of asking.
 
-Write nothing to disk. Summarize the feature-intent brief - motivation, affected user, desired
-outcome, observable success criterion, boundary and explicit exclusions - and get explicit
-confirmation, the brief passed whole as `ask_user`'s `context`, which the dialog shows above the
-question. Carry the brief into every later step.
+Write nothing to disk. Summarize the feature-intent brief - motivation, affected user, desired outcome, observable success criterion, boundary and explicit exclusions - and get explicit confirmation, the brief passed whole as `ask_user`'s `context`, which the dialog shows above the question. Carry the brief into every later step.
 
 ### scope
 
 Keep this short: enough to ask the first product question, not a design on paper.
 
-1. Find the `.plain` file(s) the feature belongs to, and read them whole, following their `import`
-   and `requires` chains: every definition, implementation and test req, functional spec and
-   acceptance test the feature will sit beside. Read `config.turri.yaml` (or the old `config.yaml`,
-   when there is no `config.turri.yaml`) and the chosen stack's `config.turri.<stack>.yaml` for
-   whether conformance tests are on.
+1. Find the `.plain` file(s) the feature belongs to, and read them whole, following their `import` and `requires` chains: every definition, implementation and test req, functional spec and acceptance test the feature will sit beside. Read `config.turri.yaml` (or the old `config.yaml`, when there is no `config.turri.yaml`) and the chosen stack's `config.turri.<stack>.yaml` for whether conformance tests are on.
 2. Ask which module only if it is genuinely ambiguous; otherwise do not.
-3. Look at what is built and queued (`drift`), so you know which specs already have code and
-   which builds are still waiting - a change to either is still just a spec diff.
+3. Look at what is built and queued (`drift`), so you know which specs already have code and which builds are still waiting - a change to either is still just a spec diff.
 
 Say in one line where the feature goes, and move on. Write nothing to disk.
 
 ### product
 
-The feature, walked question by question. Run this loop while the questioning level allows (see
-"How many questions"):
+The feature, walked question by question. Run this loop while the questioning level allows (see "How many questions"):
 
 1. **Ask** one product question with `ask_user`.
 2. The user **answers**.
-3. **Make the spec change** the answer calls for, as one git diff of the `.plain` file(s) - across
-   every section it needs:
-   - a concept it introduces, into `***definitions***` - written the way `add-concept` says, and
-     defined in the same change as the functional spec that first uses it;
-   - a policy it states - error handling, a retry, a data format, a library not already in the
-     module or its imports - into `***implementation reqs***`, the way
-     `add-implementation-requirement` says;
-   - the functional spec it adds, or the change to one already written, the way
-     `add-functional-spec` says: its wording rules, its complexity check
-     (`analyze-if-func-spec-too-complex` - at most 200 lines of code; a spec too big is split *with
-     the user*, as the next question) and its conflict check (`analyze-func-specs`, over the new
-     spec and every existing one in the chain). Follow those skills for what the text is; the diff
-     is the only thing that writes it.
-   - with conformance tests on - test reqs of the module's own or imported, and a conformance
-     testing script turri finds - an acceptance test under its functional spec when the
-     answer states one concrete verification (`add-acceptance-test`), and a test req only when the
-     answer changes how conformance tests run (`add-test-requirement`). With conformance off, none.
-   Write it as a git diff: `diff --git a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the
-   hunks with a few lines of unchanged context, paths from the project root. A new functional spec
-   goes where it belongs in build order - after what it builds on, usually at the end.
-4. **Write it with `write_spec_diff` at once**, before anything else. It applies the diff and starts
-   a render spec diff job for it; with conformance on, its conformance tests follow it. An answer
-   that covers several behaviours is a change for each: write them all. Then the changes for what
-   you decide yourself around it, if any. Say in one line what went into the spec - "added `:Note:`
-   and functional spec 7" - and what became of the build, as the tool says, then ask the next
-   question. Never wait for a build, and never ask the user to approve a change.
-
-**One answer, at least one change.** A follow-up about the same behaviour - an edge case, a
-validation rule - is its own answer and its own change. An answer that describes two behaviours is
-two changes, both written before the next question. A change never carries both an answer and
-something you decided: what you decide is a change of its own.
-
-**What already exists.** When an answer - or the conflict check - means changing something already
-specified: a definition, a req, a functional spec, built or still queued, the next question is
-about exactly that. Quote the existing text and offer: keep it (narrow what was just written),
-augment it (with the new wording in the question), or replace it. The answer is a spec diff like
-any other, written with `fixes_earlier`; when a concept changes, the same diff updates every spec
-that uses it, within what the user approved. Never rewrite earlier intent without asking. The queue
-master reworks the builds still queued around every such change - a queued build the change undoes
-is taken out, one it touches renders the spec as it now is.
-
-**Fix your own mistakes in place.** When a later answer refines or contradicts a change you wrote in
-this feature, write the correction as its own diff with `fixes_earlier`, before the next question.
-
-Once the questions are over - the cap reached, or `end_questions` called - write what is left of
-the feature the same way: one decision of yours, one spec change, with no answer between. Then run
-`validate` on every module the feature touched, and fix what it finds with a spec diff and
-`fixes_earlier`.
-
-Finish by summarizing the feature's spec changes in build order, marking what you decided without
-asking, saying what is built and what is still queued (`drift`), and getting explicit confirmation
-with `confirms_phase: true`. The summary is for the person to take in at a glance - a line a change,
-each decision you made yourself in a few words, about fifteen lines at most, never the specs'
-wording. Any further change is asked for in the conversation, each one a spec diff; the next
-feature starts again from the intent.
+3. **Make the spec change** the answer calls for, as one git diff of the `.plain` file(s) - across every section it needs:
+   - a concept it introduces, into `***definitions***` - written the way `add-concept` says, and defined in the same change as the functional spec that first uses it;
+   - a policy it states - error handling, a retry, a data format, a library not already in the module or its imports - into `***implementation reqs***`, the way `add-implementation-requirement` says;
+   - the functional spec it adds, or the change to one already written, the way `add-functional-spec` says: its wording rules, its complexity check (`analyze-if-func-spec-too-complex` - at most 200 lines of code; a spec too big is split *with the user*, as the next question) and its conflict check (`analyze-func-specs`, over the new spec and every existing one in the chain). Follow those skills for what the text is; the diff is the only thing that writes it.
+   - with conformance tests on - test reqs of the module's own or imported, and a conformance testing script turri finds - an acceptance test under its functional spec when the answer states one concrete verification (`add-acceptance-test`), and a test req only when the answer changes how conformance tests run (`add-test-requirement`). With conformance off, none. Write it as a git diff: `diff --git a/<file> b/<file>`, `--- a/<file>`, `+++ b/<file>`, then the hunks with a few lines of unchanged context, paths from the project root. A new functional spec goes where it belongs in build order - after what it builds on, usually at the end.
+4. **Write it with `write_spec_diff` at once**, before anything else. It applies the diff and starts a render spec diff job for it; with conformance on, its conformance tests follow it. An answer that covers several behaviours is a change for each: write them all. Then the changes for what you decide yourself around it, if any. Say in one line what went into the spec - "added `:Note:` and functional spec 7" - and what became of the build, as the tool says, then ask the next question. Never wait for a build, and never ask the user to approve a change.
+
+**One answer, at least one change.** A follow-up about the same behaviour - an edge case, a validation rule - is its own answer and its own change. An answer that describes two behaviours is two changes, both written before the next question. A change never carries both an answer and something you decided: what you decide is a change of its own.
+
+**What already exists.** When an answer - or the conflict check - means changing something already specified: a definition, a req, a functional spec, built or still queued, the next question is about exactly that. Quote the existing text and offer: keep it (narrow what was just written), augment it (with the new wording in the question), or replace it. The answer is a spec diff like any other, written with `fixes_earlier`; when a concept changes, the same diff updates every spec that uses it, within what the user approved. Never rewrite earlier intent without asking. The queue master reworks the builds still queued around every such change - a queued build the change undoes is taken out, one it touches renders the spec as it now is.
+
+**Fix your own mistakes in place.** When a later answer refines or contradicts a change you wrote in this feature, write the correction as its own diff with `fixes_earlier`, before the next question.
+
+Once the questions are over - the cap reached, or `end_questions` called - write what is left of the feature the same way: one decision of yours, one spec change, with no answer between. Then run `validate` on every module the feature touched, and fix what it finds with a spec diff and `fixes_earlier`.
+
+Finish by summarizing the feature's spec changes in build order, marking what you decided without asking, saying what is built and what is still queued (`drift`), and getting explicit confirmation with `confirms_phase: true`. The summary is for the person to take in at a glance - a line a change, each decision you made yourself in a few words, about fifteen lines at most, never the specs' wording. Any further change is asked for in the conversation, each one a spec diff; the next feature starts again from the intent.

package/genome/skills/bud/references/intent.md

@@ -1,11 +1,8 @@
 # The intent step - what is the feature for?
 
-Extract the intent of this feature before choosing files or authoring specifications. Ask exactly
-five core questions, one at a time, and do not write to disk.
+Extract the intent of this feature before choosing files or authoring specifications. Ask exactly five core questions, one at a time, and do not write to disk.
 
-The harness has already asked the first question of this phase: how many questions the product
-phase may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it again; this
-phase's own questions are not capped by it.
+The harness has already asked the first question of this phase: how many questions the product phase may ask - light (3), medium (5), thorough (10) or best judgement. Do not ask it again; this phase's own questions are not capped by it.
 
 ## Questions
 
@@ -15,9 +12,7 @@ phase's own questions are not capped by it.
 4. **Success criterion** — What observable result would prove the feature is useful and working?
 5. **Boundary** — What should this feature deliberately leave unchanged or out of scope?
 
-Ask one focused follow-up only when an answer is too vague to summarize. Do not choose concepts,
-spec wording, implementation technology, or tests yet - the product questions decide those, one
-spec change at a time.
+Ask one focused follow-up only when an answer is too vague to summarize. Do not choose concepts, spec wording, implementation technology, or tests yet - the product questions decide those, one spec change at a time.
 
 ## Feature-intent brief
 
@@ -29,6 +24,4 @@ Summarize the answers in five short bullets:
 - Observable success criterion
 - Boundary and explicit exclusions
 
-Ask the user to confirm or correct the brief. The intent step finishes only after explicit
-confirmation. Carry the brief into the scope step, so it maps the intent onto existing modules
-instead of restarting the feature discussion.
+Ask the user to confirm or correct the brief. The intent step finishes only after explicit confirmation. Carry the brief into the scope step, so it maps the intent onto existing modules instead of restarting the feature discussion.

package/genome/skills/implement-conformance-testing-script/SKILL.md

@@ -62,12 +62,10 @@ A PowerShell (`.ps1`) copy is optional and only for people who run the script by
    - PowerShell: `if (-not [System.IO.Path]::IsPathRooted($ConformanceTestsFolder)) { $ConformanceTestsFolder = Join-Path (Get-Location) $ConformanceTestsFolder }`
 
    Never concatenate `$current_dir/$2` at the point of use — with an absolute `$2` that produces a doubled path (`/project//abs/path/...`), the classic symptom being `ImportError: Start directory is not importable` pointing at a path that contains the project root twice.
-4. **Working directory setup.** Define a working folder at `<temp>/<lang>_<basename>` (`/tmp/<lang>_$(basename "$1")` in Bash, `Join-Path ([System.IO.Path]::GetTempPath()) "<lang>_$(Split-Path $BuildFolder -Leaf)"` in PowerShell). Wipe it (`rm -rf` / `Remove-Item -Recurse -Force`) and recreate it. Register cleanup so the folder is removed when the script exits — `trap 'rm -rf "$WORKING_FOLDER"' EXIT` in Bash, `Remove-Item -Recurse -Force` in the `finally` block in PowerShell. This folder — and **only** this folder — is where every subsequent write must land.
-4b. **Refuse conformance tests in the build folder.** Conformance and acceptance tests live in the conformance tests folder (`$2`) and nowhere else. Before anything is staged, look for them in `$1`: any file carrying a conformance or acceptance label (`conformance tests of functionality`, `conformance tests of the spec`, `acceptance test <n> of functionality`), and any test file under a folder or name that says conformance or acceptance. Found any: print each path, say they belong in the conformance tests folder, and exit `1`. See [Tests in the build folder](#tests-in-the-build-folder).
+4. **Working directory setup.** Define a working folder at `<temp>/<lang>_<basename>` (`/tmp/<lang>_$(basename "$1")` in Bash, `Join-Path ([System.IO.Path]::GetTempPath()) "<lang>_$(Split-Path $BuildFolder -Leaf)"` in PowerShell). Wipe it (`rm -rf` / `Remove-Item -Recurse -Force`) and recreate it. Register cleanup so the folder is removed when the script exits — `trap 'rm -rf "$WORKING_FOLDER"' EXIT` in Bash, `Remove-Item -Recurse -Force` in the `finally` block in PowerShell. This folder — and **only** this folder — is where every subsequent write must land. 4b. **Refuse conformance tests in the build folder.** Conformance and acceptance tests live in the conformance tests folder (`$2`) and nowhere else. Before anything is staged, look for them in `$1`: any file carrying a conformance or acceptance label (`conformance tests of functionality`, `conformance tests of the spec`, `acceptance test <n> of functionality`), and any test file under a folder or name that says conformance or acceptance. Found any: print each path, say they belong in the conformance tests folder, and exit `1`. See [Tests in the build folder](#tests-in-the-build-folder).
 5. **Copy the build.** Recursively copy everything from `<build_folder>` (`$1`) into the working folder. **Do not** copy the conformance tests — they stay where they are. After this step both `$1` (build folder) and `$2` (conformance tests folder) are treated as **read-only** for the rest of the script.
 6. **Enter the working directory.** `cd` / `Set-Location` into `<temp>/<lang>_<basename>`. If that fails, exit with code `69`. All remaining steps run from inside the working folder; they must never write back to `$1` or `$2`.
-7. **Install dependencies into an isolated environment inside `<temp>/<lang>_<basename>`.** Set up a per-working-folder dependency location (a Python venv at `./.venv`, a local `./node_modules`, a project-scoped Maven repo at `./.m2`, etc.) and install/resolve all dependencies into it. **Never** install into the source build folder (`$1`), the conformance tests folder (`$2`), the user's global cache (`~/.m2`, system-wide `pip`, `~/.cargo`, `~/.npm`, ...), or anywhere outside `<temp>/<lang>_<basename>`. If the install command fails, propagate its exit code immediately and **do not** proceed to step 8. See [Dependency isolation](#dependency-isolation).
-7b. **Static checks of the conformance tests.** Once the build and the test libraries are installed - so the tests resolve against them as they do when they run - check **the conformance tests in `$CONFORMANCE_TESTS_FOLDER`, and only them**: the formatter in check mode, the linter, and the type checker where the language has one apart from its compiler. See [Static checks of the tests](#static-checks-of-the-tests). Run every check, even after one fails, print each one's whole output, remember whether any failed - and go on to step 8 whatever they said, so one run reports both.
+7. **Install dependencies into an isolated environment inside `<temp>/<lang>_<basename>`.** Set up a per-working-folder dependency location (a Python venv at `./.venv`, a local `./node_modules`, a project-scoped Maven repo at `./.m2`, etc.) and install/resolve all dependencies into it. **Never** install into the source build folder (`$1`), the conformance tests folder (`$2`), the user's global cache (`~/.m2`, system-wide `pip`, `~/.cargo`, `~/.npm`, ...), or anywhere outside `<temp>/<lang>_<basename>`. If the install command fails, propagate its exit code immediately and **do not** proceed to step 8. See [Dependency isolation](#dependency-isolation). 7b. **Static checks of the conformance tests.** Once the build and the test libraries are installed - so the tests resolve against them as they do when they run - check **the conformance tests in `$CONFORMANCE_TESTS_FOLDER`, and only them**: the formatter in check mode, the linter, and the type checker where the language has one apart from its compiler. See [Static checks of the tests](#static-checks-of-the-tests). Run every check, even after one fails, print each one's whole output, remember whether any failed - and go on to step 8 whatever they said, so one run reports both.
 8. **Run the conformance tests.** Invoke the language's standard test command, **pointed at `$CONFORMANCE_TESTS_FOLDER`** (the absolute path resolved in step 3) **and at nothing else**, so it runs the whole suite in one go - and only it. The build's own tests (its unit tests, and anything else in it) are never collected: no discovery from the working folder, and no test configuration in the build (a `pytest.ini` / `pyproject.toml` `testpaths`, a Jest `roots`) allowed to widen the run beyond `$CONFORMANCE_TESTS_FOLDER`. The script's final exit code is whatever the test command returns — except for the "no tests discovered" case below.
 
    Then exit: the test command's own non-zero code when the suite failed; else `80` when only the static checks of step 7b failed; else `0`.
@@ -158,8 +156,7 @@ Shared across both shell flavors:
   - **Print the toolchain's own `--version` output** (and the path it resolved from) during step 1, even on success. This is the single most useful piece of forensic data when conformance passes on one machine but fails on another.
   - **Surface the install output verbatim** — do not pipe it to `/dev/null`, do not redirect to a log file inside the working folder. The operator must see every dependency-resolver line in the script's own output stream. Drop the `VERBOSE`-gated wrapping from the Python reference — conformance output is where forensic data is most valuable.
   - **On failure, print what was about to run before exiting** — the exact test command, the working directory, the resolved `$CONFORMANCE_TESTS_FOLDER`, and the relevant environment variables (`PYTHONPATH`, `NODE_PATH`, `GOMODCACHE`, `CARGO_HOME`, `MAVEN_OPTS`, `PATH`, plus `VIRTUAL_ENV` for Python).
-  - **Print a final summary line** that names the test command, the exit code, the resolved conformance-tests folder, and the working folder so the operator knows exactly what to re-run by hand if needed.
-  Verbosity is not noise here — a chatty script that documents itself in its own output is the difference between a 30-second triage and a 30-minute one. Never trade verbosity for terseness.
+  - **Print a final summary line** that names the test command, the exit code, the resolved conformance-tests folder, and the working folder so the operator knows exactly what to re-run by hand if needed. Verbosity is not noise here — a chatty script that documents itself in its own output is the difference between a 30-second triage and a 30-minute one. Never trade verbosity for terseness.
 - **Resolve `$2` before any `cd`.** This is the single most common bug in hand-written conformance scripts: using the conformance-tests argument after changing directory. Resolve it to an absolute path in step 3 (absolute → use as-is; relative → prefix the invocation directory) and use only the resolved variable afterwards. The resolved value must also appear in the verbose log (per the logging rule above) so misresolutions of `$2` are visible at a glance.
 
 ### Dependency isolation

package/genome/skills/implement-unit-testing-script/SKILL.md

@@ -72,8 +72,7 @@ Shared across both shell flavors:
   - **Print the toolchain's own `--version` output** (and the path it resolved from) during step 1, even on success. This is the single most useful piece of forensic data when a test passes locally but fails in CI.
   - **Surface the install command's output verbatim** — do not pipe it to `/dev/null`, do not redirect to a log file inside the working folder. The operator must see every dependency-resolver line in the script's own output stream.
   - **On failure, print what was about to run before exiting** — the exact command, the working directory, the relevant environment variables (`PYTHONPATH`, `NODE_PATH`, `GOMODCACHE`, `CARGO_HOME`, `MAVEN_OPTS`, `PATH`).
-  - **Print a final summary line** that names the test command, the exit code, and the working folder so the operator knows exactly what to re-run by hand if needed.
-  Verbosity is not noise here — a chatty script that documents itself in its own output is the difference between a 30-second triage and a 30-minute one. Never trade verbosity for terseness.
+  - **Print a final summary line** that names the test command, the exit code, and the working folder so the operator knows exactly what to re-run by hand if needed. Verbosity is not noise here — a chatty script that documents itself in its own output is the difference between a 30-second triage and a 30-minute one. Never trade verbosity for terseness.
 
 ### Dependency isolation