@wrongstack/core 0.148.0 → 0.236.0

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

@@ -94,6 +94,19 @@ interface WstackPathOptions {
     /** Override the global root (e.g. for tests). Default: `${userHome}/.wrongstack`. */
     globalRoot?: string | undefined;
 }
+/**
+ * The global `~/.wrongstack` root, honoring the `WRONGSTACK_HOME` env
+ * override. The override exists so tests (and sandboxed runs) can redirect
+ * ALL global state — config, secrets, logs, projects/, mailboxes — away from
+ * the real user home. Before it existed, `pnpm test` booted runtimes against
+ * the real `~/.wrongstack`: it read the user's real config.json (starting a
+ * second live Telegram poller), appended to the real wrongstack.log, and left
+ * ~20k orphaned fixture dirs under projects/.
+ *
+ * Every code path that wants the global dir must come through here (or
+ * through `resolveWstackPaths`) instead of `path.join(os.homedir(), '.wrongstack')`.
+ */
+declare function wstackGlobalRoot(): string;
 declare function resolveWstackPaths(opts: WstackPathOptions): WstackPaths;
 
-export { type WstackPaths as W, type WstackPathOptions as a, projectSlug as b, projectHash as p, resolveWstackPaths as r };
+export { type WstackPaths as W, type WstackPathOptions as a, projectSlug as b, projectHash as p, resolveWstackPaths as r, wstackGlobalRoot as w };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wrongstack/core",
-  "version": "0.148.0",
+  "version": "0.236.0",
   "license": "MIT",
   "description": "WrongStack core: kernel, types, defaults, and shared utilities for the WrongStack CLI agent.",
   "repository": {
@@ -44,6 +44,10 @@
       "types": "./dist/execution/index.d.ts",
       "import": "./dist/execution/index.js"
     },
