death-carry ยท diff
git:20260912.82c0b84 to git:20260913.d954cc7
27 added, 6 removed. Audit A to A.
---
name: death-carry
- description: Generic death penalty. What you keep, what you drop, where you wake.
+ description: Use when a death/defeat transition must define what state is kept, transformed, dropped or reset and where recovery resumes without conflating presentation, checkpointing or run rules.
---
# Death carry
- Ask: checkpoint-full | drop-bag | run-reset | none.
- Wake point is save-checkpoint or rest-site. Unlocks do not flip.
- Drop-bag is a world pickup with a lifetime. Run-reset is a roguelike column, not an action-game surprise.
- Death music does not stack.
+ Ask the policy: keep-all, partial-carry, recoverable-drop, run-reset, custom, or existing.
- Accept: a player can say what they lost and where they woke. A death does not mark a boss beaten.
+ ## Contract
+
+ Publish:
+ - stable `death_policy_id` and revision
+ - stable `death_event_id`
+ - carry/reset/drop manifest by stable state ID
+ - respawn/checkpoint source
+ - `drop/recovery record` identity when recovery exists
+ - commit boundary and retry behavior
+
+ ## Ownership
+
+ `death-carry` owns state transformation caused by the death event. `save-checkpoint` selects recovery anchors, `roguelike-run` owns run lifecycle, inventory/economy owns item/currency transactions, and presentation owns audio/VFX.
+
+ ## Rules
+
+ 1. Each `death_event_id` settles exactly once; retries/resume cannot duplicate drops, grants or resets.
+ 2. Carry/reset policy is versioned project data, not tied to one genre.
+ 3. Recovery records persist or expire according to explicit policy and never depend on display labels or render objects.
+ 4. A death transition cannot mark unrelated quest/boss/run completion unless that owner emitted the corresponding event.
+ 5. Save commit failures leave an inspectable pending/retry state rather than half-applying the carry manifest.
+
+ ## Acceptance
+
+ Given one death event, policy revision and starting state, the same carry/reset/drop result is committed exactly once and the reviewer can identify the recovery anchor, recovery record and any pending persistence work.