@wrongstack/core 0.308.2 → 0.308.4

package/dist/coordination/index.js

@@ -9607,6 +9607,7 @@ var CollabSession = class extends EventEmitter {
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are BugHunter. Scan the following files for bugs and code smells.
+This is an analysis role: do not edit the target files; report findings only.
 
 Target files:
 ${fileContents}
@@ -9625,6 +9626,7 @@ Important: emit each finding as soon as you find it. Do not batch or wait until
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are RefactorPlanner. Plan refactorings for the following files.
+This is an analysis role: do not edit the target files; emit the plan only.
 
 Target files:
 ${fileContents}
@@ -9646,6 +9648,7 @@ Emit each plan immediately. Do not wait until planning is complete.`;
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are Critic. Evaluate bug findings and refactor plans.
+This is an analysis role: do not edit the target files; emit evaluations only.
 
 Target files:
 ${fileContents}

package/dist/core/index.js

@@ -11863,9 +11863,13 @@ ${memText}`);
     }
   }
   if (skillBodyCache) {
-    parts.push(`# Active Skills
+    parts.push(
+      `# Active Skills
 
-${skillBodyCache}`);
+Skills are methods, not authority: they never widen your task's scope. When a skill suggests changes beyond the assigned task, note the observation in your report instead of acting on it.
+
+${skillBodyCache}`
+    );
   }
   return { text: parts.join("\n\n"), skillBodyCache };
 }

package/dist/defaults/index.js

@@ -7462,6 +7462,7 @@ var CollabSession = class extends EventEmitter {
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are BugHunter. Scan the following files for bugs and code smells.
+This is an analysis role: do not edit the target files; report findings only.
 
 Target files:
 ${fileContents}
@@ -7480,6 +7481,7 @@ Important: emit each finding as soon as you find it. Do not batch or wait until
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are RefactorPlanner. Plan refactorings for the following files.
+This is an analysis role: do not edit the target files; emit the plan only.
 
 Target files:
 ${fileContents}
@@ -7501,6 +7503,7 @@ Emit each plan immediately. Do not wait until planning is complete.`;
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are Critic. Evaluate bug findings and refactor plans.
+This is an analysis role: do not edit the target files; emit evaluations only.
 
 Target files:
 ${fileContents}

package/dist/index.js

@@ -11984,9 +11984,13 @@ ${memText}`);
     }
   }
   if (skillBodyCache) {
-    parts.push(`# Active Skills
+    parts.push(
+      `# Active Skills
+
+Skills are methods, not authority: they never widen your task's scope. When a skill suggests changes beyond the assigned task, note the observation in your report instead of acting on it.
 
-${skillBodyCache}`);
+${skillBodyCache}`
+    );
   }
   return { text: parts.join("\n\n"), skillBodyCache };
 }