+    "./execution/prompt-enhancer": {
+      "types": "./dist/execution/prompt-enhancer.d.ts",
+      "import": "./dist/execution/prompt-enhancer.js"
+    },
     "./coordination": {
       "types": "./dist/coordination/index.d.ts",
       "import": "./dist/coordination/index.js"
@@ -93,9 +97,9 @@
   ],
   "wrongstackApiVersion": "0.1.10",
   "devDependencies": {
-    "@types/node": "^22.19.19",
+    "@types/node": "^25.9.2",
     "tsup": "^8.5.1",
-    "typescript": "^6.0.0"
+    "typescript": "^6.0.3"
   },
   "publishConfig": {
     "access": "public"

package/skills/chimera/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: chimera
+description: |
+  Use this skill when performing a post-session code quality review of files
+  changed during an AI coding session. Activated automatically by the chimera
+  plugin after each session completes.
+  Triggers: post-session review, chimera agent, session-end code check.
+version: 1.0.0
+---
+
+# Chimera — Post-Session Code Guardian
+
+## Overview
+
+You are Chimera, a post-session code quality agent. You run automatically after
+each WrongStack session ends. Your job: review files that were **added or
+modified** during the session and produce a concise, actionable quality report.
+
+You do NOT re-litigate decisions the session already discussed. You surface NEW
+issues the session agent may have missed.
+
+## Rules
+
+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.
+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
+   chat history.
+5. **Severity-ranked.** Critical > High > Medium > Low. Only report Medium+
+   unless a Low is egregious.
+6. **One finding per line.** Each finding must have: severity, file:line, and a
+   one-sentence fix.
+
+## What to look for
+
+| Category | Examples | Severity |
+|----------|----------|----------|
+| **Logic bugs** | Off-by-one, inverted condition, null deref without guard | Critical / High |
+| **Type safety** | `as any`, missing return type on export, `!` assertion | Medium |
+| **Error handling** | Missing try/catch on async, swallowed errors | High |
+| **Security** | Hardcoded secret, shell injection, innerHTML XSS | Critical |
+| **Resource leaks** | Event listener not removed, file handle not closed | Medium |
+| **Test gaps** | New logic without corresponding test | Medium |
+| **API design** | Wrong status code, missing validation, secrets in URL | High |
+
+## Report format
+
+Write your report as a single message appended to the chat. Use this structure:
+
+```
+## 🦂 Chimera Review — <session title or date>
+
+### Critical (N)
+1. [BUG] `path/file.ts:42` — null deref on `user.name` when `user` is undefined
+   → Add guard: `if (!user) throw new NotFoundError()`
+
+### High (N)
+2. [SEC] `path/config.ts:8` — plaintext API key in source
+   → Move to env var via `process.env.MY_API_KEY`
+
+### Medium (N)
+3. [TYPE] `path/helper.ts:15` — `as any` cast silences type error
+   → Use `as unknown as T` with a comment explaining the trust boundary
+
+### Summary
+- Files reviewed: N
+- Findings: C critical, H high, M medium
+- Clean files: N
+```
+
+If you find **nothing** worth flagging: write a single line.
+
+```
+## 🦂 Chimera Review — all clear ✅
+No issues found in N changed files across M packages.
+```
+
+## Anti-patterns
+
+- **Don't flag TODOs or FIXMEs** — those are intentional markers.
+- **Don't flag test fixtures or mock data** for secrets — those are expected.
+- **Don't suggest full rewrites** — be surgical, offer the minimal fix.
+- **Don't review unchanged files** — stick to the provided file list.
+- **Don't produce walls of text** — one finding = one line + one fix line.
+
+## Context you receive
+
+The chimera plugin provides:
+- A list of changed file paths (relative to project root)
+- The full content of each changed file
+- A summary of the session (what was worked on, key decisions)
+- The chat history from the session
+
+Use the chat history to understand intent — flag only issues the session agent
+likely missed, not decisions it explicitly made.
+
+## Skills in scope
+
+- `bug-hunter` — for systematic bug detection patterns
+- `security-scanner` — for security vulnerability patterns
+- `typescript-strict` — for TypeScript type safety rules
+- `api-design` — for API design review patterns
+- `testing` — for test coverage assessment

package/skills/research-web/SKILL.md

@@ -0,0 +1,342 @@
+---
+name: research-web
+description: |
+  Use this skill when searching the web for current, up-to-date data during
+  a research phase — version checks, ecosystem changes, API deprecations,
+  tool comparisons, or any claim that needs live verification against sources
+  newer than the model's training cutoff.
+  Triggers: user says "research", "current version", "is this still true",
+  "latest", "what's new in", "breaking changes", "find current",
+  "web research", "search the web", "look up".
+version: 1.0.0
+---
+
+# Research Web — WrongStack
+
+## Overview
+
+Teaches the agent how to conduct current-data web research with discipline:
+when to search, how to cross-validate, how to inject findings for reuse, and
+how to delegate research to subagents. Complements the `research-web` mode
+(which provides tool prioritization and behavioral gating); this skill
+provides the deep methodology and patterns the mode prompt can't fit.
+
+## Rules
+
+1. Verify before claiming. Never state a version number, deprecation status,
+   or API surface from training data without a live check.
+2. Two-source minimum. Single-source claims are tentative; two agreeing
+   sources is a signal; three is confirmation.
+3. Inject, don't repeat. After research, use `context_manager` with `add_note`
+   to inject a structured summary. Never re-research the same topic.
+4. Respect the stop rule. 2-3 searches + 1-2 fetches per topic. If no clear
+   answer after that, surface the ambiguity rather than research-looping.
+5. Cite every claim. Domain name minimum; date if visible on the page.
+6. Match tool to task. `web_search` for discovery, `web_fetch` for detail,
+   `fetch` for raw API responses, `search` for source-code-specific queries.
+
+## Research Workflow Taxonomy
+
+Not every research task needs the same approach. Match the workflow to the need:
+
+### Quick Lookup (1-2 turns)
+**When**: "What's the latest version of React?" "Is package X still maintained?"
+**Pattern**:
+```
+web_search("React latest stable version 2025")  →  discover version
+web_fetch("https://react.dev/versions")          →  confirm from authoritative source
+context_manager add_note("## Research: React version\n- 19.2.0 (March 2025)\n- Source: react.dev")
+```
+**Budget**: 1 search + 1 fetch = ~2000 tokens. Done in one turn.
+
+### Deep Investigation (3-4 turns)
+**When**: "How has Next.js middleware changed across 14.x → 15.x?"
+**Pattern**:
+```
+Turn 1: web_search("Next.js middleware changes 14 to 15") → collect URLs
+Turn 2: web_fetch(upgrade guide), web_fetch(changelog)     → parallel fetches
+Turn 3: cross-reference, inject structured findings
+```
+**Budget**: 2 searches + 2-3 fetches = ~5000 tokens. Use parallel fetches.
+
+### Landscape Survey (fan-out)
+**When**: "Compare the top 5 React state management libraries in 2025"
+**Pattern**: Delegate to subagents. Each researches one library, leader aggregates.
+See "Subagent Delegation" section below.
+
+## Tool Selection Guide
+
+| Tool | Best for | Avoid for |
+|------|----------|-----------|
+| `web_search` | Broad discovery, finding current URLs, getting an overview | Deep detail (use `web_fetch` after) |
+| `web_fetch` | Reading a specific page for detail, authoritative confirmation | Broad queries (use `web_search` first) |
+| `search` | Technical docs, source code, API references (DuckDuckGo) | General web queries (use `web_search`) |
+| `fetch` | Raw API responses (JSON), registry endpoints, structured data | HTML pages (use `web_fetch` for markdown conversion) |
+| `context_manager` | Injecting research findings into conversation for future turns | Research itself (this is the *output* tool) |
+
+### Decision heuristic
+```
+                   ┌─────────────────┐
+                   │ What do I need? │
+                   └────────┬────────┘
+           ┌────────────────┼────────────────┐
+           ▼                ▼                 ▼
+     "Discover URLs"   "Read a page"    "Raw API data"
+           │                │                 │
+     web_search        web_fetch           fetch
+           │                │
+           └────────┬───────┘
+                    ▼
+            context_manager
+              add_note
+```
+
+## Source Quality Evaluation
+
+Rate every source before citing it:
+
+| Tier | Examples | Trust |
+|------|----------|-------|
+| **Primary** | Official docs, GitHub releases, registry APIs, RFCs | Cite as fact |
+| **Secondary** | Well-known tech blogs, conference talks by maintainers | Cite with "according to" |
+| **Tertiary** | Stack Overflow, Reddit, personal blogs, LLM-generated content | Corroborate before citing |
+
+**Recency check**:
+- Package version: must be ≤ 6 months old to claim "current"
+- API change: must reference the specific version that introduced it
+- Deprecation claim: must cite the deprecation notice (not just "I heard")
+- Ecosystem trend: multiple sources from the current year
+
+## Injection Format Templates
+
+Structured `add_note` formats for different research outcomes. The format matters —
+future turns need to parse these quickly without re-reading raw search results.
+
+### Version check
+
+```
+## Research: [package] version
+- Current latest: [version] ([date])
+- Previous: [version] (for context)
+- Registry source: [npm/pypi/crates.io URL]
+- Confirmed via: [source URL]
+```
+
+### API / breaking change
+
+```
+## Research: [package] [feature] changes
+- [Version]: [what changed]
+- [Version]: [what changed]
+- Breaking: [list of breaks]
+- Migration path: [if documented]
+- Source: [upgrade guide URL]
+```
+
+### Ecosystem comparison
+
+```
+## Research: [topic] comparison
+- [Tool A]: [key points, version, status]
+- [Tool B]: [key points, version, status]
+- Recommendation: [with rationale]
+- Sources: [URL, URL]
+```
+
+### Null result (important — prevents re-search)
+
+```
+## Research: [topic] — no current changes found
+- Searched: [query, query]
+- Result: No breaking changes / deprecations / version bumps found
+- Checked on: [date]
+```
+
+**Always include a null-result note.** Without it, future turns may re-research
+the same topic thinking the data was never gathered.
+
+## Subagent Delegation
+
+For landscape surveys and parallel research, delegate to subagents carrying
+this skill. The `research` and `search` roster roles are tuned for this.
+
+### Fan-out pattern (parallel)
+
+```typescript
+// Leader: fan out one topic per subagent
+batch_tool_use([
+  {
+    tool: "delegate",
+    input: {
+      task: "Research current state of Zustand: latest version, breaking changes in 5.x, ecosystem position. Inject findings via context_manager.",
+      role: "research"
+    }
+  },
+  {
+    tool: "delegate",
+    input: {
+      task: "Research current state of Jotai: latest version, breaking changes, ecosystem position. Inject findings via context_manager.",
+      role: "research"
+    }
+  },
+  {
+    tool: "delegate",
+    input: {
+      task: "Research current state of Valtio: latest version, breaking changes, ecosystem position. Inject findings via context_manager.",
+      role: "research"
+    }
+  },
+])
+```
+
+### Sequential deep-dive
+
+```typescript
+// Leader: one topic, phased research
+delegate({
+  task: "Research React 19 Server Components: what changed from 18→19, current best practices for 'use client' boundaries, known pitfalls. Cross-reference react.dev docs and the GitHub release notes. Inject structured findings.",
+  role: "research"
+})
+```
+
+### Subagent budget guidance
+
+| Research type | `maxIterations` | `maxToolCalls` | Notes |
+|---|---|---|---|
+| Quick lookup | 3 | 6 | 1 search + 1 fetch + inject |
+| Deep investigation | 8 | 20 | Multiple searches + cross-ref |
+| Landscape survey | 12 | 30 | Multiple searches + fetches per topic |
+
+## Cross-Validation Patterns
+
+### When sources agree
+```
+Source A (official docs): React 19.2.0
+Source B (npm registry):  19.2.0
+Source C (GitHub releases): 19.2.0
+→ Cite as confirmed. No need to fetch a 4th source.
+```
+
+### When sources disagree
+```
+Source A (blog post):       Next.js 15.2 deprecated middleware edge runtime
+Source B (official docs):   Middleware now defaults to Node.js, edge still available
+→ Dig deeper. The blog conflated "default change" with "deprecation".
+→ Fetch the actual upgrade guide for the precise language.
+→ Flag the disagreement in your findings.
+```
+
+### When only one source exists
+```
+Source A (GitHub issue comment): "This API is being removed in v4"
+→ Mark as TENTATIVE. State: "One source claims... cannot confirm."
+→ If the claim is critical, search specifically for confirmation.
+→ Otherwise, move on — don't spend budget chasing unconfirmed rumors.
+```
+
+## Cost Awareness
+
+| Action | Approximate cost | When to use |
+|--------|-----------------|-------------|
+| `web_search` (5 results) | ~500 tokens | Always first — cheap discovery |
+| `web_fetch` (single page) | ~1000-2000 tokens | Only for authoritative sources |
+| `context_manager add_note` | ~0 tokens (metadata op) | After every research cycle |
+| `delegate` (quick lookup subagent) | ~$0.05-0.15 | When research would bloat your context |
+| `delegate` (deep investigation) | ~$0.20-0.50 | Landscape surveys only |
+
+**Rule of thumb**: Don't spend more on research than the answer is worth.
+A version check shouldn't cost $0.50. A landscape survey justifying an
+architecture decision might be worth $2.00.
+
+## Anti-Patterns
+
+### Re-researching known data
+
+```typescript
+// ❌ Turn 5: Agent forgets it already researched React version
+web_search("React latest version")
+
+// ✅ Turn 2: Agent injected findings via add_note
+// Turn 3-5: Agent sees the note in conversation — skips re-search
+```
+
+### Fetching without searching first
+
+```typescript
+// ❌ Guessing URLs wastes fetches
+web_fetch("https://react.dev/blog/2025/03/15/react-19-2")  // 404
+
+// ✅ Search discovers the real URL first
+web_search("React 19.2 release blog post")
+web_fetch(<result from search>)
+```
+
+### Injecting raw dumps
+
+```typescript
+// ❌ Bloating context with raw JSON
+context_manager add_note(JSON.stringify(searchResults))
+
+// ✅ Structured summary
+context_manager add_note("## Research: React version\n- 19.2.0\n- Source: react.dev")
+```
+
+### Single-source claims
+
+```typescript
+// ❌ One blog post becomes "truth"
+"The React team recommends X"  — based on one Medium article from 2023
+
+// ✅ Cross-referenced
+"The React docs recommend Y (react.dev). A 2024 blog post also suggests Y.
+One 2023 article suggests X, but this appears outdated."
+```
+
+### Research-looping
+
+```typescript
+// ❌ 7 searches on the same topic, each slightly rephrased
+web_search("React 19 new features")
+web_search("React 19 what changed")
+web_search("React 19 release notes changes")
+web_search("React 19 difference from 18")
+// ...
+
+// ✅ 1-2 broad searches, then targeted fetches
+web_search("React 19 release notes breaking changes")
+web_fetch(<react.dev blog>)
+web_fetch(<GitHub releases>)
+// Done. Inject findings.
+```
+
+### Researching during tactical work
+
+```typescript
+// ❌ User asks for a quick null-check fix, agent starts web searching
+User: "fix the null deref in auth.ts line 42"
+Agent: web_search("TypeScript null check best practices") // NO
+
+// ✅ Research mode is for analysis/discussion phases, not tactical edits
+// The agent already knows how to fix a null deref — just fix it.
+```
+
+## Workflow
+
+```
+1. TRIGGER    — User asks for current data OR agent realizes knowledge is stale
+2. CLASSIFY   — Quick lookup? Deep investigation? Landscape survey?
+3. SEARCH     — web_search with 5-8 results for broad discovery
+4. FETCH      — web_fetch 1-2 authoritative results for detail (parallelize if >1)
+5. VALIDATE   — Cross-reference: 2+ sources agree? Flag single-source claims
+6. INJECT     — context_manager add_note with structured findings
+7. CITE       — In your response, cite sources for every factual claim
+```
+
+## Skills in scope
+
+- `tech-stack` — for package version verification and ecosystem validation
+- `node-modern` — for Node.js-specific version and API checks
+- `react-modern` — for React-specific version and API checks
+- `security-scanner` — for CVE and vulnerability research
+- `prompt-engineering` — for crafting effective search queries
+- `multi-agent` — for fanning out research to subagents

package/dist/logger-B9J5puGM.d.ts

@@ -1,32 +0,0 @@
-import { L as Logger, a as LogLevel } from './logger-B63L5bTg.js';
-
-interface DefaultLoggerOptions {
-    level?: LogLevel | undefined;
-    file?: string | undefined;
-    pretty?: boolean | undefined;
-    bindings?: Record<string, unknown>;
-    /**
-     * When false, suppress stderr output entirely — only write to the log
-     * file (if configured). Use this in TUI mode so plugin/library log
-     * messages don't interleave with Ink's terminal rendering.
-     * Default: true (stderr output is enabled).
-     */
-    stderr?: boolean | undefined;
-}
-declare class DefaultLogger implements Logger {
-    level: LogLevel;
-    private readonly file?;
-    private readonly bindings;
-    private readonly pretty;
-    private readonly stderr;
-    constructor(opts?: DefaultLoggerOptions);
-    error(msg: string, ctx?: unknown): void;
-    warn(msg: string, ctx?: unknown): void;
-    info(msg: string, ctx?: unknown): void;
-    debug(msg: string, ctx?: unknown): void;
-    trace(msg: string, ctx?: unknown): void;
-    child(bindings: Record<string, unknown>): Logger;
-    private log;
-}
-
-export { DefaultLogger as D, type DefaultLoggerOptions as a };