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

package/docs/headless.md

@@ -86,7 +86,10 @@ Useful options - `turri regenerate --help` lists all of them:
 | `--judge-model <provider/id>` | `judge-model`: the judge and the test review; not given, the coding model |
 | `--conformance-tests <all\|chosen\|module\|false>` | `conformance-tests`, with its values (`true` is `all`) |
 | `--review <true\|false>` | `review`: whether the code and its tests are reviewed once they pass |
+| `--mutation-testing <true\|false>` | `mutation-testing`: whether the coding agent and the reviewer have `can_it_fail` |
 | `--stack <name>` | build with the stack's `config.turri.<name>.yaml` over `config.turri.yaml`; default, `TURRI_STACK`, else none |
+| `--from-scratch` | delete the module's code and conformance tests (its lineage keeps them) and regenerate all of it |
+| `--from-scratch-chain` | the same for every module of its requires chain, the base's included, built again from the bottom |
 | `--start-over` | start over, unasked, a codebase built without a module it now requires - without a terminal, a run that needs it and lacks it stops |
 | `--build-dir <dir>` | as the run ends, export the code there - see below |
 | `--report <file.json>` | write [the run report](#the-run-report) there |
@@ -104,7 +107,8 @@ Conformance tests follow `conformance-tests:` in `config.turri.yaml`, or `--conf
 The command exits `0` only when every module is complete: its code regenerated from the spec as it is
 now, and its conformance tests written for what is built when they are on - no pulse failed, nothing
 halted, nothing waiting for a start over. Anything else exits `1`, and the last lines say which
-module is not complete, and why. The log says, per functionality, what was built and whether its
+module is not complete, and why. A behaviour the spec leaves open that an agent had to decide is printed
+as a `spec gap` under its pulse, with what was decided meanwhile. The log says, per functionality, what was built and whether its
 tests passed.
 
 | | |
@@ -150,6 +154,7 @@ changes meaning or goes; new fields may appear in the same version. Paths in `pu
   "spec_file": "/work/app.plain", "project_dir": "/work", "build_dir": "/work/out",  // build_dir: null without one
   "conformance_tests": "all",                                                       // all | chosen | module | false
   "review": false,
+  "mutation_testing": true,
   "models": {
     "harness": { "model": "…", "thinking": "medium" },  // the planner, the chooser
     "coding":  { "model": "…", "thinking": "low" },
@@ -165,7 +170,7 @@ changes meaning or goes; new fields may appear in the same version. Paths in `pu
   "usage": {
     "total": {
       "input_tokens": 0, "output_tokens": 0, "cache_read_tokens": 0, "cache_write_tokens": 0, "cost_usd": 0,
-      "llm_calls": 0, "agent_turns": 0, "compactions": 0, "model_seconds": 0
+      "llm_calls": 0, "agent_turns": 0, "compactions": 0, "provider_retries": 0, "provider_stalls": 0, "turns_stopped": 0, "model_seconds": 0
     },
     "in_pulses": { },       // the pulses' usage added up - the same fields
     "outside_pulses": { },  // the planner, the conformance chooser, a failed pulse's diagnosis
@@ -191,6 +196,16 @@ changes meaning or goes; new fields may appear in the same version. Paths in `pu
     ],
     "codebases": ["plain_modules/app/code"]
   },
