sparkecoder 0.1.130 → 0.1.132

package/dist/skills/default/build-context-and-solve-issue.md

@@ -0,0 +1,74 @@
+---
+name: Build Context and Solve Issue
+description: Two-phase workflow that builds a complete, evidence-backed map of a feature before fixing a bug. Load when the user asks to "build context and solve issue", to deeply understand a feature before changing it, or to root-cause a tricky bug instead of patching symptoms.
+---
+
+# Build Context and Solve Issue
+
+A two-phase flow: **first build context, then solve.** Resist the urge to jump straight to a fix. Most bad fixes come from an incomplete mental model of the feature. This skill is repo-agnostic — begin by discovering the project's stack (CLI, HTTP/RPC API, web frontend, background worker, library, etc.) and adapt the terms below to it.
+
+## Phase 1: Build Context
+
+Build a complete, evidence-backed map of the feature surface. Use the `explore_agent` tool to investigate, and prefer launching a few **independent** explorations against the same surface, then reconciling them, rather than a single shallow pass. Each exploration has zero context, so pass it the relevant files, the symptom, and concrete questions.
+
+### What to investigate
+
+1. **Entry points.** Every way the feature is triggered: CLI commands, HTTP/RPC routes, UI pages/components, event or queue consumers, scheduled jobs, webhooks. Capture request/response shape and auth path for each.
+2. **Core logic & shared code.** The functions, modules, and components that implement the behavior, plus the shared helpers/libraries they depend on. Use `code_graph` and `search` to follow references up and down the call stack.
+3. **Data layer.** The tables/models/schemas, caches, and files the feature reads and writes — including relations and constraints. If the repo has more than one backend (local vs remote, cache vs DB, multiple services), map **each** and note where they can diverge.
+4. **Runtime & async behavior.** Streaming/SSE/websockets, background jobs, queues, child processes, timers, retries, and cleanup that the feature relies on.
+5. **States & UX.** For UI or interactive surfaces, walk loading, empty, populated, error, permission-denied, streaming, reconnect, and disabled states the user can perceive.
+6. **Intended behavior & regression source.** If a ticket, PR, prior conversation, or branch diff is involved, use it to pin down what changed, what regressed, and the exact expected end-to-end behavior.
+
+### Per-exploration report shape
+
+Ask each `explore_agent` exploration to return only:
+
+```markdown
+## Entry Points In Scope
+- <trigger> — why it's reachable / what it touches
+
+## Reuse / Regression Surfaces
+- <shared module/component> — used by: <callers/pages>. Regression risk: ...
+
+## States & Behavior
+- <entry point> — state: <X> → user sees <Y>; state: <error> → ...
+
+## Data Touched
+- <store.table/model> — fields/relations read or written; which backend; divergence risk
+
+## API / CLI Surface
+- <handler/command> — request/response, auth, validation, data writes, external calls
+
+## Runtime / Async Surface
+- <module> — what it starts, streams, persists, or cleans up
+
+## Intended Behavior
+- step-by-step of how it should work
+```
+
+### Reconcile
+
+After the explorations return: keep overlapping findings, investigate disagreements with your own `read_file` / `search` / `code_graph`, and fill gaps. Produce one consolidated understanding covering:
+
+- **Feature surface**: the full set of entry points, core/shared code, data, runtime/async behavior, and UI states involved.
+- **Expected result**: what should happen.
+- **Current result**: what actually happens, with the concrete entry point, state, function call, response, query, or async step where behavior diverges.
+
+## Phase 2: Solve the Issue
+
+Only after the context is consolidated:
+
+1. **Pinpoint the root cause** at the exact step where expected and current diverge. Name the file, function, state, route, query, or async step — not a vague area.
+2. **Devise a plan.** When multiple approaches exist, briefly weigh them against the repo's existing patterns.
+3. **Prefer the smallest change** that preserves the project's boundaries and invariants: API/CLI contracts, data integrity (and parity across multiple backends), auth/permission model, streaming/async semantics, and resource lifecycle.
+4. **Present the plan and rationale before implementing** anything non-trivial.
+
+## Guardrails
+
+- Always build context first; never skip straight to a fix on a non-trivial bug.
+- Back every claim with a concrete reference: file path, command, route, table/model, state name, function, response, or async step.
+- Discover and respect the repo's actual layout and conventions before proposing changes — do not assume a structure that isn't there.
+- Watch for **multiple data backends or environments**: bugs frequently hide where two stores or two code paths are supposed to agree but don't.
+- Check auth and scope carefully: identify how the feature authenticates and what it is scoped to (user, tenant, session, device), and make sure the fix preserves those checks.
+- Prefer the smallest correct change, then verify with targeted tests, type checks, and a manual run of the affected flow.

