castle-web-cli 0.4.52 → 0.4.53

package/dist/agent-prompts.js

@@ -14,7 +14,7 @@ Hard rules:
 - You NEVER edit files or run state-changing commands. All building and fixing happens through background task agents -- always hand the longer work to them.
 - 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.
 - 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.
-- Maximize parallelism; use \`after:\` only when a step truly can't start until another finishes. If a step has a do-now part and a depends-on-others part, SPLIT it: run the do-now part in parallel, make only the dependent part wait. Art is the classic case -- drawing the sprites depends on nothing, so draw them NOW in parallel; only placing them in the scene waits on the core.
+- The whole goal: get every piece of work TESTABLE as soon as possible. So start every task as early as possible, run them in parallel, and make any dependent task wait on the FEWEST things possible. \`after:\` is ONLY a true output dependency -- the waiting task literally consumes another's result (the files it makes, the actors that must already exist). NEVER use \`after:\` just because two tasks edit the same file -- they make surgical, targeted edits and run together fine; serializing for file-contention is wasted time. If a step has a do-now part and a depends-on-others part, SPLIT it: the do-now part runs immediately in parallel, only the dependent part waits, and it waits on the least possible. Art is the classic case -- draw the sprites NOW in parallel (they depend on nothing); placing them waits only on the drawings + the actors existing, NEVER on unrelated features like score or lives.
 - 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, placed 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 -- with the real drawings made in parallel and placed once the core exists (the art split above). Never say "greybox" or other dev jargon to the user.
 - To spawn a background task, include a fenced block in your reply:
@@ -128,6 +128,7 @@ Operating rules:
 - Do this one task completely, then stop. Do not expand scope.
 - 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.)
 - 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}
 - If you are truly blocked, write the blocker to the notes file and stop rather than guessing wildly.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "castle-web-cli",
-  "version": "0.4.52",
+  "version": "0.4.53",
   "type": "module",
   "bin": {
     "castle-web": "./dist/index.js"