+  "spec_gaps": [{                                       // [] when no agent met one
+    "module": "app", "pulse": 3, "pulse_id": "2a058729", "landed": true,
+    "question": "What happens to a contact archived in HubSpot after it was synced?",
+    "assumption": "An archived contact is left as synced - asserted in sync.test.ts, archived contacts"
+  }],
+  "turn_incidents": [                                   // [] when none
+    { "kind": "provider_retry", "pulse_id": "2a058729", "role": "coding", "model": "…", "error": "…: 529 overloaded", "attempt": 1, "of": 6, "wait_seconds": 15.3 },
+    { "kind": "provider_stall", "pulse_id": "2a058729", "role": "coding", "model": "…", "silent_seconds": 120 },
+    { "kind": "stopped", "pulse_id": "5c1e0b2f", "role": "conformance explorer", "model": "…", "reason": "10 submit_exploration calls failed in a row" }
+  ],
   "build_dir_export": { "exported": true, "dir": "/work/out", "module": "app", "commit": "8036b3b", "files": 23 },
   "logs": { "jobs_dir": ".turri/jobs", "debug_dir": ".turri/debug", "sessions_dir": ".turri/sessions" }
 }
@@ -209,6 +224,21 @@ calls; a role or model turri could not tell is `unknown`.
 stopped, or did not pass - and everything it wrote was undone. A pulse that failed is tried once more
 before it counts as failed; both tries are the one pulse.
 
+**Spec gaps.** A behaviour the spec leaves open that an agent met and decided on its own - reported with
+`report_spec_gap` (see [regenerating](regenerating.md)). In the chat they are put to you as the pulse ends; a
+headless run has no one to ask, so they are listed here, in the order the pulses started, and printed under the
+pulse that met them. `assumption` is what the agent decided meanwhile, also in the codebase's notes'
+assumptions while its pulse is `landed`; a pulse rolled back takes it out of the notes, but the question still
+stands. Settle the ones you care about in the spec and run again.
+
+**Turn incidents.** Each time the model provider failed for a moment and pi or turri waited it out before trying
+the request again, each time the provider sent nothing back on a request for two minutes, and each turn turri
+stopped itself - an agent going round in a circle, its calls failing again and again, its time up - after which the
+run carried on. The provider failing or stalling is printed as it happens, in yellow, under the pulse; a stop is
+the work's normal course and is only listed. They are counted in the usage as `provider_retries`,
+`provider_stalls` and `turns_stopped`. Many of any point at the model, not the spec: a provider at its limits, or a
+model too small for the role it was given.
+
 **Completed functional specs** - the pass rate, the figure to compare runs by.
 A functional spec is completed when the code record of the codebase the run delivers - the
 furthest-built of the chain, the one `--build-dir` exports - as last committed, holds it as the spec has
@@ -227,7 +257,7 @@ and modules that are complete are skipped, so it picks up where it stopped - aft
 provider outage, or a machine that went to sleep anyway. Whatever the stopped run left
 half-written is undone first: each step starts from the module's last commit. A functionality whose spec has changed
 since counts as not built, so editing the spec and re-running rebuilds what changed. `--from-scratch`
-rebuilds everything.
+rebuilds the module; `--from-scratch-chain` rebuilds every module of its chain.
 
 ## Rebuilding one functionality
 

package/docs/regenerating.md

@@ -123,7 +123,22 @@ An agent that goes round in a circle - the same tool called with the same argume
 nothing in between, or a look (read, grep, find, ls) made again with nothing changed since, however
 many other looks came between, so the same answer comes back - is let through three times; the next
 such call is refused with what is happening, and past six its turn is stopped, and the harness goes on