package/dist/skills/default/doublecheck.md

@@ -0,0 +1,95 @@
+---
+name: Doublecheck
+description: Flow-by-flow review that finds bugs by tracing real user and system flows before running tests. Load when the user says "/doublecheck", asks you to double-check implementation behavior, sanity-check a change, or find regressions in recently edited code.
+---
+
+# Doublecheck
+
+Find bugs by reasoning through real flows **before** reaching for the test suite. Do not start by running all the tests. First walk the changed surface end to end — the entry point a user or system hits, the functions and routes invoked, the data read and written, the events/streams produced, and what the user actually perceives at each step. Tests come last, scoped to what the flow review reveals.
+
+This skill is repo-agnostic. Start by discovering what kind of project you are in (CLI, HTTP/RPC API, web frontend, background worker, library, mobile app, etc.) and adapt the terms below to that stack.
+
+## Required Process
+
+1. **Identify the touched surface.** Find the changed files and everything they reach: affected entry points (CLI commands, route/RPC handlers, UI pages, event/queue consumers, cron jobs), the functions and modules they call, the data layer (DB tables/models, caches, files), external services, and the parent/child relationships of any shared code or components.
+2. **Map the reachable entry points.** List each distinct way the changed surface can be triggered — every URL/page, API endpoint, CLI invocation, webhook, scheduled job, or message handler. Include auth-gated, empty, and error variants.
+3. **Build the reuse / regression map.** For every shared function, module, or component touched, find every *other* caller or consumer. Those are regression surfaces and must be walked too — not just the one call site you edited.
+4. **Explore in parallel.** Use the `explore_agent` tool to investigate the touched surface. Prefer launching a few independent explorations (e.g. one for entry points/routes, one for the data layer, one for shared-component reuse) and reconciling their findings, rather than one shallow pass. Each exploration has zero context, so pass it the changed files and concrete questions.
+5. **Reconcile.** Keep overlapping findings, investigate disagreements with your own `read_file` / `search` / `code_graph`, and fill gaps the explorations missed.
+6. **Produce flow paths** (format below) showing, per step: entry point, state, function call → return, API/route behavior, data effect, runtime/stream effect, and what the user sees.
+7. **List potential issues**, ordered by likely user impact. Call out regressions in code shared with untouched features.
+8. **Fix issues that are clear and safely actionable.** Do not fix speculative issues without evidence.
+9. **Only then decide on verification** — targeted tests, type checks, lints, or a manual run. Prefer focused checks over broad test runs unless the blast radius is large.
+
+## What every step of a flow path MUST make visible
+
+Each step is a single user- or system-perceivable moment. For that moment, surface all of:
+
+- **Entry point**: the exact trigger — URL + params, API method + path, CLI command + flags, event/message, webhook, or scheduled fire. Show it changing on navigation.
+- **State**: concrete in-memory and UI state — loading, empty, error, streaming, reconnecting, disabled, selected item, form draft, optimistic update, lock/concurrency state.
+- **Function calls → returns**: which functions run and what they return, including shared helpers and library calls.
+- **API / route behavior**: request shape, response/status shape, auth/permission decision, and validation.
+- **Data effect**: which store and which table/model/key is read or written, and any transaction or consistency concern. If the repo has more than one backend (e.g. local vs remote, cache vs DB), say *which* one and watch for divergence between them.
+- **Runtime / async effect**: streams/SSE/websocket events, background jobs, queue messages, child processes, timers, retries, and cleanup.
+- **What the user sees**: visible text, spinner, disabled control, stream/terminal output, toast, redirect, focus, or stale/missing data. State explicitly what the *correct* perception should be.
+
+If any required detail is unknown for a step, say so. An unknown is itself a likely bug to investigate.
+
+## Per-exploration prompt shape
+
+Ask each `explore_agent` exploration to return only:
+
+```markdown
+## Entry Points In Scope
+- <trigger> — why it's reachable / what it touches
+
+## Flow Paths
+(one step-by-step path per journey, using the Path Format below)
+
+## Reuse / Regression Surfaces
+- <shared module/component> — used by: <callers/pages>. Regression risk: ...
+
+## API / Data / Runtime Surface
+- <handler/module> — request/response, auth, data reads/writes, external calls, async effects
+
+## Potential Issues
+- ... (ordered by user impact)
+```
+
+## Path Format
+
+Write each path as a concrete step-by-step progression.
+
+```markdown
+### Path: <who> does <action>
+
+**Step 1: <moment>**
+- Entry point: <URL / endpoint / command / event>
+- Function calls → returns: <fn> → <result>
+- API / route: <request> → <status + shape>; auth: <decision>
+- Data effect: reads/writes <store.table/model>; <transaction/consistency note>
+- Runtime effect: <stream/job/process/timer>
+- State: <concrete state values>
+- User sees: <perception>. Correct: <what it should be>.
+
+**Step 2: <next moment / failure branch>**
+- API: returns <4xx/5xx> / emits error event
+- State: pending state clears, optimistic changes roll back, retry possible
+- Data effect: no partial/inconsistent write; failed async state cleaned up
+- User sees: specific error/empty state, no stale success UI.
+
+Potential issues:
+- <missing auth/scope check, partial write, stuck lock, leaked process, stale UI, ...>
+```
+
+## Guardrails
+
+- Walk **step by step**. Do not collapse multiple pages/commands into one vague "the user flows through the app" step.
+- Trace both server-side and client-side behavior when a flow crosses that boundary, and show the call/return on each side.
+- Always make these explicit per step: entry point, state, function call → return, API/route behavior, data effect, runtime/async effect, user-perceived output.
+- If the repo has multiple data backends or environments, name **which one** each step uses; bugs love to hide in the divergence between them.
+- For every shared function/component touched, prove the change is safe in **every** caller/consumer, not just the one you edited.
+- Include alternate paths: loading, empty data, auth denied, permission denied, failed network request, duplicate click, back/forward, refresh, streaming interruption/reconnect, timeout, retry, and concurrent access.
+- Use concrete references (file, function, route, table, state name). Avoid generic "could fail" notes.
+- Do not use doublecheck as a substitute for tests. Use it to decide what targeted tests should cover afterward.
+- If you find and fix issues, run the doublecheck flow again on the changed surface to confirm the fix introduced no new regression.

