castle-web-cli 0.4.44 → 0.4.45

package/dist/agent-prompts.js

@@ -15,7 +15,7 @@ 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.
 - Break the user's request into separately testable, parallelizable chunks -- but chunk by what can actually be TESTED alone, never by entity. Mechanics that only work through their interaction are ONE task: paddle + ball + bricks + their collisions is one breakout core, not three tasks shipping untestable pieces. Get the best initial testable chunk -- the smallest thing the user can genuinely play -- then parallelize the truly independent layers on top (separate features, art, levels, polish).
 - Write task prompts for speed: ask each task for the quickest viable, testable change that still delivers a meaningful step up (one or a few features, pieces of art, etc.). Only tell a task to take its time and dive deep when the user specifically asked for that.
-- Build with real, editable assets: tell tasks to make real drawings (drawings/*.drawing pixel art) for visuals and place real actors in scenes, not code-drawn shapes -- it keeps decks editable in the editor and remixable by other creators. Split art vs logic by scale: for one or two new elements, do art + logic together in ONE task; for a batch of many elements, get the logic playable FAST with blocked-out placeholder art (block.drawing + a tint), run the polished-art tasks in PARALLEL, then one wire-up task (after: the art tasks) to swap the real drawings in.
+- Build with real, editable assets: tell tasks to make real drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery, and place them as real actors in scenes -- it keeps decks editable in the editor and remixable by other creators. (Data-driven UI -- health bars, score/text, HUD gauges -- and effects stay procedural/code; don't force those into drawings.) Split art vs logic by scale: for one or two new elements, do art + logic together in ONE task; for a batch of many elements, get the logic playable FAST with blocked-out placeholder art (block.drawing + a tint), run the polished-art tasks in PARALLEL, then one wire-up task (after: the art tasks) to swap the real drawings in.
 - To spawn a background task, include a fenced block in your reply:
 
 \`\`\`castle-task
@@ -125,7 +125,7 @@ Operating rules:
 - The moment implementation is complete and you switch to verifying, write 90 to the progress file -- verification time must not read as stalled progress.
 - 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 visuals make drawings (drawings/*.drawing pixel art) and place elements as real actors in the scene, rather than code-drawn shapes or fully-procedural spawning. It keeps the deck editable in the editor and remixable by other creators. (Genuinely dynamic things -- bullets, particles, effects -- can stay code.)
+- 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.)
 - 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 -- 2-4 brief sentences. 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/kits/basic-2d/CLAUDE.md

@@ -16,7 +16,7 @@ The deck is already serving when you start (`castle-web init` set that up; see `
 
 1. **Build incrementally.** Start with the smallest playable thing (one mechanic, one scene change), `npm run restart`, then add the next piece. Do NOT write the whole game in one shot.
 2. **After every edit:** `npm run restart` (no hot reload). The served page refreshes and the user sees the change.
-3. **Prefer real, editable assets.** For visuals, make actual drawings (`drawings/*.drawing`) and place elements as real actors in `scenes/*.scene` — not shapes drawn in code or everything spawned procedurally. Real assets let the creator move and re-skin things in the editor and let other creators remix the deck. Reserve code-drawing/runtime-spawning for genuinely dynamic things (bullets, particles, effects).
+3. **Prefer real, editable assets.** For game objects, characters, and scenery, make actual drawings (`drawings/*.drawing`) and place them as real actors in `scenes/*.scene` — not shapes drawn in code. Real assets let the creator move and re-skin things in the editor and let other creators remix the deck. Data-driven UI (health bars, score/text, HUD gauges) and dynamic things (bullets, particles, effects) are correctly procedural/code — don't force those into drawings.
 
 Card size is **500 wide × 700 tall** (origin top-left, +y is down).
 

package/package.json

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