spawnpack 0.2.1 → 0.2.2

package/dist/spawnpack.js

@@ -1413,7 +1413,7 @@ function generateRpManifest(config, rpUuid, bpUuid, versions) {
 }
 
 // templates/AGENTS.md
-var AGENTS_default = "## Project layout\n\n- When the project has scripts, TypeScript source lives in `data/scripts/`: `main.ts` is the entry, `lib/` holds shared helpers imported as `~/lib/...`, and `modules/<feature>/` holds features imported by `main.ts`.\n- rgl builds the add-on from `config.json`: the `typegen` filter writes `data/scripts/generated_types.ts`, and the `rolldown` filter bundles `data/scripts/` into the exported behavior pack's `scripts/` folder. Never edit generated output by hand; edit the source or the filter.\n- Inspect build output through `.regolith/tmp` without resolving its symlinks.\n\n## Documentation lookup\n\n- Before relying on version-sensitive or unfamiliar Minecraft Bedrock behavior, verify the relevant current documentation for the project's target Minecraft and Script API versions and stable/preview status. This includes Script API, BP/RP JSON formats, components, events, schemas, MoLang, manifests, commands, animations, and pack behavior.\n- Prefer Bedrock-specific tools when the harness provides them, such as documentation search, Script API or component lookup, and vanilla examples. Otherwise use web search.\n- 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.\n- For other libraries, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.\n\n## Technical judgment\n\n- Do not assume the user or the agent is correct. Verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.\n- If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.\n- 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.\n\n## Verification\n\n- After TypeScript changes, run the project's `typecheck` script.\n- After BP/RP changes, validate the packs with the harness's pack validator or a Bedrock Dedicated Server load when available; otherwise check them against the project's configured Bedrock schemas.\n- Do not create or run tests unless the user asks or an existing repository policy requires them.\n- If a check is unavailable or fails for a pre-existing reason, say so plainly. Never claim a check you did not run.\n\n## Code rules\n\n- Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.\n- 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.\n\n## Minecraft Bedrock conventions\n\n- 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`.\n- Prefer `@minecraft/vanilla-data` typed identifiers over raw component, entity, block, item, and effect strings, and the generated `BlockId`/`EntityId`/`ItemId` enums for this add-on's own content.\n- Check `@minecraft/math` before writing vector, matrix, clamp, lerp, or similar math helpers.\n- Never reference another add-on's content IDs in data-driven JSON such as `minecraft:break_blocks`; Bedrock validates those IDs at pack load and errors when that add-on is absent. Handle optional cross-add-on content in scripts.\n\n## Performance preferences\n\n- 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. Poll only when no suitable event exists; then minimize the frequency, players, slots, and work performed.\n- 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.\n- Cache stable configuration in memory and persist only when values actually change.\n\n## Repository hygiene\n\n- Never discard, overwrite, or revert unrelated user changes.\n- Do not create repository files for agent memory, lessons, session notes, plans, or debugging logs.\n- Do not create or update documentation, changelogs, or generated artifacts unless requested or required by the changed contract.\n- Do not commit, push, publish, or delete unrelated files unless explicitly requested.\n- 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.\n\n## Communication\n\n- Be direct and concise. State assumptions only when they materially affect the implementation.\n- After changes, report what changed, the verification evidence, and any real blocker or residual risk. Do not add ritual sections for untouched files.\n";
+var AGENTS_default = "## Project layout\n\n- When the project has scripts, TypeScript source lives in `data/scripts/`: `main.ts` is the entry, `lib/` holds shared helpers imported as `~/lib/...`, and `modules/<feature>/` holds features imported by `main.ts`.\n- rgl builds the add-on from `config.json`: the `typegen` filter writes `data/scripts/generated_types.ts`, and the `rolldown` filter bundles `data/scripts/` into the exported behavior pack's `scripts/` folder. Never edit generated output by hand; edit the source or the filter.\n- Inspect build output through `.regolith/tmp` without resolving its symlinks.\n\n## Documentation lookup\n\n- Before relying on version-sensitive or unfamiliar Minecraft Bedrock behavior, verify the relevant current documentation for the project's target Minecraft and Script API versions and stable/preview status. This includes Script API, BP/RP JSON formats, components, events, schemas, MoLang, manifests, commands, animations, and pack behavior.\n- Prefer the sculkwire MCP tools when available (see Bedrock MCP tools). Otherwise use web search.\n- 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.\n- For other libraries, SDKs, APIs, and CLI tools, verify current official documentation before relying on unfamiliar or version-sensitive behavior.\n\n## Bedrock MCP tools\n\n- sculkwire covers Bedrock add-on facts and proof. Look up before writing content: `docs_search`, `api_lookup`, `component_lookup`, `command_lookup`, `molang_lookup`, `vanilla_example`, and `changelog_search`. Check `knowledge_versions` against the project's target versions before trusting a result.\n- After BP/RP edits, run sculkwire `validate_file` or `validate_pack` and fix every reported error by file and line. Use `bds_check` to confirm the packs load, and `bds_session_*` (including `bds_session_logs`) or `script_profile` when behavior or performance must be proven on a running server. Run `gametest_run` only under the test rule in Verification.\n- oxygen covers particle effect JSON. Use `reference` for components, Molang queries, and game rules; `create_effect` or `list_examples` to start; `edit_effect` for formatting-preserving edits, or `write_effect` when the file is not valid JSON or needs a full rewrite; `check_effect` after every change; `simulate_effect` and `preview_effect` to confirm particle counts, bounds, and appearance. Debug Molang with `trace_effect`, `inspect_effect`, or `evaluate_molang` instead of guessing.\n- Tools that launch, drive, or deploy into the user's Minecraft client (sculkwire `game_*`, `player_*`, `engine_*`; oxygen `game_*`, `open_in_editor`) run only when the user asks for in-game verification or to see the result.\n\n## Technical judgment\n\n- Do not assume the user or the agent is correct. Verify assumptions against current documentation, repository evidence, established patterns, or a working project sample.\n- If those sources do not resolve a choice that materially affects the result, ask the user for a reference, pattern, or sample project.\n- 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.\n\n## Verification\n\n- After TypeScript changes, run the project's `typecheck` script.\n- After BP/RP changes, validate the packs with sculkwire, another pack validator, or a Bedrock Dedicated Server load when available; otherwise check them against the project's configured Bedrock schemas.\n- Do not create or run tests unless the user asks or an existing repository policy requires them.\n- If a check is unavailable or fails for a pre-existing reason, say so plainly. Never claim a check you did not run.\n\n## Code rules\n\n- Do not write comments in code. Use clear naming and straightforward structure so the code is self-explanatory.\n- 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.\n\n## Minecraft Bedrock conventions\n\n- 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`.\n- Prefer `@minecraft/vanilla-data` typed identifiers over raw component, entity, block, item, and effect strings, and the generated `BlockId`/`EntityId`/`ItemId` enums for this add-on's own content.\n- Check `@minecraft/math` before writing vector, matrix, clamp, lerp, or similar math helpers.\n- Never reference another add-on's content IDs in data-driven JSON such as `minecraft:break_blocks`; Bedrock validates those IDs at pack load and errors when that add-on is absent. Handle optional cross-add-on content in scripts.\n\n## Performance preferences\n\n- 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. Poll only when no suitable event exists; then minimize the frequency, players, slots, and work performed.\n- 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.\n- Cache stable configuration in memory and persist only when values actually change.\n\n## Repository hygiene\n\n- Never discard, overwrite, or revert unrelated user changes.\n- Do not create repository files for agent memory, lessons, session notes, plans, or debugging logs.\n- Do not create or update documentation, changelogs, or generated artifacts unless requested or required by the changed contract.\n- Do not commit, push, publish, or delete unrelated files unless explicitly requested.\n- 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.\n\n## Communication\n\n- Be direct and concise. State assumptions only when they materially affect the implementation.\n- After changes, report what changed, the verification evidence, and any real blocker or residual risk. Do not add ritual sections for untouched files.\n";
 
 // templates/filters/typegen/main.js
 var main_default = `import { pascalCase } from "es-toolkit";

package/package.json

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