@turri-dev/cli 0.1.20-next.3ae4a0b → 0.1.21-next.741b3a9

package/README.md

@@ -4,6 +4,7 @@
   <a href="https://www.npmjs.com/package/@turri-dev/cli"><img src="https://img.shields.io/npm/v/@turri-dev/cli?label=npm" alt="npm version"></a>
   <a href="LICENSE"><img src="https://img.shields.io/npm/l/@turri-dev/cli" alt="MIT licence"></a>
   <a href="https://nodejs.org/en/download"><img src="https://img.shields.io/node/v/@turri-dev/cli" alt="Node version"></a>
+  <a href="https://discord.com/invite/REJzFmVQfC"><img src="https://img.shields.io/badge/Discord-join%20the%20community-5865F2?logo=discord&logoColor=white" alt="Join the turri Discord"></a>
 </p>
 
 **turri** builds regenerative software: what lasts is the system's intent, and the code is derived from it - cheap to throw away and build again. You tell **turri** what the system should do; **turri** writes that down as durable intent, with the tests that say when it is met, and builds the code from it. From then on the durable intent is the source of truth: as it changes, the code is regenerated from it rather than patched in place, and never left to drift from it.

package/dist/sentinel-chat.js

@@ -1,5 +1,5 @@
 import { Box, Text } from "@earendil-works/pi-tui";
-import { readProjectConfig, roleModel } from "./config.js";
+import { projectModels, readProjectConfig, roleModel } from "./config.js";
 import { concludedNote, concludeTool, keepGuidanceTool, notifyTool, sentinelFileTools } from "./sentinel.js";
 /**
  * The sentinel in a chat: its tools in place of the chat's - the project to read, its shell behind the walls, notices,
@@ -37,11 +37,13 @@ export function registerSentinel(pi, session, cwd, hostTools, allowed) {
         catch {
             /* a session let go has no tools to set */
         }
-        // Its model, once: the `sentinel` role's, else the chat's - what the person then picks in its chat stands.
+        // Its model, once: the `sentinel` role's, else the chat's - never the one its session started on, which in a host is
+        // pi's default and may not be the project's provider's. What the person then picks in its chat stands.
         if (modelSet)
             return;
         modelSet = true;
-        const choice = roleModel(readProjectConfig(cwd), "sentinel");
+        const config = readProjectConfig(cwd);
+        const choice = roleModel(config, "sentinel") ?? projectModels(config).harness;
         if (choice?.model !== undefined) {
             const slash = choice.model.indexOf("/");
             const found = slash === -1 ? undefined : ctx.modelRegistry.find(choice.model.slice(0, slash), choice.model.slice(slash + 1));

package/docs/hosting.md

@@ -121,6 +121,7 @@ The [sentinel](sentinel.md) is one of the host's chats: turri opens it with the
 
 - **Notices.** What it finds wrong comes as `onNotice(notice)`: `{ id, chat, severity: "error" | "warning" | "info", summary, evidence: string[], actions: [{ label, task }], module?, pulse?, job?, state: "open" }`. Draw it in the chat `chat` names - the one `focus` last named, or, while that is the sentinel, the chat that asked for the pulse. It is drawn there as a card in the transcript too. A host given `onNotice` answers it itself - the terminal's dialog is not opened - with `answer(id, …)`: `{ action: index | label }` starts that chat's agent on the action's task, `{ steer: text }` on the person's words, `{ dismiss: true }` on nothing. `onNoticeOver(notice)` comes as it is answered - and when a newer notice about its module supersedes it (`state: "superseded"`) - for the host to take the card down. `notices()` lists the open ones.
 - **Conclusions.** As the sentinel is done with each pulse - all well or not - `onConcluded({ job, verdict: "holds" | "wrong", summary, module, pulse, chat })` comes, and the chat `chat` names - the one `focus` last named, as for a notice - shows it and its agent says so in a line.
+- **Its model.** The `sentinel` role in `models:`, else the chat's model - `models.chat`, else `harness-model` - with its thinking, set as its chat opens: not pi's default model, which may not be one the project's provider has. What the person then picks in its chat stands. See [its model](sentinel.md#its-model).
 - **Its tools.** `sentinel: { tools }` are [pi](https://pi.dev) tool definitions registered in the sentinel's chat alone and told to it in its prompt - the host's browser, say, for it to test a release with. The rest of the host's `extensions` are built into its chat too, but their tools are refused it: only its own read, and these.
 - **Its surface.** What it is told is its own prompt, not the conversation's: the host's `surface` is not in it; `systemPrompt` still has the last word.
 

package/docs/sentinel.md

@@ -43,7 +43,7 @@ It has a slot of its own: with it on, you open up to eight chats, and the ninth
 
 ## Its model
 
-The `sentinel` role in `models:` - else the chat's model, `harness-model` - see [models](config.md#models). Judging behaviour against \*\*\*plain, and driving a browser, want a capable model; point it at a cheaper one if it costs too much for every pulse.
+The `sentinel` role in `models:` - else the chat's model, `models.chat` else `harness-model`, with its thinking - see [models](config.md#models). A `sentinel` entry that gives only `thinking` runs on the chat's model, thinking as it says. It is set as the sentinel's chat opens, in the terminal and in a host alike - never the model its session started on, which in a host is [pi](https://pi.dev)'s default and may not be one the project's provider has. What the person then picks in its chat stands. Judging behaviour against \*\*\*plain, and driving a browser, want a capable model; point it at a cheaper one if it costs too much for every pulse.
 
 ## In a host
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@turri-dev/cli",
-  "version": "0.1.20-next.3ae4a0b",
+  "version": "0.1.21-next.741b3a9",
   "license": "MIT",
   "type": "module",
   "repository": {