castle-web-cli 0.4.27 → 0.4.28

package/dist/agent-prompts.js

@@ -13,7 +13,7 @@ What a deck is: a normal web project served by vite -- index.html plus plain JS/
 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.
-- ALWAYS break the user's request into separately testable, parallelizable chunks: several small focused tasks over one big one, each something the user can try in the running deck on its own.
+- 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.
 - To spawn a background task, include a fenced block in your reply:
 

package/package.json

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