Handler Burden Ledger / 处理人负荷账本机制

Handler Burden Ledger is the mechanism that prevents named handlers from becoming infinite crisis-solving buttons.

The mechanism records how a person was used, what burden they accepted, which claimant was helped or harmed, and how that burden changes future assignments. It deepens management + RPG play by making character availability a consequence of earlier production decisions rather than a generic cooldown.

Mechanic promise

Whenever a handler resolves or materially affects a crisis, the game may create or update a row in 处理人负荷账本. That row can later be consumed, respected, repaired, traded, or broken by 处理人负荷复盘. If ignored or overdrawn, 处理人透支破口 must make the consequence visible.

The mechanism is satisfied only when burden changes future assignment, not when it merely adds flavor text.

State machine

handler_state:
  fresh:
    can_assign_normally: true
  committed:
    requires_prior_commitment_reference: true
  strained:
    repeat_assignment_requires_support_or_cost: true
  exposed:
    hostile_claimant_can_target: true
  compromised:
    neutral_roles_blocked_or_costlier: true
  refusing:
    assignment_can_be_declined: true
  hostile:
    creates_counteroffer_or_route_block: true
  unavailable:
    explicit_absence_required: true
  recovered_with_scar:
    can_assign_with_route_scar: true
  captured:
    rescue_exchange_or_appeal_required: true

A handler may move more than one step if the branch justifies it, but the implementation must preserve the source burden row and future assignment effect.

Entry rule

Open the mechanism from state, not sequence, when:

  1. a crisis needs a handler or explicit absence;
  2. the eligible handler has a prior burden row, exposed state, compromised role, refusal, hostile posture, capture, or unavailable state;
  3. the current crisis can be affected by support, refusal, overdraw, faction access, replacement, or absence;
  4. the outcome can mutate at least one future assignment, route, claimant posture, or pressure counter.

Required assignments

The associated rite must expose these inputs:

  • burden ledger;
  • target handler or explicit absence;
  • current crisis surface;
  • intended role;
  • prior burden row or explicit absence;
  • support, override, trade, refusal, recovery, replacement, or forced overdraw;
  • claimant benefited and claimant harmed.

Branch families

Supported reuse

A support object lets the handler act again.

Required mutation:

  • one crisis pressure improves;
  • handler remains available or returns as recovered_with_scar;
  • a support cost, exposure, capture, debt, or future restriction rises.

Refusal respected

The player preserves the handler by accepting a weaker or delayed solution.

Required mutation:

  • handler trust, bond, or recoverability improves;
  • the current crisis becomes weaker, delayed, default-ready, public-only, lawful-only, sponsor-only, or costlier.

Access traded

A faction funds, shields, or claims the handler’s next use.

Required mutation:

  • current crisis gains relief;
  • handler becomes compromised, captured, public-only, lawful-only, sponsor-only, or equivalent;
  • faction debt or route pressure rises.

Forced overdraw

The handler is pushed through another crisis without adequate support.

Required mutation:

  • immediate collapse may be softened;
  • handler state worsens;
  • 处理人透支破口 fires or the burden row marks default-ready;
  • future assignment becomes harder, blocked, hostile, or requires recovery.

Replacement or absence

The player uses another handler or records absence.

Required mutation:

  • original handler does not lose additional state;
  • current crisis pays through weaker proof, delay, rival advantage, or unstaffed/default pressure.

Recovery with scar

The player spends support to bring a damaged handler back.

Required mutation:

  • support is spent;
  • handler becomes usable but scarred;
  • one future route carries public-only, lawful-only, sponsor-only, costlier, or recovery-only state.

Counter contract

Each resolution must change at least three counters or durable states. At least one must represent relief and one must represent cost.

Suggested counters/states:

  • handler_burden
  • handler_trust
  • handler_loyalty_doubt
  • handler_refusal_pressure
  • handler_exposure
  • handler_capture_pressure
  • handler_recovery_cost
  • staff_fatigue
  • public_exposure
  • inspection_heat
  • bureau_favor_debt
  • contract_capture
  • edit_debt
  • witness_retaliation_risk
  • route_asset_pressure
  • unstaffed_ticket_risk
  • black_screen_slots
  • future_assignment_cost

Cross-system bridges

Replay evidence shape

mechanic: storyteller.mechanic.handler_burden_ledger.v1
session_id: lens-handler-burden-ledger-v1-<timestamp>
seed: <deterministic-seed>
entry_state:
  crisis_surface: <surface id>
  target_handler: <handler id or explicit absence>
  prior_burden_row: <row id or explicit absence>
  handler_state_before: <state>
  intended_role: <role>
  support_options:
    - <support or override>
offered:
  card: storyteller.card.handler_burden_ledger.v1
  rite: storyteller.rite.handler_burden_review.v1
branch_runs:
  supported_reuse:
    selected_support: <support>
    handler_state_after: <state>
    future_assignment_effect: <effect>
  forced_overdraw:
    event: storyteller.event.handler_overdraft_break.v1
    handler_state_after: <state>
    future_assignment_effect: <effect>
assertions:
  - entry_is_state_driven
  - prior_burden_is_visible
  - support_or_absence_required
  - handler_state_changes_future_assignment
  - break_event_or_default_is_durable
  - no_fixed_turn_trigger

Non-goals

  • Not a generic stamina mechanic.
  • Not a fixed daily upkeep phase.
  • Not a romance/approval score.
  • Not a reason to punish every assignment.
  • Not a filler character scene generator.
  • Not satisfied by page existence; replay must show burden, support/override, branch outcome, counter deltas, and future assignment effect.