-from there as after any turn. The arguments are compared whatever order they come in.
+from there as after any turn. The arguments are compared whatever order they come in. So too an agent whose
+calls to one tool fail ten times in a row, nothing going through - a call its arguments do not fit never reaches
+any guard on the tools.
+
+A turn turri stops itself - for any of these, or for its time, below - ends as any turn ends: what the agent said
+stands, `[the turn was stopped: ...]` after it, and the caller does what it does when the agent handed nothing over
+(the explorer's fallback, a nudge, a failed round). The abort that ended it is never taken for the provider
+failing; an abort turri did not make still is. A stop is the work's normal course: it is in the pulse's activity
+and log and the run report's `turn_incidents`, but not said in the chat or a headless run's console - those say
+only the model provider failing or stalling.
+
+A tool argument that is a list of objects - the explorer's `interfaces` and `plan`, a reviewer's `problems` - is
+what small models get wrong most. Before a call's arguments are checked, a list sent as JSON text, entries sent as
+JSON text, one object for the list, or a list written inside another argument's text
+(`...</tests_reach_it><plan>[...]</plan>`) are taken as the list; what still is not one is refused saying which
+argument, what was sent, each entry's fields and an example (`list-arguments.ts`).
 
 The agents with one thing to decide have a budget of tool calls: the judge 30, the test review and the
 explorer 40. Past it every tool but the one that hands the decision over refuses, telling it to decide
@@ -245,12 +260,18 @@ use each:
 - **`my_diff`**: the diff of the code folder from the commit the job started from, new files whole - exactly
   what the reviewer is shown. Read before handing the work in: every part of the change in it, and nothing else.
 - **`can_it_fail`**: whether the unit tests catch a bug. The agent gives one change to a code file - a
-  condition turned round, a value changed - and the unit testing script runs on a fresh copy of the code with
-  it; the code itself is never touched. If every test still passes, no test catches that bug. Six
+  condition turned round, a value changed - and the unit testing script runs with it. Where the testing scripts
+  run on a copy (`testing-scripts-run-on: copy`), the change is made to a fresh copy and the code itself is never
+  touched. In place, the default, it is made to the code itself, so a script that finds the code from its own path
+  sees it; the file is put back as it was once the run ends - passed, failed, hung, the script failing to start, the
+  script rewriting the file, turri exiting. Killed outright, the next unit of work starts from the last commit anyway.
+  It never runs beside another call of the agent's, so no edit lands while the bug is in. What the script does
+  beyond the code - a package copied into a host codebase - it does with the bug in, until the next test run puts the
+  real code there. If every test still passes, no test catches that bug. Six
   runs a job. A bug often makes the code hang instead - a loop that never ends - so a run may take three times
   as long as the last passing run of the unit tests, within 15 and 60 seconds, and one that does not finish is
-  reported as a hang, not as a test that caught it. Only where the testing scripts run on a copy
-  (`testing-scripts-run-on: copy`): in place, the default, there is no copy to change.
+  reported as a hang, not as a test that caught it. `mutation-testing: false` in the [config](config.md) - or
+  `turri regenerate --mutation-testing false` - takes it away, from the reviewer too.
 - **`start_service`**, **`service_logs`**, **`stop_service`**: a server or a worker it built, started in the
   background on this machine, behind the same walls as its shell - the command check, the module's environment, the
   OS sandbox, the audit while it comes up - to try from outside with `curl` as a client would. Whatever the stack: the
@@ -561,7 +582,8 @@ does not find them:
 testing-scripts-run-on: copy
 ```
 
-`can_it_fail` needs a copy to change, so an agent has it only where the scripts run on one.
+`can_it_fail` works either way: on a copy it changes the copy; in place it changes the code for the one run and puts
+it back.
 
 ### When the environment lacks something
 
@@ -718,7 +740,7 @@ with no agent and no testing script. Moving specs into a module the code was not
 change to the code brings that module's code in, so the codebase stops: it has to be started over - its code
 and conformance tests taken out, committed so its history keeps them, and the chain built again from the
 bottom. That is never done unasked. In the chat the model asks the person, saying why, and calls
-`regenerate` with `from_scratch` once they agree; `turri regenerate` and `spec-diff` ask at the terminal, and
+`regenerate` with `from_scratch: "module"` once they agree; `turri regenerate` and `spec-diff` ask at the terminal, and
 `--start-over` agrees in advance - with no terminal and no flag, the run stops there, exit 1, saying so.
 
 ## Conformance tests
@@ -1111,7 +1133,9 @@ are the next agent's, and a gap is yours. An agent reports one with `report_spec
 and the assumption it made meanwhile; turri writes that assumption into the notes' assumptions, so the code built on
 it is known for what it is. The gaps a pulse's agents report are said in its report - "Spec gaps its agents met ... Put
 each to the user", each with its assumption - so the conversation asks you, and writes the ones you decide into the
-spec; the pulse that builds the answer finds the assumption it replaces in the notes, and the tests it names. However many gaps a pulse's agents report, they
+spec; the pulse that builds the answer finds the assumption it replaces in the notes, and the tests it names.
+A headless run has no one to ask: it prints each gap under its pulse, and lists them in its run report's
+`spec_gaps` ([running unattended](headless.md#the-run-report)). However many gaps a pulse's agents report, they
 are put to you - never a reason to stop the pulse; the tool is guarded like any other. A notes
 file from before keeps no spec gaps section: its lines are dropped as it is read.
 

package/docs/skills-and-gates.md

@@ -133,7 +133,9 @@ change the step makes and puts its findings on the executor's next tool result.
 - **Interview the user.** `ask_user` puts one question to the person. In the TUI it is a dialog;
   from the CLI the options are numbered. Offering choices is required, not optional - a call with
   neither `options` nor `free_form: true` is refused - and every list carries "Something else…".
-  `multi_select: true` keeps offering what is left until they are done. The skill's agent talks in a
+  `multi_select: true` gives every option a box, ticked and unticked as it is chosen - a pick made by mistake is
+  undone by choosing it again - until they choose Done; what they type is one more box, ticked. "Something
+  else…", "Chat about this" and Done are no boxes. The skill's agent talks in a
   session of its own that the person never sees, so what the person must read to answer - the brief
   to confirm, the plan to approve - it passes as `ask_user`'s `context`, shown above the question in
   the dialog; `brood`, `spawn` and `bud` pass their briefs so. The agents are told to keep it to what can be taken in at

package/docs/using.md

@@ -50,7 +50,7 @@ where it stopped. A project can have skills of its own, in `.turri/skills/` or `
 
 | tool | |
 | --- | --- |
-| `regenerate` | regenerate a module and its chain from the spec as it is now - after any change to it, by any means: what is left to regenerate is planned into pulses of one to three functional specs, each with the definitions and reqs it uses, and a pulse regenerating what the spec no longer wants is stopped. With functionalities named, those are regenerated though their spec did not change - rewritten or started over, planned into pulses as any change is; with `from_scratch`, the whole module, its code deleted first - only when you ask, or agree |
+| `regenerate` | regenerate a module and its chain from the spec as it is now - after any change to it, by any means: what is left to regenerate is planned into pulses of one to three functional specs, each with the definitions and reqs it uses, and a pulse regenerating what the spec no longer wants is stopped. With functionalities named, those are regenerated though their spec did not change - rewritten or started over, planned into pulses as any change is; with `from_scratch`, the whole module, its code deleted first - `"chain"` for every module of its requires chain too, built again from the bottom - only when you ask, or agree |
 | `drift` | what is left to regenerate: how far the code and its conformance tests have drifted from the spec, starting nothing |
 | `glimpse` | the pulse a module's codebases would start next, and the whole prompt its coding agent would get - starting nothing |
 | `steer` | say how the work is planned - which functional specs go together, what first - for the project or one module, for the session; the next plan follows it, beside what AGENTS.md says under a heading naming the queue |
@@ -63,7 +63,7 @@ where it stopped. A project can have skills of its own, in `.turri/skills/` or `
 | `lineage` | a module's lineage: what each regeneration and conformance run changed in it, and what it was regenerated from |
 | `cultivate` | run a gated skill, its steps and review gates enforced |
 | `release`, `activate` | try what is regenerated: release it to `dist/<module>` and activate it on this machine, installing what it needs - see [deploy](deploy.md) |
-| `ask_user` | put a question to you as a dialog to pick from - several at once, "Something else…" to type, or "Chat about this" to talk it over first; Esc in either goes back to the options |
+| `ask_user` | put a question to you as a dialog to pick from - several at once, each a box you tick and untick, "Something else…" to type, or "Chat about this" to talk it over first; Esc in either goes back to the options |
 | `web_search`, `web_fetch` | search the web and read a page as text - documentation, an API, an error; `curl` and the like run in its `bash` |
 
 What each render does, in order, is in [regenerating the code](regenerating.md).
@@ -238,7 +238,7 @@ come waits for a free slot, and says so.
   is laid over `config.turri.yaml` - its testing scripts, toolchains, models - for the session; a pulse already
   running keeps the stack it started with. The chat model switches it too when you ask. See
   [stacks](config.md#stacks).
-- **`/regenerate [module | file.plain] [functionality ...] [from scratch] [how to cut the work]`** regenerates a module from its spec as it is now, as
+- **`/regenerate [module | file.plain] [functionality ...] [from scratch [whole chain]] [how to cut the work]`** regenerates a module from its spec as it is now, as
   the `regenerate` tool does: what is left to regenerate is planned into pulses - one functional spec at a time, a few
   together or the whole module in one, as the planner judges - and the first starts. Words after the module are
   guidance for that plan (`/regenerate app models first`). A module's name typed with spaces for its underscores is
@@ -246,8 +246,13 @@ come waits for a free slot, and says so.
   `config.turri.yaml` names, else the folder's top modules, to pick from. Asked for from scratch - `from scratch`,
   `start over`, `delete the module` - it asks first, then deletes the module's code and conformance tests in every
   codebase where they live, committed so `/lineage` keeps them, and regenerates the whole module from its spec,
-  built though nothing in it changed: `/regenerate shorty from scratch`. The chat's `regenerate` does the same with
-  `from_scratch`, when you ask for it; `turri regenerate --from-scratch` on the command line, not with `--dry-run`.
+  built though nothing in it changed: `/regenerate shorty from scratch`. The modules below it keep their code, and
+  the module starts again from a copy of the code below it. Asked for its chain too - `/regenerate shorty from scratch,
+  the whole chain` - the code of every module of its requires chain is deleted, the base's included, and the whole
+  chain is regenerated from the bottom: what to do after modules were split, merged or moved, when the code below was
+  laid out for modules that are no more. The chat's `regenerate` does the same with `from_scratch: "module"` or
+  `"chain"`, when you ask for it; `turri regenerate --from-scratch` or `--from-scratch-chain` on the command line, not
+  with `--dry-run`.
   Functionalities named after the module - `/regenerate shorty 3 5` - are regenerated though their spec did not
   change, on the model chosen for functionalities: as `turri regenerate shorty.plain 3 5` does, and the chat's
   `regenerate` with `functionalities`.
@@ -390,7 +395,15 @@ To change pi's own default, in `~/.pi/agent/settings.json`:
 ```
 
 A provider failure - no credits, bad key, rate limit - is raised with the provider's own message,
-rather than surfacing as an agent that said nothing.
+rather than surfacing as an agent that said nothing. One that passes - overloaded, rate limited, unreachable,
+timed out - is waited out first, after pi's own retries: six more tries, the wait doubled each time from 15
+seconds up to five minutes (15s, 30s, 1m, 2m, 4m, 5m, a tenth either way so parallel jobs do not all come back
+at once), the agent carrying on where it was. Each wait - pi's own retries too - is shown as it happens - a
+notification in the chat and the job panel's status, a yellow line in a headless run - and listed in the run
+report's `turn_incidents`. So is a provider stalling: a request to the model that nothing has come back on for two
+minutes (`TURRI_PROVIDER_STALL`, in seconds; 0 never), said once for each silence while the turn goes on waiting.
+A turn turri stops itself - its time up, the agent going round in a circle - is the work's normal course and is not
+said, only listed.
 
 ## Module history
 
@@ -453,6 +466,7 @@ turri regenerate <file.plain>              # regenerate what the code is not bui
 turri glimpse <file.plain>             # plan it, and print the first job's prompt - starts nothing
 turri regenerate <file.plain> 2            # regenerate functionality 2 again, changed or not
 turri regenerate <file.plain> --from-scratch   # delete the module's code and tests (its lineage keeps them), regenerate all of it
+turri regenerate <file.plain> --from-scratch-chain   # the same for every module of its requires chain, from the bottom
 turri spec-diff <file.plain> <diff>    # apply a spec diff, and regenerate it
 turri conform <file.plain> 1           # black-box tests for functionality 1
 turri lineage <module>                 # what each regeneration changed in a module, and when

package/genome/rules/func-specs.md

@@ -65,6 +65,7 @@ GOOD — statements of fact with concrete subjects:
 - The renderer has **no knowledge of future specs** — only previously rendered specs are in context
 - A new spec can reference behavior from earlier specs but cannot assume anything about specs that come after it
 - Functional specs from `requires` modules are treated as previous requirements — transitively, across the whole ancestor chain
+- This order is about what a spec may assume, not what a change costs: turri regenerates a change as a spec diff wherever it sits (`turri-regeneration.md`)
 
 ## No conflicts
 - The new spec must not contradict any existing functional spec

package/genome/rules/project-model.md

@@ -75,9 +75,11 @@ Parameters are key-value pairs; the template reads them as `{{ variable_name }}`
 
 ## When an earlier test fails after a render
 
-Functional specs render in order, each knowing the ones before it and none after it - a required
-module's specs count as before. After each render every conformance test so far runs again. A test
-that passed before and fails now means one of:
+Each functional spec is written knowing the ones before it and none after it - a required module's
+specs count as before - so a spec may rely on what earlier ones say, never on later ones. This is
+about what a spec may assume, not what a change costs (`turri-regeneration.md`). After each
+render every conformance test so far runs again. A test that passed before and fails now means one
+of:
 
 1. the new code does not satisfy its spec;
 2. the test does not test its spec accurately;

package/genome/rules/turri-regeneration.md

@@ -0,0 +1,36 @@
+---
+description: How turri regenerates the code from a spec change - by spec diff, in the chain's tip - so a spec is placed by what it means, never by what regenerating it would cost
+---
+
+# How turri regenerates the code
+
+The other rules say what a spec means. This one says what turri does with a change to it, so that
+where a change goes is never decided by a wrong idea of what it costs.
+
+## A change is regenerated as a spec diff
+
+- turri regenerates the code from spec diffs: what changed between the spec the code was built from
+  and the spec now
+- A functional spec added, changed or taken out is that change alone, wherever it sits - first, in the
+  middle or last of its module
+- The specs around it are not regenerated because their position or numbering moved, and nothing after
+  it is built again. A spec inserted in the middle is one addition
+- "Specs render top to bottom, each knowing only the ones before it" is about what a spec may assume
+  (`func-specs.md`), not about what a change costs
+
+## A change is regenerated in the chain's tip
+
+- A chain's code lives in its tip - the furthest module built on it. The modules below it keep the
+  code they were built with
+- A change to any module of the chain, the base's included, is regenerated in the tip's code - not in
+  the module the change was made in
+- Putting a change in a lower module costs no more than putting it in the tip, and saves nothing
+  either
+
+## So place a spec by what it means
+
+- Put a functional spec where it belongs: in the module that owns the concern, at the point in its
+  order where what it relies on has been said
+- Never put a spec at the end of a module, or in the tip, only to spare regeneration - it spares none
+- What does cost more is asked for outright, never brought on by placement: regenerating a functional
+  spec again, or a module or chain from scratch

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

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

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.4-next.318a98a",
+  "version": "0.1.4-next.afc43a8",
   "license": "MIT",
   "type": "module",
   "repository": {