@turri-dev/cli 0.1.27 → 0.2.0

package/genome/skills/debug-specs/SKILL.md

@@ -2,7 +2,7 @@
 name: debug-specs
 description: >-
   Investigate a bug observed in the running application by reading the generated
-  code in plain_modules/, tracing the issue back to the specs, and fixing only
+  code in plain_modules/, tracing the issue back to the ***plain, and fixing only
   the .plain files. Generated code is never modified. Use when the user reports
   unexpected behavior, visual glitches, crashes, or incorrect logic in the app.
 allowed-tools: [read, write, edit, bash, ls, grep, find]
@@ -19,17 +19,17 @@ allowed-tools: [read, write, edit, bash, ls, grep, find]
 
 ## Guiding Principle
 
-Generated code in `plain_modules/<module>/code/` and `plain_modules/<module>/tests/` is **read-only** — it exists solely as evidence for diagnosis. All fixes are applied exclusively to the `.plain` spec files. The workflow is: observe → read generated code → trace to spec → fix the spec.
+Generated code in `plain_modules/<module>/code/` and `plain_modules/<module>/tests/` is **read-only** — it exists solely as evidence for diagnosis. All fixes are applied exclusively to the `.plain` files. The workflow is: observe → read generated code → trace to the ***plain → fix the ***plain.
 
 ## Input
 
 1. **The module name** — identifies the `plain_modules/<module_name>/` directory (`code/` and `tests/`) and the corresponding `.plain` file(s).
 2. **The user's observation** — what is wrong? This can be a bug description, a screenshot, a test failure, an error message, or a general "this doesn't work right."
-3. **Optional: a specific functional spec** — if the user suspects a particular spec, start there. Otherwise, investigate broadly.
+3. **Optional: a specific functional spec** — if the user suspects a particular functional spec, start there. Otherwise, investigate broadly.
 
 ## Phase 1 — Understand the Context
 
-1. **Read the `.plain` file(s)** for the module — frontmatter, definitions, implementation reqs, test reqs, and all functional specs. Also read `import` and `requires` chains.
+1. **Read the `.plain` file(s)** for the module — frontmatter, definitions, implementation reqs, test reqs, and all functional specs. Also read `import` and `requires` chains, and the module's test plain files.
 2. **Read the user's observation carefully.** Rephrase it back to confirm understanding. Identify:
    - What is the expected behavior?
    - What is the actual behavior?
