spawnpack 0.1.17 → 0.1.19

package/package.json

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

package/templates/AGENTS.md

@@ -34,7 +34,7 @@
 - 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.
-- Use naming instead of explanatory comments. Add a short comment only for a non-obvious invariant, external constraint, or unavoidable workaround.
+- 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.
@@ -47,13 +47,20 @@
 - Validate changed BP/RP JSON against the project's configured Bedrock schemas when available.
 - In Regolith projects, inspect compilation output through `.regolith/tmp` without resolving its symlinks.
 
+## Performance preferences
+
+- Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
+- 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.
+
 ## Repository hygiene
 
 - Never discard, overwrite, or revert unrelated user changes.
 - Do not create repository files for agent memory, lessons, session notes, plans, or debugging logs.
 - Do not create or update documentation, changelogs, or generated artifacts unless requested or required by the changed contract.
 - Do not commit, push, publish, or delete unrelated files unless explicitly requested.
-- Commit messages, when requested, use a short natural subject and no AI attribution, tool attribution, or structured report trailers.
+- Commit messages, when requested, use short natural subjects without Conventional Commit prefixes, AI/tool attribution, or structured report trailers. Split unrelated logical changes into separate commits.
 
 ## Communication
 

package/templates/CLAUDE.md

@@ -34,7 +34,7 @@
 - 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.
-- Use naming instead of explanatory comments. Add a short comment only for a non-obvious invariant, external constraint, or unavoidable workaround.
+- 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.
@@ -47,13 +47,20 @@
 - Validate changed BP/RP JSON against the project's configured Bedrock schemas when available.
 - In Regolith projects, inspect compilation output through `.regolith/tmp` without resolving its symlinks.
 
+## Performance preferences
+
+- Prefer event-driven subscriptions over polling. Avoid per-tick held-item or inventory scans and repeated dynamic-property serialization.
+- 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.
+
 ## Repository hygiene
 
 - Never discard, overwrite, or revert unrelated user changes.
 - Do not create repository files for agent memory, lessons, session notes, plans, or debugging logs.
 - Do not create or update documentation, changelogs, or generated artifacts unless requested or required by the changed contract.
 - Do not commit, push, publish, or delete unrelated files unless explicitly requested.
-- Commit messages, when requested, use a short natural subject and no AI attribution, tool attribution, or structured report trailers.
+- Commit messages, when requested, use short natural subjects without Conventional Commit prefixes, AI/tool attribution, or structured report trailers. Split unrelated logical changes into separate commits.
 
 ## Communication