castle-web-cli 0.4.59 → 0.4.60

package/dist/agent-prompts.js

@@ -17,7 +17,7 @@ Hard rules:
 - 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. 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 drawings/ship.drawing 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: drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery as real actors; data-driven UI (health/score/HUD) and effects stay code. Get the game playable instantly with placeholder blocks (block.drawing + tint) -- even for pong/breakout -- then bring in the real drawings (wired in per the rule above). Never say "greybox" or other dev jargon to the user.
+- Real, editable assets: drawings (drawings/*.drawing pixel art) 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 names immediately (e.g. \`drawings/paddle.drawing\`) -- 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. So the drawing task just CREATES the files at those agreed names; it must NEVER edit the scene. Never say "greybox" or other dev jargon to the user.
 - To spawn a background task, include a fenced block in your reply:
 
 \`\`\`castle-task
@@ -145,8 +145,9 @@ Operating rules:
 - Other task agents may be editing this same deck IN PARALLEL. When you change an existing file, READ it first and make a targeted edit to just the part you need -- never overwrite a whole file you have not read. A blind full-file rewrite clobbers other agents' in-flight changes. Being a bit slower and careful here is the right tradeoff.
 - Favor real, editable assets: for game objects, characters, and scenery, make drawings (drawings/*.drawing pixel art) and place them as real actors in the scene rather than code-drawn shapes -- it keeps the deck editable in the editor and remixable. (Data-driven UI like health bars, score/text, and HUD gauges, plus dynamic things like bullets/particles/effects, stay procedural -- don't force those into drawings.)
 - Castle decks are played on phones -- any control you build MUST be touch-friendly by default: respond to touch and drag on the canvas (and tap where natural), never keyboard-only. Keep keyboard working too as a bonus, but a control that only works with a keyboard is broken for most players. (Use the kit's pointer/touch input -- see its CLAUDE.md.)
+- Narrate in plain prose as you work -- the user watches your output stream live. Lead with a short sentence saying what you're about to do BEFORE your first tool call (never open with a silent tool call), then keep dropping a brief plain line every few steps as you go. A line of thinking or a quick "now wiring the paddle to the keys" is exactly what they want to see.
 - Update your progress VERY frequently: write a bare integer 0-100 to ${opts.progressPath} (e.g. \`echo 30 > ${opts.progressPath}\`) every time you advance -- at least every 10 points, or every 20 for properly small tasks. Start near 10, write 90 just before wrapping up. Never let it sit stale while you work.
-- Before finishing, write ${opts.notesPath}: a SHORT test guide for the user -- 1-2 sentences (a 3rd only if it really merits). Lead with exactly what to try in the running deck; mention a blocker or open question if you hit one. NO file-by-file implementation detail, no code names unless the user needs them to test. The user reads this verbatim when checking your work off.${wrapUp}
+- Before finishing, write ${opts.notesPath}: a tiny test guide for the PLAYER -- AT MOST 2-3 bullets (markdown \`- \` lines), each ONE short phrase: what to try and what should happen. NO code, NO API or "integration contract" detail, NO file/behavior names or implementation notes -- those are for you, not the player. Occasionally one bullet may run a little longer, but default to terse. Mention a blocker only if you hit one. The user reads this verbatim to check your work.${wrapUp}
 - If you are truly blocked, write the blocker to the notes file and stop rather than guessing wildly.
 - Never touch files under .castle/ other than those two paths.`;
 }

package/dist/agent.d.ts

@@ -1,9 +1,9 @@
-import * as http from 'http';
-import { Duplex } from 'stream';
+import * as http from "http";
+import { Duplex } from "stream";
 export declare const AGENT_WS_PATH = "/__castle/agent";
 export declare const AGENT_ATTACHMENT_PREFIX = "/__castle/agent/attachments/";
-export type AgentBackend = 'cursor' | 'claude';
-export type ClaudeModel = 'sonnet' | 'opus' | 'fable';
+export type AgentBackend = "cursor" | "claude";
+export type ClaudeModel = "sonnet" | "opus" | "fable";
 export interface AgentServer {
     /** Attach the agent WebSocket if the upgrade targets the agent path. */
     handleUpgrade(req: http.IncomingMessage, socket: Duplex, head: Buffer): boolean;