@@ -37,12 +37,12 @@ Generated code in `plain_modules/<module>/code/` and `plain_modules/<module>/tes
 
 ## Phase 2 — Investigate the Generated Code
 
-Read files in `plain_modules/<module_name>/code/` to understand what the renderer produced. **Do not modify any generated files.**
+Read files in `plain_modules/<module_name>/code/` to understand what the coding agent produced. **Do not modify any generated files.**
 
 ### 2a. Narrow the search
 
-If the user pointed to a specific spec or area:
-- Identify which generated files implement that spec's behavior.
+If the user pointed to a specific functional spec or area:
+- Identify which generated files implement that functional spec's behavior.
 - Read those files to understand the current implementation.
 
 If the investigation is broad:
@@ -53,60 +53,65 @@ If the investigation is broad:
 
 For each relevant file:
 1. Read the code and understand what it does.
-2. Compare the behavior to what the spec says it should do.
-3. Note any discrepancies — places where the code doesn't match the spec's intent.
+2. Compare the behavior to what the functional spec says it should do.
+3. Note any discrepancies — places where the code doesn't match the functional spec's intent.
 
 ### 2c. Check conformance tests and unit tests (if relevant)
 
 If the bug manifests as a test failure:
-1. Read the failing test — conformance tests in `plain_modules/<module_name>/tests/` (the module's whole suite, no per-functionality subfolders), unit tests inside `plain_modules/<module_name>/code/`.
+1. Read the failing test — conformance tests in `plain_modules/<module_name>/tests/` (the module's whole suite, no per-functional-spec subfolders), each labelled with the scenario it implements (`conformance scenario <scenario-id> of <module>:<func-id>`, `acceptance scenario <scenario-id> of <module>:<func-id>`), unit tests inside `plain_modules/<module_name>/code/`.
 2. Understand what the test expects vs. what the implementation does.
-3. Determine whether the test expectation is correct (matches the spec) or incorrect (doesn't match the spec).
+3. Determine whether the test expectation is correct (matches the functional spec) or incorrect (doesn't match the functional spec).
 
 ## Phase 3 — Diagnose the Root Cause
 
-Trace the issue from the generated code back to the specs. There are five possible root causes — determine which one applies **before** making changes:
+Trace the issue from the generated code back to the ***plain. There are six possible root causes — determine which one applies **before** making changes:
 
 | Root Cause | Symptom | Fix |
 |------------|---------|-----|
-| **Ambiguous spec** | The spec is correct in intent, but vague enough that the renderer interpreted it differently than intended. | Add explicit detail to the spec to eliminate the ambiguity. |
-| **Missing spec** | The desired behavior is not covered by any spec. The renderer had no guidance and either did nothing or made an arbitrary choice. | Add a new functional spec, checked as `func-specs.md` says (*Adding a functional spec*). |
-| **Conflicting specs** | Two specs contradict each other, causing the renderer to produce inconsistent behavior. | Use the `resolve-spec-conflict` skill. |
-| **Incorrect spec** | The spec explicitly describes the wrong behavior. The renderer implemented it faithfully, but the spec itself is wrong. | Rewrite the spec to describe the correct behavior. |
-| **Missing implementation req** | The spec is correct, but the implementation req doesn't provide enough guidance for the renderer to produce the right code (e.g., missing library, missing architectural constraint, missing platform detail). | Add or update the implementation req, per `impl-reqs.md`. |
+| **Ambiguous functional spec** | The functional spec is correct in intent, but vague enough that the coding agent interpreted it differently than intended. | Add explicit detail to the functional spec to eliminate the ambiguity. |
+| **Missing functional spec** | The desired behavior is not covered by any functional spec. The coding agent had no guidance and either did nothing or made an arbitrary choice. | Add a new functional spec, checked as `func-specs.md` says (*Adding a functional spec*). |
+| **Conflicting functional specs** | Two functional specs contradict each other, causing the coding agent to produce inconsistent behavior. | Use the `resolve-spec-conflict` skill. |
+| **Incorrect functional spec** | The functional spec explicitly describes the wrong behavior. The coding agent implemented it faithfully, but the functional spec itself is wrong. | Rewrite the functional spec to describe the correct behavior. |
+| **Incorrect scenario** | The functional spec is correct and the code matches it, but a scenario in its test plain file expects an outcome the functional spec does not state, or contradicts one it states. | Fix the scenario in the test plain file (`test-plain-files.md`). |
+| **Missing implementation req** | The functional spec is correct, but the implementation req doesn't provide enough guidance for the coding agent to produce the right code (e.g., missing library, missing architectural constraint, missing platform detail). | Add or update the implementation req, per `impl-reqs.md`. |
 
 ### How to diagnose
 
-1. **Read the spec that governs the buggy behavior.** Does it clearly and unambiguously describe the correct behavior?
-   - If the spec is clear and correct but the code is wrong → **ambiguous spec** (the renderer misinterpreted it) or **missing implementation req**.
-   - If the spec doesn't mention the behavior at all → **missing spec**.
-   - If the spec explicitly describes the wrong behavior → **incorrect spec**.
-2. **Check for conflicts.** Could another spec be overriding or contradicting this behavior?
+1. **Read the functional spec that governs the buggy behavior.** Does it clearly and unambiguously describe the correct behavior?
+   - If the functional spec is clear and correct but the code is wrong → **ambiguous functional spec** (the coding agent misinterpreted it) or **missing implementation req**.
+   - If the functional spec doesn't mention the behavior at all → **missing functional spec**.
+   - If the functional spec explicitly describes the wrong behavior → **incorrect functional spec**.
+2. **Check for conflicts.** Could another functional spec be overriding or contradicting this behavior?
    - Read all functional specs that touch the same concepts.
-   - If two specs are in tension → **conflicting specs**.
-3. **Check implementation reqs.** Is the renderer missing guidance on how to implement correctly?
+   - If two functional specs are in tension → **conflicting functional specs**.
+3. **Check the scenario.** When a conformance or acceptance test fails, find its scenario by the scenario-id in the test's label and compare it with the functional spec.
+   - If the scenario contradicts or extends the functional spec → **incorrect scenario**.
+4. **Check implementation reqs.** Is the coding agent missing guidance on how to implement correctly?
    - Does the implementation req specify the right library, pattern, or constraint?
    - If a platform-specific or framework-specific detail is missing → **missing implementation req**.
 
-## Phase 4 — Fix the Specs
+## Phase 4 — Fix the ***plain
 
 Apply the fix based on the diagnosed root cause:
 
 | Root Cause | How |
 |------------|-------------|
-| Ambiguous spec | Edit the spec inline — add sub-bullets or reword for clarity |
-| Missing spec | `func-specs.md`, *Adding a functional spec* |
-| Conflicting specs | `resolve-spec-conflict` |
-| Incorrect spec | Edit the spec inline — rewrite the incorrect part |
+| Ambiguous functional spec | Edit the functional spec inline — add detail under its statement line or reword for clarity |
+| Missing functional spec | `func-specs.md`, *Adding a functional spec* |
+| Conflicting functional specs | `resolve-spec-conflict` |
+| Incorrect functional spec | Edit the functional spec inline — rewrite the incorrect part |
+| Incorrect scenario | `test-plain-files.md` - change or take out the scenario |
 | Missing implementation req | `impl-reqs.md` |
 
 ### Fix guidelines
 
-- **Minimal changes.** Only modify what is necessary to fix the observed bug. Avoid rewriting unrelated specs.
-- **Preserve chronological order.** If adding a new spec, place it correctly relative to existing specs.
+- **Minimal changes.** Only modify what is necessary to fix the observed bug. Avoid rewriting unrelated functional specs.
+- **Preserve chronological order.** If adding a new functional spec, place it correctly relative to the existing ones.
 - **Stay language-agnostic.** Functional specs describe behavior, not implementation. Platform-specific guidance belongs in implementation reqs.
-- **Respect the 200 LOC limit.** If a fix makes a spec too complex, use `break-down-func-spec` to split it.
-- **Check for new conflicts.** After editing, verify the fix doesn't conflict with other specs by running `analyze-func-specs` once with the edited spec(s) plus every existing spec that touches the same concepts. The batched analyzer reports all conflicting pairs in a single call; resolve each with `resolve-spec-conflict`.
+- **Respect the 200 LOC limit.** If a fix makes a functional spec too complex, use `break-down-func-spec` to split it.
+- **Keep the test plain file in step.** A functional spec you change has its scenarios, if it has any, reviewed in the same ***plain diff, so they still follow from it (`test-plain-files.md`).
+- **Check for new conflicts.** After editing, verify the fix doesn't conflict with other functional specs by running `analyze-func-specs` once with the edited functional spec(s) plus every existing functional spec that touches the same concepts. The batched analyzer reports all conflicting pairs in a single call; resolve each with `resolve-spec-conflict`.
 
 ## Phase 5 — Verify and Report
 
@@ -114,30 +119,30 @@ Apply the fix based on the diagnosed root cause:
 2. **Summarize the findings** for the user:
    - What was observed (the bug)
    - What the generated code was doing (the symptom in code)
-   - Which spec(s) caused the issue (the root cause)
-   - What was changed in the specs (the fix)
-   - What to expect after re-rendering
+   - Which functional spec(s) caused the issue (the root cause)
+   - What was changed in the ***plain (the fix)
+   - What to expect after regenerating
 3. **If uncertain**, present the diagnosis and proposed fix to the user for confirmation before making changes. Some bugs have multiple possible causes — when in doubt, explain the options and let the user decide.
 
 ## Debugging Strategies
 
 ### Strategy 1: Observation-Driven (most common)
 
-Start from the user's observation and work backward through the code to the spec.
+Start from the user's observation and work backward through the code to the functional spec.
 
 ```
 User sees bug → Read generated code → Find the responsible code path →
-Identify which spec governs that code → Diagnose why the spec produced wrong code →
-Fix the spec
+Identify which functional spec governs that code → Diagnose why the functional spec produced wrong code →
+Fix the ***plain
 ```
 
 ### Strategy 2: Spec-Focused
 
-The user suspects a specific spec. Compare the spec directly against the generated code.
+The user suspects a specific functional spec. Compare the functional spec directly against the generated code.
 
 ```
-User points to spec → Read the spec → Find the generated code that implements it →
-Compare spec intent vs. code behavior → Diagnose the gap → Fix the spec
+User points to functional spec → Read the functional spec → Find the generated code that implements it →
+Compare functional spec intent vs. code behavior → Diagnose the gap → Fix the ***plain
 ```
 
 ### Strategy 3: Test-Failure-Driven
@@ -146,43 +151,44 @@ A test is failing. Use the test as the entry point.
 
 ```
 Read failing test → Understand what it expects → Read the implementation →
-Determine if the test or the implementation is wrong → Trace back to the spec →
-Fix the spec (or test reqs/acceptance tests if the test itself is wrong)
+Determine if the test or the implementation is wrong → Trace back to the ***plain →
+Fix the ***plain (or the test reqs / the scenario in the test plain file if the test itself is wrong)
 ```
 
 ### Strategy 4: Differential
 
-The bug appeared after a new spec was added. Compare before and after.
+The bug appeared after a new functional spec was added. Compare before and after.
 
 ```
