@north-light/crouter 0.3.187 → 0.3.188

package/dist/builtin-memory/internal/agent-shaping.md

@@ -47,7 +47,7 @@ Specialist sub-personas hang off a parent kind — `plan/reviewers/*` (architect
 
 ### Custom personas
 
-The roster is extensible. Add a `kinds.<name>` entry to a `config.json` at user or project scope (fields: `whenToUse` required, plus optional `model`, `orchestratorModel`, `tools`, `extensions`, `availableTo`) and author the persona prose at `kinds/<name>/00-base.md` (and `01-orchestrator.md`) gated `{kind: <name>, mode: ...}`. A standing personal assistant, for example, is a scope-configured custom `personal-assistant` kind rather than a builtin kind. The registry merges **project > user > builtin**, so a custom kind can add a new role or shadow a builtin one without restating the rest. A plugin can ship a kind the same way — a `kinds` block in its manifest plus gated persona docs in its memory tree; an enabled plugin's entries layer directly below its host scope's own `config.json` (see `internal/plugins`). Reach for a custom kind when a **recurring role** wants its own standing discipline and model/tool defaults that outlast any single task — not for a one-off instruction, which belongs in the spawn prompt.
+The roster is extensible. Add a `kinds.<name>` entry to a `config.json` at user or project scope (any subset of `whenToUse`, `model`, `orchestratorModel`, `tools`, `extensions`, `availableTo` — an entry field-merges over a kind a lower layer defines, so `{"whenToUse": "…"}` alone re-glosses a builtin kind without touching its model tier; a NEW kind requires `whenToUse`) and author the persona prose at `kinds/<name>/00-base.md` (and `01-orchestrator.md`) gated `{kind: <name>, mode: ...}`. A standing personal assistant, for example, is a scope-configured custom `personal-assistant` kind rather than a builtin kind. The registry merges **project > user > builtin**, so a custom kind can add a new role or shadow a builtin one without restating the rest. A plugin can ship a kind the same way — a `kinds` block in its manifest plus gated persona docs in its memory tree; an enabled plugin's entries layer directly below its host scope's own `config.json` (see `internal/plugins`). Reach for a custom kind when a **recurring role** wants its own standing discipline and model/tool defaults that outlast any single task — not for a one-off instruction, which belongs in the spawn prompt.
 
 ## Modes — base vs orchestrator
 

package/dist/builtin-memory/internal/plugins.md

@@ -64,7 +64,7 @@ The `<plugin-name>` directory IS the plugin. The manifest's `name` field must ma
 | `owner` | optional | Author info. |
 | `commands` | optional | Plugin-root-relative path to a `commands.json` command manifest. It must appear with `transport`; together they make the plugin contribute `crtr` commands — see [Plugin commands](#plugin-commands). |
 | `transport` | optional | Required exactly when `commands` is present. `{ "kind": "exec", "executable": "bin/cmd.js" }` runs executable leaves; a passthrough-only exec manifest may omit `executable`. `{ "kind": "http", "endpoint": "https://…", "authEnv": "TOKEN_NAME" }` calls a remote HTTP command surface. Archive-installed plugins also carry crouter-synthesized `bundle` provenance; authors do not add it. |
-| `kinds` | optional | Kind-registry contributions, keyed by full kind string — the same two entry shapes a scope `config.json` `kinds` block accepts: a FULL entry (`whenToUse` required, plus optional `model`, `orchestratorModel`, `tools`, `extensions`, `availableTo`) defines or shadows a kind; a sparse PATCH overrides launch knobs of a kind a lower layer defines. See [Plugin kinds](#plugin-kinds). |
+| `kinds` | optional | Kind-registry contributions, keyed by full kind string — the same rule a scope `config.json` `kinds` block follows: each entry is any subset of `KindConfig` fields (`whenToUse`, `model`, `orchestratorModel`, `tools`, `extensions`, `availableTo`). It field-merges over a kind a lower layer already defines — `whenToUse` included, so overriding just the spawn guidance never strips the kind's model tier — and defines a new kind when none does (then `whenToUse` is required). See [Plugin kinds](#plugin-kinds). |
 
 ## Plugin kinds