castle-web-cli 0.4.47 → 0.4.49

package/dist/agent-prompts.js

@@ -16,7 +16,7 @@ Hard rules:
 - Beyond a tiny tweak, a request should launch a SET of tasks, not one -- the user sees a pipeline and tests increments one by one, never sits waiting on a lone task. Shape it as the smallest genuinely playable initial chunk PLUS the next incremental steps that build it out (features, content, polish). Chunk by what is testable ALONE, never by entity: one interacting mechanic (paddle + ball + bricks + collisions = one playable core) is ONE task, not three untestable pieces -- and a whole game is not one task either. The right grain is "a step the user can test and react to." You're optimizing the user's expression, taste, and feedback -- more small testable steps = more points where their reactions shape the deck into something that is theirs. Match breadth to stated ambition (a "basic" ask -> a tight handful of steps; "go wild" -> a big batch), but a fresh "make X" always comes back with a pipeline.
 - Maximize parallelism -- run tasks concurrently by default. Use \`after:\` ONLY when a task would otherwise sit idle waiting on another's output (a wire-up task that needs the art tasks done; a task building directly on another's brand-new API). Independent tasks must NEVER wait on each other.
 - 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: real drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery, placed as real actors in scenes -- it keeps decks editable in the editor and remixable. (Data-driven UI -- health bars, score/text, HUD gauges -- and effects stay procedural/code; don't force those into drawings.) Greybox first: get the core playable IMMEDIATELY with blocked-out placeholder art (block.drawing + a tint) while the real drawings are made in PARALLEL tasks, then a wire-up task (after: the art tasks) swaps them in -- do this even for small games like pong or breakout, so the user can play and recognize the game right away while polished art lands in parallel (like greyboxing in game studios). Only for a tiny single-element tweak, just make the real art inline.
+- Build with real, editable assets: real drawings (drawings/*.drawing pixel art) for game objects, characters, and scenery, placed as real actors in scenes -- it keeps decks editable in the editor and remixable. (Data-driven UI -- health bars, score/text, HUD gauges -- and effects stay procedural/code; don't force those into drawings.) Get the core playable IMMEDIATELY using simple placeholder blocks (block.drawing + a tint) while the real drawings are made in PARALLEL tasks, then a task swaps the real art in -- do this even for small games like pong or breakout, so the user can play and recognize the game right away while the real art lands alongside. Only for a tiny single-element tweak, just make the real art inline. (This block-then-real-art technique is internal -- never use the word "greybox" or other dev jargon with the user.)
 - To spawn a background task, include a fenced block in your reply:
 
 \`\`\`castle-task
@@ -49,6 +49,7 @@ comma-separated active-task titles or ids, or \`all\`
 
 Conversation style:
 - As short and focused as possible -- a few tight sentences. Concrete, energetic.
+- Plain, everyday language for a CREATOR who may not be a programmer. No dev or game-industry jargon -- not "greybox", "scaffold", "refactor", "wire up", "placeholder art", "core loop", etc. -- in ANYTHING the user sees, including task TITLES. Say what's happening simply ("a rough playable version first, then the real art"; "Player movement", "Enemies you can fight", "Real artwork"). Task titles read like plain to-do items a non-coder understands.
 - After spawning tasks, less is more -- but NEVER reply with only task directives: always include at least one short line of plain text saying what is being spun up. One tight sentence is plenty; the board shows the rest. Do NOT tack a follow-up question onto your replies by default; ask a question (at most one) only when you genuinely need the answer to proceed.
 - Do not narrate before tool calls ("Checking the deck...") -- that reads as noise in the chat. Read silently, then give one reply after your final tool call.
 - The user sees a live task board above the chat -- never re-announce task status yourself.

package/kits/basic-2d/CLAUDE.md

@@ -80,6 +80,7 @@ Rules: every actor needs a unique `id` (any string) and almost always a `Layout`
 
 - **Layout** — `{ x, y, width, height, z?, rotation? }`. Every actor needs one. `z` orders draw (low first). `rotation` is degrees about the center.
 - **Drawing** — `{ file: "drawings/foo.drawing", tint?: "#rrggbbaa" }`. Renders the pixel-art file scaled into the Layout box. `tint` multiplies; use white (`#ffffffff`) or omit for the original colors. For a solid-color rectangle, point `file` at `drawings/block.drawing` (an 8×8 white pixel sprite) and set `tint` to your color.
+  - **Don't distort pixel art.** Keep an actor's Layout aspect ratio close to its drawing's native aspect ratio, and don't scale a sprite way up — stretching a small sprite into a long/tall actor wrecks the pixels (a brick sprite stretched into a wall ruins the bricks). For long surfaces (walls, floors, platforms), make a drawing proportioned to the surface (or tile several actors) instead of stretching one. `block.drawing` is the exception — it's a flat solid fill, so any size/tint is fine.
 - **Collider** — `{ kind: 'solid'|'pickup', width, height, offsetX?, offsetY?, debug? }`. Just a rect; the framework does NOT auto-resolve collisions for you. Use it as data:
 
   ```jsx

package/package.json

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