spawnpack 0.1.19 → 0.1.21

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "spawnpack",
-    "version": "0.1.19",
+    "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

@@ -1,20 +1,3 @@
-## Priorities
-
-1. Implement the user's requested behavior completely.
-2. Use the smallest maintainable change that fits existing project patterns.
-3. Verify the changed behavior with the least expensive reliable check.
-4. Preserve unrelated user work and avoid expanding scope.
-
-## Scope and execution
-
-- Read the relevant source, configuration, references, and callers before editing. For a bug, fix the shared root cause rather than one visible symptom.
-- Act immediately on small, clear tasks. Plan only when the approach is materially ambiguous, architectural, or risky.
-- Ask a question only when repository evidence and documentation cannot resolve choices with meaningfully different outcomes.
-- Do not add unrelated features, refactors, abstractions, dependencies, documentation, or cleanup.
-- Reuse existing helpers and patterns first, then the standard library or platform, then already-installed dependencies.
-- You may suggest a production dependency when it is the smallest suitable solution, but explain why and ask the user before adding it.
-- Keep changes local and migrate every affected caller. Remove obsolete code introduced by the changed path; do not leave compatibility shims unless requested.
-
 ## Documentation lookup
 
 - Before planning or implementing any Minecraft Bedrock change, verify the current relevant documentation. This includes Script API and BP/RP JSON formats, components, events, schemas, MoLang, manifests, commands, animations, and pack behavior.
@@ -22,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`.
@@ -31,17 +20,12 @@
 
 ## Code rules
 
-- Prefer boring, linear code, guard clauses, explicit state names, and one source of truth.
-- Do not build speculative flexibility. Avoid one-implementation interfaces, factories for one product, and helpers used once unless they materially clarify the code.
-- Preserve input validation, security boundaries, and protections against data loss, duplication, or invalid world state.
 - Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.
 - Validate predictable invalid states before calling an API. Use `try-catch` only for a documented or observed unguardable failure when the catch performs meaningful recovery, cleanup, translation, or contextual rethrow. Keep the `try` block narrow; never silently swallow errors.
-- Avoid repeated allocation, copying, logging, or exception handling in tick handlers and other hot paths.
-- Follow the existing TypeScript configuration and style. Do not introduce unused imports, variables, or exports.
 
 ## Minecraft Bedrock conventions
 
-- Check entity validity, optional components, and unloaded blocks with guards before use.
+- Guard before Script API calls that can throw: check `entity.isValid` (players are valid only while loaded) before `getComponent`/`getComponents`; confirm the chunk is loaded before `dimension.getBlock`/`spawnEntity`; and use containers only after re-fetching them from a current block or entity rather than holding a stale reference. Defer world-mutating work from read-only or early-execution callbacks with `system.run`. Reserve `try-catch` for calls whose validity cannot be checked in advance, such as `runCommand` throwing `CommandError`.
 - Prefer `@minecraft/vanilla-data` typed identifiers over raw component, entity, block, item, and effect strings.
 - Check `@minecraft/math` before writing vector, matrix, clamp, lerp, or similar math helpers.
 - Validate changed BP/RP JSON against the project's configured Bedrock schemas when available.
@@ -49,10 +33,10 @@
 
 ## 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.
-- Prefer validity and loaded-position guards over exception handling. Keep `try-catch` only at documented or observed unguardable boundaries, and require meaningful recovery; never use an empty catch as routine control flow.
+- 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.
 
 ## Repository hygiene
 
@@ -66,4 +50,3 @@
 
 - Be direct and concise. State assumptions only when they materially affect the implementation.
 - After changes, report what changed, the verification evidence, and any real blocker or residual risk. Do not add ritual sections for untouched files.
-- Never report completion with known errors in the changed path or imply that a check ran when it did not.

package/templates/CLAUDE.md

@@ -1,20 +1,3 @@
-## Priorities
-
-1. Implement the user's requested behavior completely.
-2. Use the smallest maintainable change that fits existing project patterns.
-3. Verify the changed behavior with the least expensive reliable check.
-4. Preserve unrelated user work and avoid expanding scope.
-
-## Scope and execution
-
-- Read the relevant source, configuration, references, and callers before editing. For a bug, fix the shared root cause rather than one visible symptom.
-- Act immediately on small, clear tasks. Plan only when the approach is materially ambiguous, architectural, or risky.
-- Ask a question only when repository evidence and documentation cannot resolve choices with meaningfully different outcomes.
-- Do not add unrelated features, refactors, abstractions, dependencies, documentation, or cleanup.
-- Reuse existing helpers and patterns first, then the standard library or platform, then already-installed dependencies.
-- You may suggest a production dependency when it is the smallest suitable solution, but explain why and ask the user before adding it.
-- Keep changes local and migrate every affected caller. Remove obsolete code introduced by the changed path; do not leave compatibility shims unless requested.
-
 ## Documentation lookup
 
 - Before planning or implementing any Minecraft Bedrock change, verify the current relevant documentation. This includes Script API and BP/RP JSON formats, components, events, schemas, MoLang, manifests, commands, animations, and pack behavior.
@@ -22,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`.
@@ -31,17 +20,12 @@
 
 ## Code rules
 
-- Prefer boring, linear code, guard clauses, explicit state names, and one source of truth.
-- Do not build speculative flexibility. Avoid one-implementation interfaces, factories for one product, and helpers used once unless they materially clarify the code.
-- Preserve input validation, security boundaries, and protections against data loss, duplication, or invalid world state.
 - Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.
 - Validate predictable invalid states before calling an API. Use `try-catch` only for a documented or observed unguardable failure when the catch performs meaningful recovery, cleanup, translation, or contextual rethrow. Keep the `try` block narrow; never silently swallow errors.
-- Avoid repeated allocation, copying, logging, or exception handling in tick handlers and other hot paths.
-- Follow the existing TypeScript configuration and style. Do not introduce unused imports, variables, or exports.
 
 ## Minecraft Bedrock conventions
 
-- Check entity validity, optional components, and unloaded blocks with guards before use.
+- Guard before Script API calls that can throw: check `entity.isValid` (players are valid only while loaded) before `getComponent`/`getComponents`; confirm the chunk is loaded before `dimension.getBlock`/`spawnEntity`; and use containers only after re-fetching them from a current block or entity rather than holding a stale reference. Defer world-mutating work from read-only or early-execution callbacks with `system.run`. Reserve `try-catch` for calls whose validity cannot be checked in advance, such as `runCommand` throwing `CommandError`.
 - Prefer `@minecraft/vanilla-data` typed identifiers over raw component, entity, block, item, and effect strings.
 - Check `@minecraft/math` before writing vector, matrix, clamp, lerp, or similar math helpers.
 - Validate changed BP/RP JSON against the project's configured Bedrock schemas when available.
@@ -49,10 +33,10 @@
 
 ## 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.
-- Prefer validity and loaded-position guards over exception handling. Keep `try-catch` only at documented or observed unguardable boundaries, and require meaningful recovery; never use an empty catch as routine control flow.
+- 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.
 
 ## Repository hygiene
 
@@ -66,4 +50,3 @@
 
 - Be direct and concise. State assumptions only when they materially affect the implementation.
 - After changes, report what changed, the verification evidence, and any real blocker or residual risk. Do not add ritual sections for untouched files.
-- Never report completion with known errors in the changed path or imply that a check ran when it did not.