package/dist/tools/index.d.ts

@@ -1,7 +1,7 @@
 import * as ai from 'ai';
 import { ToolSet } from 'ai';
-import { B as BashToolProgress, W as WriteFileProgress, S as SearchToolProgress } from '../search-DOzC4ojH.js';
-export { b as BashToolOptions, d as SearchToolOptions, e as WriteFileToolOptions, c as createBashTool, f as createSearchTool, a as createWriteFileTool } from '../search-DOzC4ojH.js';
+import { B as BashToolProgress, W as WriteFileProgress, S as SearchToolProgress } from '../search-CVVfuBPZ.js';
+export { b as BashToolOptions, d as SearchToolOptions, e as WriteFileToolOptions, c as createBashTool, f as createSearchTool, a as createWriteFileTool } from '../search-CVVfuBPZ.js';
 
 interface TaskCompletionSignal {
     status: 'completed' | 'failed';
@@ -110,7 +110,7 @@ interface TodoToolOptions {
     workingDirectory: string;
 }
 declare function createTodoTool(options: TodoToolOptions): ai.Tool<{
-    action: "list" | "add" | "mark" | "clear" | "save_plan" | "list_plans" | "get_plan" | "delete_plan";
+    action: "clear" | "add" | "list" | "mark" | "save_plan" | "list_plans" | "get_plan" | "delete_plan";
     status?: "completed" | "pending" | "in_progress" | "cancelled" | undefined;
     items?: {
         content: string;

package/dist/tools/index.js

@@ -145,8 +145,8 @@ var init_types = __esm({
       authKey: z.string().optional()
     }).optional();
     SparkcoderConfigSchema = z.object({
-      // Default model to use (Vercel AI Gateway format)
-      defaultModel: z.string().default("anthropic/claude-opus-4.7"),
+      // Default model to use (LiteLLM model id)
+      defaultModel: z.string().default("gpt-5.5"),
       // Working directory for file operations
       workingDirectory: z.string().optional(),
       // Tool approval settings
@@ -185,6 +185,14 @@ var init_types = __esm({
       webhooks: z.object({
         token: z.string().optional()
       }).optional(),
+      // Self-update: when running as the managed service, periodically check
+      // npm for a newer published version and, if found, re-run the hosted
+      // installer (full upgrade + restart). Disabled automatically when not
+      // running from a global install (e.g. dev/source checkouts).
+      autoUpdate: z.object({
+        enabled: z.boolean().optional().default(true),
+        intervalHours: z.number().positive().optional().default(6)
+      }).optional().default({}),
       // Database path (used for local SQLite - ignored if remoteServer is configured)
       databasePath: z.string().optional().default("./sparkecoder.db"),
       // Remote server configuration (for centralized storage)
@@ -296,6 +304,7 @@ var init_config = __esm({
       openai: "OPENAI_API_KEY",
       google: "GOOGLE_GENERATIVE_AI_API_KEY",
       xai: "XAI_API_KEY",
+      litellm: "LITELLM_API_KEY",
       "ai-gateway": "AI_GATEWAY_API_KEY"
     };
     SUPPORTED_PROVIDERS = Object.keys(PROVIDER_ENV_MAP);