@turri-dev/cli 0.1.22 → 0.1.23

package/dist/extension.js

@@ -1712,11 +1712,13 @@ async function deliver(jobs, input) {
                     ? `Queued ${input.kind} as pulse ${job.id}: ${summary}${onModel}. It writes the same ` +
                         `module as ${job.waitingOn.map((id) => `pulse ${id}`).join(" and ")}, so it starts when that ` +
                         "finishes. Nothing to wait for: if what you are doing has a next step, take it now, in this same turn, and tell " +
-                        "the user it is queued and why alongside it, never as a reply that ends your turn. "
+                        "the user it is queued and why alongside it, never as a reply that ends your turn - and that the two of you " +
+                        "can go on with the ***plain, or anything else, meanwhile: they need not wait for it. "
                     : `Started ${input.kind} as pulse ${job.id}: ${summary}${onModel}.\n` +
                         "It is running now and will report back when it finishes - nothing to wait for: if what you are doing has a " +
                         "next step, take it now, in this same turn, and tell the user it has started alongside it, never as a reply " +
-                        "that ends your turn. ") +
+                        "that ends your turn - and that the two of you can go on with the ***plain, or anything else, meanwhile: they " +
+                        "need not wait for it. ") +
                     `Use pulses with "${job.id}" if they ask how it is going.`,
             },
         ],

package/dist/identity.js

