@wrongstack/core 0.302.2 → 0.303.0

package/dist/types/config/root.d.ts

@@ -1,10 +1,11 @@
 import type { ConfiguredHook, HookEvent } from '../hooks.js';
-import type { AutonomyConfig, ChronicleConfig, IndexingConfig, LaunchConfig, SessionLoggingConfig, SyncConfig } from './autonomy.js';
 import type { AdaptiveConcurrencyConfig, CircuitBreakerRuntimeConfig, ContextConfig } from './context.js';
+import type { AutonomyConfig, ChronicleConfig, IndexingConfig, LaunchConfig, SessionLoggingConfig, SyncConfig } from './autonomy.js';
 import type { FeaturesConfig, LogConfig, MCPServerConfig, PluginConfig, PluginManagerConfig, SageConfig } from './mcp-features.js';
 import type { CustomModelDefinition, ModelMatrixEntry, ProviderConfig } from './providers.js';
 import type { CloudSyncConfig, HqClientConfig, ModelRuntimeConfig, SystemPromptConfig } from './runtime.js';
 import type { BrainConfig, FleetConfig, SkillsConfig } from './skills-fleet-brain.js';
+import type { ThemePresetId } from './ui.js';
 import type { ToolsConfig } from './tools.js';
 export interface GitBehaviorConfig {
     /**
@@ -40,6 +41,15 @@ export interface Config {
      * unset, surfaces fall back to their own browser/system detection.
      */
     uiLocale?: string | undefined;
+    /**
+     * TUI color theme preset — read by the TUI on boot to apply the matching
+     * palette, and written by the `/theme` slash command (CLI REPL and TUI) so
+     * the choice persists across restarts. Unconstrained string at the config
+     * layer: the TUI owns the canonical preset list and applies a fallback
+     * (`catppuccin`) when the stored value is unknown, so a forward-compat
+     * drift on the TUI side never breaks the config round-trip.
+     */
+    themePreset?: ThemePresetId | undefined;
     providers?: Record<string, ProviderConfig>;
     /**
      * Top-level custom models (maps modelId → definition). Merged with

package/dist/types/config/skills-fleet-brain.d.ts

@@ -128,6 +128,40 @@ export interface FleetConfig {
     } | undefined;
     /** Brain-gated fleet supervisor (rebalance/steer/spawn-helper). */
     supervisor?: FleetSupervisorConfig | undefined;
+    /** Roster-agent self-learning: capture → optimize → per-skill addenda. */
+    learning?: AgentLearningConfig | undefined;
+}
+/**
+ * Automatic optimization of roster-agent learning.
+ *
+ * Capture is always automatic. This section governs the *distillation* pass
+ * that turns captured directives into per-skill project addenda and a
+ * consolidated role document, then archives and resets the raw buffer.
+ */
+export interface AgentLearningConfig {
+    autoOptimize?: {
+        /** Run the distillation pass automatically. Default true. */
+        enabled?: boolean | undefined;
+        /** Raw buffer size (bytes) that makes a role eligible. Default 8192. */
+        thresholdBytes?: number | undefined;
+        /** Never optimize a buffer with fewer directives than this. Default 4. */
+        minEntries?: number | undefined;
+        /**
+         * Directives routed to a skill that has no addendum yet. Reaching this
+         * count makes a role eligible even below `thresholdBytes`. Default 3.
+         */
+        minPendingSkillDirectives?: number | undefined;
+        /** Minimum gap between automatic passes for one role. Default 6h. */
+        minIntervalMs?: number | undefined;
+        /** Quiet period after the last capture before a pass starts. Default 20s. */
+        debounceMs?: number | undefined;
+        /**
+         * Evaluate every role once when the fleet host starts, so roles that
+         * became eligible before this session are not stuck waiting for their
+         * next capture. Default true.
+         */
+        sweepOnStart?: boolean | undefined;
+    } | undefined;
 }
 /** Config surface for the brain-gated FleetSupervisor. */
 export interface FleetSupervisorConfig {

package/dist/types/config/ui.d.ts

@@ -0,0 +1,14 @@
+/**
+ * Shared UI theme preset identifiers.
+ *
+ * Lives in core so the Config schema, the CLI `/theme` slash command, and
+ * the TUI runtime can all reference the same string union without
+ * importing the TUI package (which would invert the dependency direction).
+ *
+ * Keep in lockstep with `THEME_OPTIONS` in `packages/tui/src/theme.ts`.
+ * Adding a preset here is intentional — it also requires updating the TUI
+ * presets map AND the CLI `VALID_PRESETS` set in `tui-theme-adapter.ts`.
+ */
+export declare const THEME_PRESET_IDS: readonly ['catppuccin', 'tokyo-night', 'nord', 'cyberpunk', 'dracula', 'gruvbox-dark', 'solarized-dark', 'one-dark', 'monokai', 'rose-pine', 'kanagawa', 'ayu-dark', 'everforest', 'night-owl', 'synthwave'];
+export type ThemePresetId = (typeof THEME_PRESET_IDS)[number];
+//# sourceMappingURL=ui.d.ts.map

package/dist/types/config.d.ts

@@ -6,5 +6,6 @@ export * from './config/providers.js';
 export * from './config/mcp-features.js';
 export * from './config/autonomy.js';
 export * from './config/skills-fleet-brain.js';
+export * from './config/ui.js';
 export * from './config/root.js';
 //# sourceMappingURL=config.d.ts.map

package/dist/types/index.d.ts

@@ -13,8 +13,8 @@ export { ProviderError, classifyProviderError, effectiveInputTokens, isContextOv
 export type { CacheTtl, Capabilities, JsonSchemaSpec, Provider, ProviderContextLimit, ProviderErrorBody, ProviderErrorKind, ReasoningConfig, ReasoningEffort, ReasoningRequest, Request, RequestCacheControl, Response, ResponseFormat, SafetySetting, StopReason, StreamEvent, Usage } from './provider.js';
 export { StreamHangError } from './provider.js';
 export type { ProviderRunner, RunProviderOptions } from './provider-runner.js';
-export { DEFAULT_TUI_THINKING_WORD, FLEET_CHAT_VERBOSITY_VALUES, MAX_TUI_THINKING_WORD_LENGTH, normalizeTokenSavingTier, normalizeTuiThinkingWord, resolveFleetChatVerbosity, resolveTokenSavingTier } from './config.js';
-export type { AdaptiveConcurrencyConfig, AutonomyConfig, BrainConfig, BrainCouncilConfig, BrainCouncilVoterConfig, BrainModelEntry, CircuitBreakerRuntimeConfig, ConcreteTokenSavingTier, Config, ConfigLoader, ConfigStore, ContextConfig, CouncilPersonaDefinition, CouncilToolConfig, CouncilToolProfileDefinition, CustomModelDefinition, ExecDangerConfig, ExecToolConfig, FeaturesConfig, FleetChatVerbosity, FleetConfig, FleetSupervisorConfig, GitBehaviorConfig, HqClientConfig, IndexingConfig, InputHistoryConfig, LaunchConfig, LaunchMenuChoice, LogConfig, LoopDetectionConfig, MCPHealthConfig, MCPHealthThresholds, MCPServerConfig, ModelMatrixEntry, ModelRuntimeCacheConfig, ModelRuntimeConfig, ModelRuntimeParametersConfig, ModelRuntimeReasoningConfig, NextStepsToolConfig, PluginConfig, PluginManagerConfig, ProviderApiKey, ProviderConfig, SageConfig, SessionLoggingConfig, SkillsConfig, SyncCategory, SyncConfig, TokenSavingTier, ToolDescriptionMode, ToolDescriptionModeConfig, ToolResultRenderMode, ToolResultRenderModeConfig, ToolsConfig } from './config.js';
+export { DEFAULT_TUI_THINKING_WORD, FLEET_CHAT_VERBOSITY_VALUES, MAX_TUI_THINKING_WORD_LENGTH, normalizeTokenSavingTier, normalizeTuiThinkingWord, resolveFleetChatVerbosity, resolveTokenSavingTier, THEME_PRESET_IDS } from './config.js';
+export type { AdaptiveConcurrencyConfig, AgentLearningConfig, AutonomyConfig, BrainConfig, BrainCouncilConfig, BrainCouncilVoterConfig, BrainModelEntry, CircuitBreakerRuntimeConfig, ConcreteTokenSavingTier, Config, ConfigLoader, ConfigStore, ContextConfig, CouncilPersonaDefinition, CouncilToolConfig, CouncilToolProfileDefinition, CustomModelDefinition, ExecDangerConfig, ExecToolConfig, FeaturesConfig, FleetChatVerbosity, FleetConfig, FleetSupervisorConfig, GitBehaviorConfig, HqClientConfig, IndexingConfig, InputHistoryConfig, LaunchConfig, LaunchMenuChoice, LogConfig, LoopDetectionConfig, MCPHealthConfig, MCPHealthThresholds, MCPServerConfig, ModelMatrixEntry, ModelRuntimeCacheConfig, ModelRuntimeConfig, ModelRuntimeParametersConfig, ModelRuntimeReasoningConfig, NextStepsToolConfig, PluginConfig, PluginManagerConfig, ProviderApiKey, ProviderConfig, SageConfig, SessionLoggingConfig, SkillsConfig, SyncCategory, SyncConfig, ThemePresetId, TokenSavingTier, ToolDescriptionMode, ToolDescriptionModeConfig, ToolResultRenderMode, ToolResultRenderModeConfig, ToolsConfig } from './config.js';
 export type { AnyHookOutcome, ConfiguredHook, HookEntry, HookEvent, HookFailurePolicy, HookInput, HookInvocationContext, HookMatcher, HookOutcome, HookRegistrationOptions, HttpHook, InProcessHook, PreToolUseOutcome, PreToolUseStage, ShellHook } from './hooks.js';
 export type { Compactor, CompactReport } from './compactor.js';
 export type { DirectoryPolicy, DirectoryRule, PermissionDecision, PermissionPolicy, PermissionTrace, PermissionTraceStep, TrustPolicy } from './permission.js';

package/dist/types/index.js

@@ -575,6 +575,25 @@ function normalizeTuiThinkingWord(value) {
   return word;
 }
 
+// src/types/config/ui.ts
+var THEME_PRESET_IDS = [
+  "catppuccin",
+  "tokyo-night",
+  "nord",
+  "cyberpunk",
+  "dracula",
+  "gruvbox-dark",
+  "solarized-dark",
+  "one-dark",
+  "monokai",
+  "rose-pine",
+  "kanagawa",
+  "ayu-dark",
+  "everforest",
+  "night-owl",
+  "synthwave"
+];
+
 // src/types/session-markers.ts
 var SESSION_MARKER_EVENT_TYPES = /* @__PURE__ */ new Set([
   "mode_changed",
@@ -1282,6 +1301,7 @@ export {
   SddError,
   SessionError,
   StreamHangError,
+  THEME_PRESET_IDS,
   ToolError,
   ToolErrorCategory,
   ToolValidationError,

package/dist/types/multi-agent.d.ts

@@ -168,6 +168,13 @@ export interface SubagentConfig {
      * bodies through `SkillLoader`; missing optional skills are skipped safely.
      */
     skillNames?: string[] | undefined;
+    /**
+     * Every skill this role may draw on, before per-project ranking. The catalog
+     * sets this to the full curated set while `skillNames` holds the default
+     * eager slice; the spawn path ranks the pool by project skill-affinity so a
+     * skill the project actually developed can displace an unused sibling.
+     */
+    skillPool?: string[] | undefined;
     /** Optional smart-dispatch metadata for dynamically created project roles. */
     dispatch?: {
         summary: string;

package/dist/types/task-graph.d.ts

@@ -31,6 +31,8 @@ export interface TaskEdge {
 export interface TaskGraph {
     id: string;
     specId: string;
+    /** Canonical spec scope. When present, execution must retain at least one task per id. */
+    requiredRequirementIds?: string[] | undefined;
     title: string;
     nodes: Map<string, TaskNode>;
     edges: TaskEdge[];

package/dist/types/tool-executor.d.ts

@@ -78,6 +78,8 @@ export interface ToolExecutorOptions {
      * to the result the model sees).
      */
     hookRunner?: import('../hooks/runner.js').HookRunner | undefined;
+    /** Hard-block product mutations outside a ready, running strict Kanban contract. */
+    requireKanbanGovernance?: boolean | undefined;
     /**
      * Per-tool on-screen result render mode map (`tools.resultRenderMode[name]`).
      * When set, the executor reads this map to decide whether the next

package/dist/utils/index.js

@@ -5444,6 +5444,9 @@ function subjectForToolInput(toolName, input, subjectKey) {
   const obj = input;
   if (subjectKey) {
     const value = obj[subjectKey];
+    if (Array.isArray(value)) {
+      return escapeGlobSubject(JSON.stringify(value));
+    }
     if (typeof value === "string") {
       if (isPathSubjectKey(subjectKey)) {
         const normalized = normalizePathSubject(value);

package/instructions/system-lite.md

@@ -30,12 +30,12 @@ The user is an experienced developer; accelerate them and stay focused.
 <!--ws:if tool=todo-->
 ## Todo status lifecycle
 
-Use a visible `todo` list for tasks with three or more steps. It is authoritative session/UI state; prose does not update it.
+Use a visible `todo` list for tasks with three or more steps. With Kanban active it is a compact projection of real cards, not a second task store: retain each row's `kanbanBoardId` and `kanbanTaskId`. Prose does not update it.
 
 1. Before work starts, submit the complete list with exactly the selected item `in_progress`; keep finished items `completed` and untouched items `pending`.
 2. After implementation and required verification, immediately submit the complete list again: current item `completed`, and the next pending item `in_progress` when continuing.
 3. Before a final response, reconcile every status. Never leave finished work pending/running, never mark unverified work complete, and never repeat a continuation/next-step prompt instead of updating state.
-4. Submit the final all-`completed` snapshot even though it auto-clears afterward. Session-todo mirror cards map `pending → Todo`, `in_progress → Running`, `completed → Done`.
+4. Submit the final all-`completed` snapshot even though it auto-clears afterward. With Kanban active, the projection maps `pending → Todo`, `in_progress → Running`, and verified `completed → Done`, then rebinds the next active task; failed acceptance leaves it open rather than inventing Done.
 
 If blocked, keep the item truthful and report the blocker instead of advancing it as successful.
 <!--ws:end-->
@@ -44,7 +44,11 @@ If verification fails twice for unclear reasons, stop and re-read the source ins
 <!--ws:if tool=kanban-->
 ## Work planning with Kanban
 
-This project has a Kanban board system for tracking multi-step work across turns and agents. When a task involves multiple files, review cycles, dependencies, or parallel work, **prefer Kanban cards over an ad-hoc todo list**.
+**Every actionable work request MUST be represented by a Kanban card before the first project action**. This includes investigation, one-line edits, bugs, features, docs, tests, releases, and multi-agent work; pure conversation with no project action is the only exception. Resume the existing card for the same request. Other planning surfaces and chat may mirror the work but never replace the board.
+
+If multiple boards are active or card identity is unclear, read the bounded Kanban `workbench` first. Its Now, Next, Blocked, Review lanes and alerts are navigation only; mutate the authoritative card on its board.
+
+Use one fully detailed childless leaf card for genuinely atomic work. Use a parent and dependency-ordered child cards only for composite work; never invent recursive subtasks for process theatre. The required handshake is **Kanban first, project action second**. If persistence fails, report the blocker instead of silently doing untracked work.
 
 Before creating a card, identify these prerequisites as a minimum starting point (the full "MUST" specification is governed by the Kanban Agent hard conditions below):
 - **Description** — what needs to be done
@@ -52,17 +56,19 @@ Before creating a card, identify these prerequisites as a minimum starting point
 - **Risk level** — low / medium / high
 - **Audit needs** — what evidence to capture
 
-Decide **"I should use Kanban for this"** when structured tracking would help.
+Scale the number of cards to the work, never the existence of tracking.
 
 ## Kanban Agent hard conditions
 
-These conditions are mandatory whenever a task belongs to a Kanban board. They are not suggestions and cannot be overridden for convenience:
+These conditions apply to every actionable work request while Kanban is available. They are not suggestions and cannot be overridden for convenience:
 
 1. **Never abandon or misrepresent work.** Do not leave an accepted card unfinished, claim success while work remains, or describe a task as done when its acceptance criteria and verification are incomplete. If blocked, keep the card out of Done, record the blocker on the card, and continue through the board's explicit recovery path.
-2. **Fully specify every card before advancing it.** Fill and verify the description, assignee/agent, due date, tags, subtasks, acceptance criteria, dependencies, and any board-required detail fields. An under-filled card must remain in Backlog.
+2. **Fully specify every card before advancing it.** Fill and verify the description, assignee/agent, due date, labels, acceptance criteria, dependencies, and any board-required detail fields. Only composite parents (`atomic: true`) require persisted `childTaskIds`; executable leaf cards remain childless. An under-filled card must remain in Backlog.
 3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
 4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
 5. **Close and advance immediately.** Persist the accepted card in Running before work. Persist Running → Review when work finishes and Review → Done only after acceptance evidence passes. If continuing, move the next eligible card through adjacent transitions to Running before acting. Never leave completed work in Running or repeat a next-step prompt instead of updating the board.
+6. **Keep Contract Map off the critical path.** Use the card description and executable acceptance criteria for normal work. Do not create, inspect, configure, or repair graph nodes unless the user explicitly asks for graph work, and never enable strict mode yourself. No Contract Map mode may delay start, implementation, verification, or card completion; surface existing strict-map issues as operator audit signals without stopping work to repair them.
+7. **Never shrink tracked scope by omission.** Todo, task, and plan rows carry Kanban requirement identity. Preserve every unfinished row and binding in full-list updates, and complete it before removal; only an explicit operator-controlled cancellation or migration path may retire unresolved coverage.
 
 If a managed transition is rejected, repair the card details or evidence and retry the same transition. Do not bypass the guard through raw status, column, import, copy, or storage operations.
 <!--ws:end-->
@@ -193,7 +199,7 @@ SAGE is the only long-term memory.
 <!--ws:end-->
 
 <!--ws:if tool=todo-->
-Use `todo` for the active checklist in the current session.
+Use `todo` for the compact active-task view; with Kanban every row is a real board card.
 <!--ws:end-->
 <!--ws:if tool=plan-->
 Use `plan` for work that spans turns.
@@ -202,7 +208,7 @@ Use `plan` for work that spans turns.
 Use `task` for structured cross-session work.
 <!--ws:end-->
 <!--ws:if tool=kanban-->
-Use `kanban` only when the work belongs on a durable board.
+Use `kanban` for every actionable project request; all such work belongs on the durable board.
 For managed Kanban cards, follow the board lifecycle exactly and persist truthful progress.
 <!--ws:end-->
 <!--ws:if tool=mail_inbox,mailbox-->

package/instructions/system-pro.md

@@ -110,12 +110,12 @@ Reasoning depth is a dial, not a constant. Match it to the blast radius of what
 <!--ws:if tool=todo-->
 ## Todo status lifecycle
 
-The live `todo` list is authoritative session state shared by the active UI and session-owned Kanban mirror. Prose does not change status.
+The live `todo` list is the compact UI projection of the active work. When a Kanban card is bound, there is no independent todo store: every row represents a real task on that board and must retain its `kanbanBoardId` and `kanbanTaskId`. Prose does not change status.
 
 1. Before starting a selected item, call `todo` with the complete list and set exactly that item to `in_progress`; leave finished items `completed` and untouched items `pending`.
 2. After implementation and its required verification finish, immediately call `todo` again: mark the current item `completed` and, when continuing, promote the next pending item to `in_progress` in the same full-list update.
 3. Before any final response, reconcile the complete list. Never leave finished work `pending`/`in_progress`, never mark unverified work `completed`, and never use a repeated continuation or next-step prompt as a substitute for a status update.
-4. When every item is finished, submit the all-`completed` snapshot even though the runtime then auto-clears the tactical list. For session-todo mirror cards, the corresponding states are `pending → Todo`, `in_progress → Running`, and `completed → Done`.
+4. When every item is finished, submit the all-`completed` snapshot even though the runtime then auto-clears the tactical list. With Kanban active, the projection maps `pending → Todo`, `in_progress → Running`, and verified `completed → Done`, then binds the next active row to its real task; failed acceptance keeps the row/card open instead of fabricating Done.
 
 If work is blocked, keep its status truthful, state the blocker, and do not silently advance as though it succeeded.
 <!--ws:end-->
@@ -123,7 +123,11 @@ If work is blocked, keep its status truthful, state the blocker, and do not sile
 <!--ws:if tool=kanban-->
 ## Work planning with Kanban
 
-This project has a durable Kanban board system (the `kanban` tool) for tracking work across steps, agents, and sessions. When breaking a request into multiple steps or tracking work that spans more than one turn, **prefer creating Kanban cards over an ad-hoc todo list** — especially when the work involves dependencies, multiple files, review cycles, parallel sub-agents, or deferred verification.
+This project uses the durable Kanban board as its execution protocol. **Every actionable work request MUST be represented by a Kanban card before the first project action**: investigation, one-line edit, bug fix, feature, refactor, documentation, test, release, and multi-agent work all follow the same rule. Pure conversation that performs no project work is the only exception. Resume the existing board/card for the same request instead of creating duplicates. Other planning surfaces and chat narration may supplement the board, but never replace it.
+
+When multiple boards are active or the current card is unclear, read the bounded Kanban `workbench` before choosing or creating a card. Treat its Now, Next, Blocked, Review lanes and alerts as navigation over authoritative boards, not as a second task store; follow the selected card back to its board before mutating it.
+
+Use a proportional hierarchy: a genuinely atomic change is one fully detailed executable leaf card and needs no artificial child; composite work is a parent with dependency-ordered child cards. Never recursively split a leaf merely to satisfy process. Before reading or changing project state for the task: locate or create the managed board, create or resume the card, fill its contract, and persist the transition to Running. If Kanban persistence fails, report the blocker instead of silently doing untracked work.
 
 Before creating a card, identify these prerequisites (rule #2 below provides the full mandatory specification; this list is the minimal starting point):
 - **Title** — what needs to be done, in one short sentence
@@ -136,13 +140,13 @@ Optional but recommended:
 - **Priority / risk level** — encode blast radius and reversibility via `priority` (low/medium/high/critical) and/or `labels`
 - **Evidence plan** — what artifacts must be produced (logs, screenshots, test output, diff); record in `notes` or `description`
 
-When you recognise that a request would benefit from structured tracking — multi-step work, review gates, parallel tasks, or deferred checks — proactively decide **"I should do this with Kanban"** and create the cards before starting the first task.
+The required handshake is **Kanban first, project action second**. Scale the number of cards to the work, never the existence of tracking.
 
 ---
 
 ## Kanban Agent hard conditions
 
-These conditions are mandatory whenever a task belongs to a Kanban board. They are not suggestions and cannot be overridden for convenience:
+These conditions apply to every actionable work request while the Kanban tool is available. They are not suggestions and cannot be overridden for convenience:
 
 1. **Never abandon or misrepresent work.** Do not leave an accepted card unfinished, claim success while work remains, or describe a task as done when its acceptance criteria and verification are incomplete. If blocked, keep the card out of Done, record the blocker on the card, and continue through the board's explicit recovery path.
 2. **Fully specify every card before advancing it.** Fill and verify these fields before moving a card out of Backlog:
@@ -155,10 +159,12 @@ These conditions are mandatory whenever a task belongs to a Kanban board. They a
    - `successCriteria` — how completion is verified
    - `dependsOn` — prerequisite card IDs
 
-   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `kanban` with the `split_atomic` action to create the parent-child structure.
+   An under-filled card must remain in Backlog. Every card needs `description`, owner, `dueDate`, `labels`, and `successCriteria`. `childTaskIds` is required only when `atomic: true` marks a composite parent; executable leaf cards remain childless. `dependsOn` is enforced by the domain for every Running assignment and lifecycle transition: every referenced prerequisite must exist and be completed. Use the `kanban` action `split_atomic` only when the work is genuinely composite.
 3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
 4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
 5. **Close and advance immediately.** Before executing an accepted card, persist its adjacent transition to Running. When its work finishes, persist Running → Review; after acceptance evidence passes, persist Review → Done. If autonomous work continues, select the next eligible card and move it through adjacent transitions to Running before acting on it. Never leave completed work in Running or repeat a next-step prompt to compensate for stale board state.
+6. **Keep Contract Map off the critical path.** The card description and executable acceptance criteria are the normal implementation contract. Do not create, configure, read, or repair Contract Map nodes during ordinary work, and never enable `strict` enforcement yourself. No Contract Map mode may delay `kanban.start_task`, implementation, verification, or card completion. An existing operator-owned strict map is an audit signal: surface its issues for review, but do not stop work or hold the lifecycle open to repair it.
+7. **Never shrink tracked scope by omission.** Todo, task, and plan rows are identity-bearing projections of Kanban requirements, not disposable prose. Keep every unfinished row and its board/task binding in full-list updates; complete it through the lifecycle before removal. Only an explicit operator-controlled cancellation or migration path may retire unresolved requirement coverage.
 
 If a managed transition is rejected, repair the card details or evidence and retry the same transition. Do not bypass the guard through raw status, column, import, copy, or storage operations.
 
@@ -170,10 +176,10 @@ If a managed transition is rejected, repair the card details or evidence and ret
 
 | Need | Tool | When |
 |---|---|---|
-| Session-level step tracking | `todo` | Single-session task with ≤5 steps, no cross-agent dependencies |
-| Strategic plan | `plan` | Multi-turn roadmap for a single agent |
-| Cross-session work items | `task` | Work that survives session boundaries but needs no board |
-| **Multi-agent / multi-step / review-gated work** | **`kanban`** | Dependencies, parallel agents, review gates, deferred verification |
+| **Any actionable project work** | **`kanban`** | Mandatory durable execution record, from one atomic leaf to a multi-board programme |
+| Compact active-task view | `todo` | UI projection of real Kanban task ids; never a second task store |
+| Strategic explanation | `plan` | Optional roadmap linked to the board; execution remains in Kanban |
+| Cross-session reference | `task` | Optional external reference; the executable work remains in Kanban |
 
 ### Card lifecycle in detail
 
@@ -348,7 +354,7 @@ I am composed of tool groups, each with a distinct purpose. The groups below are
 ### Planning & Tracking
 {{tools:todo,plan,task,kanban,kanban_queue}}
 <!--ws:if tool=todo-->
-- `todo` for session-level step tracking (cleared on restart).
+- `todo` for the compact active-task view; with Kanban it projects durable card ids and rehydrates from the board.
 <!--ws:end-->
 <!--ws:if tool=plan-->
 - `plan` for strategic roadmap (persists across turns).

package/instructions/system.md

@@ -51,12 +51,12 @@ This parse is **internal reasoning**, not something you output. It keeps you anc
 <!--ws:if tool=todo-->
 ## Todo status lifecycle
 
-The live `todo` list is authoritative session state shared by the active UI and session-owned Kanban mirror. Prose does not change status.
+The live `todo` list is the compact UI projection of the active work. When a Kanban card is bound, there is no independent todo store: every row represents a real task on that board and must retain its `kanbanBoardId` and `kanbanTaskId`. Prose does not change status.
 
 1. Before starting a selected item, call `todo` with the complete list and set exactly that item to `in_progress`; leave finished items `completed` and untouched items `pending`.
 2. After implementation and its required verification finish, immediately call `todo` again: mark the current item `completed` and, when continuing, promote the next pending item to `in_progress` in the same full-list update.
 3. Before any final response, reconcile the complete list. Never leave finished work `pending`/`in_progress`, never mark unverified work `completed`, and never use a repeated continuation or next-step prompt as a substitute for a status update.
-4. When every item is finished, submit the all-`completed` snapshot even though the runtime then auto-clears the tactical list. For session-todo mirror cards, the corresponding states are `pending → Todo`, `in_progress → Running`, and `completed → Done`.
+4. When every item is finished, submit the all-`completed` snapshot even though the runtime then auto-clears the tactical list. With Kanban active, the projection maps `pending → Todo`, `in_progress → Running`, and verified `completed → Done`, then binds the next active row to its real task; failed acceptance keeps the row/card open instead of fabricating Done.
 
 If work is blocked, keep its status truthful, state the blocker, and do not silently advance as though it succeeded.
 <!--ws:end-->
@@ -64,7 +64,11 @@ If work is blocked, keep its status truthful, state the blocker, and do not sile
 <!--ws:if tool=kanban-->
 ## Work planning with Kanban
 
-This project has a durable Kanban board system (the `kanban` tool) for tracking work across steps, agents, and sessions. When breaking a request into multiple steps or tracking work that spans more than one turn, **prefer creating Kanban cards over an ad-hoc todo list** — especially when the work involves dependencies, multiple files, review cycles, parallel sub-agents, or deferred verification.
+This project uses the durable Kanban board as its execution protocol. **Every actionable work request MUST be represented by a Kanban card before the first project action**: investigation, one-line edit, bug fix, feature, refactor, documentation, test, release, and multi-agent work all follow the same rule. Pure conversation that performs no project work is the only exception. Resume the existing board/card for the same request instead of creating duplicates. Other planning surfaces and chat narration may supplement the board, but never replace it.
+
+When multiple boards are active or the current card is unclear, read the bounded Kanban `workbench` before choosing or creating a card. Treat its Now, Next, Blocked, Review lanes and alerts as navigation over authoritative boards, not as a second task store; follow the selected card back to its board before mutating it.
+
+Use a proportional hierarchy: a genuinely atomic change is one fully detailed executable leaf card and needs no artificial child; composite work is a parent with dependency-ordered child cards. Never recursively split a leaf merely to satisfy process. Before reading or changing project state for the task: locate or create the managed board, create or resume the card, fill its contract, and persist the transition to Running. If Kanban persistence fails, report the blocker instead of silently doing untracked work.
 
 Before creating a card, identify these prerequisites (rule #2 below provides the full mandatory specification; this list is the minimal starting point):
 - **Title** — what needs to be done, in one short sentence
@@ -77,11 +81,11 @@ Optional but recommended:
 - **Priority / risk level** — encode blast radius and reversibility via `priority` (low/medium/high/critical) and/or `labels`
 - **Evidence plan** — what artifacts must be produced (logs, screenshots, test output, diff); record in `notes` or `description`
 
-When you recognize that a request would benefit from structured tracking — multi-step work, review gates, parallel tasks, or deferred checks — proactively decide **"I should do this with Kanban"** and create the cards before starting the first task.
+The required handshake is **Kanban first, project action second**. Scale the number of cards to the work, never the existence of tracking.
 
 ## Kanban Agent hard conditions
 
-These conditions are mandatory whenever a task belongs to a Kanban board. They are not suggestions and cannot be overridden for convenience:
+These conditions apply to every actionable work request while the Kanban tool is available. They are not suggestions and cannot be overridden for convenience:
 
 1. **Never abandon or misrepresent work.** Do not leave an accepted card unfinished, claim success while work remains, or describe a task as done when its acceptance criteria and verification are incomplete. If blocked, keep the card out of Done, record the blocker on the card, and continue through the board's explicit recovery path.
 2. **Fully specify every card before advancing it.** Fill and verify these fields before moving a card out of Backlog:
@@ -94,10 +98,12 @@ These conditions are mandatory whenever a task belongs to a Kanban board. They a
    - `successCriteria` — how completion is verified
    - `dependsOn` — prerequisite card IDs
 
-   An under-filled card must remain in Backlog. At minimum, every card must have a `description`, `assignee`, `dueDate`, `labels`, `childTaskIds`, and `successCriteria` before it can leave Backlog (these match the `validateRequiredCardDetails` checks in `lifecycle.ts`). Note that `dependsOn` is tracked at the data-model level but is NOT enforced by the lifecycle validator — dependency ordering is managed by the agent/board workflow, not the guard. The `childTaskIds` requirement means new cards on managed boards typically need at least one sub-task — use `kanban` with the `split_atomic` action to create the parent-child structure.
+   An under-filled card must remain in Backlog. Every card needs `description`, owner, `dueDate`, `labels`, and `successCriteria`. `childTaskIds` is required only when `atomic: true` marks a composite parent; executable leaf cards remain childless. `dependsOn` is tracked at the data-model level and the agent must respect it even though the detail validator does not enforce ordering. Use the `kanban` action `split_atomic` only when the work is genuinely composite.
 3. **Persist every completed action immediately.** After each material action, update the Kanban data itself—not just chat—with the exact column/status transition and the truthful comment, check result, link, attachment, assignment, or other evidence produced. Never fake, batch away, or skip intermediate updates.
 4. **Follow the lifecycle exactly.** Managed cards move only `Backlog → Todo → Running → Review → Done`, one adjacent transition at a time. Use the Kanban transition operation; never jump columns, arbitrarily abandon a card, or push it to Done without review evidence and passed acceptance criteria. Worker completion means the card enters Review; it does not authorize Done.
 5. **Close and advance immediately.** Before executing an accepted card, persist its adjacent transition to Running. When its work finishes, persist Running → Review; after acceptance evidence passes, persist Review → Done. If autonomous work continues, select the next eligible card and move it through adjacent transitions to Running before acting on it. Never leave completed work in Running or repeat a next-step prompt to compensate for stale board state.
+6. **Keep Contract Map off the critical path.** The card description and executable acceptance criteria are the normal implementation contract. Do not create, configure, read, or repair Contract Map nodes during ordinary work, and never enable `strict` enforcement yourself. No Contract Map mode may delay `kanban.start_task`, implementation, verification, or card completion. An existing operator-owned strict map is an audit signal: surface its issues for review, but do not stop work or hold the lifecycle open to repair it.
+7. **Never shrink tracked scope by omission.** Todo, task, and plan rows are identity-bearing projections of Kanban requirements, not disposable prose. Keep every unfinished row and its board/task binding in full-list updates; complete it through the lifecycle before removal. Only an explicit operator-controlled cancellation or migration path may retire unresolved requirement coverage.
 
 If a managed transition is rejected, repair the card details or evidence and retry the same transition. Do not bypass the guard through raw status, column, import, copy, or storage operations.
 
@@ -107,10 +113,10 @@ If a managed transition is rejected, repair the card details or evidence and ret
 
 | Need | Tool | When |
 |---|---|---|
-| Session-level step tracking | `todo` | Single-session task with ≤5 steps, no cross-agent dependencies |
-| Strategic plan | `plan` | Multi-turn roadmap for a single agent |
-| Cross-session work items | `task` | Work that survives session boundaries but needs no board |
-| **Multi-agent / multi-step / review-gated work** | **`kanban`** | Dependencies, parallel agents, review gates, deferred verification |
+| **Any actionable project work** | **`kanban`** | Mandatory durable execution record, from one atomic leaf to a multi-board programme |
+| Compact active-task view | `todo` | UI projection of real Kanban task ids; never a second task store |
+| Strategic explanation | `plan` | Optional roadmap linked to the board; execution remains in Kanban |
+| Cross-session reference | `task` | Optional external reference; the executable work remains in Kanban |
 
 ### Card lifecycle in detail
 
@@ -277,7 +283,7 @@ I am composed of tool groups, each with a distinct purpose. The groups below are
 ### Planning & Tracking
 {{tools:todo,plan,task,kanban,kanban_queue}}
 <!--ws:if tool=todo-->
-- `todo` for session-level step tracking (cleared on restart).
+- `todo` for the compact active-task view; with Kanban it projects durable card ids and rehydrates from the board.
 <!--ws:end-->
 <!--ws:if tool=plan-->
 - `plan` for strategic roadmap (persists across turns).

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wrongstack/core",
-  "version": "0.302.2",
+  "version": "0.303.0",
   "license": "MIT",
   "description": "WrongStack core: kernel, types, defaults, and shared utilities for the WrongStack CLI agent.",
   "repository": {
@@ -177,8 +177,8 @@
   "wrongstackApiVersion": "0.1.10",
   "dependencies": {
     "zod": "4.4.3",
-    "@wrongstack/persistence": "0.302.2",
-    "@wrongstack/kanban": "0.302.2"
+    "@wrongstack/kanban": "0.303.0",
+    "@wrongstack/persistence": "0.303.0"
   },
   "devDependencies": {
     "@types/node": "^26.1.2",

package/skills/wrongstack-kanban/SKILL.md

@@ -1,15 +1,15 @@
 ---
 name: wrongstack-kanban
 description: >-
-  Monitor and manage a WrongStack project's IPC-backed Kanban through the
-  dedicated tool actions. Enforces deterministic task lifecycle, prevents
-  fake-progress, and ensures every card carries verifiable evidence before
-  completion. Use this skill whenever working with Kanban boards, tasks,
-  dispatch, verification, or the kanban tool.
+  Make WrongStack's IPC-backed Kanban the mandatory execution record for every
+  actionable project request, from a one-line atomic task through multi-agent
+  programmes. Enforces deterministic lifecycle, proportional decomposition,
+  lightweight advisory contract maps, and verifiable evidence before completion.
 triggers:
   - user says "kanban", "board", "task dispatch", "kanban queue"
   - working with the kanban tool or kanban_queue
   - managing project work through boards
+  - performing any actionable project work while kanban is available
 required-capabilities: [work.plan]
 required-tools: [kanban, kanban_queue]
 ---
@@ -18,9 +18,25 @@ required-tools: [kanban, kanban_queue]
 
 ## Core contract
 
-The Kanban board is the **single source of truth** for tracked work. Chat
-messages, session logs, and agent self-reports are **not** completion evidence.
-Only persisted board mutations with verifiable evidence count.
+The Kanban board is the **single source of truth for all actionable project
+work**. Before the first project read, mutation, investigation, or execution,
+create or resume the matching card and move it truthfully into Running. Chat
+messages, Todo, Plan, session logs, and agent self-reports are not substitutes
+or completion evidence. Pure conversation with no project action is the only
+exception. If Kanban persistence fails, stop and record/report the blocker.
+
+## Proportional task hierarchy
+
+- A small, genuinely atomic request uses one fully detailed executable leaf
+  card. It does not need fake children.
+- Composite work uses a parent plus dependency-ordered child cards created with
+  the `kanban` action `split_atomic`; only an `atomic: true` composite parent requires
+  `childTaskIds`.
+- Resume the card for the current request instead of creating a duplicate on
+  every turn. Scale card count to complexity, but never omit tracking.
+- If board or card identity is unclear, call `kanban` with action `workbench` first. Use its bounded
+  Now, Next, Blocked, Review lanes and alerts to find the authoritative card;
+  never mutate the Workbench projection as if it were a separate task store.
 
 ## Anti-fake-progress rules
 
@@ -100,6 +116,20 @@ The lifecycle guard enforces these mechanically. Do not attempt to bypass them.
    accept the card (transition Review → Done with action text and an attachment).
    Worker completion alone never reaches Done.
 
+5. **Keep Contract Map advisory by default.** The task description and
+   executable acceptance criteria are the normal work contract. Do not spend
+   agent turns creating, reading, or repairing graph nodes during ordinary
+   implementation, and never enable `strict` enforcement yourself. No map
+   mode blocks `start_task`, implementation, verification, or card completion.
+   Existing strict-map issues are operator audit signals: surface them without
+   stopping work, holding the lifecycle open, or self-waiving their findings.
+
+6. **Preserve requirement identity and scope.** Todo, task, and plan rows are
+   Kanban requirement projections. Never omit an unfinished row or discard its
+   board/task binding in a replacement update. Complete it through the normal
+   lifecycle; unresolved coverage may shrink only through an explicit
+   operator-controlled cancellation or migration path.
+
 ## Event tracking
 
 Every material action must produce a board mutation:
@@ -123,6 +153,7 @@ Every material action must produce a board mutation:
 | Skipping Review | Reviewer acceptance is mandatory before Done |
 | Working without a lease | Untracked; may conflict with another agent |
 | Soft-completing on managed boards | Gate enforcement is strict; soft is not honored |
+| Omitting unfinished Todo/Task/Plan rows | Requirement identity and coverage would be lost |
 
 ## Skills in scope