-Identify the newly added spec → Read the specs it might conflict with →
-Check if the new spec introduced the bug → Use resolve-spec-conflict or
-revise the new spec
+Identify the newly added functional spec → Read the functional specs it might conflict with →
+Check if the new functional spec introduced the bug → Use resolve-spec-conflict or
+revise the new functional spec
 ```
 
 ## Common Pitfalls
 
-### Fixing the code instead of the spec
-Never modify files in `plain_modules/<module>/code/` or `plain_modules/<module>/tests/`. Even if the fix is obvious in the code, the change must be made in the `.plain` file so it persists across re-renders.
+### Fixing the code instead of the ***plain
+Never modify files in `plain_modules/<module>/code/` or `plain_modules/<module>/tests/`. Even if the fix is obvious in the code, the change must be made in the `.plain` file so it persists across regenerations.
 
 ### Treating symptoms instead of root causes
-If the user says "the button is in the wrong place," don't just add positioning detail. Investigate why the renderer placed it there — the root cause might be a missing layout spec, an ambiguous screen description, or a conflict with another spec.
+If the user says "the button is in the wrong place," don't just add positioning detail. Investigate why the coding agent placed it there — the root cause might be a missing layout functional spec, an ambiguous screen description, or a conflict with another functional spec.
 
 ### Over-specifying the fix
 Adding too much implementation detail to a functional spec (e.g., specific pixel values, widget names, CSS properties) makes it brittle. Prefer behavior-level fixes. Use implementation reqs for platform-specific guidance.
 
 ### Ignoring ripple effects
-A spec fix may affect other specs that reference the same concepts. Always check neighboring specs for conflicts after making a change.
+A fix to one functional spec may affect others that reference the same concepts. Always check neighboring functional specs for conflicts after making a change.
 
 ## Validation Checklist
 
 - [ ] User's observation is clearly understood (expected vs. actual behavior)
 - [ ] Generated code has been read to understand the current implementation
-- [ ] Root cause is diagnosed (ambiguous / missing / conflicting / incorrect / missing impl req)
+- [ ] Root cause is diagnosed (ambiguous / missing / conflicting / incorrect / incorrect scenario / missing impl req)
 - [ ] Fix is applied in the `.plain` file(s) only — no generated code modified
 - [ ] Fix is minimal and targeted to the observed bug
-- [ ] Fix does not introduce new conflicts with existing specs
-- [ ] Modified specs respect the 200 LOC limit
-- [ ] Modified specs remain language-agnostic
+- [ ] Fix does not introduce new conflicts with existing functional specs
+- [ ] Modified functional specs respect the 200 LOC limit
+- [ ] Modified functional specs remain language-agnostic
 - [ ] Chronological ordering is preserved
+- [ ] Test plain file of every changed functional spec in step with it
 - [ ] Summary of findings and fix presented to the user

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

@@ -10,6 +10,10 @@ description: >-
   a new language (Node.js, Go, Rust, Flutter, etc.) to a ***plain project, or
   wants to regenerate / adapt one of the existing runners.
 allowed-tools: [read, write, edit, bash, ls, grep, find]
+metadata:
+  # In the chat it runs in the background, on the coding model of the module it is for: its end comes back to the chat.
+  background: true
+  model: coding
 ---
 
 # Implement Conformance Testing Script
@@ -26,9 +30,9 @@ Read both `.sh` references before writing anything — every script you produce
 
 ## How the harness uses the script
 
-A module's conformance tests live in one folder, `plain_modules/<module>/tests` — the module's whole conformance suite: every functionality's tests, plus those carried up from the modules it requires. There are no per-functionality subfolders.
+A module's conformance tests live in one folder, `plain_modules/<module>/tests` — the module's whole conformance suite: every functional spec's tests, plus those carried up from the modules it requires. There are no per-functional-spec subfolders.
 
-The harness (not the rendering agent) runs the script once per check, against the whole suite:
+turri (not the agent that writes the tests) runs the script once per check, against the whole suite:
 
 ```
 bash run_conformance_tests_<lang>.sh <build_folder> <conformance_tests_folder>
@@ -42,7 +46,7 @@ Every conformance script is self-contained: toolchain check, argument validation
 
 A conformance script is structurally very close to a unit-test script (see the sibling skill [`implement-unit-testing-script`](../implement-unit-testing-script/SKILL.md)) but with two important differences:
 
