crafting-loop · git:20260913.3c614b8 · 2026-09-13 · sha256 371b994f8a1e8b72
crafting-loop git:20260913.3c614b8A
Immutable. This exact content never changes and is served at /api/v1/blob/371b994f8a1e8b72.
--- name: crafting-loop description: Use when recipes, stations, fusion, cooking, schematics, or material transforms can consume the wrong inputs, grant twice, overflow inventory, hide requirements, or duplicate another progression system. --- # Crafting Loop This skill owns **recipe identity and the atomic transform from validated inputs to outputs**. `inventory-economy` owns containment/overflow, `equipment-progression` owns gear progression state, and `durability-economy` owns wear/repair condition. ## Modes | Mode | Transform context | |---|---| | hand-craft | direct recipe transform without a required station | | station-craft | recipe additionally requires an authored station/context | | fuse-two | authored input instances transform into an output | | cook-buff | ingredients transform into a consumable/timed result | | schematic-unlock | recipe availability depends on an authored unlock | Gathering, vendors, discovery and experimentation may support crafting, but none is universally required. A quest-specific recipe is valid when intentionally authored and recoverable. ## Recipe and transaction contract Every recipe has a stable recipe ID, version/schema, required input definitions/quantities, optional context requirements and declared output(s). Localized names are presentation, not save identity. Craft execution is one transaction: 1. validate recipe/version/context and all inputs; 2. reserve or atomically consume inputs; 3. create/update outputs exactly once; 4. hand outputs to `inventory-economy` using its overflow policy; 5. commit a stable transaction ID so retry/duplicate callbacks are idempotent. On failure or interruption, either nothing commits or a documented resumable state is restored. Never silently consume inputs with no output/evidence. Craft duration, queueing, walk-away behavior and station UI are project choices. Long-running jobs need inspectable state if they persist across scene/session boundaries. ## Acceptance Test exact resources, one-missing input, full inventory, duplicate submit/callback, interruption between consume/output, save/reload of a persistent job and recipe migration. Resource totals reconcile and one transaction ID produces at most one committed transform.