castle-web-cli 0.4.114 → 0.4.116

package/dist/agent-prompts.js

@@ -30,9 +30,9 @@ Hard rules:
 - You are the fast lane: get to your final reply as quickly as possible. When the user reports something broken, do NOT dig into the code to diagnose it first -- spawn a task whose job is to investigate AND fix it. Only read deck files when your reply itself needs them (answering a question about the deck, grounding a claim -- never make things up); never read as pre-work before spawning a task, and never read files just to learn conventions already covered by the Quick reference.
 - Launch a SET of small steps the user tests one by one -- a pipeline, never one big task they wait on, never untestable fragments. One interacting mechanic = one task (paddle + ball + bricks = one playable core, not three). First step = the smallest genuinely playable thing; later steps build it out. Match breadth to ambition ("basic" = a few steps; "go wild" = many). You're optimizing the user's taste and feedback -- more small testable steps = more points where they steer it into something theirs.
 - The whole goal: every piece of work TESTABLE in actual gameplay ASAP. Start every task as early as possible and run them in PARALLEL. Do NOT break tasks down by which files they touch, and never add \`after:\` just to avoid two tasks editing the same file -- tasks make surgical edits and overlap fine. The only real dependency between tasks is INFORMATION: a task is blocked only when it needs a fact it does not yet have.
-- Dissolve those information-dependencies with a CONTRACT decided up front, instead of serializing tasks. Before spawning, pin the shared names the tasks will agree on -- scene file names, behavior names, drawing file names, tags -- and give each parallel task the exact names it must CREATE or REFERENCE. Pinned names must be EXACT filenames, extension included -- \`drawings/ship.pxart\` in a kit deck (the kit's CLAUDE.md names the format), \`drawings/ship.svg\` in a bare one. A bare deck has no kit to define a default art format or loader, so its contract must also state the format and loading approach every consumer will use. Then they all run at once and converge to a working game with NO follow-up wiring task: the scene task places actors referencing behaviors and drawings by their agreed names before those files even exist; the behavior tasks create those behavior names; the drawing tasks create those drawing files. (Art: pin an exact drawing filename like \`drawings/ship.pxart\` up front -> the scene task points an actor at it while another task draws it, in parallel; no place-it-later task.) Fall back to a separate waiting wire-in task (\`after:\` the maker, on the least possible) ONLY when a task truly needs another's actual produced output, not just its agreed name. Working out this breakdown -- what to parallelize, which names to pin up front -- is the core of your job and differs per game.
+- Dissolve those information-dependencies with a CONTRACT decided up front, instead of serializing tasks. Before spawning, pin the shared names the tasks will agree on -- scene file names, behavior names, drawing file names, tags -- and give each parallel task the exact names it must CREATE or REFERENCE. Pinned names must be EXACT filenames, extension included -- \`drawings/ship.sprite\` in a kit deck (the kit's CLAUDE.md names the format), \`drawings/ship.svg\` in a bare one. A bare deck has no kit to define a default art format or loader, so its contract must also state the format and loading approach every consumer will use. Then they all run at once and converge to a working game with NO follow-up wiring task: the scene task places actors referencing behaviors and drawings by their agreed names before those files even exist; the behavior tasks create those behavior names; the drawing tasks create those drawing files. (Art: pin an exact drawing filename like \`drawings/ship.sprite\` up front -> the scene task points an actor at it while another task draws it, in parallel; no place-it-later task.) Fall back to a separate waiting wire-in task (\`after:\` the maker, on the least possible) ONLY when a task truly needs another's actual produced output, not just its agreed name. Working out this breakdown -- what to parallelize, which names to pin up front -- is the core of your job and differs per game.
 - Write each task prompt for the quickest viable, testable change that still delivers a meaningful step up. Dive deep only if the user asked.
-- Real, editable assets: drawing files under \`drawings/\` for game objects, characters, and scenery as real actors; data-driven UI (health/score/HUD) and effects stay code. The logic/scene task references the REAL drawing filenames immediately (e.g. \`drawings/paddle.pxart\`) -- a not-yet-created drawing auto-renders as a plain block, so the game is playable instantly AND the real art appears the moment the drawing task writes that file, with NO scene change. Ownership is EXCLUSIVE and reciprocal: the drawing task just CREATES the files at those agreed names and must NEVER edit the scene; the scene/logic task only REFERENCES those names and must NEVER create the drawing files (a sibling task owns them). When you split art into its own task, spell out BOTH sides in the prompts you write -- tell the art task exactly which drawing names to create, and tell every consumer task to reference those names and explicitly NOT draw them itself -- so two agents never make the same sprites. (The deck's CLAUDE.md / AGENTS.md gives the deck's drawing format, file extension, and how to make art.) Never say "greybox" or other dev jargon to the user.
+- Real, editable assets: drawing files under \`drawings/\` for game objects, characters, and scenery as real actors; data-driven UI (health/score/HUD) and effects stay code. The logic/scene task references the REAL drawing filenames immediately (e.g. \`drawings/paddle.sprite\`) -- a not-yet-created drawing auto-renders as a plain block, so the game is playable instantly AND the real art appears the moment the drawing task writes that file, with NO scene change. Ownership is EXCLUSIVE and reciprocal: the drawing task just CREATES the files at those agreed names and must NEVER edit the scene; the scene/logic task only REFERENCES those names and must NEVER create the drawing files (a sibling task owns them). When you split art into its own task, spell out BOTH sides in the prompts you write -- tell the art task exactly which drawing names to create, and tell every consumer task to reference those names and explicitly NOT draw them itself -- so two agents never make the same sprites. (The deck's CLAUDE.md / AGENTS.md gives the deck's drawing format, file extension, and how to make art.) Never say "greybox" or other dev jargon to the user.
 - To spawn a background task, include a fenced block in your reply:
 
 \`\`\`castle-task

package/dist/agent.d.ts

@@ -1,12 +1,12 @@
-import * as http from "http";
-import { Duplex } from "stream";
-import type { ORReasoningEffort, ORRoutingMode } from "./native/openrouter.js";
+import * as http from 'http';
+import { Duplex } from 'stream';
+import type { ORReasoningEffort, ORRoutingMode } from './native/openrouter.js';
 export declare const AGENT_WS_PATH = "/__castle/agent";
 export declare const AGENT_ATTACHMENT_PREFIX = "/__castle/agent/attachments/";
 export declare const AGENT_PLAYTEST_PREFIX = "/__castle/agent/playtest/";
 export declare const AGENT_MODEL_CAPS_PREFIX = "/__castle/agent/model-caps";
-export type AgentBackend = "cursor" | "claude" | "smith";
-export type ClaudeModel = "sonnet" | "opus" | "fable" | "openrouter";
+export type AgentBackend = 'cursor' | 'claude' | 'smith';
+export type ClaudeModel = 'sonnet' | 'opus' | 'fable' | 'openrouter';
 interface AgentSettings {
     router: AgentBackend;
     tasks: AgentBackend;
@@ -21,14 +21,14 @@ interface AgentSettings {
     routerProviderTier: string;
     tasksProviderTier: string;
 }
-type OpenrouterSlugKey = "routerOpenrouterModel" | "tasksOpenrouterModel";
+type OpenrouterSlugKey = 'routerOpenrouterModel' | 'tasksOpenrouterModel';
 type SettingsWarnings = Partial<Record<OpenrouterSlugKey, {
     model: string;
-    status: "unknown-model" | "no-tools";
+    status: 'unknown-model' | 'no-tools';
     message: string;
     suggestion?: string;
 }>>;
-type TaskStatus = "waiting" | "running" | "blocked" | "done" | "failed" | "interrupted";
+type TaskStatus = 'waiting' | 'running' | 'blocked' | 'done' | 'failed' | 'interrupted';
 interface TaskRecord {
     id: string;
     title: string;
@@ -55,7 +55,7 @@ interface TaskRecord {
 }
 export declare function roleUsesOpenrouter(backend: AgentBackend, claudeModel: ClaudeModel): boolean;
 export interface DepsState {
-    kind: "ready" | "waiting" | "blocked";
+    kind: 'ready' | 'waiting' | 'blocked';
     blockedBy?: string[];
 }
 export declare function classifyDeps(tasks: Map<string, TaskRecord>, task: TaskRecord): DepsState;