spawnpack 0.1.20 → 0.1.21

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "spawnpack",
-    "version": "0.1.20",
+    "version": "0.1.21",
     "description": "Minecraft Bedrock addon project generator — scaffold your BP+RP in seconds",
     "author": "veedy-dev",
     "license": "MIT",

package/templates/AGENTS.md

@@ -5,6 +5,12 @@
 - Prefer current Microsoft Creator documentation and versioned references on `bedrock.dev`. For Script API, also use `https://jaylydev.github.io/scriptapi-docs/latest/`. Use `wiki.bedrock.dev` for established concepts and proven implementation patterns. Confirm stable versus preview status and the target Minecraft version.
 - For other external libraries, frameworks, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.
 
+## Technical judgment
+
+- Do not assume the user or the agent is correct. Before implementing, verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.
+- If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.
+- If evidence shows the requested approach is incorrect, unsafe, incompatible, unnecessarily complex, or slower than a supported alternative, explain why and recommend the better implementation. Follow the user's final choice unless it violates safety or repository constraints.
+
 ## Verification
 
 - After TypeScript changes, run `tsc --noEmit`.
@@ -27,7 +33,7 @@
 
 ## Performance preferences
 
-- Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
+- Before adding `system.runInterval` polling, check the project's Script API version and current documentation for a matching event. Prefer the event when it provides the required data and timing, such as `PlayerInventoryItemChangeAfterEventSignal` instead of repeatedly scanning every player's inventory or hotbar for item changes. Poll only when no suitable event exists or the event cannot represent the required behavior; then minimize the polling frequency, players, slots, and work performed.
 - In hot loops, iterate maps directly with `for (const value of map.values())`. Do not spread maps into temporary arrays or iterate entry pairs when values or keys are enough.
 - Cache stable configuration in memory and persist only when values actually change.
 - Guard invalid states with conditions before they reach the API — unloaded chunks or locations, invalid or despawned entities, etc so Minecraft Bedrock does not throw. Guards are required wherever a state check is possible. Prefer guards over `try-catch`; `try-catch` is allowed only for documented or observed unguardable failures, and must perform meaningful recovery — never rely on it as routine control flow or swallow errors.

package/templates/CLAUDE.md

@@ -5,6 +5,12 @@
 - Prefer current Microsoft Creator documentation and versioned references on `bedrock.dev`. For Script API, also use `https://jaylydev.github.io/scriptapi-docs/latest/`. Use `wiki.bedrock.dev` for established concepts and proven implementation patterns. Confirm stable versus preview status and the target Minecraft version.
 - For other external libraries, frameworks, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.
 
+## Technical judgment
+
+- Do not assume the user or the agent is correct. Before implementing, verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.
+- If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.
+- If evidence shows the requested approach is incorrect, unsafe, incompatible, unnecessarily complex, or slower than a supported alternative, explain why and recommend the better implementation. Follow the user's final choice unless it violates safety or repository constraints.
+
 ## Verification
 
 - After TypeScript changes, run `tsc --noEmit`.
@@ -27,7 +33,7 @@
 
 ## Performance preferences
 
-- Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
+- Before adding `system.runInterval` polling, check the project's Script API version and current documentation for a matching event. Prefer the event when it provides the required data and timing, such as `PlayerInventoryItemChangeAfterEventSignal` instead of repeatedly scanning every player's inventory or hotbar for item changes. Poll only when no suitable event exists or the event cannot represent the required behavior; then minimize the polling frequency, players, slots, and work performed.
 - In hot loops, iterate maps directly with `for (const value of map.values())`. Do not spread maps into temporary arrays or iterate entry pairs when values or keys are enough.
 - Cache stable configuration in memory and persist only when values actually change.
 - Guard invalid states with conditions before they reach the API — unloaded chunks or locations, invalid or despawned entities, etc so Minecraft Bedrock does not throw. Guards are required wherever a state check is possible. Prefer guards over `try-catch`; `try-catch` is allowed only for documented or observed unguardable failures, and must perform meaningful recovery — never rely on it as routine control flow or swallow errors.