Parry and guard

Choose the defense model:

Column	Input
hold-block	held state with published damage/reaction rules
tap-parry	short authored success window
both	held guard plus an explicit parry window
none	no guard/parry mechanic

Rules

Guard/parry windows use the same published logical clock as combat.
Contact eligibility is evaluated at the contact tick before applying reaction effects; same-tick attack/defense transitions follow the project's declared priority rule.
Chip, chip-kill, guard damage, guard break and stamina cost are explicit data or explicitly absent.
Guard direction uses a published arc/facing rule. Do not universally make “back attacks” unblockable; the selected arc decides.
A successful parry causes authored logical states/reactions, not only a flash or sound.
Focus loss or device reset cannot leave a synthetic held-block input stuck.