docs: block final recruit dismissal

docs/product/ECONOMY_AND_BALANCE.md

@@ -177,7 +177,18 @@ Locked, equipped, or battle-committed items must be released before sale.
 
 ### 5.3 Dismissal Rebate
 
-For a living Recruit:
+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:
@@ -191,6 +202,28 @@ 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
@@ -593,6 +626,7 @@ alter transaction integrity or reintroduce permanent Meta stats.
 | 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 |
@@ -604,6 +638,8 @@ alter transaction integrity or reintroduce permanent Meta stats.
 - [ ] Coin, Credit, XP, Renown, and progression facts have explicit persistence,
       sources, sinks, caps, and non-power boundaries.
 - [ ] 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.

docs/product/GAME_PRODUCT_CONTRACT.md

@@ -117,6 +117,19 @@ same meaning.
 deployment cap. A run's cumulative hire count and living Reserve count are
 independent from Line capacity.
 
+The canonical count used by every dismissal rule is:
+
+```text
+live_recruit_count = count(unique Recruit IDs owned by the current run
+                           whose state is living,
+                           across deployed party and Reserve)
+```
+
+Offers, summons, Fallen Recruits, dismissed Recruits, and pending hires do not
+count. A dismissal is legal only while a Market is open, its target is living,
+and `live_recruit_count >= 2` at both preview and commit. A legal dismissal must
+leave at least one living Recruit.
+
 ## 4. Fixed Content Envelope
 
 The complete package contains exactly:
@@ -247,8 +260,10 @@ than persistent playable units.
 - All rolled attribute totals at a given offer level use the same budget;
   distribution, Profession, Trait, order, and price create value differences.
 - A Recruit has exactly one Trait for its entire lifetime.
-- Dismissal is legal only in a Market, returns equipment, removes the Recruit,
-  and requires review when survival history is nonzero.
+- Dismissal is legal only in a Market when the canonical
+  `live_recruit_count >= 2`, returns equipment, removes the Recruit, and
+  requires review when survival history is nonzero. Preview and commit both
+  revalidate the count.
 - Death never selects or destroys equipped items; they return after outcome.
 - Fallen Recruits do not return later in the run through reload, training,
   healing, promotion, reward, or Meta progression.
@@ -256,6 +271,14 @@ than persistent playable units.
 - All hire, dismissal, casualty, equipment return, and credit changes are
   atomic operations owned by the save/failure authority.
 
+Attempting to dismiss the final living Recruit is blocked with
+`FINAL_LIVE_RECRUIT`. It removes nothing, returns no rebate, creates no
+protected recovery offer, and does not become Company collapse. Ending a run
+with a living Recruit remains the separate explicit `Abandon Run` transaction.
+If the final Recruit instead becomes Fallen, casualty settlement, protected
+recovery, and Company-collapse rules apply without being routed through
+dismissal.
+
 This is an economic and strategic loss model, not a character-bond simulator.
 The result report respects the generated name and survival record without
 creating authored biography obligations.
@@ -423,6 +446,8 @@ With at least five uncoached target players:
 - four distinguish Line capacity, living Company, and cumulative hires;
 - four explain one equipment or order counterfactual before battle;
 - four state what death, dismissal, retreat, and run close preserve;
+- four can explain why the final living Recruit cannot be dismissed and can
+  find the separate `Abandon Run` action;
 - four use refresh and lock without expecting a reload reroll;
 - three voluntarily start another Round or name a specific build test.
 
@@ -462,6 +487,8 @@ separately authorized.
 - [ ] Battle is fully automatic apart from diagnostic controls and retreat.
 - [ ] Generated-Recruit, death, dismissal, replacement, Reserve, capacity, and
       cumulative-hire rules are explicit.
+- [ ] Final-Recruit dismissal is illegal at preview and commit without changing
+      abandonment or casualty recovery.
 - [ ] All four authorities use the same counts, terms, IDs, and ownership.
 - [ ] The complete Market loop includes Recruit, equipment, battle, refresh,
       lock, risk, result, reward, and recovery decisions.

docs/product/SAVE_AND_FAILURE_CONTRACT.md

@@ -190,7 +190,7 @@ that lacks a valid target after recovery becomes rejected with no deltas.
 | Lock/refresh | Market hash, selected locks, expected cost | Coin cost, counters, complete fixed offer board |
 | Equip/reorder | Recruit/item/order IDs | complete legal inventory and Party-line state |
 | Promote | Recruit, old/new Profession, eligibility proof | one Profession replacement and derived-state refresh |
-| Dismiss | Recruit, equipment set, rebate preview | Recruit removal, equipment return, Coin rebate |
+| Dismiss | Recruit, equipment set, rebate preview, expected `live_recruit_count` | Recruit removal, equipment 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 |
@@ -300,12 +300,41 @@ operation and cannot affect ownership.
 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.
+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. Retrying an
-applied dismissal returns the original receipt and cannot produce a second
-rebate.
+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
 
@@ -438,6 +467,11 @@ 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.
@@ -574,7 +608,10 @@ receipt and cannot dismiss, grant, overwrite, close, or delete twice.
 | 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 |
-| Dismiss duplicate | repeat confirm | one Recruit removal, one equipment return set, one rebate |
+| Legal dismiss duplicate | start with two live Recruits; repeat confirm | one Recruit removal, one equipment return set, 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 |
@@ -606,6 +643,8 @@ receipt and cannot dismiss, grant, overwrite, close, or delete twice.
       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.

docs/product/SYSTEMS_AND_BATTLE.md

@@ -659,9 +659,32 @@ do not change the permanence of already Fallen Recruits.
 
 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. Review shows equipment return, rebate, lost level/history,
-and resulting deployable footprint. Confirm removes the Recruit once. Dismissal
-never creates Replacement Credit or a Meta reward.
+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
 
@@ -670,6 +693,8 @@ 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
 
@@ -828,6 +853,7 @@ expected duration, profile assertion, causal-report requirements
 | 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 three items | Recruit removed and all three item IDs returned exactly once |
+| Final dismissal | one living Recruit across deployed plus Reserve | preview/commit reject `FINAL_LIVE_RECRUIT`; no state or recovery-offer change |
 
 ## 25. Acceptance Checklist