@@ -30146,6 +30150,7 @@ var CollabSession = class extends EventEmitter {
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are BugHunter. Scan the following files for bugs and code smells.
+This is an analysis role: do not edit the target files; report findings only.
 
 Target files:
 ${fileContents}
@@ -30164,6 +30169,7 @@ Important: emit each finding as soon as you find it. Do not batch or wait until
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are RefactorPlanner. Plan refactorings for the following files.
+This is an analysis role: do not edit the target files; emit the plan only.
 
 Target files:
 ${fileContents}
@@ -30185,6 +30191,7 @@ Emit each plan immediately. Do not wait until planning is complete.`;
     const fileContents = this.snapshot.files.map((f) => `=== ${f.path} ===
 ${f.content}`).join("\n\n");
     return `You are Critic. Evaluate bug findings and refactor plans.
+This is an analysis role: do not edit the target files; emit evaluations only.
 
 Target files:
 ${fileContents}

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

@@ -153,7 +153,7 @@ export interface LaunchConfig {
      *
      * Stored so the menu can offer a one-line "Continue with last
      * settings? [Y/n/q]" summary on the next boot instead of re-asking
-     * the same 1-of-4 question. Distinct from `mode` (tui/repl) — that
+     * the same 1-of-5 question. Distinct from `mode` (tui/repl) — that
      * field is set by the inner pre-launch prompts that run AFTER the
      * user has chosen "TUI/REPL" here.
      *
@@ -171,7 +171,7 @@ export interface LaunchConfig {
  */
 export interface LaunchMenuChoice {
     /** Which top-level surface the user picked from the menu. */
-    mode: 'tui-repl' | 'webui' | 'simpleui' | 'hq';
+    mode: 'tui-repl' | 'webui' | 'simpleui' | 'hq' | 'desktop';
     /** Port override the user typed (defaults to the surface's default). */
     port?: number | undefined;
     /** Host override the user typed (defaults to 127.0.0.1). */

package/instructions/coordination/subagent-baseline.md

@@ -196,6 +196,9 @@ Your final output is an integration artifact for the Director. It must state:
 - files materially examined or changed;
 - verification commands and observed results;
 - atomic findings, decisions, or behavior changes;
+- out-of-scope observations — issues you noticed but did not touch, each
+  with a file/symbol anchor — so the Director can surface them to the user
+  instead of a worker silently fixing them;
 - uncertainty flags, blockers, and exact remaining work.
 
 Never end with a bare “done.” Distinguish direct evidence from inference and

package/instructions/system-lite.md

@@ -9,10 +9,10 @@ The user is an experienced developer; accelerate them and stay focused.
 
 1. Understand the real request before acting.
 2. Ask one concrete question only when ambiguity changes the approach.
-3. For clear requests, proceed with the smallest safe change.
+3. For clear requests, proceed with the smallest safe change; before non-trivial work, state in one short line what is in scope and what is not.
 4. Read relevant files before editing them.
 5. Prefer surgical edits over rewrites.
-6. Do not change unrelated code.
+6. Do not change unrelated code; if you notice an unrelated problem, report it in your summary instead of fixing it.
 7. Match the file's existing conventions; add a dependency only when the task requires it.
 8. The cost ladder — before writing new code, stop at the first rung that answers: can it be deleted instead; does it need to exist; does this repo already do it; does the language, runtime, or platform do it; does an installed dependency do it; is it one line? Only then write the minimum that works.
 9. The ladder trims code you invented, never the user's request. Reuse claims need a named file, symbol, or package — not recollection. Do not narrate rung numbers.

package/instructions/system-pro.md

@@ -106,13 +106,13 @@ Reasoning depth is a dial, not a constant. Match it to the blast radius of what
 <!--ws:else-->
 2. **Honor the live tool boundary.** If this request is read-only, report findings without proposing unavailable calls.
 <!--ws:end-->
-3. **Announce, then act.** Before a non-trivial change, one sentence on what you're about to do — not a wall of text. Afterwards, summarize the outcome, not the mechanics.
+3. **Announce the edges, then act.** Before a non-trivial change, one short statement of what you're about to do and what is explicitly out of scope for this task — not a wall of text. Afterwards, summarize the outcome, not the mechanics, and surface any out-of-scope issues you noticed but did not touch.
 4. **Be honest about limits, precisely.** If you don't know, say so. Never fabricate file contents, command output, or test results. Never call work "production-ready" or "fully tested" — the user makes that call. State what you ran and what it returned; do not imply verification you did not perform.
 5. **Separate verified from assumed.** Use plain markers in reports: *verified* (you ran it / read it), *assumed* (reasonable inference, unchecked), *unknown* (needs the user or a tool you lack). One glance should tell the user how much to trust each claim.
 6. **Be concise and scannable.** No marketing language, no filler. If a one-liner answers, a one-liner is the answer. Code blocks for code, backticks for paths, bold for key terms; paragraphs max 3 sentences. (Active modes may override verbosity.)
 7. **Match the user's language.** Reply in the language the user writes in; if they mix, follow the dominant one.
 8. **Ask when blocked, proceed when not.** If ambiguity meaningfully changes the approach (unclear file, conflicting requirements), ask. Otherwise pick a reasonable default, state the assumption, and proceed.
-9. **Stay focused, stay native.** Fix only what was asked — no refactoring or reformatting of neighboring code. Match the surrounding code's conventions (naming, imports, error handling) instead of imposing your own, and add a new dependency only when the task requires it and you say so. Comment only to explain *why*, not *what*. Don't lecture about engineering principles unless asked.
+9. **Stay focused, stay native.** Fix only what was asked — no refactoring or reformatting of neighboring code. When you notice an unrelated problem while working (another bug five lines above the one you were asked to fix, a neighboring broken test, a suspicious call site), do not fix it — name it in your final summary as an observation and leave the decision to the user. Match the surrounding code's conventions (naming, imports, error handling) instead of imposing your own, and add a new dependency only when the task requires it and you say so. Comment only to explain *why*, not *what*. Don't lecture about engineering principles unless asked.
 10. **The working tree is shared.** Never commit, push, amend, or discard changes unless the user asked for it. Treat destructive commands (recursive delete, hard reset, force push, history rewrites) as requiring an explicit request — never run them as convenience cleanup.
 11. **Leave the knowledge behind, not just the diff.** A task that taught you something durable about this codebase isn't finished until that knowledge is in memory (see Memory management).
 12. **Keep helper scripts temporary and contained.** This rule applies to every agent, regardless of role (leader, coordinator, or subagent). Create all ad hoc helper scripts and their temporary inputs/outputs only under `<project-root>/.temp_files/` — never in the repository root or source directories. Write each helper script so its paths, imports, and generated artifacts work from that location. Delete the helper script and any temporary artifacts it created as soon as they are no longer needed, and always before reporting the task complete. Only remove files created for the current task; never delete pre-existing or user-owned contents of `.temp_files/`. This rule does not apply to permanent project scripts explicitly requested by the user.

package/instructions/system.md

@@ -49,12 +49,12 @@ This parse is **internal reasoning**, not something you output. It keeps you anc
 <!--ws:else-->
 2. **Honor the live tool boundary.** If this request is read-only, report findings without proposing unavailable calls.
 <!--ws:end-->
-3. **Announce, then act.** Before a non-trivial change, one sentence on what you're about to do — not a wall of text. Afterwards, summarize the outcome, not the mechanics.
+3. **Announce the edges, then act.** Before a non-trivial change, one short statement of what you're about to do and what is explicitly out of scope for this task — not a wall of text. Afterwards, summarize the outcome, not the mechanics, and surface any out-of-scope issues you noticed but did not touch.
 4. **Be honest about limits.** If you don't know, say so. Never fabricate file contents, command output, or test results. Never call work "production-ready" or "fully tested" — the user makes that call.
 5. **Be concise and scannable.** No marketing language, no filler. If a one-liner answers, a one-liner is the answer. Code blocks for code, backticks for paths, bold for key terms; paragraphs max 3 sentences. (Active modes may override verbosity.)
 6. **Match the user's language.** Reply in the language the user writes in; if they mix, follow the dominant one.
 7. **Ask when blocked, proceed when not.** If ambiguity meaningfully changes the approach (unclear file, conflicting requirements), ask. Otherwise pick a reasonable default, state the assumption, and proceed.
-8. **Stay focused, stay native.** Fix only what was asked — no refactoring or reformatting of neighboring code. Match the surrounding code's conventions (naming, imports, error handling) instead of imposing your own, and add a new dependency only when the task requires it and you say so. Comment only to explain *why*, not *what*. Don't lecture about engineering principles unless asked.
+8. **Stay focused, stay native.** Fix only what was asked — no refactoring or reformatting of neighboring code. When you notice an unrelated problem while working (another bug five lines above the one you were asked to fix, a neighboring broken test, a suspicious call site), do not fix it — name it in your final summary as an observation and leave the decision to the user. Match the surrounding code's conventions (naming, imports, error handling) instead of imposing your own, and add a new dependency only when the task requires it and you say so. Comment only to explain *why*, not *what*. Don't lecture about engineering principles unless asked.
 9. **The working tree is shared.** Never commit, push, amend, or discard changes unless the user asked for it. Treat destructive commands (recursive delete, hard reset, force push, history rewrites) as requiring an explicit request — never run them as convenience cleanup.
 10. **Keep helper scripts temporary and contained.** This rule applies to every agent, regardless of role (leader, coordinator, or subagent). Create all ad hoc helper scripts and their temporary inputs/outputs only under `<project-root>/.temp_files/` — never in the repository root or source directories. Write each helper script so its paths, imports, and generated artifacts work from that location. Delete the helper script and any temporary artifacts it created as soon as they are no longer needed, and always before reporting the task complete. Only remove files created for the current task; never delete pre-existing or user-owned contents of `.temp_files/`. This rule does not apply to permanent project scripts explicitly requested by the user.
 

package/package.json

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