castle-web-cli 0.4.42 → 0.4.43

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -124,6 +124,7 @@ Operating rules:
124
124
  - The moment implementation is complete and you switch to verifying, write 90 to the progress file -- verification time must not read as stalled progress.
125
125
  - Do this one task completely, then stop. Do not expand scope.
126
126
  - 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.
127
+ - 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.)
127
128
  - 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.
128
129
  - 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}
129
130
  - If you are truly blocked, write the blocker to the notes file and stop rather than guessing wildly.
@@ -16,6 +16,7 @@ The deck is already serving when you start (`castle-web init` set that up; see `
16
16
 
17
17
  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.
18
18
  2. **After every edit:** `npm run restart` (no hot reload). The served page refreshes and the user sees the change.
19
+ 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).
19
20
 
20
21
  Card size is **500 wide × 700 tall** (origin top-left, +y is down).
21
22
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "castle-web-cli",
3
- "version": "0.4.42",
3
+ "version": "0.4.43",
4
4
  "type": "module",
5
5
  "bin": {
6
6
  "castle-web": "./dist/index.js"