@wrongstack/core 0.264.0 → 0.265.1

package/dist/{wstack-paths-CJjEwPXn.d.ts → wstack-paths-hOpNLmvf.d.ts}

@@ -81,6 +81,8 @@ interface WstackPaths {
     projectAutophase: string;
     /** ~/.wrongstack/sync.json — CloudSync configuration */
     syncConfig: string;
+    /** Function to get the status.json path for a project given its hash. */
+    projectStatus: (projectHash: string) => string;
 }
 declare function projectHash(absRoot: string): string;
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wrongstack/core",
-  "version": "0.264.0",
+  "version": "0.265.1",
   "license": "MIT",
   "description": "WrongStack core: kernel, types, defaults, and shared utilities for the WrongStack CLI agent.",
   "repository": {

package/skills/api-design/SKILL.md

@@ -74,7 +74,7 @@ Response.json({ error: '...' }, { status: 200 }); // lies about outcome
 
 ```
 POST /sessions
-Body: { "provider": "anthropic", "model": "claude-3-5-sonnet" }
+Body: { "provider": "anthropic", "model": "<model-id>" }
 201: { "id": "sess_abc", "provider": "anthropic", ... }
 400: { "error": { "code": "VALIDATION_ERROR", "message": "model is required" } }
 ```

package/skills/audit-log/SKILL.md

@@ -20,7 +20,7 @@ Parses WrongStack session JSONL files to extract tool usage patterns, error dist
 1. Always parse from the source JSONL — never summarize what you didn't read.
 2. Analyze one session at a time, or aggregate with clear labeling per session.
 3. Cite specific data in reports: iteration numbers, tool names, error messages.
-4. Flag repeated failures (same tool,5+ times) as a real issue, not noise.
+4. Flag repeated failures (same tool, 5+ times) as a real issue, not noise.
 5. Report cost trends in context of iteration count — a spike means context growth.
 
 ## Patterns
@@ -77,7 +77,7 @@ const errorsByType = events
 - **Tool entropy**: too many different tools in one iteration = unfocused task
 
 ### Error patterns
-- **Same error repeating**: `ToolExecutionError`47x across iterations = systemic issue
+- **Same error repeating**: `ToolExecutionError` 47x across iterations = systemic issue
 - **Error clustering**: all errors in `bash` tool = command timeout pattern
 - **Error rate by type**: which error type is most common?
 - **Error distribution**: are errors clustered in specific packages or tools?
@@ -85,7 +85,7 @@ const errorsByType = events
 ### Cost patterns
 - **Token growth**: tokens/iteration trending up = context bloat
 - **Provider cost**: which model is most expensive per call?
-- **Cost spikes**: sudden3x increase = large file reads or excessive tool calls
+- **Cost spikes**: sudden 3x increase = large file reads or excessive tool calls
 - **Iteration cost variance**: avg $0.04/iter → $0.11/iter = context growing
 
 ### Context management
@@ -154,10 +154,10 @@ When reading a session file:
 - Iteration 11-20: avg $0.11/iteration (context growth)
 
 <next_steps>
-1. Investigate bash failures — command timeout pattern in iterations 14-20
-2. Review tool call count in iteration 14 — 50+ tool calls suggests loop
-3. Run `pnpm test` to verify fixes for identified issues
+1. Run the session tests and the type checker
 </next_steps>
+
+Investigate iterations 14–20 in the session log for the bash command timeout pattern. Review iteration 14's tool call count for loop behavior.
 ```
 
 ## Anti-patterns

package/skills/bug-hunter/SKILL.md

@@ -17,7 +17,7 @@ Grep/read across target files to surface bugs, anti-patterns, and quality issues
 
 ## Rules
 
-1. Always include `file:line` in every finding — no line reference = can't be fixed.
+1. Always include a `file:line` you have actually read — verify the line exists; never invent, guess, or extrapolate a reference. No line reference = can't be fixed.
 2. Never scan `node_modules` — waste of time, false positives.
 3. Don't report style issues as bugs — those are lint findings.
 4. If >30% of findings are noise, note the false positive rate in the report.
@@ -127,10 +127,10 @@ const data: any = response.json();
 Total: 16 findings in 12 files
 
 <next_steps>
-1. [SHELL-INJ] `tools/shell.ts:42` — replace exec() with execFile()
-2. [SECRET] `lib/config.ts:8` — move API key to environment variable
-3. [MEMORY] `tools/pool.ts:89` — add cleanup in component unmount
-4. [TYPE] `core/agent.ts:103` — replace `as any` with proper type
+1. Fix the shell injection in tools/shell.ts:42
+2. Fix the hardcoded API key in lib/config.ts:8
+3. Fix the memory leak in tools/pool.ts:89
+4. Fix the unsafe any cast in core/agent.ts:103
 </next_steps>
 ```
 

package/skills/chimera/SKILL.md

@@ -22,7 +22,7 @@ issues the session agent may have missed.
 
 1. **Only review changed files.** The list of files is provided to you — do not
    expand scope.
-2. **Read before judging.** Always read the file before flagging an issue.
+2. **Read before judging.** Read the file and confirm the exact line before flagging — never cite a `file:line` you haven't read.
 3. **Be surgical.** Flag real bugs, not style preferences. If it compiles and
    the logic is sound, it's fine.
 4. **No re-litigation.** Do not re-raise issues already discussed in the session
@@ -57,9 +57,9 @@ Write your report as a single message appended to the chat. Use this structure:
 - Clean files: N
 
 <next_steps>
-1. [CRITICAL] `path/file.ts:42` — add null guard for `user`
-2. [HIGH] `path/config.ts:8` — move API key to environment variable
-3. [MEDIUM] `path/helper.ts:15` — replace `as any` with `as unknown as T`
+1. Fix null deref in path/file.ts:42
+2. Fix plaintext API key in path/config.ts:8
+3. Fix unsafe any cast in path/helper.ts:15
 </next_steps>
 ```
 

package/skills/docker-deploy/SKILL.md

@@ -119,7 +119,7 @@ WRONGSTACK_SESSION_ROOT=/app/sessions
 
 # Optional
 WRONGSTACK_PROVIDER=anthropic
-WRONGSTACK_MODEL=claude-3-5-sonnet-20241022
+WRONGSTACK_MODEL=<model-id>
 WRONGSTACK_API_KEY=${ANTHROPIC_API_KEY}  # from secrets manager
 ```
 

package/skills/git-flow/SKILL.md

@@ -146,10 +146,10 @@ git rebase main && git merge --ff-only feature
 3. Open PR with description linking to issue
 
 <next_steps>
-1. `git checkout -b fix/session-leak` from `main`
-2. Commit with: `fix: correct race condition in token refresh`
-3. Open PR with description linking to issue #123
+1. Create a branch fix/session-leak, commit the token refresh fix, and push it
 </next_steps>
+
+Open a PR at GitHub linking to issue #123 with the commit message describing the fix.
 ```
 
 ## Skills in scope

package/skills/multi-agent/SKILL.md

@@ -127,9 +127,9 @@ When a leader synthesizes results from subagents:
 [Deduplicated and prioritized action items]
 
 <next_steps>
-1. [Priority] Action item 1 — file:line reference
-2. [Priority] Action item 2 — file:line reference
-3. [Priority] Action item 3 — file:line reference
+1. Fix critical issue in <file:line>
+2. Fix high-priority issue in <file:line>
+3. Fix remaining issue in <file:line>
 </next_steps>
 ```
 

package/skills/node-modern/SKILL.md

@@ -113,6 +113,7 @@ setTimeout(handler, 1000, { signal: userSignal });
 ```ts
 // ✅ Atomic write pattern
 import { rename, writeFile } from 'node:fs/promises';
+import { randomBytes } from 'node:crypto';
 const tmp = `${target}.${randomBytes(4).toString('hex')}.tmp`;
 await writeFile(tmp, data);
 await rename(tmp, target);

package/skills/observability/SKILL.md

@@ -53,7 +53,7 @@ console.log(JSON.stringify({
 }));
 
 // ✅ Trace span around a tool call
-import { trace } from 'node:opentelemetry/api';
+import { trace, SpanStatusCode } from '@opentelemetry/api';
 const span = trace.getTracer('wrongstack').startSpan('bash');
 try {
   const result = await bash(cmd);
@@ -90,7 +90,7 @@ console.log(JSON.stringify({ event: 'tool_executed' })); // no correlation
 |-------|-------------|---------|
 | `DEBUG` | Dev-only detail | "entering parseArgs with 3 args" |
 | `INFO` | Normal flow | "tool executed", "session started" |
-| `WARN` | Recoverable issue | "retry attempt2/3", "cache miss" |
+| `WARN` | Recoverable issue | "retry attempt 2/3", "cache miss" |
 | `ERROR` | Needs attention | "tool timeout", "auth failure" |
 
 ## Structured log schema

package/skills/output-standards/SKILL.md

@@ -15,26 +15,25 @@ extract structured data from agent responses.
 
 ## Rules
 
-1. **Only the leader agent's final message MUST include `<next_steps>` tag** — subagents report findings only. If nothing is pending, write "No pending actions."
-2. **Tags must be properly closed** — `<next_steps>...</next_steps>` with exact tag names.
-3. **No markdown inside tags** — plain text only, one action per line.
-4. **Use imperative mood** — "Fix X", "Run Y", not "Fixed X" or "Running Y".
-5. **Be specific** — mention file paths, tool names, or exact commands.
-6. **Keep concise** — max 5 items unless the task genuinely requires more.
-7. **Items must be concrete actionable commands** — something another agent or the user can immediately execute. Never write declarations of intent ("we should fix X", "consider refactoring Y") or manual execution suggestions ("manually review file Z", "check if X is correct").
+1. **Only the leader agent's final message SHOULD include `<next_steps>`** — subagents report findings only. If nothing is pending, omit the tag and say "No pending actions."
+2. **`<next_steps>` is for prompt options only** — every item must be something the user can type into the prompt and submit. If a step is a human-only action (e.g., "open DevTools", "check the browser console"), put it outside the tag as informational text instead.
+3. **Tags must be properly closed** — `<next_steps>...</next_steps>` with exact tag names.
+4. **No markdown inside tags** — plain text only, one item per line.
+5. **Items are prompt inputs** — not imperative instructions. Write what the user would type, not what they should do.
+6. **Items marked `auto="true"` must include input content** — the user can copy and submit it directly.
+7. **Keep concise** — max 5 items unless the task genuinely requires more.
 
 ## Output Format
 
-Every agent's final message MUST end with this structure:
-
 ```
 [... task results ...]
 
 <next_steps>
-1. First actionable next step — imperative, specific
-2. Second actionable next step
-3. Third actionable next step (if needed)
+1. Prompt option the user can enter — phrased as what to type, not what to do
+2. Another prompt option
 </next_steps>
+
+Informational text for human-only actions (outside the tag, no tag wrapper).
 ```
 
 ### Format Requirements
@@ -44,29 +43,31 @@ Every agent's final message MUST end with this structure:
 | Opening tag | `<next_steps>` on its own line | `<next_steps>` |
 | Numbered items | `1. ` prefix, one per line | `1. Fix auth bug in core/session.ts` |
 | Closing tag | `</next_steps>` on its own line | `</next_steps>` |
-| Blank line before | Optional but recommended | Improves readability |
-| Blank line after | Not required | — |
+| `auto="true"` items | Include the full input content | `1. fix in core/auth.ts:42 auto="true"` |
 
 ### ✅ Correct Examples
 
 ```
-Task completed successfully.
+Bug Hunt complete. Found 3 critical issues.
 
 <next_steps>
-1. Fix shell injection in packages/cli/src/slash-commands/dev.ts:15
-2. Replace Math.random() with randomUUID() in 4 files
-3. Run pnpm run typecheck to verify fixes
+1. Fix the shell injection in packages/cli/src/slash-commands/dev.ts:15
+2. Replace Math.random() with randomUUID() in the affected files
+3. Run the type checker
 </next_steps>
+
+Open browser DevTools → Network tab to verify the WebSocket
+connection is established before testing.
 ```
 
 ```
-Analysis finished. Found 3 critical issues.
+Audit complete. Found bash command timeout pattern in iterations 14–20.
 
 <next_steps>
-1. [CRITICAL] packages/cli/src/slash-commands/dev.ts:15 — exec() → execFile()
-2. [HIGH] packages/core/src/session-registry.ts:145 — remove ! assertion
-3. [HIGH] packages/core/src/session-registry.ts:169 — remove ! assertion
+1. Run the session tests and the type checker
 </next_steps>
+
+Review iterations 14–20 in the session log to characterize the loop.
 ```
 
 ### ❌ Incorrect Examples
@@ -102,15 +103,35 @@ Next steps:
 # ❌ Missing opening/closing tags
 ```
 
+```
+<next_steps>
+1. Open the browser console and check for errors  # ❌ Human-only action, not a prompt
+</next_steps>
+```
+
+## `auto="true"` Format
+
+Items that should be auto-submitted (the user can copy-paste and send) use `auto="true"`:
+
+```
+<next_steps>
+1. Run the type checker auto="true"
+2. Fix the shell injection in packages/cli/src/slash-commands/dev.ts:15
+</next_steps>
+```
+
+The text before `auto="true"` is the exact prompt the user would type. Items without `auto="true"` are suggestions the user can select manually.
+
 ## Subagent Requirements
 
 When a **leader agent** synthesizes output from **subagents**, the leader MUST:
 
 1. Collect findings from subagents (they return results, not `<next_steps>`)
-2. Based on findings, produce a unified `<next_steps>` section
+2. Based on findings, produce a unified `<next_steps>` section with prompt options
 3. Remove duplicates (dedupe by file path + action)
 4. Re-prioritize if needed (critical > high > medium > low)
-5. Keep the unified list within the 5-item guideline, but no hard cap
+5. Human-only findings (e.g., "check the browser console") go outside the tag
+6. Keep the unified list within the 5-item guideline, but no hard cap
 
 When a **subagent** completes its task, it MUST:
 
@@ -120,13 +141,15 @@ When a **subagent** completes its task, it MUST:
 
 ## Anti-patterns
 
+- **Don't put human-only actions in `<next_steps>`** — those belong outside the tag as plain text
+- **Don't write imperative instructions** — write what the user would type, not what they should do
 - **Don't use markdown inside `<next_steps>`** — plain text only
-- **Don't skip the tag** — the leader's final message always needs one
+- **Don't skip the tag when there are prompt options** — the tag enables the `/next` workflow
 - **Don't use dashes or asterisks** — use `1.`, `2.`, `3.` numbering
-- **Don't be vague** — "fix bugs" is useless, "fix auth/session.ts:42" is actionable
+- **Don't be vague** — "fix bugs" is useless, "fix auth/session.ts:42" is a valid prompt
 - **Don't exceed 5 items without reason** — if >5, it's probably not a single task
-- **Don't write declarations of intent** — "we should refactor X" is not actionable; "Extract the parseConfig function in core/config.ts:88" is
-- **Don't suggest manual review** — "manually check if X is correct" is not a next step; "Run pnpm typecheck to verify" is
+- **Don't write declarations of intent** — "we should refactor X" is not a prompt; "refactor core/config.ts" is
+- **Don't suggest manual review as a prompt** — "manually check if X is correct" is not a valid LLM prompt; instead put it outside the tag
 - **Don't include `<next_steps>` in subagent output** — subagents report findings, leaders produce next steps
 
 ## Skills in scope

package/skills/refactor-planner/SKILL.md

@@ -157,9 +157,9 @@ config.ts → logger.ts → path-resolver.ts
 - [ ] `Context` interface < 20 methods
 
 <next_steps>
-1. [Phase 1] Extract `ToolExecutor` interface in core/tool-executor.ts
-2. [Phase 1] Decouple `SessionStore` from Agent in core/session-store.ts
-3. [Phase 2] Break circular dep: Config ↔ Logger in core/config.ts
+1. Extract ToolExecutor interface in core/tool-executor.ts
+2. Decouple SessionStore from Agent in core/session-store.ts
+3. Break circular dep between Config and Logger in core/config.ts
 </next_steps>
 ```
 

package/skills/security-scanner/SKILL.md

@@ -21,6 +21,7 @@ Scans code, configs, and dependencies for security issues. Reports with severity
 4. Don't flag test fixtures — mock credentials in tests are acceptable.
 5. Always run dependency audit — supply chain is a real attack vector.
 6. Flag config issues (TLS disabled, HTTP in production) as CRITICAL.
+7. Never echo a full secret into the report — redact it (short prefix + char count, e.g. `ghp_…36 chars`). Cite `file:line` you have read; don't flag from a pattern guess.
 
 ## Patterns
 
@@ -157,9 +158,9 @@ element.textContent = userInput;
 - [ ] Add rate limiting to `src/api/` routes
 
 <next_steps>
-1. [CRITICAL] `src/config.ts` — remove hardcoded API key, use env var
-2. [HIGH] `src/auth/login.ts` — replace exec() with execFile()
-3. [MEDIUM] `src/api/routes.ts` — add rate limiting middleware
+1. Fix the hardcoded API key in src/config.ts
+2. Fix the shell injection in src/auth/login.ts
+3. Fix the missing rate limiting in src/api/routes.ts
 </next_steps>
 ```
 

package/skills/tech-stack/SKILL.md

@@ -105,8 +105,7 @@ When APPROVED:
 **Note**: <any caveats about the version, semver range, or compatibility>
 
 <next_steps>
-1. [APPROVED/REJECTED] Package decision with rationale
-2. [If rejected] Migration step to the recommended alternative
+1. Add <package>@<version> to the project auto="true"
 </next_steps>
 ```
 

package/dist/secret-vault-BJDY28ev.d.ts

@@ -1,25 +0,0 @@
-/**
- * SecretVault encrypts secrets-at-rest in config files. The wire format is
- * `enc:v1:<base64-iv>:<base64-tag>:<base64-ciphertext>`. Plaintext strings
- * (those that do not match this prefix) are passed through unchanged so that
- * existing configs and env-var-derived values keep working.
- *
- * The vault is intentionally NOT designed to defeat a determined local
- * attacker who can read both the config file and the key file — that level
- * of secrecy needs the OS keychain. The goal is to keep keys from being
- * visible in screen shares, accidental log captures, and `cat config.json`
- * over someone's shoulder.
- */
-interface SecretVault {
-    encrypt(plaintext: string): string;
-    decrypt(value: string): string;
-    isEncrypted(value: string): boolean;
-}
-/**
- * No-op SecretVault that passes values through unchanged.
- * Used in contexts where encryption is not needed — e.g. reading/writing
- * config sections that contain no secret fields (models, settings, etc.).
- */
-declare const noOpVault: SecretVault;
-
-export { type SecretVault as S, noOpVault as n };