-1. **Two positional arguments instead of one.** A conformance script takes both the **build folder** (source under test) and a **separate conformance tests folder** (the tests to execute against that build). Both arrive as **absolute paths** from current renderers (older renderer versions passed relative ones) — the script must work with both.
+1. **Two positional arguments instead of one.** A conformance script takes both the **build folder** (source under test) and a **separate conformance tests folder** (the tests to execute against that build). Both arrive from turri as **absolute paths** (older harnesses passed relative ones) — the script must work with both.
 2. **Tests are loaded from outside the working folder.** The build is staged into the working folder `<temp>/<lang>_<basename>` (system temp directory + language id + basename of `$1` — see [Conventions](#conventions)) and the script `cd`s into it, but the test command is pointed at the conformance tests folder, resolved to an **absolute path** up front (`$CONFORMANCE_TESTS_FOLDER` below). Tests are never copied into the staging area.
 
 Everything else — toolchain check, build staging, dependency isolation, exit codes — is the same.
@@ -57,12 +61,12 @@ A PowerShell (`.ps1`) copy is optional and only for people who run the script by
 
 1. **Toolchain check.** Verify that the required language runtime / build tool (and the required version, if any) is installed. If not, print an error and exit with code `69`.
 2. **Argument validation.** Require **two** positional arguments: `<build_folder>` and `<conformance_tests_folder>`. If either is missing, print usage and exit with code `69`.
-3. **Resolve the conformance tests folder to an absolute path.** Current renderers pass `$2` as an absolute path; older ones passed it relative to the invocation directory. Resolve it once, up front, into a variable the test command in step 8 uses:
+3. **Resolve the conformance tests folder to an absolute path.** turri passes `$2` as an absolute path; older harnesses passed it relative to the invocation directory. Resolve it once, up front, into a variable the test command in step 8 uses:
    - Bash: `case "$2" in /*) CONFORMANCE_TESTS_FOLDER="$2" ;; *) CONFORMANCE_TESTS_FOLDER="$(pwd)/$2" ;; esac`
    - 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 <module>:<func-id>`, `conformance scenario <scenario-id> of <module>:<func-id>`, `acceptance scenario <scenario-id> of <module>:<func-id>`), 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.
@@ -83,7 +87,7 @@ A conformance script has **two** read-only inputs: the source build folder (`$1`
 
 Why each input is read-only:
 
-- **`$1` (build folder)** is shared with the renderer (`plain_modules/<module>/code` by default) and downstream tooling. Writing into it corrupts the renderer's view of "what was generated" and breaks subsequent renders. The whole point of staging into the system temp directory is so the source folder stays a clean, reproducible artifact of the render.
+- **`$1` (build folder)** is shared with turri (`plain_modules/<module>/code` by default) and downstream tooling. Writing into it corrupts turri's view of "what was generated" and breaks subsequent regenerations. The whole point of staging into the system temp directory is so the source folder stays a clean, reproducible artifact of the regeneration.
 - **`$2` (conformance tests folder)** is the user's authored test source — typically checked into version control. Writing into it pollutes the working tree, churns git status, and (with frameworks that auto-discover) can make subsequent runs pick up generated files as if they were tests.
 
 If you find yourself about to issue any command whose `cwd` is `$1` or `$2`, or whose target path starts with `$1/` or `$2/`, **stop**. Either move the operation into `<temp>/<lang>_<basename>`, or you're doing something the script must not do.
@@ -94,7 +98,7 @@ A conformance test written into the build folder is in the wrong place: nothing
 
 ```bash
 MISPLACED=$(grep -rlE --exclude=".turri*" --exclude-dir=.venv --exclude-dir=node_modules --exclude-dir=target \
-  "conformance tests of (functionality [0-9]|the spec)|acceptance test [0-9]+ of functionality" "$1" 2>/dev/null; \
+  "(conformance tests|(conformance|acceptance) scenario [a-z0-9-]+) of [^[:space:]:]+:[a-z0-9-]+" "$1" 2>/dev/null; \
   find "$1" -type f \( -ipath "*conformance*" -o -ipath "*acceptance*" \) -iname "*test*" \
   -not -name ".turri*" -not -path "*/.venv/*" -not -path "*/node_modules/*" -not -path "*/target/*" 2>/dev/null)
 if [ -n "$MISPLACED" ]; then
@@ -148,7 +152,7 @@ Shared across both shell flavors:
   - Any other non-zero code — propagated from the underlying test command.
 - **Working folder naming:** `<temp>/<lang>_<basename>` — the system temp directory (`/tmp` in Bash, `[System.IO.Path]::GetTempPath()` in PowerShell) plus a short identifier for the language (`java`, `python`, `node`, `go`, `rust`, ...) and the **basename** of the *first* argument (the build folder — `$(basename "$1")` / `Split-Path $BuildFolder -Leaf`), never the conformance tests folder and never the raw argument (it may be absolute; concatenating it produces broken doubled paths). All dependency installs, build outputs, caches, test runner artifacts, and the test invocation itself live inside this folder. Nothing the script does should touch `$1` after step 5, or `$2` at any point.
 - **Cleanup ownership:** the script owns its working folder and removes it on exit, success and failure alike (`trap 'rm -rf "$WORKING_FOLDER"' EXIT` in Bash; `Remove-Item -Recurse -Force` in the PowerShell `finally` block, after `Pop-Location`).
-- **Logging — be as verbose as possible.** The script is the only thing the operator sees between a `turri` render and a green/red conformance result; when it fails, the only forensic evidence anyone has is its stdout/stderr. Treat the script like a production runbook, not a quiet helper. Concretely:
+- **Logging — be as verbose as possible.** The script is the only thing the operator sees between a `turri` regeneration and a green/red conformance result; when it fails, the only forensic evidence anyone has is its stdout/stderr. Treat the script like a production runbook, not a quiet helper. Concretely:
   - **Announce every step before doing it**, with the exact value of every variable involved — the resolved build folder, the resolved conformance-tests folder, the working folder, the language, the toolchain version detected, the isolation root being set up, and the test command about to run. "Running tests" alone is useless; "Running `python -m unittest discover -b -s /abs/path/to/tests` from working folder `/tmp/python_build/` with venv activated at `./.venv` (Python 3.11.6)" is triage-ready.
   - **Echo every non-trivial command before executing it.** In Bash, use `set -x` for the body of the script (or `echo "+ <cmd>"` immediately before each call); in PowerShell, set `$VerbosePreference = 'Continue'` and use `Write-Verbose` / `Write-Host` to print each command line with its arguments.
   - **Print clear section banners.** Each pattern step gets a banner like `===== [7/8] Install dependencies =====` so a long log can be navigated by eye.
@@ -202,26 +206,26 @@ The harness never runs `.ps1` scripts. These notes apply only to an optional cop
 
 ## Workflow
 
-1. Confirm the target **language** and **dependency manifest** (`pom.xml`, `requirements.txt` / `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`, ...). Ask if either is unclear.
+1. Take the target **language**, **conformance test framework** and **dependency manifest** (`pom.xml`, `requirements.txt` / `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`, ...) from the module the script is for: its stack - the `stdlib/...` template it imports, and its conformance template `stdlib/<kind>/conformance/<stack>` - its ***test reqs***, and the project. You run in the background, with nobody to ask: decide what they leave open, the choice most consistent with them, and say what you decided in your result.
 2. Read [assets/run_conformance_tests_java.sh](assets/run_conformance_tests_java.sh) and [assets/run_conformance_tests_python.sh](assets/run_conformance_tests_python.sh) to refresh the exact structure.
 3. Translate each step into the equivalent Bash commands for the target language. The toolchain check, dependency install, and test invocation are the language-specific parts; the rest is mechanical.
 4. Pick the right row from the [Dependency isolation](#dependency-isolation) table — use the same flag/env var in steps 7, 7b and 8 — and the checks from [Static checks of the tests](#static-checks-of-the-tests).
 5. Add the language-appropriate "no tests discovered" guard from [No tests discovered detection](#no-tests-discovered-detection), and the guard against conformance tests in the build folder from [Tests in the build folder](#tests-in-the-build-folder).
 6. Save the new script as `test_scripts/run_conformance_tests_<lang>.sh` and `chmod +x` it. Write a `.ps1` copy only if the user wants to run it by hand on Windows.
-7. **Make sure turri finds the script.** Do not link it from the specs - turri finds the conformance testing script in the project root (the folder that holds `plain_modules/`) and puts it, whole, into the prompts of the agents that write and review the conformance tests itself, whenever conformance tests are written for a build; a link to it from a spec is ignored. It looks, in order, at `config.turri.yaml` in the root (`conformance-tests-script: <path relative to the root>`) - with the chosen stack's `config.turri.<stack>.yaml` over it, then for the one `run_conformance_tests*.sh` in the root, then for the one in `test_scripts/`. Saving the script in `test_scripts/` (or the root) is enough when it is the only one there. If the project keeps it elsewhere, name it in `config.turri.yaml` as `conformance-tests-script:` - and 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 edit the copy; `config.yaml` may be another tool's, and is never written. If the project has modules on different stacks - e.g. a Python backend and a React frontend side by side, sharing only an imported module - each part is on a stack of its own, and each stack names its own script in its own file beside `config.turri.yaml`: `conformance-tests-script:` in `config.turri.backend.yaml` for the stack `backend`, in `config.turri.frontend.yaml` for the stack `frontend`. Name each stack after the module it builds - `config.turri.backend.yaml` for `backend.plain` - and that module is built with it by itself, with nothing to choose; a stack named otherwise is passed as `stack` to `regenerate` in the chat, or `--stack <stack>` on the command line. turri never guesses between two. The script is required: with conformance testing on, a build without one stops before it starts. The `***test reqs***` still describe the conformance framework and command in words; do not paraphrase the script into them.
+7. **Make sure turri finds the script.** Do not link it from the ***plain - turri finds the conformance testing script in the project root (the folder that holds `plain_modules/`) and puts it, whole, into the prompts of the agents that write and review the conformance tests itself, whenever conformance tests are written for a build; a link to it from the ***plain is ignored. It looks, in order, at `config.turri.yaml` in the root (`conformance-tests-script: <path relative to the root>`) - with the chosen stack's `config.turri.<stack>.yaml` over it, then for the one `run_conformance_tests*.sh` in the root, then for the one in `test_scripts/`. Saving the script in `test_scripts/` (or the root) is enough when it is the only one there. If the project keeps it elsewhere, name it in `config.turri.yaml` as `conformance-tests-script:` - and 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 edit the copy; `config.yaml` may be another tool's, and is never written. If the project has modules on different stacks - e.g. a Python backend and a React frontend side by side, sharing only an imported module - each part is on a stack of its own, and each stack names its own script in its own file beside `config.turri.yaml`: `conformance-tests-script:` in `config.turri.backend.yaml` for the stack `backend`, in `config.turri.frontend.yaml` for the stack `frontend`. Name each stack after the module it builds - `config.turri.backend.yaml` for `backend.plain` - and that module is built with it by itself, with nothing to choose; a stack named otherwise is passed as `stack` to `regenerate` in the chat, or `--stack <stack>` on the command line. turri never guesses between two. The script is required: without one, no conformance or acceptance test is written or run. The `***test reqs***` still describe the conformance framework and command in words; do not paraphrase the script into them.
 
 ## Anti-Patterns
 
-- **(Hard mistake) Don't install into, build into, or otherwise write to the source build folder (`$1`) or the conformance tests folder (`$2`).** Both arguments are read-only input. Every install, cache, build artifact, log, JUnit XML, coverage report, compiled test class, and temp file must land in `<temp>/<lang>_<basename>`. This includes never running `pip install`, `npm install`, `mvn install`, or `cargo build` with `$1` or `$2` as their `cwd` or target; never letting a venv / `node_modules` / `.m2` / `.gocache` / `.cargo` directory appear inside `$1` or `$2`; and never running the test command from inside either folder. The whole point of staging into the system temp directory is so the build folder remains a clean artifact of the render and the conformance tests folder remains a clean tree under the user's version control — writing to either one corrupts those guarantees.
-- **(Hard mistake) Don't build any path by concatenating a raw argument.** `$1` and `$2` arrive as absolute paths from current renderers. Patterns like `WORKING_FOLDER=.tmp/$1`, `WORKING_FOLDER=<lang>_$1`, or `"$current_dir/$2"` silently produce doubled paths (`/project//abs/path/...`) — the classic symptom is `ImportError: Start directory is not importable` or "folder does not exist" pointing at a path that contains the project root twice. Always derive the working folder from `$(basename "$1")` / `Split-Path -Leaf`, and use the `$CONFORMANCE_TESTS_FOLDER` resolved in step 3.
+- **(Hard mistake) Don't install into, build into, or otherwise write to the source build folder (`$1`) or the conformance tests folder (`$2`).** Both arguments are read-only input. Every install, cache, build artifact, log, JUnit XML, coverage report, compiled test class, and temp file must land in `<temp>/<lang>_<basename>`. This includes never running `pip install`, `npm install`, `mvn install`, or `cargo build` with `$1` or `$2` as their `cwd` or target; never letting a venv / `node_modules` / `.m2` / `.gocache` / `.cargo` directory appear inside `$1` or `$2`; and never running the test command from inside either folder. The whole point of staging into the system temp directory is so the build folder remains a clean artifact of the regeneration and the conformance tests folder remains a clean tree under the user's version control — writing to either one corrupts those guarantees.
+- **(Hard mistake) Don't build any path by concatenating a raw argument.** `$1` and `$2` arrive from turri as absolute paths. Patterns like `WORKING_FOLDER=.tmp/$1`, `WORKING_FOLDER=<lang>_$1`, or `"$current_dir/$2"` silently produce doubled paths (`/project//abs/path/...`) — the classic symptom is `ImportError: Start directory is not importable` or "folder does not exist" pointing at a path that contains the project root twice. Always derive the working folder from `$(basename "$1")` / `Split-Path -Leaf`, and use the `$CONFORMANCE_TESTS_FOLDER` resolved in step 3.
 - **Don't rely on anything being set up before the script runs.** The script is self-contained: it stages the build and installs dependencies itself, every time. Don't look for a pre-warmed working folder or environment left by an earlier run.
 - **Don't copy the conformance tests folder into the working folder.** Only the build folder is staged. The test folder is read in place from `$CONFORMANCE_TESTS_FOLDER`.
 - **Don't compute the test path after `cd`.** Resolve `$2` to an absolute path in step 3; otherwise a relative `$2` will be resolved against the working folder and silently miss the tests.
-- **Don't expect per-functionality subfolders in `$2`.** `$2` holds the module's whole conformance suite; point the test command at it and let the runner discover every test in it.
+- **Don't expect per-functional-spec subfolders in `$2`.** `$2` holds the module's whole conformance suite; point the test command at it and let the runner discover every test in it.
 - **Don't run tests from anywhere but the conformance tests folder, and don't let conformance tests in the build folder pass unnoticed.** The build's tests are the unit testing script's; a conformance test in the build folder is misplaced, and the script fails on it (step 4b) instead of running it or ignoring it.
 - **Don't skip the "no tests discovered" check.** A conformance suite that finds zero tests and exits `0` is the worst possible failure mode — it looks like success.
 - **Don't skip the toolchain check**, even when "everyone has it installed" — exit code `69` is what the calling system relies on to detect a missing runtime.
-- **Don't reuse the source folder in place.** Always copy into `<temp>/<lang>_<basename>` first; the renderer relies on this isolation.
+- **Don't reuse the source folder in place.** Always copy into `<temp>/<lang>_<basename>` first; turri relies on this isolation.
 - **Don't skip cleanup.** Register the `trap` / `finally` removal of the working folder right after creating it, so it is removed on success and failure alike.
 - **Don't change the exit-code contract.** Other parts of the system branch on `69`, `1` and `80` specifically — and these codes must be identical between the Bash script and any PowerShell copy.
 - **Don't check the tests on their own, or the code with them.** The checks run after the install, against what the tests run with, and report the tests' findings alone.
@@ -231,5 +235,5 @@ The harness never runs `.ps1` scripts. These notes apply only to an optional cop
 - **Don't ship only a `.ps1`.** The harness runs `.sh` scripts only; a project with just a PowerShell runner has no conformance testing script as far as turri is concerned.
 - **Don't install dependencies into the user's global location** (`~/.m2`, system-wide `pip`, `~/.cargo`, etc.). Always isolate inside `$WORKING_FOLDER` so concurrent runs and other projects can't interfere.
 - **Don't run the test command without first verifying the install succeeded.** A failed install followed by a "test" run produces misleading errors that look like test failures.
-- **Don't link the script from the specs, and don't leave turri guessing.** turri finds the script in `config.turri.yaml`, the project root, or `test_scripts/`, shows it to the agents that write the conformance tests itself, and stops before the build starts without it; a link to it from a spec is ignored. Put it where it is found, and when there are two conformance testing scripts in one folder, name the one to use as `conformance-tests-script:` - in each stack's `config.turri.<stack>.yaml` when they are for parts on different stacks (see Workflow step 7).
+- **Don't link the script from the ***plain, and don't leave turri guessing.** turri finds the script in `config.turri.yaml`, the project root, or `test_scripts/`, shows it to the agents that write the conformance tests itself, and writes or runs no conformance test without it; a link to it from the ***plain is ignored. Put it where it is found, and when there are two conformance testing scripts in one folder, name the one to use as `conformance-tests-script:` - in each stack's `config.turri.<stack>.yaml` when they are for parts on different stacks (see Workflow step 7).
 - **Don't write a terse script.** Silent steps, `>/dev/null` redirects on the install output, missing `--version` prints, absent step banners, an un-logged resolved `$2`, and a missing final summary all make the script harder to debug than the tests it is running. Follow the *Logging — be as verbose as possible* rule under [Conventions](#conventions) literally: every step announces itself, every command is echoed, the resolved `$CONFORMANCE_TESTS_FOLDER` is printed, every failure prints what was about to run and where, and the final summary names the test command, exit code, and working folder.

package/genome/skills/implement-conformance-testing-script/assets/run_conformance_tests_java.sh

@@ -21,7 +21,7 @@ printf "Current directory: $current_dir\n"
 
 # Resolve the conformance tests folder to an absolute path so it can be used
 # after changing into the working folder ($2 may be relative to the invocation
-# directory on older renderers; newer renderers pass it as an absolute path).
+# directory on older harnesses; turri passes it as an absolute path).
 case "$2" in
   /*) CONFORMANCE_TESTS_SOURCE="$2" ;;
   *)  CONFORMANCE_TESTS_SOURCE="$current_dir/$2" ;;
@@ -46,7 +46,7 @@ mkdir -p "$JAVA_BUILD_SUBFOLDER"
 # Conformance tests live in the conformance tests folder and nowhere else. One in the
 # build folder is in the wrong place: nothing would run it as part of the suite. Refuse.
 MISPLACED=$( (grep -rlE --exclude=".turri*" --exclude-dir=target --exclude-dir=.m2 \
-    "conformance tests of (functionality [0-9]|the spec)|acceptance test [0-9]+ of functionality" "$1" 2>/dev/null; \
+    "(conformance tests|(conformance|acceptance) scenario [a-z0-9-]+) of [^[:space:]:]+:[a-z0-9-]+" "$1" 2>/dev/null; \
   find "$1" -type f \( -ipath "*conformance*" -o -ipath "*acceptance*" \) -iname "*test*" \
     -not -name ".turri*" -not -path "*/target/*" -not -path "*/.m2/*" 2>/dev/null) | sort -u)
 if [ -n "$MISPLACED" ]; then

package/genome/skills/implement-conformance-testing-script/assets/run_conformance_tests_python.sh

@@ -28,7 +28,7 @@ fi
 
 # Resolve the conformance tests folder to an absolute path so it can be used
 # after changing into the working folder ($2 may be relative to the invocation
-# directory on older renderers; newer renderers pass it as an absolute path).
+# directory on older harnesses; turri passes it as an absolute path).
 case "$2" in
   /*) CONFORMANCE_TESTS_FOLDER="$2" ;;
   *)  CONFORMANCE_TESTS_FOLDER="$(pwd)/$2" ;;
@@ -37,7 +37,7 @@ esac
 # Conformance tests live in the conformance tests folder and nowhere else. One in the
 # build folder is in the wrong place: nothing would run it as part of the suite. Refuse.
 MISPLACED=$( (grep -rlE --exclude=".turri*" --exclude-dir=.venv --exclude-dir=node_modules --exclude-dir=target \
-    "conformance tests of (functionality [0-9]|the spec)|acceptance test [0-9]+ of functionality" "$1" 2>/dev/null; \
+    "(conformance tests|(conformance|acceptance) scenario [a-z0-9-]+) of [^[:space:]:]+:[a-z0-9-]+" "$1" 2>/dev/null; \
   find "$1" -type f \( -ipath "*conformance*" -o -ipath "*acceptance*" \) -iname "*test*" \
     -not -name ".turri*" -not -path "*/.venv/*" -not -path "*/node_modules/*" -not -path "*/target/*" 2>/dev/null) | sort -u)
 if [ -n "$MISPLACED" ]; then

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

@@ -10,6 +10,10 @@ description: >-
   etc.) to a ***plain project, or wants to regenerate / adapt the existing
   Java runner.
 allowed-tools: [read, write, edit, bash, ls, grep, find]
+metadata:
+  # In the chat it runs in the background, on the coding model of the module it is for: its end comes back to the chat.
+  background: true
+  model: coding
 ---
 
 # Implement Unit Testing Script
@@ -20,7 +24,7 @@ The reference implementation is [assets/run_unittests_java.sh](assets/run_unitte
 
 ## Always Bash
 
-turri requires this script and runs it itself, as `bash run_unittests_<lang>.sh <build_folder>` on the person's machine - macOS, Linux or WSL: its exit code decides whether a functionality's unit tests pass. So the script is always **Bash (`.sh`)**, and stays portable across them - POSIX tools and flags, nothing only one of them has.
+turri requires this script and runs it itself, as `bash run_unittests_<lang>.sh <build_folder>` on the person's machine - macOS, Linux or WSL: its exit code decides whether a functional spec's unit tests pass. So the script is always **Bash (`.sh`)**, and stays portable across them - POSIX tools and flags, nothing only one of them has.
 
 A **PowerShell (`.ps1`)** copy is written only when the user asks for one, to run the tests by hand on native Windows. turri never runs it, so a project with only a `.ps1` has no unit testing script.
 
@@ -31,7 +35,7 @@ The same eight-step pattern applies to both. Only the syntax changes.
 Every testing script must implement these steps **in this order**:
 
 1. **Toolchain check.** Verify that the required language runtime / build tool (and the required version, if any) is installed. If not, print an error and exit with code `69`.
-2. **Argument validation.** Require exactly one positional argument: the source build folder. If missing, print usage and exit with code `1`. The renderer passes this argument as an **absolute path** (older renderer versions passed a relative one) — the script must work with both, which is why the working-folder name in step 3 is built from the argument's *basename*, never from the raw argument.
+2. **Argument validation.** Require exactly one positional argument: the source build folder. If missing, print usage and exit with code `1`. turri passes this argument as an **absolute path** (older harnesses passed a relative one) — the script must work with both, which is why the working-folder name in step 3 is built from the argument's *basename*, never from the raw argument.
 3. **Working directory setup.** Define a working folder in the **system temp directory**: `/tmp/<lang>_$(basename "$1")` in Bash, `Join-Path ([System.IO.Path]::GetTempPath()) "<lang>_$(Split-Path $BuildFolder -Leaf)"` in PowerShell (written as `<temp>/<lang>_<basename>` below). If it exists, wipe its contents; otherwise create it. Register cleanup so the folder is removed when the script exits — `trap 'rm -rf "$WORKING_FOLDER"' EXIT` in Bash, a `Remove-Item -Recurse -Force` in the `finally` block in PowerShell. This folder — and **only** this folder — is where every subsequent write must land.
 4. **Copy the build.** Recursively copy everything from the source folder into the working folder. After this step the source folder (`$1`) is treated as **read-only** for the rest of the script.
 5. **Enter the working directory.** `cd` / `Set-Location` into `<temp>/<lang>_<basename>`. If that fails, exit with code `2`. All remaining steps run from inside the working folder; they must never write back to the source build folder.
@@ -48,7 +52,7 @@ The source build folder passed in as `$1` is **input only**. The script must nev
 - run the test command from inside it (every test command runs from inside `<temp>/<lang>_<basename>` after the `cd` in step 5),
 - create logs, caches, build outputs, or temp files inside it.
 
-The build folder is shared with the renderer (`plain_modules/<module>/code` by default) and downstream tooling. Writing into it corrupts the renderer's view of "what was generated" and breaks subsequent renders. Every write must go into `<temp>/<lang>_<basename>` — the whole point of staging into the system temp directory is so the source build folder stays a clean, reproducible artifact of the render and no build debris is left inside the user's project.
+The build folder is shared with turri (`plain_modules/<module>/code` by default) and downstream tooling. Writing into it corrupts turri's view of "what was generated" and breaks subsequent regenerations. Every write must go into `<temp>/<lang>_<basename>` — the whole point of staging into the system temp directory is so the source build folder stays a clean, reproducible artifact of the regeneration and no build debris is left inside the user's project.
 
 If you find yourself about to issue any command whose `cwd` is the source folder, or whose target path starts with `$1/`, **stop**. Either move the operation into `<temp>/<lang>_<basename>`, or you're doing something the script must not do.
 
@@ -64,7 +68,7 @@ Shared across both shell flavors:
   - Any other non-zero code — propagated from the underlying test command.
 - **Working folder naming:** `<temp>/<lang>_<basename>` — the system temp directory (`/tmp` in Bash, `[System.IO.Path]::GetTempPath()` in PowerShell) plus a short identifier for the language (`java`, `python`, `node`, `go`, `rust`, ...) and the **basename** of the build-folder argument (`$(basename "$1")` / `Split-Path $BuildFolder -Leaf`). Never embed the raw argument in the path — it may be absolute, and concatenating it produces broken doubled paths. All dependency installs, build outputs, caches, and the test run itself live inside this folder. Nothing the script does should touch the source build folder after step 4.
 - **Cleanup on exit:** the working folder is temporary — remove it when the script exits, on success and failure alike (`trap 'rm -rf "$WORKING_FOLDER"' EXIT` in Bash; `Remove-Item -Recurse -Force` in the PowerShell `finally` block, after `Pop-Location`). No leftover build folders may accumulate in the temp directory or the user's project.
-- **Logging — be as verbose as possible.** The script is the only thing the operator sees between a `turri` render and a green/red test result; when it fails, the only forensic evidence anyone has is its stdout/stderr. Treat the script like a production runbook, not a quiet helper. Concretely:
+- **Logging — be as verbose as possible.** The script is the only thing the operator sees between a `turri` regeneration and a green/red test result; when it fails, the only forensic evidence anyone has is its stdout/stderr. Treat the script like a production runbook, not a quiet helper. Concretely:
   - **Announce every step before doing it**, with the exact value of every variable involved — the resolved source folder, the working folder, the language, the toolchain version detected, the isolation root, the dependency-manifest path, the test command about to run. "Installing dependencies" alone is useless; "Installing dependencies from `./requirements.txt` into venv `./.venv` (Python 3.11.6 at `/usr/local/bin/python3`)" is triage-ready.
   - **Echo every non-trivial command before executing it.** In Bash, use `set -x` for the body of the script (or `echo "+ <cmd>"` immediately before each call); in PowerShell, set `$VerbosePreference = 'Continue'` and use `Write-Verbose` / `Write-Host` to print each command line with its arguments.
   - **Print clear section banners.** Each of the eight steps gets a banner like `===== [3/8] Working directory setup =====` so a long log can be navigated by eye.
@@ -134,19 +138,19 @@ Notes:
 
 ## Workflow
 
-1. Confirm the target **language**, **shell flavor** (Bash or PowerShell), and **dependency manifest** (`pom.xml`, `requirements.txt` / `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`, ...). Ask if any is unclear.
+1. Take the target **language**, **test framework** and **dependency manifest** (`pom.xml`, `requirements.txt` / `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`, ...) from the module the script is for: its stack - the `stdlib/...` template it imports - its implementation reqs, and the project. You run in the background, with nobody to ask: decide what they leave open, the choice most consistent with them, and say what you decided in your result. The script is Bash; a PowerShell copy only when the context asks for one. When `config.turri.yaml` - or the stack's `config.turri.<stack>.yaml` - names a `base-folder:`, the module's code starts as a copy of that folder: an existing codebase to build on, or only files to use. Read it. When it holds code with its own test setup - a `pytest.ini` or `pyproject.toml` test section, `package.json` test scripts, a `pom.xml`, a `go.mod` - the script runs that setup's tests as they run there, beside the tests the coding agents write, so they keep passing; its existing dependency manifest is the one to install from. A folder of assets alone changes nothing.
 2. Read [assets/run_unittests_java.sh](assets/run_unittests_java.sh) to refresh the exact structure.
 3. Translate each of the eight steps above into the equivalent commands for the target language **and** shell. The toolchain check, dependency install, static checks and test invocation are the language-specific parts; the rest is mechanical translation between Bash and PowerShell syntax.
 4. Pick the dependency-isolation mechanism from the [Dependency isolation](#dependency-isolation) table and use it consistently in steps 6, 7 and 8, and the checks from the [Static checks](#static-checks) table.
 5. Save the new script as `test_scripts/run_unittests_<lang>.sh` (a `.ps1` copy next to it only if the user wants to run it by hand on Windows). For Bash, `chmod +x` it.
-6. **Make sure turri finds the script.** Do not link it from the specs - turri finds the unit testing script in the project root (the folder that holds `plain_modules/`) and puts it, whole, into the prompt of the coding agent itself; a link to it from a spec is ignored. It looks, in order, at `config.turri.yaml` in the root (`unittests-script: <path relative to the root>`) - with the chosen stack's `config.turri.<stack>.yaml` over it, then for the one `run_unittests*.sh` in the root, then for the one in `test_scripts/`. Saving the script in `test_scripts/` (or the root) is enough when it is the only one there. If the project keeps it elsewhere, name it in `config.turri.yaml` as `unittests-script:` - and 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 edit the copy; `config.yaml` may be another tool's, and is never written. If the project has modules on different stacks - e.g. a Python backend and a React frontend side by side, sharing only an imported module - each part is on a stack of its own, and each stack names its own script in its own file beside `config.turri.yaml`: `unittests-script:` in `config.turri.backend.yaml` for the stack `backend`, in `config.turri.frontend.yaml` for the stack `frontend`. Name each stack after the module it builds - `config.turri.backend.yaml` for `backend.plain` - and that module is built with it by itself, with nothing to choose; a stack named otherwise is passed as `stack` to `regenerate` in the chat, or `--stack <stack>` on the command line. turri never guesses between two. The script is required: a build without one stops before it starts.
+6. **Make sure turri finds the script.** Do not link it from the ***plain - turri finds the unit testing script in the project root (the folder that holds `plain_modules/`) and puts it, whole, into the prompt of the coding agent itself; a link to it from the ***plain is ignored. It looks, in order, at `config.turri.yaml` in the root (`unittests-script: <path relative to the root>`) - with the chosen stack's `config.turri.<stack>.yaml` over it, then for the one `run_unittests*.sh` in the root, then for the one in `test_scripts/`. Saving the script in `test_scripts/` (or the root) is enough when it is the only one there. If the project keeps it elsewhere, name it in `config.turri.yaml` as `unittests-script:` - and 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 edit the copy; `config.yaml` may be another tool's, and is never written. If the project has modules on different stacks - e.g. a Python backend and a React frontend side by side, sharing only an imported module - each part is on a stack of its own, and each stack names its own script in its own file beside `config.turri.yaml`: `unittests-script:` in `config.turri.backend.yaml` for the stack `backend`, in `config.turri.frontend.yaml` for the stack `frontend`. Name each stack after the module it builds - `config.turri.backend.yaml` for `backend.plain` - and that module is built with it by itself, with nothing to choose; a stack named otherwise is passed as `stack` to `regenerate` in the chat, or `--stack <stack>` on the command line. turri never guesses between two. The script is required: a build without one stops before it starts.
 
 ## Anti-Patterns
 
-- **(Hard mistake) Don't install into, build into, or otherwise write to the source build folder.** The build folder passed as `$1` is read-only input. Every install, cache, build artifact, log, and temp file must land in `<temp>/<lang>_<basename>`. This includes never running `pip install`, `npm install`, `mvn install`, or `cargo build` with the source folder as their `cwd` or target, never letting a venv / `node_modules` / `.m2` / `.gocache` / `.cargo` directory appear inside the source folder, and never running the test command from inside it. The whole point of staging the build into the system temp directory is so the source folder remains a clean, reproducible artifact of the render — writing to it corrupts the renderer's view and breaks subsequent renders.
-- **(Hard mistake) Don't build any path by concatenating the raw build-folder argument.** `$1` arrives as an absolute path from current renderers. Patterns like `WORKING_FOLDER=.tmp/$1`, `WORKING_FOLDER=<lang>_$1`, or `"$current_dir/$1"` silently produce doubled paths (`/project//abs/path/...`) — the classic symptom is an `ImportError: Start directory is not importable` or "folder does not exist" pointing at a path that contains the project root twice. Always take `$(basename "$1")` / `Split-Path -Leaf`.
+- **(Hard mistake) Don't install into, build into, or otherwise write to the source build folder.** The build folder passed as `$1` is read-only input. Every install, cache, build artifact, log, and temp file must land in `<temp>/<lang>_<basename>`. This includes never running `pip install`, `npm install`, `mvn install`, or `cargo build` with the source folder as their `cwd` or target, never letting a venv / `node_modules` / `.m2` / `.gocache` / `.cargo` directory appear inside the source folder, and never running the test command from inside it. The whole point of staging the build into the system temp directory is so the source folder remains a clean, reproducible artifact of the regeneration — writing to it corrupts turri's view and breaks subsequent regenerations.
+- **(Hard mistake) Don't build any path by concatenating the raw build-folder argument.** `$1` arrives from turri as an absolute path. Patterns like `WORKING_FOLDER=.tmp/$1`, `WORKING_FOLDER=<lang>_$1`, or `"$current_dir/$1"` silently produce doubled paths (`/project//abs/path/...`) — the classic symptom is an `ImportError: Start directory is not importable` or "folder does not exist" pointing at a path that contains the project root twice. Always take `$(basename "$1")` / `Split-Path -Leaf`.
 - Don't skip the toolchain check, even when "everyone has it installed" — exit code `69` is what the calling system relies on to detect a missing runtime.
-- Don't reuse the source folder in place. Always copy into `<temp>/<lang>_<basename>` first; the renderer relies on this isolation.
+- Don't reuse the source folder in place. Always copy into `<temp>/<lang>_<basename>` first; turri relies on this isolation.
 - Don't leave the working folder behind. Register the cleanup (`trap … EXIT` / `finally`) before the first write so even an early failure removes it.
 - Don't change the exit-code contract. Other parts of the system branch on `1`, `2`, `69` and `80` specifically — and these codes must be identical between the Bash and PowerShell variants.
 - Don't stop at the first failing check, and don't skip the tests because a check failed. Every check and the tests run each time, so one run tells the agent everything; the exit code says which failed.
@@ -155,5 +159,5 @@ Notes:
 - Don't write a cross-shell hybrid (e.g. a `.sh` that detects PowerShell, or vice versa). Ship one script per shell, named with the appropriate extension.
 - Don't install dependencies into the user's global location (`~/.m2`, system-wide `pip`, `~/.cargo`, etc.). Always isolate inside `$WORKING_FOLDER` so concurrent runs and other projects can't interfere.
 - Don't run the test command without first verifying the install step succeeded. A failed install followed by a "test" run produces misleading errors that look like test failures.
-- **Don't link the script from the specs, and don't leave turri guessing.** turri finds the script in `config.turri.yaml`, the project root, or `test_scripts/`, and shows it to the coding agent itself; a link to it from a spec is ignored. Put it where it is found, and when there are two unit testing scripts in one folder, name the one to use as `unittests-script:` - in each stack's `config.turri.<stack>.yaml` when they are for parts on different stacks (see Workflow step 6).
+- **Don't link the script from the ***plain, and don't leave turri guessing.** turri finds the script in `config.turri.yaml`, the project root, or `test_scripts/`, and shows it to the coding agent itself; a link to it from the ***plain is ignored. Put it where it is found, and when there are two unit testing scripts in one folder, name the one to use as `unittests-script:` - in each stack's `config.turri.<stack>.yaml` when they are for parts on different stacks (see Workflow step 6).
 - **Don't write a terse script.** Silent steps, `>/dev/null` redirects on the install output, missing `--version` prints, and absent failure banners all make the script harder to debug than the code it is testing. Follow the *Logging — be as verbose as possible* rule under [Conventions](#conventions) literally: every step announces itself, every command is echoed, every failure prints what was about to run and where.