@@ -53,6 +53,13 @@ const IDENTITY_BEFORE = [
     "pulses lists every pulse, whichever chat asked for it. What was said in another chat is not in this one: when the",
     "person speaks of it, ask.",
     "",
+    "Pulses regenerate in the background and never hold the conversation: while they run, you and the person go on -",
+    "shaping the ***plain and writing its next change, answering their questions, trying what has landed or was",
+    "released. When a pulse starts, say so in a way that makes it plain they need not wait for it to finish; never tell",
+    "them to wait for one, and never stop to wait for one yourself. Changing the ***plain while a pulse runs is safe: a",
+    "change inside what the running pulse regenerates steers it, and the rest is planned again around it - the next",
+    "change never waits for the last to land.",
+    "",
     "Your words, and the older ones for the same things - a project's AGENTS.md, a skill, notes or the person may use",
     "either, and they mean the same:",
     "- A pulse is one unit of work regenerating the code - a spec diff regenerated in a codebase, or its conformance",

package/dist/loop-tools.js

@@ -103,7 +103,8 @@ export async function loopReply(loop, statuses, wait) {
             ? "Tell the user how it went."
             : "It regenerates in the background. " +
                 "Nothing to wait for: if what you are doing has a next step - a question to ask, a file to edit, functional specs to conform - take it now, " +
-                "in this same turn, and tell the user what runs and what is planned alongside it, never as a reply that ends your turn. " +
+                "in this same turn, and tell the user what runs and what is planned alongside it, never as a reply that ends your turn - " +
+                "and that the two of you can go on with the ***plain, or anything else, meanwhile: they need not wait for it. " +
                 "Use pulses with a pulse's id if they ask how it is going.",
     ].join("\n");
     return { content: [{ type: "text", text }], details: { jobIds } };

package/docs/using.md

@@ -57,7 +57,7 @@ The agent does this work with these tools, never by running turri's command line
 
 A pulse is one unit of work regenerating the code. It was called a job, and still is where a name is kept - `job_id`, `parallel-jobs`, `allow-to-stop-jobs`, `.turri/jobs/` - and in a project's own files written before: the chat is told the two are the same, so an `AGENTS.md` or a skill that says "job" needs no change.
 
-A regeneration takes minutes, so in the TUI every tool that regenerates starts the work as a pulse and returns straight away. The conversation carries on; pulses on the same module - or on modules of one `requires` chain - queue behind each other, in the order they were asked for, from the first pulse on: one queued while the module's \*\*\*plain is only a scaffold, with no functional specs yet, or while it does not parse, still holds its module, so nothing on the module runs beside it. Pulses on modules that share nothing run side by side, each with its own progress panel - two modules or ten. How many run at once is capped by what the machine has room for: past `parallel-jobs` (see [the project config](config.md#how-many-jobs-at-once)), a pulse whose turn has come waits for a free slot, and says so.
+A regeneration takes minutes, so in the TUI every tool that regenerates starts the work as a pulse and returns straight away. The conversation carries on, and you need not wait for a pulse to finish: go on shaping the \*\*\*plain and writing its next change, ask questions, try what has landed - turri says so as each pulse starts, and never waits for one itself. A \*\*\*plain change made meanwhile steers the running pulse or is planned again around it (see below); pulses on the same module - or on modules of one `requires` chain - queue behind each other, in the order they were asked for, from the first pulse on: one queued while the module's \*\*\*plain is only a scaffold, with no functional specs yet, or while it does not parse, still holds its module, so nothing on the module runs beside it. Pulses on modules that share nothing run side by side, each with its own progress panel - two modules or ten. How many run at once is capped by what the machine has room for: past `parallel-jobs` (see [the project config](config.md#how-many-jobs-at-once)), a pulse whose turn has come waits for a free slot, and says so.
 
 - **The panel** above the input, while something runs, shows on top what finished - a line a module, the module that finished last on top, its pulses newest first, each with its mark (green, red or amber, as in the side panel), number and kind - what it regenerated is in the side panel - `cognio  ✓ 4 conformance · ✓ 3 regenerate · … 2 earlier`, the newest that fit the width - then a rule, and under it each running pulse, the newest first - `cognio · regenerate pulse 5`, `cognio · conformance pulse 6` - its time and cost, and what its agents are doing. A module whose work is being planned into pulses shows at once, before any pulse runs - `shorty · planning the pulses · 12s` - the planner is an agent, and takes a while; a `/regenerate` says it began the moment it is sent. Pulses are numbered within their module, as regen numbers them. `ctrl+o` expands the agents' trace alone; what finished stays a line a module. The line of keys under it - `ctrl+o to expand the trace · ctrl+h to peek at regen` - has each key breathing, fully there to a little faint and back, until it is first pressed: once `ctrl+o` has opened the trace, or the side panel has been opened, that key is still for the rest of the session and the other breathes on. What waits is not in it, and it shows no \*\*\*plain diff - the side panel has both. With nothing running it is gone.
 - **A pulse's change** is what its agent works from, not a text diff of the module's file: the items `<spec change>` gives the agent - only what the pulse's functional specs use, an import's items as well as the module's own, a code pulse's without the test reqs - each in the file it is written in, under its section, in the file's order (`change-view.ts`).

package/genome/rules/turri-regeneration.md

@@ -41,6 +41,7 @@ The other rules say what a spec means. This one says what turri does with a chan
 
 - Never edit the code under `plain_modules/`: the next regeneration does not keep it, and the code record no longer says what the code is
 - In order of cost: change the spec where it is wrong or silent; regenerate the functional specs whose code went bad again, by name; regenerate the module from scratch, or its whole chain - only when the person asks for it or agrees to it
+- Pulses regenerate in the background: the spec can be changed while they run, and need not wait for them. A change inside what a running pulse regenerates steers it; the rest is planned again around it
 - A pulse that does not land is rolled back whole - code, tests and record together - and its module waits until the spec changes or the module is asked for again. Running it again unchanged usually ends the same way: look at why it did not land first
 - A finished pulse goes to the sentinel, a chat of turri's own - unless `sentinel: false`: it checks the pulse, tests what was released, and puts what is wrong to the person as a notice with what can be done. A pulse that landed is told to the chat the person is in too, only to say it landed and what the sentinel does with it, and when the sentinel is done with a pulse, what it found - the chat does nothing else about either; a pulse that went wrong is not told to it - the chat's agent is given a notice's task once the person accepts it, and does that
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.22",
+  "version": "0.1.23",
   "license": "MIT",
   "type": "module",
   "repository": {