@north-light/crouter 0.3.186 → 0.3.187

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. 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 (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.
 
 ## Modes — base vs orchestrator
 

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

@@ -64,6 +64,15 @@ 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). |
+
+## Plugin kinds
+
+A plugin can ship a complete persona kind: declare the registry entry in the manifest's `kinds` block, and author the persona prose as ordinary plugin memory docs gated `{kind: <name>, mode: base}` (and `{kind: <name>, mode: orchestrator}`) with `system-prompt-visibility: content` — the same shape a builtin kind uses at `kinds/<kind>/00-base.md`. Nothing else is needed: gates evaluate uniformly over plugin docs, so the persona splices into any node launched with that kind.
+
+`readMergedLaunchConfig` layers an enabled plugin's `kinds` entries directly above the builtin registry and below its host scope's own `config.json` — full precedence: builtin → user-scope plugins → user config → profile → per project root (that root's plugins → that root's config). So a plugin kind appears in `crtr node new -h` and is launchable like any other, and a user or project `config.json` can still patch or shadow it. Plugins within one scope layer name-sorted; the scope's own config always wins.
+
+For archive plugins the declaration lives in the archive's `bundle.json` — `{"bundleVersion": 1, "kinds": {…}}` — and the installer copies the block into the synthesized manifest. Install validates the block strictly (an invalid entry fails the install with per-entry reasons); the read side drops invalid entries silently, so the loud gate is install time.
 
 ## Scopes