@crouton-kit/crouter 0.3.37 → 0.3.39

package/dist/pi-extensions/canvas-doc-substrate.js

@@ -2,9 +2,8 @@
 // a single self-contained canvas pi extension.
 //
 // Loaded into a canvas node's pi process via the node's launch.extensions list
-// (registered in CANVAS_EXTENSIONS at the flip — see the note at the bottom of
-// this file; AUTHOR-ONLY for now, NOT yet registered). INERT when CRTR_NODE_ID
-// is absent (a plain pi session or legacy job agent loads it as a no-op).
+// (registered in CANVAS_EXTENSIONS, src/core/runtime/launch.ts). INERT when
+// CRTR_NODE_ID is absent (a plain pi session or legacy job agent loads it as a no-op).
 //
 // It owns the substrate's two new pi hooks:
 //

package/dist/types.d.ts

@@ -100,6 +100,29 @@ export interface ModelLaddersConfig {
     anthropic: Record<ModelStrength, string>;
     openai: Record<ModelStrength, string>;
 }
+/** Launch metadata for one kind (a top-level kind like `developer`, or a full
+ *  sub-kind string like `plan/reviewers/security`) — the settings-file
+ *  replacement for per-kind persona frontmatter. `model`/`tools`/`extensions`
+ *  are launch knobs consumed by `buildLaunchSpec` (Phase 3); `whenToUse` is the
+ *  one-line gloss shown in `node new -h` / `node promote -h`. `availableTo` is
+ *  VISIBILITY-ONLY (never launch validation): the list of top-level kind names
+ *  whose spawn menus surface this sub-kind, `'*'` meaning every kind; omitted
+ *  defaults to the sub-kind's own top-level ancestor (e.g.
+ *  `plan/reviewers/security` defaults to `['plan']`) — this reproduces the
+ *  original sub-persona `availableTo` semantics. A direct launch by full kind
+ *  string is always valid regardless of `availableTo`. */
+export interface KindConfig {
+    model?: string;
+    /** Model override for ORCHESTRATOR mode only, e.g. a kind whose orchestrator
+     *  body warrants a stronger model than its base worker. Selection: base mode
+     *  always uses `model`; orchestrator mode uses `orchestratorModel ?? model`.
+     *  Omit when the kind runs the same model in both modes. */
+    orchestratorModel?: string;
+    tools?: string[];
+    extensions?: string[];
+    whenToUse: string;
+    availableTo?: string[];
+}
 export interface ScopeConfig {
     schema_version: number;
     marketplaces: Record<string, ConfigMarketplaceEntry>;
@@ -108,7 +131,12 @@ export interface ScopeConfig {
     max_panes_per_window: number;
     canvasNav: CanvasNavConfig;
     modelLadders: ModelLaddersConfig;
-    personaStrengths: Record<string, ModelStrength>;
+    /** The kind registry (spec §1.5): kind existence + launch knobs, keyed by
+     *  full kind string (top-level e.g. `developer`, or sub-kind e.g.
+     *  `plan/reviewers/security`). Builtins ship a default registry via
+     *  `defaultScopeConfig()`; user/project `config.json` adds or shadows
+     *  entries at the same scope precedence as the rest of `ScopeConfig`. */
+    kinds: Record<string, KindConfig>;
 }
 export interface ScopeState {
     marketplaces: Record<string, {
@@ -158,6 +186,23 @@ export interface InstalledMarketplace {
     url: string;
     ref: string;
 }
+/** The on-disk manifest at `~/.crouter/profiles/<slug>-<id>/profile.json`
+ *  (spec §2.1). A profile is an agent identity defined at the user root: it
+ *  names N project directories and owns its own `memory/` store. `projects`
+ *  are absolute, real-path-resolved directories in manifest order — the
+ *  pointer set `findProjectScopeRoots` walks (Phase 5), after the node's own
+ *  cwd. `name` is the mutable display name (and the gateable `profile` subject
+ *  field, Phase 6); `<slug>-<id>` in the directory name is the stable id and
+ *  never changes on rename. See `src/core/profiles/manifest.ts` for every
+ *  read/write of this file — it is the sole owner of path resolution and
+ *  mutation. */
+export interface ProfileManifest {
+    schema_version: number;
+    name: string;
+    projects: string[];
+    created_at: string;
+    last_used_at: string | null;
+}
 export declare const PLUGIN_MANIFEST_DIR = ".crouter-plugin";
 export declare const PLUGIN_MANIFEST_FILE = "plugin.json";
 export declare const MARKETPLACE_MANIFEST_DIR = ".crouter-marketplace";
@@ -166,8 +211,19 @@ export declare const CRTR_DIR_NAME = ".crouter";
 export declare const CONFIG_FILE = "config.json";
 export declare const STATE_FILE = "state.json";
 export declare const AGENTS_DIR = "agents";
+export declare const PROFILE_DIR = "profiles";
 export declare const DEFAULT_MAX_PANES_PER_WINDOW = 3;
 export declare function defaultScopeConfig(): ScopeConfig;
+/** The builtin kind registry (spec §1.5): the built-in defaults for every
+ *  top-level kind and its sub-persona kinds. `whenToUse`/`model` are the
+ *  one-per-kind defaults (not one per mode) that seed a node's spawn menu
+ *  and default model choice. Roadmap-shaping guidance is orchestrator-only —
+ *  an orchestrator-gated memory doc keyed to the kind, not baked into the
+ *  registry entry. Sub-persona `availableTo` is
+ *  omitted where it only reproduces the default (its own top-level
+ *  ancestor) — `product/teardown` is included explicitly below for parity
+ *  even though its value equals the default. */
+export declare function defaultKindsConfig(): Record<string, KindConfig>;
 /** Built-in canvas-nav binds so an absent config still gives the intended UX.
  *  prefixBinds restate the current menu defaults; graphBinds stay empty.
  */

package/dist/types.js

@@ -17,6 +17,9 @@ export const STATE_FILE = 'state.json';
 // Subagent definitions live as flat `<name>.md` files under `<root>/agents/`,
 // for both scope roots and plugins.
 export const AGENTS_DIR = 'agents';
+// Profile stores live as `<slug>-<id>/` dirs under `<user-scope-root>/profiles/`
+// (never a project/builtin scope — profiles are a user-root-only concept).
+export const PROFILE_DIR = 'profiles';
 export const DEFAULT_MAX_PANES_PER_WINDOW = 3;
 export function defaultScopeConfig() {
     return {
@@ -27,7 +30,86 @@ export function defaultScopeConfig() {
         max_panes_per_window: DEFAULT_MAX_PANES_PER_WINDOW,
         canvasNav: defaultCanvasNavConfig(),
         modelLadders: defaultModelLaddersConfig(),
-        personaStrengths: {},
+        kinds: defaultKindsConfig(),
+    };
+}
+/** The builtin kind registry (spec §1.5): the built-in defaults for every
+ *  top-level kind and its sub-persona kinds. `whenToUse`/`model` are the
+ *  one-per-kind defaults (not one per mode) that seed a node's spawn menu
+ *  and default model choice. Roadmap-shaping guidance is orchestrator-only —
+ *  an orchestrator-gated memory doc keyed to the kind, not baked into the
+ *  registry entry. Sub-persona `availableTo` is
+ *  omitted where it only reproduces the default (its own top-level
+ *  ancestor) — `product/teardown` is included explicitly below for parity
+ *  even though its value equals the default. */
+export function defaultKindsConfig() {
+    return {
+        general: {
+            whenToUse: 'Anything else — the catch-all worker for a task that does not fit a specialist kind.',
+            model: 'anthropic/strong',
+        },
+        explore: {
+            whenToUse: 'Map unfamiliar code or architecture — read-only orientation and code-path research with concrete file:line evidence. Anything diagnostic — investigating a failure, why something is broken or misbehaving, or live/runtime behavior — is advisor, not explore.',
+            model: 'anthropic/light',
+        },
+        developer: {
+            whenToUse: 'Implement a change — make the feature or fix genuinely work against its acceptance criteria, not merely compile.',
+            model: 'anthropic/medium',
+            orchestratorModel: 'anthropic/strong',
+        },
+        design: {
+            whenToUse: 'Architect a solution — produce one design document an implementer can build from without re-deciding anything left open.',
+            model: 'anthropic/strong',
+        },
+        plan: {
+            whenToUse: 'Break work into steps — turn a spec or design into a concrete, phased, parallelizable plan with every decision resolved.',
+            model: 'openai/strong',
+        },
+        spec: {
+            whenToUse: 'Collaborate with the user to discover what to build, then write the spec — behavior, non-goals, interfaces, edge cases, testable acceptance criteria.',
+            model: 'anthropic/strong',
+        },
+        product: {
+            whenToUse: 'Discover the real user need behind a request and define the product experience that meets it — use cases, how it should feel and look, grounded in how comparable products solve it. Hands off to spec.',
+            model: 'anthropic/strong',
+        },
+        review: {
+            whenToUse: 'Validate or critique code, a plan, or a spec — deliver a complete, severity-rated verdict without adjudicating.',
+            model: 'openai/strong',
+        },
+        advisor: {
+            whenToUse: 'Debug failures, investigate why something is broken or misbehaving, diagnose live/runtime issues, or give engineering advice and second opinions — reason from evidence and recommend the next move. Use advisor (not explore) whenever the task is to find out what is going wrong.',
+            model: 'anthropic/ultra',
+        },
+        'plan/reviewers/requirements-coverage': {
+            whenToUse: 'every requirement and design constraint maps to a concrete plan task, classified Covered/Partial/Missing; flags only blocking gaps',
+            model: 'openai/strong',
+        },
+        'plan/reviewers/pattern-consistency': {
+            whenToUse: "the plan honors the codebase's real conventions; reads actual source and cites the pattern each finding deviates from; owns contract-level conflicts between parts",
+            model: 'openai/strong',
+        },
+        'plan/reviewers/code-smells': {
+            whenToUse: 'nullability mismatches, type conflicts across parts, hidden N+1s, over-fetching, missing error boundaries, leaky abstractions; owns file-level conflicts between parts',
+            model: 'openai/strong',
+        },
+        'plan/reviewers/security': {
+            whenToUse: 'input validation, injection surfaces, auth/authz gaps, data exposure, races; flags only risks with a concrete exploit path',
+            model: 'openai/strong',
+        },
+        'plan/reviewers/architecture-fit': {
+            whenToUse: "proposed files/modules/abstractions fit the system's existing decomposition; flags new units that duplicate existing ones or cross layer boundaries",
+            model: 'openai/strong',
+        },
+        'spec/requirements': {
+            whenToUse: 'Derive testable EARS requirements from a finished, approved design — in isolation, from the rendered design text alone.',
+            model: 'anthropic/strong',
+        },
+        'product/teardown': {
+            whenToUse: 'Tear down ONE comparable product against a specific job-to-be-done — how it solves it, where it succeeds and fails its users, and what to borrow, avoid, or differentiate from.',
+            model: 'anthropic/strong',
+            availableTo: ['product'],
+        },
     };
 }
 /** Built-in canvas-nav binds so an absent config still gives the intended UX.