@sayknow-cli/coding-agent 0.5.25 → 0.6.0

package/src/config/settings-schema.ts

@@ -5,6 +5,7 @@ import { getThinkingLevelMetadata } from "../thinking-metadata";
 import { EDIT_MODES } from "../utils/edit-mode";
 import { CONFIGURABLE_SEARCH_PROVIDER_IDS } from "../web/search/types";
 import type { ModelSelectorValue } from "./model-selector-value";
+import { TASK_MODEL_SPECIALTY_IDS } from "./task-model-specialties";
 
 const THINKING_EFFORTS = ["minimal", "low", "medium", "high", "xhigh", "max"] as readonly Effort[];
 const DEFAULT_THINKING_LEVELS = ["off", ...THINKING_EFFORTS] as const;
@@ -192,6 +193,11 @@ interface RecordDef<T> {
 	type: "record";
 	default: Record<string, T>;
 	valueSchema?: RecordValueDef;
+	/**
+	 * Closed key set. When present, reconciliation rejects any other key instead of
+	 * silently carrying a typo that no consumer will ever read.
+	 */
+	keys?: readonly string[];
 	ui?: UiBase;
 }
 
@@ -2002,12 +2008,32 @@ export const SETTINGS_SCHEMA = {
 	// Typed decisions
 	"decisions.enabled": {
 		type: "boolean",
-		default: false,
+		default: true,
 		ui: {
 			tab: "context",
 			label: "Typed decisions",
 			description:
-				"Add a model-backed second stage to workflow routing. The keyword table already runs on every turn and costs nothing; this handles the phrasings it cannot express, which is most wording that is not a literal match. Costs one small model call, and only on turns the keyword table did not already answer. Any failure falls back to keyword-only behaviour, but a successful answer can also select a different workflow than the deep-interview ambiguity detector would have.",
+				"Model-backed second stage for workflow routing. The keyword table runs first on every turn and costs nothing; this handles the phrasings it cannot express, which is most wording that is not a literal match. Costs one small model call, only on turns the keyword table did not already answer, on the cheapest backend available: TypeSafe when a key is stored, else a local runtime that is running, else the small model of the provider you are chatting with. Any failure falls back to keyword-only behaviour, but a successful answer can also select a different workflow than the deep-interview ambiguity detector would have. Turn off to route on the keyword table alone.",
+		},
+	},
+
+	/**
+	 * Feed routing answers back into the deterministic keyword table.
+	 *
+	 * The hand-written table cannot be grown by hand for Korean — measured recall
+	 * was 0/9 — so it grows itself instead: a two-stem pattern that produced the
+	 * same routing answer on two distinct prompts, and was never contradicted, is
+	 * promoted and thereafter fires for free. One contradiction retracts it
+	 * permanently. Stems and hashes are stored; prompt text never is.
+	 */
+	"decisions.keywordLearning": {
+		type: "boolean",
+		default: true,
+		ui: {
+			tab: "context",
+			label: "Learn routing keywords",
+			description:
+				"Remember the phrasings the routing model resolves, so repeating one stops costing a model call. A pattern must give the same answer on two different prompts before it fires on its own, and a single disagreement removes it for good. Only word stems and hashes are written to disk, never your prompts. Turn off to keep the keyword table frozen at its built-in entries.",
 		},
 	},
 
@@ -2020,12 +2046,14 @@ export const SETTINGS_SCHEMA = {
 	 * mid-session invalidates the prompt cache, which on a long context costs
 	 * more than the cheaper tier saves.
 	 *
-	 * Needs `decisions.enabled` and at least two tiers configured. Without both
-	 * it never fires and the configured role models are used unchanged.
+	 * Needs `decisions.enabled` and at least two tiers configured. The tiers are
+	 * empty by default, so this is a no-op until the user sets them — which is why
+	 * it defaults on: shipping it off meant the routing code existed and never ran
+	 * even for users who had configured the tiers it needs.
 	 */
 	"task.modelRouting.enabled": {
 		type: "boolean",
-		default: false,
+		default: true,
 		ui: {
 			tab: "tasks",
 			label: "Route subagent models per task",
@@ -2050,6 +2078,25 @@ export const SETTINGS_SCHEMA = {
 	 * frontend, not to write it.
 	 */
 	"task.modelRouting.frontendModel": { type: "string", default: "" },
+	/**
+	 * Per-specialty models — the **work-kind** axis.
+	 *
+	 * Keys are the bounded ids in `config/task-model-specialties.ts`; values use the
+	 * same selector grammar as any other model setting, so a chain is allowed. A
+	 * specialty with no entry inherits the role's resolved model unchanged, which is
+	 * why the default is empty rather than pre-populated.
+	 *
+	 * These are routing hints, never agents: nothing here widens the canonical role
+	 * roster, model-profile role keys, tool grants, or spawn permissions. Saving one
+	 * does not enable `task.modelRouting.enabled`; the assignment surface reports the
+	 * disabled state instead of silently turning routing on.
+	 */
+	"task.modelRouting.specialtyModels": {
+		type: "record",
+		default: {} as Record<string, ModelSelectorValue>,
+		valueSchema: MODEL_SELECTOR_VALUE_SCHEMA,
+		keys: TASK_MODEL_SPECIALTY_IDS,
+	},
 
 	// TTSR
 	"ttsr.enabled": {
@@ -4079,15 +4126,20 @@ export function reconcileSettingsSchema(raw: Record<string, unknown>): {
 		}
 		if (!validSettingValue(definition, next))
 			issues.push({ path, kind: "invalid", detail: `Expected ${definition.type}.` });
-		if (
-			definition.type === "record" &&
-			"valueSchema" in definition &&
-			definition.valueSchema &&
-			validSettingValue(definition, next)
-		) {
+		if (definition.type === "record" && validSettingValue(definition, next)) {
+			const allowedKeys = "keys" in definition && definition.keys ? new Set<string>(definition.keys) : undefined;
+			const valueSchema = "valueSchema" in definition ? definition.valueSchema : undefined;
 			for (const [key, entry] of Object.entries(next as Record<string, unknown>)) {
+				if (allowedKeys && !allowedKeys.has(key)) {
+					issues.push({
+						path: `${path}.${key}`,
+						kind: "invalid",
+						detail: `Unknown key. Expected one of: ${[...allowedKeys].join(", ")}.`,
+					});
+					continue;
+				}
 				if (
-					definition.valueSchema.type === "model-selector-value" &&
+					valueSchema?.type === "model-selector-value" &&
 					!(typeof entry === "string" || (Array.isArray(entry) && entry.every(item => typeof item === "string")))
 				) {
 					issues.push({ path: `${path}.${key}`, kind: "invalid", detail: "Expected model-selector-value." });

package/src/config/task-model-specialties.ts

@@ -0,0 +1,131 @@
+/**
+ * Bounded work-specialty axis for subagent model selection.
+ *
+ * A canonical role model is a standing guess about the *average* assignment that
+ * role gets. The difficulty ladder in `decisions/task-routing.ts` moves that guess
+ * when one assignment is unusually hard or unusually mechanical. This axis moves it
+ * for a different reason: the assignment belongs to a *kind of work* the user has
+ * deliberately picked a model for — backend architecture, frontend design, plain
+ * implementation, test work, or review.
+ *
+ * Specialties are **not agents**. They never appear in agent discovery, task `agent`
+ * values, prompts, tool grants, spawn allowlists, or model-profile role keys. The
+ * canonical roster stays exactly `executor`, `architect`, `planner`, `critic`, and
+ * `default` remains the main-model assignment target. A specialty only ever selects
+ * a model for work that is already being routed to one of those roles.
+ */
+import { normalizeModelSelectorValue } from "./model-selector-value";
+
+/** Stable configuration/routing identifiers. Display strings are localized separately. */
+export const TASK_MODEL_SPECIALTY_IDS = [
+	"backendArchitecture",
+	"frontendDesign",
+	"implementation",
+	"testing",
+	"review",
+] as const;
+
+export type TaskModelSpecialty = (typeof TASK_MODEL_SPECIALTY_IDS)[number];
+
+/**
+ * Which canonical role agents may receive each specialty.
+ *
+ * Planning roles share the two design specialties on purpose: the user's intent is
+ * "a backend-strong model plans backend work", not "planner and architect each get
+ * their own private backend model". Implementation roles never take a design
+ * specialty, mirroring the existing frontend-domain rule.
+ */
+export const TASK_MODEL_SPECIALTY_ROLES: Readonly<Record<TaskModelSpecialty, readonly string[]>> = {
+	backendArchitecture: ["planner", "architect"],
+	frontendDesign: ["planner", "architect"],
+	implementation: ["executor"],
+	testing: ["executor"],
+	review: ["critic"],
+};
+
+/** Neutral classifier outcome: the work does not clearly belong to one specialty. */
+export const TASK_MODEL_SPECIALTY_NONE = "none" as const;
+
+/** Bounded-key predicate for the `task.modelRouting.specialtyModels` record. */
+export function isTaskModelSpecialty(value: unknown): value is TaskModelSpecialty {
+	return typeof value === "string" && (TASK_MODEL_SPECIALTY_IDS as readonly string[]).includes(value);
+}
+
+/** Specialties a given canonical role agent is allowed to receive, in declaration order. */
+export function specialtiesForRole(agentName: string): TaskModelSpecialty[] {
+	return TASK_MODEL_SPECIALTY_IDS.filter(specialty => TASK_MODEL_SPECIALTY_ROLES[specialty].includes(agentName));
+}
+
+/** Whether a specialty may be applied to work routed to this canonical role agent. */
+export function specialtySupportsRole(specialty: TaskModelSpecialty, agentName: string): boolean {
+	return TASK_MODEL_SPECIALTY_ROLES[specialty].includes(agentName);
+}
+
+/** Where a composed candidate came from, so a receipt never overstates what was selected. */
+export type TaskRoutingSource = "specialty" | "legacy-frontend" | "tier" | "baseline";
+
+export interface TaskRoutingCandidate {
+	/** The configured selector, normalized but otherwise untouched. */
+	selector: string;
+	source: TaskRoutingSource;
+	/** Set when `source` is `specialty` or `legacy-frontend`. */
+	specialty?: TaskModelSpecialty;
+	/** Set when `source` is `tier`. */
+	tier?: string;
+}
+
+/**
+ * Identity used for deduplication.
+ *
+ * An explicit thinking suffix is part of the identity: `provider/model:high` and
+ * `provider/model:low` are different configured intents, and collapsing them would
+ * silently drop the user's effort choice from a chain.
+ */
+export function specialtySelectorIdentity(selector: string): string {
+	return selector.trim().toLowerCase();
+}
+
+/** The `provider/model` part, ignoring any thinking suffix. Used for "same model" checks. */
+export function specialtySelectorHead(selector: string): string {
+	return specialtySelectorIdentity(selector).split(":")[0]?.trim() ?? "";
+}
+
+/** Expand a configured selector value into normalized candidates tagged with their origin. */
+export function toRoutingCandidates(
+	value: string | readonly string[] | undefined,
+	source: TaskRoutingSource,
+	extra?: { specialty?: TaskModelSpecialty; tier?: string },
+): TaskRoutingCandidate[] {
+	return normalizeModelSelectorValue(value)
+		.map(selector => selector.trim())
+		.filter(selector => selector.length > 0)
+		.map(selector => ({ selector, source, ...extra }));
+}
+
+/**
+ * Concatenate candidate segments, keeping the first occurrence of each identity.
+ *
+ * A selector that also exists in the baseline segment is attributed to `baseline`
+ * even when an earlier specialty segment introduced it. Resolving that entry proves
+ * only that the role's own configured model was usable — reporting it as a specialty
+ * hit would claim a routing decision that never happened.
+ */
+export function dedupeRoutingCandidates(segments: readonly TaskRoutingCandidate[][]): TaskRoutingCandidate[] {
+	const flattened = segments.flat();
+	const baselineIdentities = new Set(
+		flattened.filter(candidate => candidate.source === "baseline").map(c => specialtySelectorIdentity(c.selector)),
+	);
+	const seen = new Set<string>();
+	const deduped: TaskRoutingCandidate[] = [];
+	for (const candidate of flattened) {
+		const identity = specialtySelectorIdentity(candidate.selector);
+		if (seen.has(identity)) continue;
+		seen.add(identity);
+		deduped.push(
+			candidate.source !== "baseline" && baselineIdentities.has(identity)
+				? { selector: candidate.selector, source: "baseline" }
+				: candidate,
+		);
+	}
+	return deduped;
+}

package/src/decisions/index.ts

@@ -43,8 +43,9 @@ export function createDecisionService(options: DecisionServiceOptions): Decision
 	 * probabilities, and it resolves `null` immediately when no key is stored, so users
 	 * who never added one pay nothing for it being in the list.
 	 *
-	 * The user's logged-in model is the fallback and the default experience: no extra
-	 * vendor, no extra key, works offline of TypeSafe entirely.
+	 * The user's logged-in provider is the fallback and the default experience: no extra
+	 * vendor, no extra key, works offline of TypeSafe entirely. Inside it, a live local
+	 * runtime is tried before a hosted small model; see `llm-backend.ts`.
 	 */
 	const backends = options.backends ?? [createTypeSafeDecisionBackend(options), createLlmDecisionBackend(options)];
 
@@ -53,6 +54,11 @@ export function createDecisionService(options: DecisionServiceOptions): Decision
 		async decide(request: DecisionRequest): Promise<DecisionResult | null> {
 			if (!enabled || backends.length === 0) return null;
 			for (const backend of backends) {
+				// A listener added to a signal that already fired never runs, and the
+				// backends only read their own derived signal. Measured: a caller that
+				// aborted during the previous backend's await got a full attempt budget of
+				// silence from the next one instead of an immediate null.
+				if (request.signal?.aborted) return null;
 				const controller = new AbortController();
 				const abortOnCallerSignal = () => controller.abort();
 				request.signal?.addEventListener("abort", abortOnCallerSignal, { once: true });