# Aetherbound Guild - Gameplay, Battle, Economy And Save Complete gameplay rules, deterministic battle, progression, economy, pacing, failure, persistence and recovery. ## Owner Review / Owner 审核 重点确认招募、自动排阵、战斗、击倒与下关恢复、装备、持续成长、经济、难度、失败与存档规则。这里回答“每一步怎么玩、怎么算、输赢后发生什么”。 本文件是当前六份审核文档之一。历史拆分文件仅保留在 Git 历史中；文内规则、表格和 ID 仍是完整开发依据。 ## P0 Consolidation Role This document is the systems authority inside the consolidated project contract. It defines what each recurring decision changes, which state owns the result, how Coin/XP/Equipment/Company/Contract values persist, and how failure, recovery and Save receipts behave. It does not define page layout or art treatment; those belong to `03_PAGES_AND_UX.md` and `04_ART_ANIMATION_AUDIO.md`. ## 2026-08-17 Continuous-Growth Owner Override This override is the current authority everywhere this file conflicts with the older FG-4 implementation model below: - one Guild save owns one persistent Expedition Company across Contract runs; - New Game creates exactly four stable provisional offers and commits exactly two of them once as the initial persistent roster; - a zero-HP Recruit is knocked out for the current battle, remains owned and is battle-ready again for the next stage with the same identity and growth; - Contract clear or withdrawal closes only Contract-local progress, formation, encounter and temporary-effect state, then returns to the Guild; and - death-funded Replacement Credit, Company-collapse roster deletion, Recruit archiving and loss of levels/XP/equipment at Contract close are superseded. The exact next-stage HP amount is intentionally frozen for the later balance conversion. DEV-2 guarantees persistent ownership and next-stage availability; it must not invent a full-heal rule or permanent casualty. The older sections that still name `Fallen`, `Replacement Credit`, `run_creation_draft`, short-lived `current_run` Recruits, Company collapse or roster archiving are `FROZEN_LEGACY_FG4` evidence. Their deterministic battle, economy and Save-v11 details remain preserved until the named later player-order conversion, but those conflicting lifecycle effects are not current product authority. Battle-local `Fallen` event/code identifiers may temporarily remain as implementation names only; product-facing meaning is `Knocked Out` and never permanent roster removal. For DEV-2, the current persistence boundary is: ```text Guild_slot initial_company_draft or null expedition_company or null initial_company_draft draft_id, seed, status, source_revision offers[0..3], offer_set_hash selected_offer_ids[0..2], selection_revision expedition_company company_id, created_from_draft_id owned_recruits[2..], reserve_recruit_ids[] persistent inventory, Coin, levels, XP, Professions, Traits and history active_contract or null ``` An uncommitted draft and a committed initial Company are mutually exclusive. The same saved seed always produces the same four IDs in the same positions. Selection may contain zero, one or two distinct offer IDs; only exactly two can enter review. Commit atomically removes the draft, writes one Company containing only the selected two Recruit records and stores an idempotent receipt. A retry returns that receipt and never creates a second Company or rerolls the offers. ## Aetherbound Guild: Systems And Battle Authority > Authority: generated-Recruit state, Profession grammar, Market/run handoffs, > ordered Party-line geometry, deterministic auto-battle, equipment and Artifact > hooks, targeting, movement, knockout, recovery, and causal diagnosis. > > Revision: recruit-line-design-r2 / 2026-08-10 > > Product intent is defined in > [01_GAME_DESIGN.md](01_GAME_DESIGN.md). Prices, rewards, > progression rates, capacity selection, and pacing are defined in > [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md). Durable commit and recovery > semantics are defined in > [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md). ### 1. System Invariants 1. Each side occupies one ordered horizontal line. Position zero is front; a larger position is farther rearward. There is no second spatial axis. 2. Allied simultaneous footprint begins at four and reaches ten. Reserve and cumulative hires are separate and never redefine this limit. 3. Battle is automatic. The player may start, pause, change speed, inspect, or retreat, but cannot activate attacks/skills, reorder, equip, or promote while resolving. 4. A Recruit has one generated identity, one current fixed Profession, five rolled attributes from an equal level budget, exactly one Trait, equipment, level, and survival history. 5. Zero HP means Knocked Out. The Recruit leaves the resolving line immediately, never respawns in that battle, and is never replaced by Reserve during that battle. The Recruit remains in the persistent Expedition Company and is battle-ready again for the next stage with equipment and growth unchanged. 6. The same start state, ruleset, content revision, seed, and retreat timestamp produces the same state hashes and result. 7. Display frame rate and pause/1x/2x/4x do not change simulation time or draws. 8. Every targeting exception, failed action, movement conflict, retarget, immunity, proc suppression, and outcome has one inspectable reason. 9. All damage has a declared type, power source, defense, rounding boundary, critical rule, modifier groups, and floor/nullification behavior. 10. No standard battle exceeds 150 simulation seconds. ### 2. Authoritative State Model ```text profile settings, accessibility, language, input mappings Renown, unlock breadth, Region/Contract progress, Records, collection facts persistent Expedition Company, inventory, Coin and Recruit growth Contract expedition contract_run_id, contract_id, difficulty_id, ruleset_version, content_revision generation_seed, Market index, cleared Rounds, Line capacity route, refresh/lock counters, deployed formation, temporary Artifacts knockout events, boss state, Contract result Recruit recruit_id, generated_name_parts, rendered_name_snapshot, appearance_seed origin_profession_id, current_profession_id, promotion_state level, xp, five base attributes, Trait id equipped_item_id or null, effective stats, battles entered, victories, hire receipt encounter encounter_id, battle_offer_id, root_seed, phase, tick ordered allied/enemy actor sequences and footprints HP, resources, readiness, cooldowns, casts, statuses, barriers event queue, draw counters, retreat state, objective, outcome, event journal presentation only camera, interpolation, animation frame, particles, selected inspector, expanded tooltip, pointer, audio playback cursor ``` Presentation never authors state. Battle arithmetic uses signed 64-bit integer fixed point with 100 units per displayed point. Percentages use basis points (`10,000 = 100%`). A formula rounds only where this document says `floor`, `ceil`, or `round_half_up`. ### 3. Run And Market State Machine ```text Contract_created -> Market_open -> battle_offer_committed -> countdown -> resolving -> outcome_locked -> diagnosis -> reward_or_failure_applied -> next_Market | boss_Muster | Contract_return_to_Guild ``` The Market snapshot contains three Recruit offers, four equipment offers, and three battle offers. Offer generation, prices, locks, and refreshes are owned by the economy authority. This document owns these system rules: - leaving and reopening a Market preserves all offer IDs and generated values; - buying removes exactly that offer and never silently fills the empty slot; - locked unbought offers persist to the next Market as declared; - equipment, order, promotion, and dismissal are legal only while Market is open or during boss Muster; - battle commit stores an immutable deployed lineup, inventory ownership, effective-stat snapshot, enemy lineup, seed, risk, and result rules; - no Market edit after commit can affect that encounter; - result inspection never applies or skips a reward operation. ### 4. Generated Recruit Contract #### 4.1 Generation Recruit generation uses labeled deterministic streams so a name draw cannot change attributes or Trait: ```text recruit_name, recruit_appearance, recruit_profession, recruit_attributes, recruit_trait ``` For offer level `L` from 1 through 10: ```text attribute_budget(L) = 30 + 5*L attribute_floor(L) = 3 + L attribute_cap(L) = 12 + 3*L ``` `Might + Finesse + Insight + Vigor + Resolve` equals the exact budget. Every attribute stays within floor/cap. The generator first assigns the floor to all five, then distributes the remaining points one at a time by the labeled stream without exceeding cap. Because totals are equal at a level, no Recruit is strictly superior only because its random total is larger. Every Recruit row stores its inputs and output hash. Generated name components and modular visual parts create identity and readable variation but no hidden mechanical modifier. #### 4.2 Trait Each Recruit receives exactly one of 36 authored Traits. A Trait row has one visible benefit and one visible cost, both mechanical. It cannot be removed, stacked, upgraded, rerolled, or suppressed by changing language or appearance. A Trait is invalid if its cost never changes a decision in either of its two fixed fixtures, or if its benefit is only a larger unconditional value. Trait tags may participate in hidden-hybrid eligibility only when that condition is shown after discovery. #### 4.3 Survival History The persistent Recruit records battles entered, victories, retreats survived, allies ahead at commit, first knocked-out ally witnessed, promotion, knockout events and final dismissal if any. History may unlock a title or catalog fact but cannot grant a hidden stat. Contract close adds an immutable summary Record without making that Recruit unplayable or replacing its stable ID. ### 5. Profession Catalog And Promotion The fixed catalog contains 12 base, 24 regular advanced, and 6 hidden hybrid Professions. Content owns identities and instances; this document owns schema and topology. #### 5.1 Topology - Every base Profession has exactly two regular advanced descendants. - Every regular advanced Profession has exactly one parent base. - Every hidden hybrid declares exactly two compatible base-family IDs and an original battlefield responsibility distinct from both parents. - A Recruit has exactly one current Profession. Equipment never changes the stored Profession ID. - A Recruit's origin base is immutable even after promotion. #### 5.2 Promotion A base Recruit becomes eligible after reaching level 4 and surviving three completed battles. Promotion is one-way and can happen once. The Market review shows new action rules, lost rules, target/reach changes, resource loop, price or opportunity cost, and the two validation fixtures before confirm. The two regular descendants are always deterministic choices once eligible. A hidden hybrid appears as an additional choice only when its revealed catalog predicate is satisfied. Allowed predicate inputs are origin base, Trait tags, equipped behavior tags, current Artifact tags, adjacent deployed Profession families, and cleared Contract facts. A predicate cannot read generated name, appearance, playtime, wall clock, or social state. Promotion preserves that Recruit's individual level and XP, HP percentage outside battle, Trait, equipped item, survival history, and recruit ID. It replaces current Profession, action table, resource meter, and derived Profession bases atomically. It is not a free job switch or reversible respec. #### 5.3 Automatic Action Unlocks A Profession action kit unlocks by that Recruit's individual level. Levels are bounded to `1..10`; there is no Company level and another Recruit's XP cannot unlock these rules: | Recruit level | Available automatic rules | |---:|---| | 1 | basic action, resource rule, identity passive | | 2 | first technique and its priority row | | 3 | second technique and its priority row | | 4 | signature and its priority row; promotion becomes possible after the survival requirement | Promoting replaces the action kit with the promoted Profession's level-valid kit. A direct regular-advanced hire uses the same level schedule. Falling below an unlock level is impossible, and equipment cannot unlock a later action early. Every unlocked action is automatic; the player prepares through hire, equipment, deployment, and order rather than selecting it during battle. #### 5.4 Profession Row ```text profession_id, tier (base | regular_advanced | hidden_hybrid) parent_base_ids, unlock/promotion predicate battlefield responsibility, preferred depth, failure mode, counter tags base HP, base Tempo, base defenses, resource schema basic action, two techniques, signature, passives automatic priority table and target policies movement/reach/protection/projectile/healing rules two decision-opposed validation fixtures presentation and accessibility event requirements ``` An advanced or hidden Profession must transform target, timing, position, resource flow, protection, or risk ownership. A stronger scalar copy fails. ### 6. Party-Line Geometry #### 6.1 Ordered Footprint Each actor declares footprint 1 or 2. Standard Recruits use footprint 1. An actor with footprint 2 is one unit ID, one HP pool, and one action state occupying a contiguous block. The authoritative line is an ordered actor sequence with no interior empty space after normalization. For actor `A`: ```text depth(A) = sum(footprint(X) for every living actor X ahead of A) front_cell(A) = depth(A) rear_cell(A) = depth(A) + footprint(A) - 1 ``` Allied deployed footprint cannot exceed current Line capacity. Recruits left out of the sequence are Reserve. Order ties and simultaneous insertion use stable actor ID only after all player-visible rules are equal. #### 6.2 Cross-Line Distance And Same-Line Distance For opposing source `S` and target `T`: ```text cross_line_distance(S,T) = 1 + depth(S) + depth(T) ``` For allied actors: ```text same_line_distance(S,T) = max(0, max(front_cell(S), front_cell(T)) - min(rear_cell(S), rear_cell(T)) - 1) ``` Adjacent footprints therefore have same-line distance zero. Every action declares a maximum cross-line or same-line reach. No visual closeness overrides the integer distance. #### 6.3 Protection ```text protection_stacks(T) = min(2, depth(T)) ``` Each occupied footprint ahead contributes one stack up to two. Protection is not a generic defense stat; actions use one declared mode: | Mode | Rule | |---|---| | `frontbound` | Only targets with `depth=0` are candidates | | `screened` | Deeper targets may be candidates, but resolved damage is multiplied by `max(0.70, 1 - 0.15*protection_stacks)` | | `intercepted_projectile` | Projectile collides with the first eligible footprint in its current path | | `lobbed` | Ignores collision but uses screened damage | | `bypass_protection` | Ignores stacks; must be declared in preview and telegraph | Healing and boons do not gain a hidden bonus from protection. The inspect view shows stacks, contributing actors, target legality, and expected multiplier. ### 7. Encounter Lifecycle | Phase | Legal player actions | Commit behavior | |---|---|---| | Preview | Inspect enemy order, actions, risk, reward, timeout, retreat | Offer is stable; no spend | | Prepare | Equip, promote, dismiss, deploy, reorder | Changes remain reversible until battle confirm | | Countdown | Pause, speed, inspect | Three simulation seconds; lineup locked | | Resolve | Pause, speed, inspect, retreat | Automatic action events and retreat timestamp journaled | | Outcome locked | Inspect | Victory, defeat, timeout, or retreat cannot change | | Diagnose | Inspect causal timeline | No reward applied by viewing/skipping | | Settle | Choose fixed reward if eligible | One atomic result operation | | Finalized | Continue to Market/run result | Casualties, equipment return, Coin/Credit, and reward agree | ### 8. Deterministic Time, Events, And Draws #### 8.1 Fixed Tick And Priority One simulation tick is exactly 100 milliseconds. At each tick: 1. accept lifecycle control stamped for this tick, including retreat start; 2. expire statuses and barriers whose end tick equals this tick; 3. resolve periodic status events due this tick; 4. complete casts, channels, projectile arrivals, and summon expiries; 5. select actions for actors already ready and legal; 6. resolve voluntary and forced movement intents; 7. apply simultaneous damage, healing, barrier, and resource deltas by batch; 8. finalize action-outcome records, mark zero-HP actors Fallen, and run declared outcome/death triggers once; 9. compact lines, insert legal summons, and evaluate objective/retreat/phase; 10. advance readiness, cooldown, cast, status, timeout, and retreat clocks. Events in the same numeric batch read one pre-batch state and apply together. An actor alive at batch start completes its already-scheduled event even if the same batch makes it Fallen. A death trigger cannot restore the source above zero HP and cannot recursively produce another death trigger in the same tick. An outcome-triggered derived action is queued no earlier than priority 4 of the next tick; it cannot join or reopen the batch that produced its outcome. #### 8.2 Labeled Determinism The encounter root seed supplies independent labels: ```text target_tie, critical, status_apply, proc_choice, summon_variant, reward ``` For a draw: ```text roll_bp = hash64(root_seed, label, actor_id, action_sequence, target_id, draw_index) mod 10,000 ``` The event journal records label and draw index. Adding an equipment proc cannot shift target, critical, status, or reward results in another stream. There is no random damage variance or hidden miss chance. ### 9. Attributes And Derived Statistics | Attribute | Primary responsibility | |---|---| | Might | physical power and Guard contribution | | Finesse | Tempo, physical precision, and critical pressure | | Insight | arcane power and status Potency | | Vigor | maximum HP, Guard, and movement stability | | Resolve | healing power, Ward, and status Tenacity | At level `L`: ```text PhysicalPower = WeaponPower + 2.00*Might + 0.50*Finesse ArcanePower = FocusPower + 2.00*Insight + 0.50*Resolve HealingPower = FocusPower + 1.20*Insight + 1.20*Resolve MaxHP = ProfessionBaseHP + 8*L + 10*Vigor Guard = ArmorGuard + 1.20*Vigor + 0.60*Might Ward = ArmorWard + 1.20*Resolve + 0.60*Insight Potency = Insight + 0.50*Finesse + FlatPotency Tenacity = Resolve + 0.50*Vigor + FlatTenacity Tempo = clamp(ProfessionBaseTempo + 0.40*Finesse + FlatTempo, 20, 100) Initiative = clamp(ProfessionBaseInitiative + 0.25*Finesse + FlatInitiative, 0, 95) ``` Derived values round down to 1/100 after the full expression. Profession bases must stay within `BaseHP 140-420`, `BaseTempo 24-55`, and `BaseInitiative 0-45` unless a fixed exception fixture is approved. A MaxHP change outside battle preserves current HP percentage and does not heal. ### 10. Readiness And Automatic Action Selection At battle start, `Readiness = Initiative`. Each tick while an actor can act: ```text Readiness = min(150, Readiness + Tempo*0.1) ``` At `Readiness >= 100`, the actor scans its Profession priority rows from top to bottom. The first row with a legal action, true visible condition, and legal target starts. It subtracts 100 Readiness and retains overflow. If none is legal, readiness remains capped and the actor checks again next tick. Priority conditions may read only current HP bands, resource, status, casts, depth, protection, ally/enemy counts, summon space, cooldown, phase, and preview tags. They cannot read future draws. Every Profession has a legal fallback or an explicit `NO_REACHABLE_TARGET` idle result. | Timing field | Boundary | |---|---| | Wind-up | 0.1-1.5 s | | Major telegraph | at least 1.5 s; first boss use at least 2.5 s | | Channel/cast | 0.3-4.0 s | | Recovery | 0-2.0 s | | Cooldown | 0-30 s | The automatic table is part of Profession identity. Players compare it but do not script arbitrary condition programs. ### 11. Target Selection, Reach, And Retarget An action constructs candidates in this order: 1. required side and living/Fallen/summon state; 2. cross-line or same-line reach; 3. protection mode; 4. required status, cast, HP band, or tag; 5. exclusion, immunity, and maximum targets; 6. target policy. Core target policies are `frontmost`, `rearmost`, `lowest_hp_ratio`, `highest_power`, `active_cast`, `marked`, and `self`. Numeric ties use depth in the policy's natural direction, then `target_tie`. The default hostile policy is frontmost. Enemy-specific score tables must be shown in preview when they can select something other than the declared policy result. At action start the target unit ID is reserved. At completion, the action uses one declared invalid-target policy: - `retarget_same_policy`: rebuild candidates and choose again; - `fizzle`: apply no primary effect and use the stated cooldown refund; - `ground_resolve`: resolve at the stored depth and affect current occupants. A target moving to another depth remains the same target if still legal. Every retarget or fizzle logs the first rejecting filter. #### 11.1 Forecast Is Not Resolution A forecast is a diagnostic prediction made from the committed preview or the state at automatic action selection. It stores predicted target IDs, depth, timing, and the rules that could change them. It never reserves a target and never fires a battle trigger. At action start, target selection creates the authoritative reservation. If its target differs from forecast because an earlier action, movement, collapse, or status changed state, the journal records `FORECAST_DIVERGED` with the first changed input. That is not a hit, miss, dodge, resistance, or action outcome. The reserved action then resolves normally. Likewise, if a reserved target moves before completion but remains targetable and inside all declared reach/protection filters, the action follows the same unit ID. Its terminal component outcome can be `AO_APPLIED`; the detail reason is `TARGET_MOVED_STILL_LEGAL`. Movement alone never creates an avoidance roll. #### 11.2 Terminal Outcome IDs Every started action produces one or more terminal outcome records. Records are per effect component and actual recipient; routing/invalidity records can name the intended target, and action-level cancellation records have no recipient. An area or multi-component action can therefore produce mixed outcomes without collapsing them into an invented accuracy value. | Outcome ID | Exact precondition | Ordering point | Player-visible causal label | |---|---|---|---| | `AO_APPLIED` | Legal component changes HP, barrier, status, resource, order, or another declared authoritative field on its actual recipient | Finalized after priority-7 deltas | `Applied`; use `Followed target` detail for `TARGET_MOVED_STILL_LEGAL` | | `AO_NO_CHANGE` | Component reaches a legal recipient but caps/current state yield zero primary change | Finalized after priority-7 deltas | `No change` plus cap/current-state reason | | `AO_INVALID_REACH` | Reserved target is living/targetable but current reach or protection filter is illegal | Completion validation at priority 4 | `Out of reach` plus old/current depth and required reach | | `AO_INVALID_UNTARGETABLE` | Reserved target is living but a declared Untargetable rule excludes it | Completion validation at priority 4 | `Untargetable` plus rule ID and remaining duration | | `AO_INVALID_FALLEN` | Reserved target is absent from the living line because it became Fallen before completion | Completion validation at priority 4 | `Target already Fallen` plus death event ID | | `AO_INVALID_FILTER` | Reserved target fails another declared side/state/tag candidate filter after the three specific invalid checks | Completion validation at priority 4 | `Target no longer eligible` plus filter ID | | `AO_INTERCEPTED` | Current projectile/protection path deterministically redirects the intended target's component to an eligible interceptor | Routing after target validation at priority 4 | `Intercepted by {actor}` plus path/protection rule ID | | `AO_BLOCKED` | An explicit Block charge or named deterministic component blocker nullifies the component before its primary delta | Defense allocation at priority 4; charge/delta commits in priority 7 | `Blocked` plus blocker actor/rule ID | | `AO_IMMUNE` | A declared immunity tag fully rejects the component before any resistance draw | Component defense at priority 4 | `Immune` plus immunity tag/source ID | | `AO_RESISTED` | A resistible status component is not immune and its stored `status_apply` roll is at/above `ApplyChanceBp` | Component defense at priority 4 | `Resisted` plus roll, threshold, Potency, and Tenacity | | `AO_FIZZLED` | Invalid-target policy is `fizzle`, retarget finds no legal candidate, or ground resolution has no eligible occupant | After invalid-target policy at priority 4 | `Action fizzled` plus invalid outcome/filter and refund | | `AO_INTERRUPTED` | A started wind-up/channel is cancelled by a declared interrupt before completion | When interrupt commits at priority 4 | `Interrupted` plus interrupter/rule and refund | `AO_BLOCKED` is not generic zero damage: barrier absorption is `AO_APPLIED` because barrier state changes. `AO_IMMUNE` requires a named immunity. A legal heal into full HP is `AO_NO_CHANGE`, not resistance. `AO_RESISTED` is limited to the existing deterministic status-application check and never implies an accuracy/evasion stat or a general attack miss. An action summary is derived only for display: ```text APPLIED_ALL = every primary component record is AO_APPLIED APPLIED_PARTIAL = at least one primary component is AO_APPLIED and at least one is not APPLIED_NONE = no primary component is AO_APPLIED ``` Summary values are not trigger IDs. The terminal records remain authoritative. #### 11.3 Resolution And Routing Order At priority 4, each completing action uses this order: 1. If a committed interrupt already cancelled the action, emit one `AO_INTERRUPTED` action record and stop. 2. Revalidate each reserved target against current state in this first-failure order: Fallen/absent, Untargetable, other declared candidate filter, then reach/protection. Emit the corresponding `AO_INVALID_*` reservation record. 3. Apply the skill's declared invalid-target policy. A successful `retarget_same_policy` reserves a new target and continues without refund; `ground_resolve` snapshots eligible current occupants at the stored depth; otherwise emit `AO_FIZZLED` and stop that action. 4. Resolve current projectile/protection paths. Emit `AO_INTERCEPTED` for each redirected intended target, then create component records for the actual interceptor. Interception itself never counts as an applied component. 5. Expand components and area recipients in current depth then stable-ID order. A footprint-2 actor is expanded once unless the skill explicitly says once per footprint. 6. Allocate finite Block charges and deterministic blockers. Same-tick claims use completion tick, target depth, source stable ID, then action sequence; one charge cannot block two components. Emit `AO_BLOCKED` for each allocation. 7. Check declared immunity before consuming a resistance or critical draw. Emit `AO_IMMUNE` on rejection. 8. For remaining resistible status components, consume and record exactly one `status_apply` draw. Emit `AO_RESISTED` when the roll fails the threshold. 9. Queue remaining numeric/status/movement deltas for priority 7. After the simultaneous batch, emit `AO_APPLIED` when primary state changed or `AO_NO_CHANGE` when it did not. 10. At priority 8, derive the action summary, apply at most one declared refund, claim outcome triggers, log suppressed duplicates, and queue derived actions for the next tick. An invalid reservation record remains terminal evidence even when retarget or ground resolution continues. The redirected/new recipient receives its own terminal component record, so diagnosis can say both why the original target was not affected and what actually happened. #### 11.4 Journal, Refund, And Proc Contract Every outcome record stores: ```text root_action_id, action_instance_id, action_sequence, skill_id, source_id selection_tick, completion_tick, effect_component_id, component_tags forecast_target_ids, reserved_target_id, reserved_depth actual_recipient_id, current_depth, outcome_id, reason_id retarget_policy, resolution_disposition, redirected_action_or_component_id interceptor_id, blocker_id, immunity_tag as applicable roll_label, draw_index, roll_bp, threshold_bp as applicable raw_delta, effective_delta, barrier_delta, status_or_movement_delta resource_spent, cooldown_committed, refund_resource, refund_cooldown_ticks trigger_claim_keys, fired_trigger_ids, suppressed_trigger_ids parent_action_id, derived_depth ``` Resource cost, Readiness, and cooldown are committed when the action starts. Default refund/proc behavior is: | Outcome/disposition | Default refund | Primary effect procs | |---|---|---| | Invalid record followed by successful retarget/ground resolution | none | evaluate only the new actual recipient's component outcomes | | `AO_FIZZLED` | skill's declared `fizzle_resource_refund_bp` and `fizzle_cooldown_refund_bp` | no on-hit/on-damage/on-heal/on-status proc | | `AO_INTERRUPTED` | skill's declared interrupt refund fields | `on_interrupt` and matching `on_outcome` only | | `AO_INTERCEPTED` | none | intended target can observe `AO_INTERCEPTED`; primary procs evaluate on actual recipient only | | `AO_BLOCKED`, `AO_IMMUNE`, `AO_RESISTED` | none unless exact ID appears in `refund_on_outcome_ids` | matching defensive hook and `on_outcome` only; no primary effect proc | | `AO_NO_CHANGE` | none | `on_outcome` only; no effective-delta proc | | `AO_APPLIED` | none | only hooks whose required effective delta/status/movement actually occurred | An outcome refund is evaluated once per root action after every component record is final. The skill declares `refund_match = all_primary | any_primary`; default is `all_primary`. Refund totals clamp to the originally committed cost/cooldown and never multiply by targets, components, or repeated outcome records. Outcome triggers use: ```text trigger_id, observed_role (source | intended_target | actual_recipient) outcome_ids[], component_tags[], once_scope (action | recipient | component) allow_derived (default false), resulting_action_or_hook ``` Default `once_scope` is `action`. Before firing, create: ```text trigger_claim_key = hash(root_action_id, trigger_id, scope_recipient_or_component) ``` The first claim fires in outcome-record order; later identical claims log `DUPLICATE_TRIGGER_CLAIM` and do nothing. Derived actions keep the same `root_action_id`, increment `derived_depth`, and cannot trigger a row with `allow_derived=false`. No derived chain can exceed depth 4 or the hook's declared per-action cap. ### 12. Projectile And Area Resolution A projectile declares speed in footprints per second, collision mode, pierce count, and damage retention. At launch: ```text arrival_ticks = max(1, ceil(cross_line_distance / projectile_speed / 0.1)) ``` At arrival, an intercepted projectile traverses the **current** opposing order from front to its reserved target and collides with the first eligible actor. After each pierced actor, remaining damage is multiplied by the declared retention in `0.50-0.90`. A reserved target that moved behind a new protector can therefore be intercepted. Lobbed and bypassing projectiles follow their declared protection mode instead. Areas are contiguous footprint intervals, not visual circles. An area row declares start policy, length, falloff, and whether a footprint-2 actor is hit once or once per footprint; default is once per actor. ### 13. Healing, Support, And Protection Access Support actions use same-line distance. Default heal selection is lowest HP ratio among legal allies; exact ratio ties choose the frontmost, then `target_tie`. A heal cannot pass its declared same-line reach because the animation appears to span the line. Barrier applies after healing in the same batch and is capped at 40% of target MaxHP across all generic barriers. Excess is logged as waste. `Block` is an explicit charge that nullifies one eligible hit after interception and before barrier. Area, true, or `unblockable` events must declare ineligibility. Protection stacks do not redirect heals. A support Profession may explicitly target `nearest_ally_ahead`, `nearest_ally_behind`, or a contiguous interval; the predicted support path updates when order changes. ### 14. Movement, Push, Pull, And Summons #### 14.1 Reordering Actions Battle movement is an automatic action, never free dragging: - `advance`: swap the actor block with the adjacent actor block ahead; - `withdraw`: swap with the adjacent actor block behind; - `push N`: move the target toward rear through up to `N` adjacent block swaps; - `pull N`: move the target toward front through up to `N` swaps; - `insert`: add a legal summon before/after its source; - `return`: remove a temporary summon or restore an explicitly stored order. Footprint-2 actors move as indivisible blocks. Simultaneous conflicting intents resolve larger declared movement priority first, then higher source Potency, then stable source ID. Losing intents fail with `DESTINATION_RESERVED`. Forced movement stops before an `Immovable` actor. Each unresolved forced step at a line boundary or blocker deals: ```text collision_damage = max(1, floor(0.08 * source_PhysicalPower)) ``` once per action, not once per blocked step. `Rooted` blocks voluntary movement; `Immovable` blocks forced movement. Rejections name `ROOTED`, `IMMOVABLE`, `NO_ADJACENT_ACTOR`, `DESTINATION_RESERVED`, or `CAST_LOCKED`. #### 14.2 Summon Footprint Each side has temporary summon allowance of two footprint beyond its committed deployment. A summon declares footprint 1 or 2 and insertion side relative to its source. It is legal only when: ```text current_living_footprint + summon_footprint <= committed_deployment_footprint + 2 ``` A failed insertion spends no summon resource and returns `NO_SUMMON_SPACE`. Summons never enter Reserve, hold equipment, create Replacement Credit, count as cumulative hires, or persist after battle. #### 14.3 Death Collapse After every death batch, Fallen actors are removed and both lines compact while preserving the relative order of survivors. New depths become authoritative before summon insertion and objective checks at priority 9. A scheduled action that reserved a Fallen target follows its retarget policy; it does not target the actor that happened to collapse into the old depth unless it uses `ground_resolve`. Reserve Recruits never fill a collapsed position during battle. At the next Market the player explicitly chooses any replacement and new order. ### 15. Damage, Critical, Healing, And Floors #### 15.1 Damage Skills declare `Base`, `Coefficient`, `PowerSource`, type, pierce, protection mode, and whether critical is legal. ```text RawDamage = max(0, Base + Coefficient * selected_power) EffectiveDefense = clamp(relevant_defense - pierce, -75, 500) if EffectiveDefense >= 0: DefenseMultiplier = 100 / (100 + EffectiveDefense) else: DefenseMultiplier = 2 - 100 / (100 - EffectiveDefense) CritChanceBp = clamp(skill_base_crit_bp + 20*(source_Finesse - target_Resolve) + explicit_crit_bp, 0, 5000) crit = can_crit and critical_roll_bp < CritChanceBp CritMultiplier = clamp(declared_crit_multiplier, 1.25, 2.00) if crit else 1.00 OutgoingGroup = clamp(1 + sum(outgoing_modifiers), 0.25, 3.00) IncomingGroup = clamp(1 + sum(incoming_modifiers), 0.25, 3.00) EncounterGroup = clamp(1 + sum(encounter_modifiers), 0.25, 3.00) GroupProduct = clamp(OutgoingGroup * IncomingGroup * EncounterGroup, 0.10, 4.00) Mitigated = RawDamage * DefenseMultiplier * CritMultiplier * GroupProduct Screened = Mitigated * max(0.70, 1 - 0.15*protection_stacks) DamageFloor = ceil(0.04 * RawDamage) FinalDamage = 0 if explicit_nullification else max(1, DamageFloor, floor(Screened)) HPDamage = max(0, FinalDamage - barrier_absorbed) ``` Use `Screened=Mitigated` for non-screened modes. Guard defends physical, Ward defends arcane, and true damage uses zero defense, cannot critical, ignores screening, and is capped at 25% target MaxHP per non-boss event. Barrier absorbs after the floor; an explicit nullification can produce zero. No other ordinary reduction bypasses the four-percent floor. Fixed boundary: `RawDamage=125`, defense `500`, GroupProduct `0.10`, no critical, and no screening yields `2.083...` before the floor. `DamageFloor=5`, so the resolved damage is `5` before barrier. Explicit nullification yields zero. #### 15.2 Healing ```text RawHeal = max(0, Base + Coefficient * HealingPower) FinalHeal = floor(RawHeal * OutgoingHealGroup * ReceivedHealGroup) EffectiveHeal = min(FinalHeal, MaxHP - current_HP) ``` Healing does not critical unless the skill declares a visible healing-critical rule. Overheal has no effect unless one named hook converts it; conversion is capped at 50% of overheal and still respects the barrier cap. ### 16. Status Effects And Resolution Order Each status declares: ```text status_id, category, source_id, target_id base_chance_bp, potency_source, resist_stat duration_ticks, interval_ticks, max_stacks stack_rule (add | refresh | replace | independent) dispel/immunity tags, on_apply, on_tick, on_expire presentation and causal-report events ``` For a resistible status: ```text ApplyChanceBp = clamp(BaseChanceBp + 25*(Potency - Tenacity), 500, 9500) applies = status_apply_roll_bp < ApplyChanceBp ``` Guaranteed effects bypass the roll but not declared immunity. If simultaneous effects apply the same status, resolve `replace`, then `add`, then `refresh`, then independent instances by source ID. Expiry occurs before periodic ticks, so a status with `end_tick == current_tick` does not tick again. Hard control effective duration is: ```text duration = clamp(BaseDuration * 100/(100 + Tenacity), 0.2, 3.0) ``` After hard control ends, the actor gains four seconds of Control Guard, reducing new hard-control duration by 75%. No actor may be unable to act for more than 50% of any rolling ten-second window. Boss caps and immunities are previewed. ### 17. Equipment, Artifacts, And Hooks Each Recruit has exactly one universal active equipment slot. An item may be presented as armament, guard, garb, charm, or kit, but those forms describe eligibility, attachment and visual language rather than simultaneous body slots. A Recruit therefore owns zero or one `equipped_item_id`. Equipping a candidate is one atomic replacement: the candidate leaves run inventory, the previous item returns to inventory if present, and the Recruit's single slot points to the candidate. An Artifact is a shared run rule and never occupies this slot. An item may react to an allied Recruit's item event, but no effect may require its wearer to hold a second item. All 320 equipment rows must alter a decision and declare one named hook. Scalar budget may support the hook but cannot be the row's only identity. One item ID cannot be owned by two Recruits. Company-unique effects declare a unique group; later copies retain local behavior but show the shared portion dormant. Artifacts are shared run rules. A run holds at most three active Artifacts. A fourth acquisition requires replacing one or declining the new row after an exact before/after preview. All 60 must change formation, targeting, market, risk, resource, promotion, summon, or reward valuation and must name a conflict. Legal battle hooks are: ```text before_target, after_target, before_cast, on_cast_complete, on_interrupt, before_damage, after_damage, on_critical, before_heal, after_heal, on_barrier_break, on_status_apply, on_status_expire, on_advance, on_withdraw, on_push, on_pull, on_protection_change, on_resource_gain, on_signature, on_summon, on_fallen, after_collapse ``` Each hook has a trigger limit, minimum 0.5-second cooldown unless a fixed loop proof allows otherwise, and recursion declaration. Derived events cannot retrigger their source by default. ### 18. Death, Dismissal, And Replacement #### 18.1 Battle Death At zero HP, a non-summon Recruit becomes Fallen: - it cannot act, target, protect, receive healing, or be promoted; - its death trigger resolves once at priority 8; - it is removed for line collapse; - no timer, item, Profession, Artifact, difficulty rule, or Reserve state can respawn, resurrect, or substitute for it during the encounter; - its recruit ID and optional equipped item ID enter the pending outcome casualty set; - it remains visible in diagnosis with the preceding five seconds of causes. At outcome application, each casualty and all returned equipment commit with Replacement Credit as one transaction. Victory, defeat, timeout, and retreat do not change the permanence of already Fallen Recruits. #### 18.2 Dismissal Dismissal is a Market-only operation. It is illegal for a deployed Recruit in a committed battle, a Fallen Recruit awaiting outcome, or a Recruit referenced by a pending promotion. It also uses the product authority's canonical count: ```text live_recruit_count = count(unique Recruit IDs owned by the current run whose state is living, across deployed party and Reserve) dismissal_legal = Market_open and target_is_living and live_recruit_count >= 2 ``` The preview and commit independently evaluate `dismissal_legal`. Review shows equipment return, rebate, lost level/history, and resulting deployable footprint. A legal confirm removes the Recruit once and asserts the post-state has `live_recruit_count >= 1`. If the count is one, or a once-valid preview becomes stale after another serialized operation leaves one living Recruit, reject `FINAL_LIVE_RECRUIT`. The rejection removes no Recruit or equipment, grants no Coin or Replacement Credit, changes no counters, and creates no protected recovery offer. Repeated confirm returns the same rejection. An interrupted pending dismissal must revalidate the active count before it can apply and is rejected without mutation when that count is one. Dismissal never creates Replacement Credit or a Meta reward. Explicit run abandonment is a distinct Market/result transaction, and casualty-driven replacement/Company collapse remains exclusive to casualty settlement. #### 18.3 Replacement Replacement is an ordinary hire using Coin and eligible Replacement Credit. After a casualty, the next Market protects one base-Profession recovery offer from refresh until bought or explicitly declined. Reserve never fills the line automatically. A run closes only when the player cannot legally deploy one living Recruit after all available recovery purchases or explicitly abandons. A blocked final dismissal never creates or refreshes this offer and never invokes the casualty recovery predicate. ### 19. Battle Control, Retreat, Timeout, And Outcome Pause, 1x, 2x, and 4x affect presentation only. Inspection while paused can open actor state, target reasoning, current action, queued major event, line depths, protection, status order, and causal log. Retreat becomes legal at tick 50 (5.0 seconds). Confirm begins a 20-tick global withdrawal. Automatic actions continue and Recruits can fall during it. At the end of the 20th tick, living allied non-summon actors escape and outcome becomes retreat. Repeating retreat confirm returns the same command receipt. At 120 seconds, Overtime begins: ```text for each completed 10-second Overtime band: all damage dealt multiplier += 0.25 all healing and new barrier multiplier -= 0.20 damage bonus caps at +0.75; healing/barrier penalty caps at -0.60 ``` At tick 1500, if the objective is not satisfied, the result is timeout defeat. Living Recruits survive; Fallen Recruits remain lost. Timeout grants no battle reward and applies the failure transaction in the save authority. Victory is evaluated after simultaneous damage, death, collapse, and summon events. If both victory and all-allied-Fallen predicates become true in the same batch, the declared objective decides: elimination objectives are a mutual defeat; survival/objective-complete battles are victory with zero living deployed Recruits and can close the run if no Reserve remains. ### 20. Enemy And Battle-Offer Contract Every ordinary/elite enemy and boss row declares: ```text enemy_id, ordinary | elite | boss, Region/Contract placement footprint, preferred depth, movement rules basic/technique/signature actions and automatic priority target/protection/reach/projectile/heal/summon rules first-major-action window and telegraph phase predicates, immunities, counter tags, two rational responses interaction with at least two older mechanics first-failure contribution and fixed fixtures ``` Before commitment, a battle offer shows exact enemy order and footprint, target policies, protection bypass, earliest major windows, movement, summon allowance, resistances, objective, timeout, retreat consequence, Coin reward, and reward family. A hidden visual identity may remain concealed for discovery; a mechanic needed for a fair choice may not. The complete envelope is 100 ordinary/elite identities plus 16 bosses across 8 Regions. Presentation variants do not count toward those totals. ### 21. Causal Diagnosis The result report presents, in order: 1. committed allied and enemy order; 2. predicted and actual first targets; 3. first divergence from predicted action/target/timing; 4. first protection change, projectile interception, or reach failure; 5. first decisive major action and available pre-battle counter categories; 6. every Fallen Recruit with the preceding five simulation seconds; 7. collapse, displacement, summon-space, retarget, and proc-suppression events; 8. effective damage, prevention, healing, control, and resource totals; 9. reward/failure/casualty operation IDs in technical details. The report can compare one alternate order or equipment removal against the same seed in a no-reward rehearsal. It may explain categories but cannot auto-equip a supposed universal answer. ### 22. Content Schemas #### 22.1 Skill Row ```text skill_id, owner_profession_id, tags, timing candidate filters, target policy, protection mode, retarget policy invalid-target outcome mapping, fizzle/interrupt refund fields reach, projectile/area/movement/summon fields Base, Coefficient, PowerSource, type, pierce, critical rule resource cost/gain, cooldown, status rows, proc hooks refund_on_outcome_ids, refund_match outcome triggers (trigger_id, observed_role, AO_* outcome_ids, component_tags, once_scope, allow_derived, resulting action/hook) automatic priority condition, illegal reasons, causal labels animation/VFX/SFX/caption/reduced-motion requirements fixed input and expected event output ``` #### 22.2 Equipment Row ```text equipment_id, form, acquisition band, list-price inputs eligible Profession/action tags changed decision and named behavior hook stat support budget, trigger, cooldown, recursion order/target/timing/resource/risk tradeoff two interaction fixtures and one loss/comparison fixture presentation/accessibility/localization needs ``` #### 22.3 Artifact Row ```text artifact_id, unlock/offer placement, shared hook run rule changed, conflict group, replacement comparison Market/battle/risk inputs and outputs two builds whose valuation changes in opposite directions fixed seed fixture and causal event ``` #### 22.4 Battle Offer Row ```text battle_offer_id, Region, Contract, Round, risk tier enemy lineup/order/levels, seed labels, objective preview fields, Coin reward, reward family, retreat/failure receipt expected duration, profile assertion, causal-report requirements ``` ### 23. Static Validation Gates - all Profession topology counts and parent links reconcile to 42; - all 36 Traits have one benefit, one cost, and two decision fixtures; - all 320 equipment and 60 Artifact rows name a behavior change; - all 100 ordinary/elite and 16 boss rows create a distinct counter question; - no deployed footprint exceeds current Line capacity; - target preview equals the first simulated target for fixed fixtures; - identical state/seed/retreat inputs yield identical hashes at every tick; - all actions stay inside reach, critical, defense, barrier, control, proc, and timeout bounds; - every projectile and movement conflict produces the declared collision/order; - every death returns the exact owned equipment once and never introduces a Reserve automatically; - invalid actions spend no resource and return one enumerated reason; - every started action/component has a declared terminal `AO_*` record and every outcome trigger references only IDs in Section 11.2; - duplicate trigger claims are journaled and cannot fire twice; - all standard fixtures resolve or timeout at/before tick 1500. ### 24. Required Fixed Test Vectors | Vector | Setup | Expected result | |---|---|---| | Frontbound | Three enemies; target policy frontmost | Only depth-zero enemy is a candidate | | Screened rear | Target has two footprint ahead | Legal screened hit uses `0.70` multiplier | | Cross-line reach | source depth 1, target depth 2, reach 4 | distance `1+1+2=4`, legal; reach 3 is illegal | | Heal tie | Two allies at equal HP ratio in reach | Frontmost wins, then deterministic tie draw | | Projectile intercept | Reserved rear target gains a new front summon before arrival | Current front summon is hit unless bypass/lobbed | | Push footprint | Push a footprint-2 target one step | Whole block swaps; it never splits | | Blocked push | Forced move has two remaining steps at boundary | One collision event, not two | | Summon full | committed footprint 10 plus temporary footprint 2 | another footprint-1 summon fails `NO_SUMMON_SPACE` | | Simultaneous lethal | Two actors complete lethal actions in one batch | Both events apply, both actors become Fallen | | Death collapse | Front actor falls before a reserved cast completes | Survivors compact; cast follows its declared retarget rule | | Reserve behavior | Deployed actor falls while living Reserve exists | Reserve does not enter until next Market preparation | | Damage floor | Raw 125, defense 500, group product 0.10 | damage 5 before barrier; explicit nullification 0 | | Critical boundary | roll 2499 with chance 2500 bp | critical; roll 2500 is not | | Status expiry | periodic tick equals end tick | expiry occurs; no final periodic tick | | Retreat | confirm at tick 50, no terminal predicate | outcome retreat after tick 70 batch; later duplicate has no effect | | Speed parity | identical battle at 1x and 4x | all authoritative hashes equal | | Timeout | objective incomplete at tick 1200/1500 | Overtime applies, then timeout defeat at tick 1500 | | Casualty equipment | Fallen Recruit owns one item | Recruit removed and that item ID returned exactly once; null slot returns nothing | | Final dismissal | one living Recruit across deployed plus Reserve | preview/commit reject `FINAL_LIVE_RECRUIT`; no state or recovery-offer change | | Moved target remains legal | Reserved target changes depth but remains targetable and in reach | same ID receives `AO_APPLIED`; detail `TARGET_MOVED_STILL_LEGAL`; no refund | | Moved target leaves reach | Reserved target moves from distance 2 to 3 against reach 2; policy `fizzle` | `AO_INVALID_REACH` then `AO_FIZZLED`; declared fizzle refund once | | Target becomes Untargetable | Living reserved target gains declared Untargetable before completion | `AO_INVALID_UNTARGETABLE`; row retarget/fizzle policy applies; no resistance draw | | Target falls first | Reserved target becomes Fallen in an earlier tick | `AO_INVALID_FALLEN` names death event; collapsed-depth actor is not substituted | | Interception | New front protector intercepts projectile aimed at legal rear target | intended target `AO_INTERCEPTED`; protector gets its own component outcome | | Explicit Block | Actual recipient owns one eligible Block charge | `AO_BLOCKED`; one charge consumed; no primary proc or default refund | | Immunity | Status target has matching immunity tag | `AO_IMMUNE`; no `status_apply` draw and no status proc | | Resistance | No immunity; stored roll 7000, threshold 6500 | `AO_RESISTED` with roll/threshold; no general attack miss | | Mixed area | Three recipients: one changed, one immune, one already capped | `AO_APPLIED`, `AO_IMMUNE`, `AO_NO_CHANGE`; summary `APPLIED_PARTIAL` | | Duplicate trigger suppression | Mixed area yields three matching records for one once-per-action trigger | first claim fires; later claims log `DUPLICATE_TRIGGER_CLAIM`; one derived action next tick | ### 25. Acceptance Checklist - [ ] One ordered line owns protection, reach, projectiles, healing, movement, summon footprint, death collapse, and replacement behavior. - [ ] Battle formulas define tick order, random labels, damage floor, critical, status order, timeout, and fixed vectors. - [ ] Deterministic outcomes distinguish forecast divergence, target invalidation, interception, Block, immunity, resistance, application, and duplicate trigger suppression without accuracy/evasion. - [ ] Generated Recruit and fixed Profession schemas are complete without requiring authored individual narrative content. - [ ] Fully automatic combat exposes only the approved diagnostic controls and retreat. - [ ] Content counts and no-filler tests match the product authority. - [ ] Save/failure owns durable death and operation recovery; economy owns all purchase, reward, capacity, and pacing numbers. ## Aetherbound Guild: Economy And Balance Authority > Authority: Market offers, prices, locks, refreshes, Coin and Replacement > Credit, rewards, progression rates, Line-capacity selection, difficulty > parameters, first-clear pacing, solvency, recovery, and anti-dominance tests. > > Revision: anti-dominance-fixture-r1 / 2026-08-11 > > [01_GAME_DESIGN.md](01_GAME_DESIGN.md) owns the player promise > and content envelope. [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md) owns > battle and content schemas. [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md) > owns exactly-once application, run failure, interruption, and recovery. ### 1. Economy Invariants 1. All gameplay value is earned in play. There is no paid currency, paid reroll, ad reward, energy, streak, offline income, or real-time wait. 2. Coin and Replacement Credit exist only in the current run. Renown and progression facts persist, but cannot buy raw combat stats, starting Coin, or starting Line capacity. 3. Every Market contains one steady battle offer. A random offer or refresh is never required to obtain a baseline counter for a mandatory boss. 4. Death is costly through lost level, Profession, Trait, history, and order, but returned equipment and Credit make ordinary replacement recoverable. 5. Dismissal, selling, refresh, lock, reward, and purchase formulas cannot create Coin-positive loops. 6. All 320 equipment and 60 Artifact rows change a decision. Economy tiers and prices may not turn a scalar variant into a gameplay identity. 7. Reward, Market, Recruit-generation, and combat random streams are separated. Reload, speed, input repeat, and unrelated draws do not change offers. 8. The Standard first clear is solvent on deterministic steady offers without Meta power, random high-tier equipment, or repeated failed-run farming. ### 2. Resource Ledger | ID | Player name | Persistence/cap | Sources | Sinks or closure | |---|---|---|---|---| | `coin` | Coin | Current run; nonnegative; no hard cap | Run start, battle rewards, reward cards, equipment sales, dismissal rebate | Recruit/equipment purchase, refresh, lock; cleared when run closes | | `replacement_credit` | Replacement Credit | Current run; cap 54 | Fallen non-summon Recruits | Optional reduction on a later Recruit hire; cleared when run closes | | `xp` | Experience | Current Recruit; level cap 10 | Completed battles entered by that Recruit | Level thresholds; disappears with Recruit/run close | | `renown` | Renown | Guild; cap 9,999 | first Contract clears, first discoveries, mastery goals, limited repeat objective | Catalog breadth, previews, challenge laws, hidden-hybrid discovery clues | | `clear_fact` | Region/Contract clear | Guild fact, not spendable | first valid boss result | Region order, ending, postgame access | | `discovery_fact` | Catalog discovery | Guild fact, not spendable | first valid inspection/acquisition/encounter | Collection, deterministic future pool access, completion | There is no material or crafting currency in the base contract. Equipment is bought, rewarded, equipped, returned after death, sold, or closed with the run. Adding a persistent resource requires an Owner-approved contract revision. ### 3. Run Opening And Capacity Economy A run begins with: - two of four provisional generated Recruits selected at zero Coin price; - `52 Coin`; - zero Replacement Credit; - Line capacity four; - exactly one starting item on each provisional Recruit and no extra equipped slots; - no active Artifact. The first Market contains at least two base-Profession Recruit offers at level 1. The two together cost 28 Coin, leaving 24 for an equipment, lock, refresh, or reserve decision. For `C` cleared ordinary Rounds in `0..12`: ```text line_capacity(C) = min(10, 4 + floor(C/2)) ``` Capacity therefore becomes `4,5,6,7,8,9,10` at clear counts `0,2,4,6,8,10,12`. It is granted automatically after result settlement, is not sold, and resets next run. Purchases and cumulative hires do not change it. ### 4. Market Board And Offer Generation Every ordinary Market contains: | Row | Slots | Generation constraint | |---|---:|---| | Recruit | 3 | At least one base Profession; after a casualty, one protected recovery offer | | Equipment | 4 | At least three different behavior tags and two legal current users unless Company is empty | | Battle | 3 | Exactly one steady offer and two distinct higher-risk or different-counter offers | Boss Muster uses the same Recruit/equipment counts but one fixed boss offer. It cannot refresh or replace the boss. Each Market is generated from: ```text hash(run_seed, contract_id, Market_index, row_id, slot_index, refresh_index) ``` Labeled substreams are `recruit`, `equipment`, `battle`, and `reward`. An offer stores its complete generated fields and hash before presentation. Reopening, changing language, inspecting another screen, or closing the application does not redraw it. #### 4.1 Offer Level And Pool For ordinary Round `R` in `1..12`: ```text offer_level(R) = min(10, 1 + floor((R-1)/3)) ``` Boss Muster uses the Round-12 offer level. Base Professions remain in every pool. Regular advanced direct hires may appear from Round 7 after their catalog unlock. Hidden hybrids are promotion outcomes and cannot be bought directly. Equipment uses Region band `B` in `0..7` and item tier `T` in `0..3`. At least one tier-0/1 legal item remains possible in every ordinary Market. A boss counter has one deterministic Region objective or fixed Muster offer; it is never refresh-gated. #### 4.2 Lock The player may lock at most three unbought Recruit/equipment offers. Each newly locked offer costs `2 Coin` once and persists through the next Market or until bought/declined. Unlocking does not refund Coin. Battle offers can be locked only within the current Market so the player can refresh other rows; they never carry beyond a committed battle. The protected recovery offer needs no paid lock, survives refresh, and expires only when bought, explicitly declined, or the run closes. #### 4.3 Refresh Refreshing replaces every unlocked, unbought offer except a fixed boss and a protected recovery offer. Let `N` be prior refreshes in the current Market and `L` the number of paid locked offers: ```text refresh_cost(N,L) = min(24, 6 + 3*N + 2*L) ``` `N` starts at zero each Market and increments atomically with the new board. The first no-lock refresh costs 6, the second 9, and the seventh and later cost 24. Insufficient Coin rejects the operation without changing offers or `N`. ### 5. Prices, Sales, And Dismissal #### 5.1 Recruit Price For offer level `L` and Profession tier `P` (`0` base, `1` regular advanced): ```text hire_list_price(L,P) = 10 + 4*L + 10*P ``` Trait and rolled distribution do not add a hidden price because level totals are equal-budget and every Trait has a cost. A Recruit's generated offer stores the list price. Replacement Credit is optional at confirm. If `use_credit` is true: ```text credit_used = min(replacement_credit_balance, hire_list_price) coin_cost = hire_list_price - credit_used ``` If false, `credit_used=0`. Coin cost, Credit spend, Recruit creation, and offer removal apply atomically. Credit cannot buy equipment, refreshes, locks, or Meta progression. #### 5.2 Equipment Price And Sale For Region band `B` in `0..7` and item tier `T` in `0..3`: ```text equipment_list_price(B,T) = 12 + 3*B + 6*T sale_value = floor(0.30 * coin_price_paid) ``` An equipment reward stores `coin_price_paid=0` and therefore sells for zero; its value is the behavior it enables. Purchased copies never sell above 30%. Locked, equipped, or battle-committed items must be released before sale. #### 5.3 Dismissal Rebate The product authority's canonical count and precondition apply before rebate calculation: ```text live_recruit_count = count(unique Recruit IDs owned by the current run whose state is living, across deployed party and Reserve) dismissal_legal = Market_open and target_is_living and live_recruit_count >= 2 ``` Only for a legal dismissal: ```text if survived_battles >= 2: dismissal_rebate = min(10, floor(0.25 * coin_price_paid)) else: dismissal_rebate = 0 ``` `coin_price_paid` excludes Credit. Equipment returns before the Recruit is removed, all in one operation. Dismissal creates no Credit, Renown, XP transfer, offer reroll, or reward. A same-level replacement always costs more Coin than the rebate unless Credit came from an unrelated death. When `live_recruit_count == 1`, preview and commit reject `FINAL_LIVE_RECRUIT` before the rebate formula. The blocked action grants zero Coin, zero Credit, no protected recovery offer, and no economic or roster mutation. `Abandon Run` remains a separately confirmed run-close operation and does not pay a dismissal rebate. Counterexample trace: ```text state: Market open; one living Recruit; Coin=3; Credit=0; no protected recovery offer; Recruit paid 32 Coin and survived 3 battles attempt: preview dismissal, then submit the same confirm after interruption result: FINAL_LIVE_RECRUIT at preview and commit after: one living Recruit; Coin=3; Credit=0; no protected offer; dismissed_total unchanged; calculated dismissal rebate is not applied next legal terminal choice: continue Market play or confirm Abandon Run ``` The hypothetical eight-Coin rebate cannot make the final dismissal legal. Casualty settlement may later create Credit or a protected offer if the Recruit falls; it is not simulated by dismissal. ### 6. Battle Income And Reward Drafts Battle risk `Q` is `0` steady, `1` pressured, or `2` elite. For Region band `B` in `0..7` and ordinary Round `R`: ```text battle_coin(B,R,Q) = floor((18 + 2*R + 2*B + 7*Q) * difficulty_reward_multiplier) reward_budget(B,R,Q) = 12 + 2*R + 3*B + 6*Q ``` Coin pays once on victory before the reward choice. Defeat, timeout, and retreat pay no battle Coin. Economic consequences after those outcomes are owned only by the save/failure authority. The victory reward draft is stable: | Risk | Cards | Required composition | |---|---:|---| | Steady | 2 choose 1 | one legal equipment/tag card; one `floor(0.50*reward_budget)` Coin card | | Pressured | 3 choose 1 | two distinct legal equipment/tag cards; one Coin or Recruit-discount card | | Elite | 3 choose 1 | one Artifact-eligible card, one equipment/tag card, one Coin/recovery card | An Artifact card offers three fixed Artifact IDs and the player chooses one. If three Artifacts are already active, comparison/replacement is part of the same operation. Declining a reward is legal and grants nothing. A reward card cannot be rerolled by leaving the result. The boss awards no spendable Coin because the run closes. A first boss clear grants the persistent values in Section 9 and one fixed discovery choice. ### 7. Death Credit And Recovery Solvency When a hired or provisional Recruit becomes Fallen, use its original list price and actual Coin paid: ```text credit_grant = min(original_list_price, 10 + floor(coin_price_paid/2)) new_credit_balance = min(54, old_credit_balance + credit_grant) ``` Credit, permanent Recruit removal, and equipment return apply in one casualty operation. A provisional Recruit has `coin_price_paid=0` and an implicit level-1 base list price of 14, so it grants 10 Credit. Summons grant none. After one or more casualties, the next Market reserves one base-Profession recovery offer with all of these properties: - its level is `max(1, offer_level-1)`; - its Profession supplies at least one missing primary responsibility among protection, damage, reach, or sustain when such a catalog row is unlocked; - it is not replaced by refresh and needs no lock fee; - its list price uses the normal formula and Credit can reduce it to zero; - buying or explicitly declining it clears protection, not remaining Credit. The guarantee makes a replacement visible, not automatically optimal. A lost advanced or promoted Recruit returns as a cheaper base Recruit unless the player chooses to spend more on another offer. #### 7.1 Three-Death Fixture At Round 7, three base Recruits originally bought for 18 Coin each fall. The current base list price is 22, the player has 12 Coin, and Credit cap is 54: ```text grant per Recruit = min(22, 10 + floor(18/2)) = 19 balance after three grants = min(54, 57) = 54 replacement Coin costs = 0, 0, 12 ending Coin = 0; ending Credit = 0 ``` Three legal replacements are therefore purchasable in the next Market. The player has lost their levels, Traits, promotion progress, history, and all liquid flexibility, so the loss is recoverable but not profitable. ### 8. XP, Levels, And Promotion Pace For Recruit level `L` from 1 through 9: ```text xp_to_next(L) = 20 + 10*L battle_xp(R,Q) = 10 + 2*R + 4*Q ``` Living deployed Recruits receive 100% on victory, 50% on defeat/timeout when at least one deployed Recruit survives, and 50% on completed retreat. Reserve and Fallen Recruits receive zero. Difficulty and display speed do not multiply XP. XP is applied after casualty determination. A Recruit can gain multiple levels from one award, checking the formula at each new level, but cannot exceed 10. At cap, excess is discarded and shown. Promotion eligibility at level 4 plus three survived battles is owned by the systems authority. There is no permanent Recruit level, inheritance, XP item, or Meta stat. New hires catch up through offer level and price rather than receiving another Recruit's progress. #### 8.1 Enemy Rank And Within-Run Scaling Regions add mechanics, not a permanent vertical stat ladder. Within a run, enemy stat pressure follows the current offer level and risk: ```text encounter_rank(R,Q,boss) = min(6, offer_level(R) + Q + (1 if boss else 0)) rank_multiplier = 1 + 0.08*(encounter_rank - 1) ``` Apply `rank_multiplier` once to an enemy row's base MaxHP, power, Guard, Ward, Potency, and Tenacity, rounding half up. Tempo, Initiative, reach, target rules, cooldowns, footprint, and status durations do not scale. Difficulty then applies its declared HP and damage/healing multipliers once. Identity base budgets are content-authored within the systems ranges and must pass fixed same-rank comparisons. A later Region cannot substitute a larger base budget for a new mechanic, and no mandatory battle assumes a prior run's Recruit or equipment. ### 9. Renown And Meta Progression For Region number `G` in `1..8` and Contract rank `K` in `{1,2}`: ```text first_clear_renown(G,K) = 8 + 2*G + 4*K repeat_objective_renown = min(2, unclaimed_repeat_goals_for_contract) ``` First discovery of a Profession, Trait, equipment behavior family, Artifact, ordinary/elite enemy, or boss grants one Renown once. A row's presentation variants grant none. Repeat objectives are finite checklist entries; replaying an unchanged clear after they are claimed grants zero Renown. Renown purchases only breadth: | Unlock | Cost range | Allowed effect | |---|---:|---| | Catalog pool packet | 4-8 | Add sidegrade equipment/Trait/Artifact rows to future eligible pools | | Advanced Profession clue/trial | 8-12 | Reveal requirements and enable a deterministic trial | | Hidden-hybrid clue/trial | 14-18 | Reveal one predicate and enable its mastery trial | | Threat archive upgrade | 6-10 | Expose additional exact preview fields for encountered families | | Oath law | 12-20 | Add a postgame optional run modifier and its completion Record | Forbidden effects include percentage power, HP, defense, Coin gain, cheaper shops, free refreshes, starting equipment, starting Recruits, extra reward cards, larger starting Line capacity, or casualty reversal. All mandatory Standard counters are in the default or deterministic Contract pool. A player never needs a Renown purchase to finish the first clear. #### 9.1 Guild Charter Transaction `PRO-002` presents the existing Renown authority as the **Guild Charter**. It is not a new economy, currency, progression tree, or permanent-stat layer. The board contains exactly eight horizontal Region seals in campaign order. A seal opens only its authored packet cards and prerequisite tracks; no radial layout or copied node graph is permitted. Each claim uses one stable `charter_claim_id` and the existing cost range above: ```text preview = (charter_claim_id, region_id, prerequisite_ids[], renown_cost, effect_family, future_run_effect, balance_revision) commit = verify preview + debit Renown + append one claim receipt atomically retry = return the original receipt; never debit or grant twice ``` The preview must show current Renown, remaining Renown, every prerequisite, whether each prerequisite is satisfied, the exact future-run breadth change, and the statement `No permanent combat power`. A failed prerequisite, stale balance revision, insufficient balance, duplicate claim, or interrupted write cannot partially reveal a packet or consume Renown. Respec and refund are not part of the contracted board; claims are permanent breadth unlocks. The first-clear choice after the sixteenth boss creates no new currency and grants no choice-specific combat value. Both branches settle the same earned Renown and first-clear Records exactly once, archive the surviving Company, and close Coin/Credit with the run. **Complete the First Chronicle** changes only the next destination to Final Ledger/Title. **Open the Oath Season** additionally sets postgame eligibility and enters rule review; its first playable state is a new generated run after that review. Ordinary New Run remains available and uses the same persistent breadth already owned. ### 10. Equipment And Artifact Distribution The 320 equipment entries are divided into eight Region bands of 40. Every band contains all five item forms (armament, guard, garb, charm, and kit), all primary responsibilities, and at least three opposed order/reach/protection plans. Every Recruit has one universal active slot, so form controls eligibility and presentation rather than granting simultaneous slots. Tier describes price and availability, not strict power. A lower tier must lead one fixed comparison in which it is the rational choice. Each item has a numeric support budget separate from its required behavior: ```text item_stat_budget(T) = 30 + 8*T ``` The behavior hook reserves 12-24 budget points. At most 50% of the total budget may be generic HP, power, Guard, or Ward. Remaining numeric support uses: | Stat | Cost | |---|---:| | +1 Might, Finesse, Insight, Vigor, or Resolve | 2 | | +1 WeaponPower, FocusPower, ArmorGuard, or ArmorWard | 1 | | +6 MaxHP | 1 | | +1 Potency or Tenacity | 1 | | +0.20 Tempo or Initiative | 1 | The one equipped item's numeric support is added before derived-stat rounding. Region band does not increase this budget; later bands introduce new interactions rather than automatic vertical power. All 320 entries pass the systems behavior fixture. No scalar-only allowance or minimum subset exists. The 60 Artifacts are distributed across first-clear, elite, boss, mastery, and postgame pools. Every run sees at least one deterministic Artifact choice by the end of Round 6 and at least one additional choice by boss Muster. No Artifact is required for a mandatory boss. Duplicate active Artifact IDs are illegal. Bad-luck protection uses behavior tags: ```text if two consecutive eligible equipment drafts omit the selected behavior tag: the third eligible draft contains that tag ``` The counter resets when offered, not accepted. The selected tag may be changed at any Market for zero Coin before a draft is generated. It cannot name an undiscovered exact item. ### 11. Capacity Selection Simulation The `10-12` target range was evaluated with an explicit analytical workload model. It is a design simulation, not human readability evidence. For profile `P` and candidate capacity `C`: ```text prep_seconds(P,C) = ceil(base_P + inspect_P*C + reorder_P*C*(C-1)/2) battle_p95_seconds(C) = ceil(52 + 5.4*C) causal_events_per_second(C) = 1.2 + 0.24*C ``` The pair term models order comparisons, not every permutation. The gate is `prep <= 150 s` for every profile, battle p95 `<=120 s`, causal events `<=4.0/s`, and the three-death fixture recoverable in at most one Market. | Profile | `base` | `inspect` | `reorder` | C=10 prep | C=11 prep | C=12 prep | |---|---:|---:|---:|---:|---:|---:| | Normal | 20 | 4.0 | 0.8 | 96 s | 108 s | 121 s | | Active | 25 | 5.0 | 1.4 | 138 s | 157 s | 178 s | | Efficient | 15 | 3.0 | 0.5 | 68 s | 76 s | 84 s | | Adversarial | 20 | 4.5 | 1.3 | 124 s | 141 s | 160 s | | Returning | 30 | 5.5 | 1.3 | 144 s | 162 s | 182 s | | Candidate | Profiles passing prep | Battle p95 | Causal events/s | Three-death recovery | Result | |---:|---:|---:|---:|---:|---| | 10 | 5/5 | 106 s | 3.60 | 1 Market | Pass | | 11 | 3/5 | 112 s | 3.84 | 1 Market | Fail profile gate | | 12 | 2/5 | 117 s | 4.08 | 1 Market | Fail profile and event gates | Ten is the largest candidate passing every declared gate. Human testing still owns whether ten simultaneous allies plus enemies remain visually legible. ### 12. Contract And First-Clear Pacing Each Region contains two Contracts. Every Contract is twelve ordinary Rounds, boss Muster, and one boss. The Normal authored means are: | Region | Contract 1 | Contract 2 | Region total | Content pressure | |---:|---:|---:|---:|---| | 1 | 50 min | 54 min | 104 min | recruit valuation, front/rear, reach | | 2 | 54 min | 58 min | 112 min | protection bypass and healing access | | 3 | 56 min | 60 min | 116 min | projectiles and interception | | 4 | 58 min | 62 min | 120 min | movement, push, and pull | | 5 | 60 min | 64 min | 124 min | summons and footprint pressure | | 6 | 62 min | 66 min | 128 min | status ordering and control | | 7 | 64 min | 68 min | 132 min | promotion and Artifact conflicts | | 8 | 66 min | 70 min | 136 min | full-system synthesis | Successful Contract time sums to `972 minutes`. This time is active Market, battle, result, and boss play; it excludes loading and forced waiting. #### 12.1 Five Full-Clear Profiles | Profile | Successful Contract minutes | Failed/abandoned-run minutes | Guild/onboarding/recap minutes | Total | First-clear hours | |---|---:|---:|---:|---:|---:| | Efficient | 768 | 120 | 90 | 978 | 16.30 h | | Normal | 972 | 120 | 78 | 1,170 | 19.50 h | | Active | 1,152 | 150 | 90 | 1,392 | 23.20 h | | Adversarial | 928 | 300 | 92 | 1,320 | 22.00 h | | Returning | 1,024 | 120 | 161 | 1,305 | 21.75 h | Every profile is inside 15-25 hours. The efficient profile cannot skip required bosses or decisions; it saves time through faster comparison and presentation speed. Adversarial includes more elite offers and recoverable losses. Returning includes recap/segmentation overhead, not forced repetition. Mastery targets 60+ cumulative hours. At least 70% of post-ending time must use a previously unclear Profession, Trait, equipment behavior, Artifact conflict, enemy/boss fixture, or Oath law. An unchanged clear may contribute at most 20% of any mastery milestone. ### 13. Exact Twenty-Minute Pacing Traces All timestamps are simulation-independent wall time spent actively playing a representative 1,200-second session. `M` lists Market openings. `B` lists battle start-end intervals. `D` lists meaningful decisions; confirmation, inspection, speed changes, and reward animation do not count. | Profile | `M` Market opens (s) | `B` battle intervals (s) | `D` decision timestamps (s) | Maximum decision gap | |---|---|---|---|---:| | Normal | `[0,300,600,900]` | `[(180,270),(480,570),(780,870),(1080,1170)]` | `[25,90,175,280,325,390,475,580,625,690,775,880,925,990,1075,1180]` | 105 s | | Active | `[0,330,660,990]` | `[(210,300),(540,630),(870,960),(1140,1200)]` | `[20,75,135,205,310,350,410,475,535,640,680,740,805,865,970,1015,1070,1135]` | 105 s | | Efficient | `[0,260,520,780,1040]` | `[(130,230),(390,490),(650,750),(910,1010),(1170,1200)]` | `[35,125,240,295,385,500,555,645,760,815,905,1020,1075,1165]` | 115 s | | Adversarial | `[0,290,610,940]` | `[(150,260),(440,580),(760,910),(1100,1200)]` | `[30,80,145,270,320,375,435,590,640,700,755,920,970,1030,1095]` | 165 s | | Returning | `[0,270,590,930]` | `[(140,240),(420,550),(760,890),(1090,1180)]` | `[25,85,135,250,300,355,415,560,620,680,755,900,950,1015,1085,1190]` | 145 s | The gap includes time zero to the first decision and the last decision to 1,200. Every battle that completes before the trace boundary is followed by its next decision within 15 seconds. Decision kinds across each trace must include Recruit/equipment valuation, order or deployment, battle-risk commitment, reward/recovery, and next-Market budget. Adversarial's 165-second gap is a long elite battle and remains below the product veto because the battle itself is capped at 150 simulation seconds and the result decision appears immediately afterward. ### 14. Standard Solvency Trace A lowest-reward run takes only steady offers. In Region band `B`, ordinary battle income is: ```text sum(battle_coin(B,R,0), R=1..12) = sum(18 + 2*R + 2*B) = 372 + 24*B Coin ``` With starting Coin, total pre-boss resources are `424 + 24*B Coin`. The baseline plan spends: | Required purchase | Cost | |---|---:| | Eight base hires needed to grow from two provisional Recruits to capacity ten | 156 | | Two tier-0/1/2/3 items in Region band `B` | `168 + 24*B` | | Two refreshes in one no-lock Market | 15 | | Three locks | 6 | | Total | `345 + 24*B` | The Region-band income and equipment-price terms cancel exactly, so the run reaches boss Muster with `79 Coin` before optional sales, risky-offer bonuses, reward Coin cards, or Credit. The deterministic boss-counter objective costs no more than one omitted baseline equipment purchase. Standard solvency passes when every Region seed can follow an equivalent plan with at least 40 Coin or one complete three-casualty recovery set entering boss Muster. ### 15. Anti-Dominance And Balance Gates #### 15.1 Required Strategy Tests | Candidate policy | Why it might dominate | Rejection fixture | |---|---|---| | Always refresh twice | More chances at desired synergies | Costs at least 15 Coin per Market before locks; 12-Market use costs 180, exceeds the 79-Coin baseline reserve and must lose one fixed low-variance seed | | Never refresh | Preserves all Coin | Must lose value in at least two of five seeds where one refresh exposes a counter tag worth more than 6 Coin | | Buy every Recruit | Reserve breadth and death insurance | Reserve earns no XP/Coin; dismissal returns at most 25% paid Coin; fixed plan must lose equipment/refresh flexibility and fail one boss comparison | | Dismiss after every battle | Attempt to cycle Traits/offers | No Credit, zero rebate before two survivals, maximum 10 later; cycle is strictly Coin-negative and loses history/level | | Never dismiss | Avoid sunk-cost loss | Must lose one fixture where releasing an obsolete low-level Reserve funds a reachable counter without weakening deployed footprint | | Never replace | Preserve Coin after death | Must lose one post-casualty fixture because lower footprint changes reach/protection and leaves Coin unused | | Always take steady | Minimize death | Must trail pressured/elite in at least one build-breadth objective and one Artifact timing fixture | | Always take elite | Maximize rewards | Expected casualties and missed steady recovery must reduce clear rate or terminal Coin in at least two profiles | No policy needs to be bad everywhere. A policy is dominant if it weakly beats all alternatives in every fixed state and strictly beats one; any such result blocks the design. #### 15.2 Executable Fixed-Seed Comparator The Gate 6 build-policy proof is [ANTI_DOMINANCE_FIXED_SEEDS.json](product/fixtures/ANTI_DOMINANCE_FIXED_SEEDS.json), recalculated by `python3 tools/simulate_anti_dominance.py`. It is a prebattle feasibility comparator, not a second combat model: the fixture declares the locked route's ordered enemy inputs, required counter tags, minimum deployed footprint, and casualty counts. The script replays the Market transactions, tests that the resulting deployed build covers those route requirements, and then applies the Section 6 battle-Coin formula only on a clear. It introduces no accuracy, evasion, random draw, hidden generator state, or formula override. Every seed declares all of the following rather than asking a generator for them at test time: | Fixture field | Required declared input or recalculation | |---|---| | State | Round, cleared Rounds, Region band, difficulty, Coin, Credit before casualties, prior refresh count, paid locks, and expected capacity/offer-level/refresh-cost values | | Company | Every living Recruit ID, deployed/Reserve assignment, counter tags, Coin paid, and survived-battle count | | Recovery | Every casualty's original list price, Coin paid, expected Credit grant, post-casualty Credit, and the protected offer ID or explicit null | | Boards | All three Recruit, four equipment, and three battle offers on both the opening and first-refresh board, including exact price inputs and stored prices | | Route | The paid-locked route preserved through refresh, ordered enemy inputs, risk, required tags, deployed footprint, outcome casualties, and stored battle Coin | | Oracle | Exact action trace and outcome metrics for every policy plus the expected winner | Each fixture's opening Coin is the post-lock balance; the declared paid lock is already sunk. Its count still enters the first-refresh formula, and the locked route is byte-identical on the refresh board so every policy faces the same combat contract. The script rejects a missing row or field, a sixth or duplicate seed, a changed locked route or protected offer, a noncanonical price/reward/Credit value, an illegal deployment, or an expected-result mismatch. A casualty state must have exactly one protected Recruit on both boards. The protected offer remains unchanged through refresh. Dismissal checks the canonical living count before target selection; with one living Recruit it records `FINAL_LIVE_RECRUIT`, pays no rebate, and may still perform a separate legal equipment purchase. Casualty Credit and protected recovery are inputs to later hire transactions, never a dismissal side effect. The four fixed policy families are intentionally narrow and deterministic: | Policy | Exact algorithm | |---|---| | `refresh_first` | Pay exactly the declared first refresh when affordable, then buy at most one affordable refreshed equipment offer that maximizes missing route-tag coverage; ties use lower price then offer ID | | `hire_first` | Buy at most one affordable opening-board Recruit, preferring the protected offer, then missing route-tag coverage, lower Coin cost after optional Credit, lower list price, and offer ID; deploy it only when capacity has a vacancy | | `dismiss_first` | If legal, dismiss one Reserve with least route relevance, then highest rebate and offer ID tie-breaks; otherwise record the rejection; buy at most one affordable opening-board equipment counter | | `no_replace` | Never refresh, hire, or dismiss; buy at most one affordable opening-board equipment counter using the same coverage/price/ID ordering | The comparison is lexicographic and all higher values are better: `route_cleared`, ending Coin, ending Credit, ending living Recruit count, then counter-tag coverage. The JSON also records deployed/required footprint, battle Coin, Market Coin spent, dismissal rebate, Credit used, Line capacity, and exact actions. This ordering does not convert Credit into Coin and does not claim that the fixture policies are exhaustive play. It makes one declared prebattle choice comparable without hiding a utility weight. For two policies `A` and `B`, `A` weakly dominates `B` only when `A`'s complete comparison tuple is at least `B`'s on all five seeds and strictly greater on at least one. The run fails if either policy has no win, has no loss, or any ordered policy pair meets that definition. `--self-test` first accepts the canonical matrix, then creates an in-memory matrix in which `refresh_first` beats every peer on every seed and proves that the dominance check rejects it. | Stable seed | Fixed state counterfactual | Expected winner | |---|---|---| | `AD-FS-001-REFRESH-COUNTER` | First refresh exposes the locked pressured route's only affordable wardbreak counter | `refresh_first` | | `AD-FS-002-PROTECTED-HIRE` | One casualty leaves both a protection and fourth-deployed-Recruit gap | `hire_first` | | `AD-FS-003-DISMISSAL-REBATE` | A legal four-Coin obsolete-Reserve rebate makes the current reach counter affordable | `dismiss_first` | | `AD-FS-004-PRESERVE-COIN` | The current line already clears; extra transactions lose Coin or living roster value | `no_replace` | | `AD-FS-005-CREDIT-CROSSOVER` | Final-Recruit dismissal is illegal and a zero-Coin protected hire beats two equipment paths | `hire_first` | Canonical verification is: ```sh python3 tools/simulate_anti_dominance.py --self-test python3 tools/simulate_anti_dominance.py python3 tools/simulate_anti_dominance.py | shasum -a 256 ``` Two default runs must be byte-identical. The summary prints every policy's clear, ending Coin, ending Credit, ending living count, and counter coverage for every seed, the win counts, a canonical result SHA-256, and `ABG_ANTI_DOMINANCE_OK no_weak_dominance=1`. #### 15.3 Complete Gates 1. **Solvency:** all eight Region bands have a steady Standard plan reaching boss Muster with 40 Coin or the full declared recovery set. 2. **Recovery:** the Section 7.1 three-death state fields three legal base replacements in one Market and does not increase total Coin-equivalent value. 3. **Capacity:** candidate ten is the only candidate passing all profile, battle-duration, event-rate, and recovery gates. 4. **Profession diversity:** each base branch pair and hidden hybrid has opposed fixtures; no identity leads both without a different Company/order cost. 5. **Equipment/Artifact diversity:** every row changes two observable events; no price/tier creates strict catalog-wide superiority. 6. **Market diversity:** across five fixed run seeds and five profiles, at least three different first purchases, battle risks, and final orders are optimal. 7. **Failure pressure:** one death is consequential; three are recoverable; a full-company loss can close a run without making next-run Meta power required. 8. **Decision density:** exact traces reproduce their maximum gaps, and no battle/result handoff exceeds 15 real seconds after resolution at 1x. 9. **Campaign:** all profiles finish within 15-25 hours and mastery has new decision content through 60+ hours. ### 16. Difficulty Contracts Difficulty is chosen before run creation and stored for the entire run: | Difficulty | Enemy HP | Enemy damage/healing | Reward multiplier | Audience | |---|---:|---:|---:|---| | Wayfinder | 0.90x | 0.90x | 1.00x | learning and accessibility-forward play | | Standard | 1.00x | 1.00x | 1.00x | authored first-clear baseline | | Oathbound | 1.10x | 1.12x | 1.15x | prepared high-risk play | Multipliers apply once after enemy derived stats and once to battle Coin where declared. They do not change offer access, Recruit attribute budgets, XP, Renown, target rules, telegraph length, Replacement Credit, Line capacity, or save behavior. Fallen Recruits remain permanent on every difficulty. Postgame Oath laws are opt-in rule changes, not hidden difficulty multipliers. Each declares Market/formation/enemy/reward changes and its Record. Laws may not alter transaction integrity or reintroduce permanent Meta stats. ### 17. Fixed Economy Test Vectors | Vector | Inputs | Expected result | |---|---|---| | Capacity | cleared Rounds 0,2,4,6,8,10,12 | `4,5,6,7,8,9,10` | | Base hire | L=3, P=0 | 22 Coin list price | | Advanced hire | L=3, P=1 | 32 Coin list price | | Credit hire | list 22, Credit 19, use=true | 3 Coin, Credit becomes zero | | Item price | B=4, T=2 | `12+12+12=36` Coin | | Item sale | 36 Coin paid | 10 Coin | | Refresh | N=0/L=0; N=1/L=0; N=7/L=0 | 6, 9, 24 Coin | | Steady income | B=0, R=5, Standard | 28 Coin | | Region steady income | B=7, R=5, Standard | 42 Coin | | Elite income | B=0, R=5, Oathbound | `floor((18+10+14)*1.15)=48` Coin | | Level XP | L=4 | 60 XP to level 5 | | Battle XP | R=5, Q=2 | 28 XP to living deployed winner | | Death Credit | original list 22, paid 18 | 19 Credit | | Dismissal | paid 32, survived 3 | 8 Coin; no Credit | | Final dismissal | one living Recruit, paid 32, survived 3, Coin 3 | reject `FINAL_LIVE_RECRUIT`; Coin remains 3, no rebate/offer/roster change | | Solvency | any B; start plus 12 steady wins minus baseline | 79 Coin | | Decision gaps | five Section 13 traces | 105, 105, 115, 165, 145 seconds | | Capacity candidate | C=10 | 5/5 prep, 106 s p95, 3.60 events/s, one-Market recovery | ### 18. Acceptance Checklist - [ ] Market board, offer levels, prices, refresh, lock, purchase, sale, and reward formulas are complete. - [ ] Coin, Credit, XP, Renown, and progression facts have explicit persistence, sources, sinks, caps, and non-power boundaries. - [ ] Guild Charter preview/claim/retry uses existing Renown, the declared cost ranges, exactly-once receipts, and no permanent raw power. - [ ] Death recovery is affordable without making dismissal/death profitable. - [ ] The dismissal rebate is unreachable when the target is the final living Recruit; abandonment and casualty recovery remain separate. - [ ] Capacity ten follows a declared five-profile analytical selection. - [ ] Five exact Market/battle/decision traces and campaign budgets meet 15-25 first-clear and 60+ mastery targets. - [ ] Solvency and anti-dominance gates cover refresh, hire, dismiss, replace, and risk policies. - [ ] All fixed content counts and no-filler requirements match the other authorities. - [ ] Both final-campaign choices settle identical earned economy receipts, archive the Company, and differ only in destination/postgame eligibility. ## Aetherbound Guild: Save And Failure Contract > Authority: versioned persistence, pending/applied operations, exactly-once > commit, retry, duplicate protection, deterministic battle resume, Recruit > death, dismissal, run failure, backup, corruption, migration, rollback, cloud > conflict, clock behavior, bounded offline work, delete, and recovery UX. > > Revision: recruit-line-design-r3 / 2026-08-11 > > [01_GAME_DESIGN.md](01_GAME_DESIGN.md) owns the player promise. > [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md) owns battle state and casualty > predicates. [02_GAMEPLAY_AND_BALANCE.md](02_GAMEPLAY_AND_BALANCE.md) owns normal > prices, rewards, pacing, and difficulty multipliers. This document is final > authority for operation and gameplay-failure application. ### 1. Persistence Invariants 1. A confirmed operation applies exactly once or not at all. Cost, result, receipt, and final status are one committed state. 2. A durable `pending` row contains immutable intent and zero gameplay deltas. It can be safely finalized or rejected; it can never contain a spent cost. 3. Suspend, crash, power loss, retry, duplicate input, device change, or cloud transport cannot redraw a Market/reward, duplicate an item/Renown grant, reverse a valid casualty, or change a deterministic battle. 4. The newest valid local commit remains fully playable offline. Platform and cloud copies never become gameplay authority silently. 5. A Fallen Recruit never respawns in the same battle and never returns to the same run through Reserve substitution, reload, backup choice, rehearsal, migration, reward, promotion, difficulty, or clock manipulation. 6. Death removes the Recruit but returns exactly the Recruit's optional `equipped_item_id` to run inventory. Neither half of that result can commit alone; an empty slot returns nothing. 7. Offline gameplay advances by zero simulation ticks and grants zero Coin, XP, Renown, offers, healing, or progress. 8. Migration is copy-first, deterministic, sequential, and reversible until a later verified boundary. It never rerolls generated Recruit fields. 9. Corruption recovery identifies the exact verified boundary. If later irreversible run operations cannot be reconstructed, the run is sealed rather than resumed from a state that could reverse death or duplicate value. 10. Save, conflict, recovery, overwrite, abandon, dismissal, and delete flows support touch, mouse, keyboard, controller, localization, and accessibility. 11. A Run seed is reserved in a durable `run_creation_draft` before any opening Recruit is generated. At most one draft or `current_run` exists, and a draft can only become the `current_run` that carries that same seed. ### 2. Save Topology And Envelope The product supports three independent Guild slots. Each slot holds one active commit, four rotating verified backups, one run-start checkpoint, one latest Market checkpoint, one optional pre-migration copy, and redundant closure receipt ledgers. ```text profile_save profile_schema_version settings_revision, language, accessibility, input mappings Guild_slot_index[] platform_service_outbox (non-authoritative, bounded) Guild_slot Guild_id, lineage_id, slot_id save_schema_version, ruleset_version, content_revision commit_id, parent_commit_id, commit_sequence generation_root_seed, next_run_ordinal Region/Contract progress, Renown, unlocks, Records, discoveries run_creation_draft or null current_run or null operation_journal, compact_applied_ids closure_receipt_head, run_creation_receipt_head payload_sha256, envelope_crc32 run_creation_draft draft_id, run_id, Contract, difficulty, status seed_ordinal, run_seed, source_commit_id ruleset_version, content_revision, opening_role_weight_snapshot opening_offers[0..3] or empty, opening_offer_set_hash or null selected_offer_ids[2] or empty, selection_revision draft_hash, run_creation_receipt_head current_run run_id, Contract, difficulty, run_seed, status Market/cleared-Round/boss state Coin, Replacement Credit, capacity, offers, locks, refresh counters living Recruits, Reserve, inventory, Artifacts encounter or null, pending outcome/reward or null hired/fallen/dismissed totals ``` IDs and seeds are 128-bit values rendered as lowercase hexadecimal. Commit sequence is a local monotonic unsigned integer. CRC32 catches incomplete media writes; SHA-256 covers canonical payload bytes. Checksums are integrity tools, not online signatures or anti-cheat requirements. `run_creation_draft` and `current_run` are mutually exclusive. A draft with status `seed_reserved` has an empty offer array and selection. `offers_ready` has exactly four complete offers and no accepted pair; `selection_ready` has the same four offers and exactly two distinct selected IDs. No state may serialize a partial offer array, one selected ID, or a draft whose seed ordinal is not less than `next_run_ordinal`. Wall-clock fields may be stored for display and diagnostics only. They cannot select conflict winners or calculate gameplay. ### 3. Versioning And Compatibility | Field | Changes when | Compatibility rule | |---|---|---| | `profile_schema_version` | settings/slot index layout changes | profile-only ordered migration | | `save_schema_version` | Guild/run/operation serialization changes | sequential copy migration required | | `ruleset_version` | combat, target, price, failure, or progression formula changes | committed battle finishes under stored version | | `content_revision` | stable catalog row or localization data changes | stable-ID mapping or explicit legacy handling | The current schema and previous three shipped schemas must have tested adjacent migrations. Older schemas may have a longer supported chain; absence of a chain blocks that slot with export/recovery options and never authorizes reset. A run-creation draft, battle, reward draft, Market board, or outcome already committed stays on its stored ruleset/content snapshot. A new ruleset becomes active only before seed reservation or a new Market is generated, after all prior result operations are finalized. It cannot rematerialize an existing opening four. No shipped gameplay save exists during this design-only stage. These rules bind all later prototype and production schemas and do not imply a current runtime migration obligation. ### 4. Operation Identity And Status Every state-changing action has: ```text operation_id = hash(Guild_id, lineage_id, commit_sequence_at_intent, operation_kind, source_stable_id, local_nonce) intent_hash = sha256(canonical_operation_inputs) status: pending | applied | rejected ``` The journal row stores: ```text operation_id, operation_kind, intent_hash, status pre_commit_id, result_commit_id cost_delta, result_delta, rejection_reason run_id, Market_index, encounter_id, simulation_tick as applicable receipt_hash, previous_closure_receipt_hash as applicable ``` Rules for duplicate IDs: - same `operation_id` and same `intent_hash`: return stored pending status, applied receipt, or rejection without creating a new operation; - same ID and different hash: reject `OPERATION_ID_CONFLICT`, applying nothing; - new ID: validate and enter the transaction procedure below. Applied IDs remain in the full journal through run close. They then compact into an immutable membership set retained for the Guild lineage. Receipt-bearing casualty, reward, boss-clear, Renown, run-close, migration, and delete operations remain in the redundant closure ledger until the Guild slot is deleted. The detailed journal is bounded to 4,096 rows. At a Market with no pending operation, reaching 3,584 rows compacts the oldest finalized non-closure rows into sorted exact-ID segments containing operation ID, intent hash, final status, and receipt hash. The newest 512 detailed rows and every closure receipt remain expanded. Lookup checks exact segments before accepting a new ID; probabilistic membership is forbidden because a false match could reject a valid purchase or hide a duplicate. ### 5. Pending-To-Applied Transaction Procedure Every durable transaction uses these steps: 1. Look up ID/hash before current-state validation and return any existing row. 2. Validate the active commit, legal phase, referenced IDs, target, and intent. 3. Build a candidate child commit containing a `pending` row with the complete immutable intent and **zero** `cost_delta`/`result_delta`. 4. Validate, write, flush, atomically point to, and read back that pending child. 5. From the pending intent and unchanged parent facts, compute the complete cost and result. No new random draw is allowed; generated outputs were fixed in intent or derive from stored labeled seeds. 6. Build one child that replaces `pending` with `applied`, includes all cost and result deltas, receipt, and closure link when required. 7. Validate schema, nonnegative resources, unique ownership, Recruit/equipment consistency, Market lineage, battle hashes, and operation transition. 8. Serialize to a new file, write integrity values, flush file and directory, atomically replace the active pointer, then read back. 9. Rotate backups only after the applied child reads back and validates. A precondition failure after step 3 produces a `rejected` child with zero deltas and one reason. It cannot return to pending. Presentation, sound, achievement, cloud upload, and screen transition occur only after step 9. #### 5.1 Crash And Retry Boundaries | Crash point | Reachable active state | Recovery/retry | |---|---|---| | Before pending pointer switch | Parent only | retry creates same intent; no cost exists | | After pending switch | Pending intent, zero deltas | deterministic finalize or reject once | | During applied pointer switch | Pending or complete applied child | validate selected pointer; finalize or return receipt | | After applied switch, before backup rotation | Complete applied child | return stored receipt; never reapply | | During backup/closure replication | Applied active plus older replicas | repair replicas from active receipt; no gameplay replay | Recovery may finalize a pending buy, casualty, reward, or run-close operation only from its fixed intent. It never asks the player to redraw or reconfirm a result whose confirm was already durably recorded. A pending destructive action that lacks a valid target after recovery becomes rejected with no deltas. ### 6. Transaction Boundaries | Action | Pending intent contains | Applied child contains | |---|---|---| | Begin run creation | Contract, difficulty, expected `next_run_ordinal`, derived draft/run IDs and seed, version/role-weight snapshot | one `seed_reserved` draft and ordinal increment; no offers or `current_run` | | Materialize opening offers | draft ID/hash, run seed hash, versions, expected empty offer set | all four indexed offer records/IDs/output hashes and one offer-set hash | | Set opening selection | draft ID/hash, offer-set hash, expected selection revision, exactly two distinct offer IDs | same four offers, canonical selected pair, revision increment, receipt | | Commit run creation | draft ID/hash, offer-set hash, selection revision, exact pair and output hashes | draft removed; same run ID/seed and selected Recruit records in one new `current_run`; opening Coin/capacity and run-start receipt | | Buy Recruit | offer ID, recruit output hash, Credit choice, expected price | Coin/Credit cost, offer removal, Recruit ownership | | Buy/sell equipment | offer/item ID and expected receipt | Coin delta and exactly one ownership change | | Lock/refresh | Market hash, selected locks, expected cost | Coin cost, counters, complete fixed offer board | | Equip/reorder | Recruit, candidate item, expected prior item or null, and/or order IDs | one-slot replacement receipt, complete legal inventory and Party-line state | | Promote | Recruit, old/new Profession, eligibility proof | one Profession replacement and derived-state refresh | | Dismiss | Recruit, optional equipped item ID, rebate preview, expected `live_recruit_count` | Recruit removal, optional item return, Coin rebate, post-count at least one | | Commit battle | battle offer, lineup, stats, seed, risk | immutable encounter start snapshot | | Start retreat | encounter, accepted tick | one retreat timestamp; no duplicate start | | Lock outcome | objective and final state hashes | immutable victory/defeat/timeout/retreat result | | Apply casualties | exact Recruit/optional-item/Credit set | all Recruit removals, all present item returns, all Credit grants | | Claim reward | fixed draft/card/disposition | one reward and draft removal | | Close run | terminal cause and persistent grants | Coin/Credit clear, run result, Records/Renown once | | Change difficulty/law | Guild-only selected rule set | next-run configuration only | An operation cannot use a presentation animation as a commit boundary. A double-tap, key repeat, controller repeat, OS lifecycle retry, or cloud retry returns the same status/receipt. ### 7. Run Creation, Market, And Round Save Points #### 7.1 Seed-First Run Creation `Begin run creation` derives values without an ambient RNG or wall clock: ```text seed_ordinal = next_run_ordinal run_seed = low128(sha256(generation_root_seed || lineage_id || "run-seed" || u64(seed_ordinal))) draft_id = low128(sha256(run_seed || "run-creation-draft")) run_id = low128(sha256(run_seed || "run-id")) ``` Its pending intent fixes the chosen Contract/difficulty and generation snapshot but generates no Recruit. Its applied child creates the `seed_reserved` draft, increments `next_run_ordinal` once, mirrors a seed-reservation receipt into both closure ledgers, and is flushed, pointed to, and read back before the opening generator may run. A retry from the unchanged parent derives the same ordinal and seed. Once a draft exists, a new begin request returns `RUN_CREATION_DRAFT_ACTIVE` and that draft; it cannot consume another ordinal. If `current_run` exists, begin returns `RUN_ALREADY_ACTIVE` and applies nothing. `Materialize opening offers` uses only the read-back draft and the content authority's fixed mappings for indices `0..3`. One applied child stores all four complete Recruit records, offer IDs, output hashes, and their canonical offer-set hash. A missing index, duplicate ID, output-hash mismatch, changed generation snapshot, or any fifth offer rejects with zero deltas and leaves the same reserved seed. The materialization receipt is mirrored redundantly and is sufficient to regenerate and verify the same four records. The UI may hold a zero- or one-card highlight transiently, but the durable `Set opening selection` operation accepts only a canonical unordered pair of two distinct IDs from the saved four. A different legal pair replaces the prior pair and increments `selection_revision`; repeating the same operation ID/hash returns its original receipt. A new operation requesting the already accepted pair returns `SELECTION_UNCHANGED` and that receipt without a commit. The player may revise the pair until Run commit without regenerating an offer. Back or Cancel exits the view only; it does not discard the draft, change its Contract/difficulty, consume an ordinal, or expose a refresh action. Save and Quit, suspension, process restart, locale/timezone change, and wall-clock rollback reopen the same four offers and latest durable pair. No player-facing action allocates a replacement draft while one exists. `Commit run creation` revalidates the draft ID/hash, offer-set hash, exact selection revision, pair, and both selected output hashes. Its applied child is one atomic state: it removes the draft, creates `current_run` with the same `run_id` and `run_seed`, transfers the two unchanged Recruit records, establishes 52 Coin and Line capacity four, and writes the run-start checkpoint and receipt. There is no intermediate state with both objects or neither object. A request for a stale draft/revision returns `STALE_RUN_CREATION_DRAFT` plus the current draft summary and applies nothing. A retry naming an already promoted draft and matching its commit receipt returns `RUN_CREATION_ALREADY_APPLIED` plus the original receipt; a conflicting pair/hash is rejected. Neither path generates offers or creates a second Run. The Run-creation commit receipt is indexed by both `operation_id` and `draft_id`. Therefore a duplicate confirm with the original ID and a recovery retry that acquired a new operation ID both resolve to the one applied receipt when their draft/pair/hash intent matches. A reused `draft_id` with different intent returns `RUN_CREATION_COMMIT_CONFLICT` and cannot reach the generic new-ID path. ##### Run-Creation Crash And Retry Matrix | Durable boundary | Reachable state after recovery | Exact retry result | |---|---|---| | Before begin-pending pointer | parent, no draft, unchanged ordinal | derive the same ordinal/seed and retry | | After begin-pending pointer | fixed seed intent, zero deltas | finalize the same `seed_reserved` draft once | | After seed-reservation pointer/read-back | `seed_reserved`, no offers | materialize indices `0..3` from that seed | | Before/during materialization pointer | seed-only or one complete four-offer child | validate pointer; regenerate same four or return receipt | | After materialization pointer | `offers_ready`, complete saved four | reopen exact four; no generator call on normal load | | Before/during selection pointer | prior pair or one complete revised pair | validate pointer; finalize pair or return its receipt | | After selection pointer | `selection_ready` with exact pair/revision | reopen same pair; later revision remains legal | | Before/during Run-commit pointer | complete draft or complete `current_run` | finalize from pending intent or return original commit receipt | | After Run-commit pointer, before replica rotation | `current_run`, no draft | repair replicas; never recreate draft or transfer twice | Every row uses the generic pending-to-applied procedure in Section 5. A corrupt candidate is never partially merged with its parent. #### 7.2 Market, Round, And Run Save Points Safe commits occur after: - run-seed reservation, complete opening-offer materialization, each accepted two-Recruit selection revision, and atomic Run creation; - Market generation, lock, refresh, buy, sell, equip, reorder, promote, and dismissal; - battle offer commit and countdown start; - accepted retreat start; - encounter outcome lock; - casualty application; - reward claim or failure application; - capacity increase, boss Muster, boss result, and run close. `Save and Quit` completes the current tick/transaction and points to the same active commit. It does not create a selectable branch or reroll point. Loading a Market returns the exact offers, locks, refresh counter, Coin, Credit, Company, Reserve, inventory, and order. Failed attempts increment `Market_index` but not `cleared_rounds`. The next Market still prepares the same required Round number with a new precommitted board from the run seed. A boss failure reopens boss Muster with the same fixed boss and newly derived Recruit/equipment offers. This progression cannot be reset by closing or restoring a player-selectable save. ### 8. Battle Interruption And Deterministic Resume An encounter snapshot stores: ```text encounter_id, ruleset_version, content_revision, root_seed simulation_tick and per-label draw counters ordered actor IDs/footprints, fixed-point HP/stats/resources/readiness casts, projectiles, movement intents, summons, statuses, barriers, cooldowns objective/phase/Overtime/retreat state automatic event journal and accepted lifecycle commands snapshot_hash, previous_snapshot_hash ``` The game writes a resumable snapshot every ten ticks, at every accepted retreat command, after every Fallen/collapse batch, and at outcome lock. On normal suspend it completes the current priority batch before acknowledging suspend. If killed earlier, recovery: 1. loads the newest valid encounter snapshot; 2. replays deterministic automatic events and accepted lifecycle commands from the previous valid hash to the last journaled tick; 3. verifies all labeled draw counters and state hashes; 4. resumes at the first unprocessed priority of the next tick. No wall time is substituted. A week-long suspend resumes the same tick. Camera, animation, particles, and audio may restart; authoritative events may not. If all encounter snapshots are corrupt but the committed battle start and event journal validate, replay from countdown using the same seed and retreat tick. If replay hash diverges, seal the run as `recovery_incomplete` under Section 12; never offer a fresh seed or pre-battle edit after observed casualties. ### 9. Recruit Death, Equipment Return, And Dismissal #### 9.1 Casualty Settlement Fallen state exists in battle snapshots as soon as the death batch resolves. Run ownership changes only in the casualty settlement after outcome lock. The pending intent lists, for every casualty: ```text recruit_id, final Profession/level/XP/Trait/history hash equipped_item_id or null original list price, Coin paid, computed Credit grant death tick and causal event ID ``` Applied settlement must satisfy: ```text all casualty Recruit IDs absent from living Company and Reserve every non-null casualty equipped_item_id present exactly once in run inventory Replacement Credit equals the capped sum fallen total increases by exact casualty count no non-casualty Recruit or item changes ownership ``` If any condition fails, the candidate is rejected and the outcome remains locked pending recovery. The game cannot enter the next Market with a partial casualty result. Casualties apply on victory, defeat, timeout, and retreat. A same-batch mutual defeat does not preserve either Fallen Recruit. Rehearsal simulations create no operation and cannot affect ownership. #### 9.2 Dismissal Dismissal is an explicit destructive operation from a Market. The pending review shows generated name, Profession, Trait, level, survival history, returned equipment, Coin rebate, resulting deployable footprint, and no Credit grant. Default focus is cancel. Both preview and commit use the product authority's canonical count: ```text live_recruit_count = count(unique Recruit IDs owned by the current run whose state is living, across deployed party and Reserve) dismissal_legal = Market_open and target_is_living and live_recruit_count >= 2 ``` Dismissal is rejected for a Recruit referenced by a committed battle, pending promotion, pending casualty settlement, or another dismissal. It is also rejected as `FINAL_LIVE_RECRUIT` when the canonical count is one. Preview rejection creates no operation ID, pending row, or save mutation. A crafted or stale confirm is revalidated before a pending gameplay operation can apply. Its `FINAL_LIVE_RECRUIT` response has zero cost/result deltas: no Recruit or equipment moves, no Coin rebate, no Credit, no protected recovery offer, no dismissed-total change, and no commit-sequence advance. The implementation may retain only the rejected intent response keyed by operation ID and intent hash so duplicate confirms return the same response; this is not an applied/pending gameplay receipt and cannot later become legal after the Company changes. A pending dismissal recovered after interruption stores its parent commit and expected count. Before transition to applied, it must prove the active parent is unchanged, pre-count is at least two, and post-count is exactly pre-count minus one and at least one. Otherwise it becomes the same zero-mutation rejected intent response. A successfully applied dismissal returns its original receipt on duplicate confirm and cannot remove another Recruit or pay a second rebate. Explicit `Abandon Run` is a separate run-close operation; it does not reuse a dismissal ID or pay a rebate. Casualty settlement is also separate and remains the only path by which a final Recruit's death can create Credit, a protected offer, recovery viability evaluation, or Company collapse. #### 9.3 No Resurrection Boundary Applied casualty receipts are closure receipts. An older backup that predates a casualty can become active only after the receipt chain deterministically replays through that casualty or after the affected run is sealed. A recovery UI must never present "continue run" from an older state containing a Recruit whose later valid casualty receipt is known. ### 10. Duplicate Purchase, Reward, And Persistent Grant Protection UI debounce is optional convenience; operation IDs are authority. For purchase: ```text if operation applied: return stored Recruit/item and receipt if pending: finalize same fixed offer and price if offer absent under a new operation ID: reject OFFER_ALREADY_CONSUMED ``` For reward: ```text verify card ID belongs to stored draft pending contains exact selected card and replacement choice if required applied removes draft and adds one item/Artifact/Coin result ``` For Renown, clear, and discovery facts, the stable grant ID is derived from Guild ID plus objective/content ID. A repeated boss outcome or platform retry finds the existing applied ID and grants nothing again. Optional platform achievements derive from applied Records. The outbox holds at most 100 idempotent events. When full, older events are regenerated from Records rather than blocking play or changing gameplay resources. ### 11. Backup, Corruption, And Closure Receipts #### 11.1 Backup Set Each Guild slot stores: - `active`: newest validated commit; - `backup_1..4`: distinct prior verified transaction boundaries; - `run_creation`: latest verified seed/offers/selection draft boundary until atomic Run commit; - `run_start`: current run creation commit until run close; - `Market_checkpoint`: latest Market-open commit; - `pre_migration`: source bytes before the latest migration; - `closure_A` and `closure_B`: alternating append-only closure receipt ledgers; - `quarantine`: corrupt bytes and diagnostics, never auto-deleted. Backups rotate only after active read-back. Storage pressure removes diagnostic logs before any active, closure, run-creation, run-start, Market, or pre-migration copy. Seed reservation, offer materialization, selection revision, and Run commit receipts are mirrored into both closure ledgers under `run_creation_receipt_head`. Older selection receipts may compact only after an exact-ID segment and the latest complete pair/revision snapshot are retained. #### 11.2 Validation Order 1. envelope parse and size bounds; 2. CRC32 and SHA-256; 3. schema and required fields; 4. Guild/lineage/parent/sequence links; 5. operation status transitions and receipt chain; 6. nonnegative Coin/Credit/Renown and cap checks; 7. Recruit uniqueness, generated output hashes, and Profession topology; 8. equipment ownership uniqueness and equip references; 9. run-creation seed ordinal, draft/current-run exclusivity, indexed opening offer hashes, and selection revision; 10. Market seed ancestry, offers, locks, and counters; 11. encounter snapshot, event journal, draw counters, and outcome; 12. persistent clear/discovery IDs and run-close consistency. A settings error falls back to defaults without touching gameplay. Optional cloud/platform failure never labels a local save corrupt. #### 11.3 Recovery Algorithm 1. Validate active, then backups newest to oldest. 2. Validate both closure ledgers and choose the longest common valid chain. 3. Select the newest valid gameplay commit whose ancestry matches the slot. 4. Before Run commit, reconstruct a draft only from a valid seed-reservation receipt plus a complete matching receipt chain. Regenerate the four offers and verify their saved hashes, then restore the latest complete pair/revision. 5. After a Run-commit receipt exists, never reconstruct its former draft. Recover the matching `current_run`, or seal it if the full transferred state cannot be verified. 6. Replay later closure receipts only when parent/result hashes form a complete chain and each result validates. 7. If the chain reconstructs the newer state, write a recovered child and continue normally. 8. If a missing/corrupt gap crosses a Run commit, casualty, reward, boss clear, Renown grant, or run close, restore persistent Guild state only through the verified boundary and seal the current run as `recovery_incomplete`. 9. If no active, backup, draft checkpoint, or redundant receipt proves the reserved seed, mark the slot `creation_recovery_blocked`; do not advance the ordinal, allocate another seed, or offer a playable branch. Export and the existing explicit Guild-slot delete/reset recovery remain available. 10. Preserve all rejected bytes in quarantine and write a diagnostic manifest. Sealing clears run-only Coin/Credit and prevents reward or casualty farming. Recovered persistent facts are never guessed beyond the last verified receipt. The UI states the boundary and any unverifiable operations; it never claims full preservation without matching hashes. ### 12. Failure State Model And Consequences Failure is classified before one operation calculates consequences: | Kind | Predicate | Casualties | Coin fee | Run transition | |---|---|---|---:|---| | Victory with losses | objective succeeds with one or more Fallen Recruits | Apply all | 0 | pay reward, next Market/boss/clear | | Encounter defeat | all deployed non-summons Fallen or objective failure before timeout | Apply all | difficulty table | no reward; recovery Market if viable | | Timeout defeat | objective incomplete at tick 1500 | Apply prior Fallen only | difficulty table | no reward; recovery Market if viable | | Voluntary retreat | withdrawal completes | Apply all Fallen before completion | difficulty table | no reward; recovery Market if viable | | Run abandonment | player confirms from Market/result | No new casualties | clear all run Coin/Credit | close run, no unearned boss grant | | Company collapse | no living Recruit and no affordable protected recovery hire | already applied | 0 additional | close run | | Process interruption | suspend/crash/power loss | none beyond deterministic replay | 0 | resume/reconstruct; not gameplay failure | | Save corruption | active data fails validation | none invented | 0 | recover or seal; not gameplay failure | Difficulty fees are the sole numeric failure-fee authority: | Difficulty | Encounter defeat | Timeout | Retreat | |---|---:|---:|---:| | Wayfinder | 0 Coin | `min(2,current Coin)` | `min(4,current Coin)` | | Standard | `min(2,current Coin)` | `min(4,current Coin)` | `min(6,current Coin)` | | Oathbound | `min(4,current Coin)` | `min(6,current Coin)` | `min(8,current Coin)` | Fee, casualty settlement, failure totals, consumed battle offer, and next-Market seed advance are one result transaction. Fees never make Coin negative and do not alter Credit. Retreat is therefore a controlled loss rather than a free way to cycle battle/Market offers. #### 12.1 Recovery Viability And Run Close After failure settlement: ```text can_continue = living_recruit_count > 0 or coin + replacement_credit >= protected_offer_list_price ``` If true, open a recovery Market using the same required cleared-Round number. If false, show Company collapse and close the run after confirmation/automatic receipt. Explicitly declining the only affordable protected offer recomputes the predicate and previews run close before confirm. This predicate runs only after casualty/failure settlement or protected-offer decline. Dismissal cannot reduce the canonical live count below one and cannot invoke this recovery/closure path. A player who wants to end a run while one or more Recruits live must use the separate `Abandon Run` transaction. Boss defeat follows the same rule. Cleared-Round count remains 12; boss Muster reopens if viable. No failure restores a consumed reward, dead Recruit, prior Market, or refresh counter. #### 12.2 Run Close Run close stores terminal cause, Company history, all casualties/dismissals, boss/clear facts, discoveries, and eligible Renown. It then clears run-only Coin, Credit, Recruits, inventory, Artifacts, Market, and encounter state. Survivors become nonplayable history Records. One operation applies closure and persistent grants; retry returns the same run result. ### 13. Migration Contract Migration runs only at startup or a Market with no pending operation. It never runs during countdown, battle, outcome, casualty settlement, reward selection, or run close. 1. Validate and copy source bytes to `pre_migration`. 2. Build an adjacent-version plan; skipping a required step is illegal. 3. Resolve stable content IDs and list legacy/missing rows. 4. Apply each pure deterministic migration to a copy. 5. Preserve generated name parts, rendered-name snapshot, appearance seed, attributes, Trait, Profession, level, and survival history for living Recruits; do not draw replacements. 6. Recompute derived stats from preserved source fields under the boundary rule. 7. Validate operation, ownership, Market, battle, and closure chains. 8. Write/read a new lineage child, then switch active pointer. 9. Preserve pre-migration bytes until two later valid Market commits and run close or 30 launches, whichever is later. A removed equipment/Artifact ID becomes a sealed legacy record with its stable ID and original ownership. At the next safe Market, the player chooses one of two deterministic same-band behavior replacements or leaves it sealed. A removed Profession keeps its stored ruleset for the current committed battle; afterward a deterministic parent-compatible replacement review is required. If migration fails, discard the candidate and leave the source active under its last supported ruleset where possible. Mark only that slot `migration_blocked` and offer details/export. Never reset, auto-sell, reroll, or auto-equip. ### 14. Local, Cloud, Multi-Device, And Rollback Cloud transports complete validated commits plus closure ledgers. It does not merge Coin, Recruits, equipment, offers, casualties, rewards, or operation rows. | Commit topology | Resolution | |---|---| | Identical commit | no action | | Local ancestor of cloud | offer verified cloud descendant; retain local backup | | Cloud ancestor of local | keep local; queue upload | | Different Guild/lineage | import only into an empty slot after validation | | Same lineage, divergent descendants | never merge; choose one active branch, archive the other read-only | Conflict comparison shows commit boundary, Region/Contract, Market/encounter, cleared Rounds, living/fallen counts, Renown, and closure receipt head. Wall clock is context only. Default is cancel/inspect. The unchosen divergent branch cannot be duplicated into a second playable slot, because that would duplicate generated offers and allow alternate casualty or reward outcomes. It remains exportable/read-only until explicitly deleted. A developer/support rollback follows the same recovery algorithm as corruption. It may activate an older commit only after replaying later valid closure receipts or sealing the affected run. No debug, platform, or user-facing path may resume an older branch that reverses a known applied casualty or reopens a known claimed reward. ### 15. Clock Rollback And Bounded Offline Behavior All gameplay time uses simulation ticks or monotonic in-session duration. Wall clock is display/diagnostic data. ```text wall_delta = current_wall_clock - last_seen_wall_clock if wall_delta < -300 seconds or wall_delta > 180 days: record CLOCK_ANOMALY change no gameplay state ``` While closed, the game advances exactly zero ticks and generates no Market, offer, Coin, Credit, XP, Renown, healing, promotion, unlock, enemy outcome, or reward. Return opens the saved state plus a compact recap. Background work is bounded: - at most one local save flush at a time; - at most three complete cloud payloads queued per Guild slot; - at most 100 idempotent platform events; - at most 30 seconds of best-effort upload after an explicit foreground save, cancellable without affecting the local commit; - no retry loop blocks exit, local play, or a new local commit. Changing clock, timezone, locale, sleep duration, or network availability cannot change generated names, offers, difficulty, results, or Records. ### 16. Confirmation, Overwrite, Delete, And Reset These actions require an effect review and a separate confirm: dismissal with history, promotion, Artifact replacement, protected recovery-offer decline that would close a run, run abandonment, difficulty/Oath-law change, cloud branch choice, migration fallback, Guild-slot overwrite, and Guild-slot delete. Delete moves the complete Guild slot and closure ledgers to recoverable local trash for seven successful launches or until explicit empty-trash confirmation. A profile-wide reset additionally requires selecting a displayed localized phrase in a second dialog; typing is not required. Default focus is cancel, and destructive actions cannot share a single repeated input with the opener. Every accepted confirm receives an operation ID. Repeating it returns the first receipt and cannot dismiss, grant, overwrite, close, or delete twice. ### 17. Accessibility, Localization, And Input Requirements - `Saving`, `Saved`, `Pending`, `Recovered`, `Sealed`, `Conflict`, and `Blocked` use text plus distinct icons, never color/spinner alone. - Closing during `Pending` is legal; recovery finalizes/rejects from intent. - Recovery and conflict dialogs support 130% UI scale, screen-reader order, complete touch path, keyboard/controller focus, and reduced motion. - Casualty review lists generated name, Profession, equipment returned, Credit, death tick, and first cause; it does not rely on animation or sound. - Technical IDs/hashes are hidden by default but available in details and an exportable diagnostic manifest. - Localized messages use semantic IDs and typed values, never string fragments. - Controller disconnect or focus loss pauses presentation and commits nothing until a new explicit confirm is accepted. - Haptic/audio feedback may acknowledge a save or casualty but cannot be the only state indication. ### 18. Required Recovery And Failure Matrix | Test | Fault/input | Expected invariant | |---|---|---| | Seed reservation crash | crash after begin-pending or applied pointer | same ordinal/seed; zero offers before applied draft read-back; one draft after retry | | Offer materialization crash | crash around four-offer pointer | seed-only draft or complete indices `0..3`; retry yields identical IDs/output hashes | | Selection revision crash | revise accepted pair and crash around pointer | prior complete pair or new complete pair with one revision/receipt; never one selected ID | | Run creation duplicate | repeat original ID or use a new ID naming the applied draft/pair | same original receipt, same seed/two Recruit records, no draft and no second Run | | Run creation stale draft | submit old draft hash or selection revision | `STALE_RUN_CREATION_DRAFT`, current summary returned, zero mutation | | Run creation cancel/restart | Cancel, Save and Quit, or process restart before commit | same draft, four offer IDs/hashes and latest durable pair; no new ordinal/seed | | Run draft clock rollback | wall clock moves back 24 hours before Run commit | diagnostic only; same draft/offers/pair and zero gameplay delta | | Run draft active corruption | invalid active checksum, intact draft checkpoint/backup | recover newest valid draft boundary and exact four/pair; no replacement seed | | Run draft replica corruption | active/backups invalid, redundant creation receipts intact | rebuild same seed/four/pair, or same committed Run if commit receipt exists | | Run draft total corruption | no valid primary, backup, checkpoint, or creation receipt | `creation_recovery_blocked`; quarantine/export, no new draft or free reroll | | Pending purchase | crash after pending pointer | zero cost until deterministic applied child; one Recruit after retry | | Applied purchase | duplicate same operation ID | one cost, one Recruit, same receipt | | Refresh crash | crash after Coin validation | old complete board or new complete board and cost; never mixed | | Legal dismiss duplicate | start with two live Recruits; repeat confirm | one Recruit removal, zero-or-one item return, one rebate; final live Recruit remains | | Final dismiss preview | one live Recruit, low Coin, no protected offer | `FINAL_LIVE_RECRUIT`; no operation ID or mutation; `Abandon Run` remains separate | | Stale final dismiss | preview at two, another serialized dismissal leaves one, submit old confirm | zero-delta `FINAL_LIVE_RECRUIT`; no rebate, protected offer, or count change | | Interrupted final dismiss | recover pending intent against active count one | reject without apply/receipt beyond rejected intent response; one Recruit remains | | Battle suspend | suspend during projectile at tick 417 | identical next event/draw counters/final hash | | Death snapshot | crash one tick after front Recruit falls | replay contains same death and collapse | | Outcome crash | crash before casualty settlement | locked result reopens; settlement applies exact set once | | Casualty partial candidate | omit the non-null equipped item in candidate | validation rejects; no Recruit removal/Credit commits | | Reward duplicate | double-tap selected card | one item/Artifact/Coin result and draft removal | | Boss grant duplicate | replay same boss-clear result | one clear fact and Renown grant | | Three deaths | fixed economy fixture | Recruits removed, all equipment returned, 54 Credit capped | | Standard retreat | 10 Coin at/after tick 70 | 6 Coin fee, all earlier casualties apply, no reward | | Wayfinder timeout | 1 Coin at tick 1500 | 1 Coin fee, living Recruits survive, no reward | | Company collapse | zero living, 9 Coin+Credit, protected price 14 | run closes; no free Recruit invented | | Recoverable company | zero living, 14 Coin+Credit, protected price 14 | recovery Market opens; purchase still requires confirm | | Clock rollback | wall clock moves back 24 hours | diagnostic only; zero gameplay delta | | Thirty-day offline | close mid-run and return | zero tick/resource/offer progress; exact recap | | Active corruption | invalid active checksum, intact receipts/backups | reconstruct newest valid chain or seal run at stated boundary | | Casualty receipt beyond backup | selected backup contains later-Fallen Recruit | replay casualty or seal run; never resume with Recruit | | All battle snapshots corrupt | valid start/journal remains | replay same seed/retreat tick or seal on hash divergence | | Migration failure | stable-ID mapping invalid | source stays active; candidate discarded; export offered | | Cloud divergence | same lineage, different descendants | one chosen active, other read-only; no merge/duplicate slot | | Run-close retry | crash after persistent grants before screen transition | same result, Coin/Credit remain cleared, no duplicate Renown | ### 19. Acceptance Checklist - [ ] Schema, ruleset, content, lineage, commit, and operation versions are separate and migration is copy-first. - [ ] Pending/applied/rejected operations preserve zero-delta pending and atomic cost/result receipts. - [ ] Run creation durably reserves one seed before offer generation, stores an all-or-nothing indexed four, receipts revisable exact-pair selection, and promotes that same seed and pair into `current_run` exactly once. - [ ] Market, battle, casualty, reward, and run-close retries are idempotent. - [ ] Battle suspend/crash reproduces deterministic state or seals the run on an unverifiable divergence. - [ ] Death, equipment return, Credit, dismissal, replacement, defeat, timeout, retreat, and Company collapse are explicit and testable. - [ ] Preview, stale confirm, duplicate confirm, and interruption cannot dismiss the final living Recruit or route dismissal through casualty recovery. - [ ] Backups, closure receipts, corruption, migration, rollback, and cloud conflicts cannot knowingly reverse casualties or duplicate rewards. - [ ] Clock rollback and bounded offline behavior produce zero gameplay progress. - [ ] Confirmation, delete, accessibility, localization, and input rules cover every destructive and recovery state.