realms-in-ruin-dev/Documentation/Phase2/03-SharedGameplayContracts.md

Phase 2A — Shared Gameplay Contracts

Field	Value
Status	Complete
Date	2026-07-17
Phase	2A2b — Owner contract approvals
Proposal commit (2A2a)	c2fa15db
Starting Git commit (this pass)	c2fa15db
Owner decision date	2026-07-17
Engine	Unreal Engine 5.8
Rule	C-001 through C-015 are Approved or Approved with Conditions. This document defines the approved architecture boundary. It does not authorize implementation or Phase 2A3.

Purpose

Apply project-owner decisions to the Phase 2A2a shared gameplay contract proposals. Establish the approved architecture boundary for later implementation planning. Preserve evidence, alternatives, deferred implementation choices, and runtime validation obligations.

Evidence vocabulary

Label	Meaning
Static evidence	Phase 1 archaeology observation
Runtime evidence	Phase 2A1 observed runtime behavior or tool limitation
Tool limitation	Cannot observe because tooling/environment blocked the path
Inference	Reasonable conclusion not directly proven
Approved architectural rule	Owner-approved boundary (architecture)
Deferred implementation choice	Must be resolved in planning/implementation batches — not an open architecture conflict
Runtime validation obligation	Required later test; not an architecture approval blocker

Decision states

Approved · Approved with Conditions · Deferred · Rejected · Rejected by Existing Evidence

Continuity

Check	Result
Phase 2A2a documents reviewed and committed	Yes — c2fa15db
Starting git rev-parse HEAD	c2fa15dbe3142fcf0252b91af4bb205a51f64a52
Working tree at start	Clean

Cross-links: 00-Phase2A-RuntimeBaseline.md, 01-Phase2A-RuntimeEvidenceIndex.md, 02-Phase2A-OpenDecisions.md, 04-Phase2A-DecisionRegister.md.

---

C-001 — Canonical player resource source of truth

State: Approved
Owner decision date: 2026-07-17

Owner decision

ASC attributes are the sole authoritative source for Health, MaxHealth, Mana, MaxMana, Stamina, and MaxStamina. DEPRECATED Blueprint resource variables are not authoritative.

Problem being solved

Combat, death, ability costs, potions, and HUD currently read different resource stores. ASC and DEPRECATED Blueprint values diverge immediately after spawn.

Current implementation

• Player ASC + AttributeSet live on ARIRPlayerState.
• Overlay HUD binds ASC Health/Mana.
• Abilities and Amazonian inbound damage use DEPRECATED floats.
• Consumable GEs modify ASC attributes only.
• No sync between ASC and DEPRECATED pools.

Confirmed evidence

Kind	Evidence
Static	Docs 05, 06 §8, 01 P0 dual-resource risk
Runtime	RE-2A1-001/012: ASC Health 75/100, Mana 25/50, Stamina 0/0
Runtime	RE-2A1-004/005/013: legacy pools diverge (zeros / Paladin mana 100)
Runtime	RE-2A1-002/003: no active GEs; no granted GAs at spawn

Approved architectural rule

ASC attributes are the sole canonical source of truth for Health, MaxHealth, Mana, MaxMana, Stamina, and MaxStamina. DEPRECATED Blueprint resource variables are not authoritative. UI, costs, healing, damage, death, and gameplay gating ultimately read the canonical ASC attributes. Spawn divergence is a dual-store defect, not two valid truths.

Deferred implementation choices

None for this contract’s architecture. Consumer migration sequencing is implementation planning.

Alternatives (historical)

Alternative	Status
Legacy-only SoT during reconstruction	Rejected as end state
Character-specific dual-SoT	Rejected — prolongs P0
ASC sole SoT	Approved

Allowed behavior

• Reading ASC for gameplay and UI.
• Writing ASC through shared authoritative boundaries (C-003, C-005, C-006).
• Temporary ASC→legacy shadow for named unconverted read-only consumers (C-004).

Prohibited behavior

• Treating DEPRECATED floats as authoritative for new gameplay.
• UI or death decisions driven solely by DEPRECATED values after cutover.

Transitional behavior

ASC→legacy one-way shadow only under C-004. Legacy writers must be migrated or blocked.

Dependencies

C-002, C-003, C-004.

Migration impact

Ability costs, Amazonian AnyDamage/death, Cleric heal, Overlay, Server_UpdateHUD callers, stamina systems.

Runtime validation obligation

Post-init ASC match; potion and combat mutate ASC; death from ASC Health ≤ 0. (RE-2A1-022 death path still untested.)

Failure modes

Partial migration desync; shadow omitted while legacy death still active.

Approval question

Resolved — Owner approved 2026-07-17.

---

C-002 — Character default attribute initialization

State: Approved with Conditions
Owner decision date: 2026-07-17

Owner decision

Use character-specific default Gameplay Effects, subject to the constraints below.

Approval conditions

• Apply on the authoritative server.
• Apply only after ASC actor info and avatar assignment are valid.
• Apply deterministically on initial spawn and respawn.
• Explicitly initialize all six current/max attributes.
• Do not rely on native stamina fallback values.
• Do not rely on inconsistent Blueprint CDO values.
• Missing character-default configuration must produce a visible failure.
• Prevent accidental duplicate initialization.

Problem being solved

All inspected characters spawn with identical native ASC defaults. Orphan character default GEs are unreferenced. Stamina ASC remains 0/0.

Current implementation

• Native InitHealth/Mana only; Stamina not Init’d.
• DefaultAttributesGameplayEffect = None.
• Orphan GE_*_DefaultAttributes lack Max* modifiers and have 0 referencers.

Confirmed evidence

Kind	Evidence
Static	Doc 06 §§2–4
Runtime	RE-2A1-001, 002, 011, 012

Approved architectural rule

Character-specific default Gameplay Effects initialize all six attributes on the server after ASC Owner/Avatar are valid, on spawn and respawn, with visible failure on missing configuration and protection against duplicate initialization.

Deferred implementation choices

• Exact data mapping mechanism (class→GE selection / asset wiring).

Alternatives (historical)

Alternative	Status
A. Character-specific default GE	Approved with Conditions
B. Shared init GE + SetByCaller	Retained historical alternative
C. Native initialization service	Retained historical alternative

Allowed / Prohibited / Transitional

As in conditions: server-only after actor info; no silent native/CDO fallback; no duplicate apply.

Dependencies

C-001, C-012.

Migration impact

PlayerState, character GEs (must include Max*), Gunslinger missing GE, spawn/respawn.

Runtime validation obligation

Per-class ASC after spawn/respawn; missing assignment visible error; no duplicate GE apply.

Approval question

Resolved — Owner approved with conditions 2026-07-17.

---

C-003 — Resource-access boundary

State: Approved
Owner decision date: 2026-07-17

Owner decision

Use a shared server-authoritative ASC resource boundary. All new reads, affordability checks, costs, restoration, maximum queries, and gameplay gates must use this boundary. Cost validation and commitment must be atomic.

Problem being solved

Ad-hoc DEPRECATED floats, FCanUseMana, ApplyDamage, and GEs create dual writers.

Current implementation

Abilities use DEPRECATED mana/health; potions use ASC GEs; Overlay uses ASC; no shared API above ASC.

Confirmed evidence

Static: docs 05, 06, 07 S9. Runtime: RE-2A1-001–005, 012–015 (cost path not exercised).

Approved architectural rule

Shared server-authoritative ASC resource boundary for all new resource access. Atomic cost validation and commitment on the server. No new direct DEPRECATED resource authority.

Deferred implementation choices

Exact interface surface / native vs Blueprint-callable packaging.

Alternatives

Per-system ad-hoc ASC reads — Rejected (recreates dual writers).

Dependencies

C-001, C-002, C-004, C-006.

Runtime validation obligation

Cost reduces ASC once; failed affordability leaves attributes unchanged. (RE-2A1-015 Tool Limitation.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-004 — Legacy compatibility policy

State: Approved (transitional only)
Owner decision date: 2026-07-17

Owner decision

Allow ASC-to-legacy one-way shadow values only for an identified read-only legacy consumer that cannot yet be migrated. ASC remains authoritative. Shadows are derived from ASC. Legacy code may not write through the shadow. Legacy direct writers may not update canonical attributes. Bidirectional synchronization is rejected. Feedback loops are prohibited. A shadow must have a named consumer and removal condition. Intended end state: no legacy resource shadow. Option D (no synchronization) remains preferred whenever a consumer can be migrated directly.

Problem being solved

Unconverted legacy readers still exist while ASC becomes canonical.

Current implementation

No sync. ASC and DEPRECATED diverge at spawn.

Confirmed evidence

Static: doc 06 sync Missing. Runtime: RE-2A1-004, 005, 013.

Approved architectural rule

Temporary ASC→legacy one-way shadows only for named, removable, read-only consumers. Bidirectional sync rejected. Legacy writers cannot update ASC. Prefer direct migration (no shadow) when feasible. End state: zero shadows.

Deferred implementation choices

• Whether any real consumer requires a temporary legacy shadow (inventory during implementation planning).

Alternatives

Alternative	Status
A. Bidirectional synchronization	Rejected
B. Legacy→ASC as primary	Rejected
C. ASC→legacy one-way shadow	Approved (transitional only)
D. No sync; migrate first	Preferred when migratable

Dependencies

C-001, C-003.

Runtime validation obligation

Shadow matches ASC after mutation; legacy cannot overwrite ASC.

Approval question

Resolved — Owner approved as transitional only 2026-07-17.

---

C-005 — Damage contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Establish one server-authoritative damage boundary that validates source and target, preserves instigator and damage-causer information, calculates or accepts validated damage magnitude, applies mitigation at one defined boundary, mutates canonical ASC Health, prevents duplicate damage, triggers authoritative death evaluation, and exposes an observable damage event. Existing ApplyDamage paths may remain temporarily only as adapters. Do not approve a final GameplayEffectExecutionCalculation design yet.

Problem being solved

Fragmented ApplyDamage / legacy health / missing enemy consumers.

Current implementation

Authority ApplyDamage on abilities; Amazonian AnyDamage → DEPRECATED health; enemy reception Missing; no project ExecCalc subclasses.

Confirmed evidence

Static: docs 05, 09, 06. Runtime: RE-2A1-022, 027, 030.

Approved architectural rule

Single server-authoritative damage entry writing ASC Health with validation, mitigation at one boundary, dedupe, death trigger (C-007), and observable damage event. ApplyDamage is transitional adapter only.

Deferred implementation choices

• Gameplay Effect versus ExecutionCalculation details for damage (Deferred — not selected).

Alternatives

Alternative	Status
Shared server damage API writing ASC	Approved (form TBD in planning)
Final GE ExecutionCalculation design	Deferred
Legacy ApplyDamage + DEPRECATED health as end state	Rejected

Dependencies

C-001, C-003, C-007, C-009. Enemy consumers: Phase 2D.

Runtime validation obligation

Single ASC Health reduction; no double apply; death at ≤ 0. (RE-2A1-022 blocked.)

Approval question

Resolved — Owner approved 2026-07-17; ExecCalc deferred.

---

C-006 — Healing and resource restoration contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Healing and resource restoration must execute authoritatively, use the shared resource boundary, clamp to the appropriate maximum, attribute the source, update canonical ASC attributes, and drive HUD updates through attribute delegates. Overheal and over-resource behavior are not permitted by default.

Problem being solved

Dual heal paths (Cleric legacy recover vs ASC GEs); no clamp policy.

Confirmed evidence

Static: docs 05, 06, 12. Runtime: RE-2A1-018.

Approved architectural rule

Server-authoritative restoration via C-003; clamp to Max*; source attribution; ASC mutation; HUD via attribute delegates only; no over-resource by default.

Deferred implementation choices

Whether any future tagged GE may explicitly allow over-resource (none approved now).

Dependencies

C-001, C-003, C-014.

Runtime validation obligation

Clamp at max; potion apply once; Overlay update. (RE-2A1-018 blocked.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-007 — Death contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Death must be evaluated from canonical ASC Health, trigger when Health ≤ 0, execute authoritatively, be idempotent, set one replicated shared dead state, prevent duplicate transitions, cancel or terminate active abilities, disable applicable movement and interaction, drive animation as presentation, and support distinct player and enemy lifecycle consequences without separate definitions of death. Animation may not own the death decision.

Problem being solved

Death from DEPRECATED health; enemy ABP forces IsDead false; no idempotent shared transition.

Confirmed evidence

Static: docs 05, 09, 10. Runtime: RE-2A1-004, 006, 013, 022.

Approved architectural rule

One definition of death: authoritative ASC Health ≤ 0 → idempotent replicated dead state → ability cancel → movement/interaction disable → animation presentation. Player vs enemy differ only in post-death lifecycle (respawn vs destroy/loot), not in death definition.

Deferred implementation choices

Whether State.Dead tag becomes the replicated carrier (implementation planning).

Dependencies

C-001, C-005, C-008 (players), C-011.

Runtime validation obligation

One death transition; no re-entry; ABP follows replicated state. (RE-2A1-022 blocked.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-008 — Respawn contract

State: Approved with Conditions
Owner decision date: 2026-07-17

Owner decision / ownership clarification

GameMode owns authoritative respawn orchestration.

PlayerController owns the persistent player-facing control handoff and may: request respawn when permitted; receive respawn state; possess or be assigned the replacement pawn through the authoritative flow; restore player input and HUD integration.

The dying pawn may report its death but must not create or possess its replacement.

Approval conditions — contract coverage required

• Duplicate-request prevention
• Timing
• Pawn destruction
• Replacement spawning
• PlayerState persistence
• ASC avatar teardown and reinitialization
• Default-attribute reapplication (C-002)
• Possession
• Input restoration
• HUD idempotence (C-013)

Problem being solved

Unverified respawn/HUD recreation; risk of pawn-owned replacement and duplicate overlays.

Confirmed evidence

Static: docs 07 S8, 11. Runtime: RE-2A1-010, 022.

Approved architectural rule

GameMode orchestrates respawn. PlayerController handles request/state/possession handoff/input/HUD. Dying pawn reports only. PlayerState persists. ASC Avatar teardown/re-init and defaults reapply. Idempotent HUD. Duplicate-request prevention.

Deferred implementation choices

Exact timer values and SpawnActor parameter packaging.

Alternatives

Pawn-owned sole Server_RespawnPlayer as primary owner — Rejected.

Dependencies

C-002, C-007, C-012, C-013.

Runtime validation obligation

One death → one respawn; ASC Owner/Avatar correct; one Overlay. (RE-2A1-022 blocked.)

Approval question

Resolved — Owner approved with ownership clarification 2026-07-17.

---

C-009 — Authority contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Clients submit intent. The server validates life state, ability state, target, range, resources, cost, cooldown, and gameplay result. Only the authoritative owner writes replicated gameplay state. Multicast execution is presentation-only.

Problem being solved

Legacy notify-driven gameplay on Multicast montage evaluation.

Confirmed evidence

Static: docs 05, 10. Runtime: RE-2A1-015, 019, 021, 023–026.

Approved architectural rule

Client intent → server validation (life, ability, target, range, resources, cost, cooldown, result) → authoritative state write → multicast presentation-only. Multicast AnimNotify cannot be sole authority for damage, healing, spawning, costs, or state transitions.

Deferred implementation choices

Narrow documented multicast exceptions (none approved now).

Dependencies

C-003, C-005, C-006, C-010, C-011.

Runtime validation obligation

Listen-server: damage once on server; montage both; no client Health write. (Enhanced Input + 2P blocked.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-010 — Animation responsibility contract

State: Approved with Conditions
Owner decision date: 2026-07-17

Owner decision / timing clarification

Animation may own: visual playback, sound timing, cosmetic Niagara timing, camera presentation, cosmetic trails, presentation events.

Animation may emit a timing signal evaluated on the authoritative server. However: a multicast or cosmetic notify cannot be the sole authority for gameplay; timing signals must enter an authoritative ability lifecycle; damage, healing, spawning, resource commitment, death, and guaranteed cleanup remain owned outside cosmetic multicast evaluation; interruption or missing notify execution must not permanently block cleanup.

Do not prescribe the exact replacement timing mechanism in this pass.

Confirmed evidence

Static: doc 10. Runtime: RE-2A1-019–021.

Approved architectural rule

Animation is presentation. Server-evaluated timing signals may feed the ability lifecycle (C-011) but are never sole gameplay authority. Cleanup must not depend solely on notify execution.

Deferred implementation choices

• Exact authoritative animation-timing mechanism (Ability Tasks, windows, etc.).

Alternatives

Notify-authoritative hit windows as end state — Rejected.

Dependencies

C-009, C-011, C-007.

Runtime validation obligation

Interrupt cleanup without AN_AttackComplete. (RE-2A1-020 blocked.)

Approval question

Resolved — Owner approved with timing clarification 2026-07-17.

---

C-011 — Ability lifecycle and cleanup contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Adopt shared lifecycle: Requested → Validated → Committed → Active → Ending → Completed | Canceled | Interrupted | Failed.

Define guaranteed cleanup for: normal completion, input release, validation failure, montage start failure, interruption, death, pawn destruction, target invalidation, timeout or failsafe.

AN_AttackComplete cannot be the only cleanup path.

Confirmed evidence

Static: docs 05, 07 S3/S12, 10. Runtime: RE-2A1-020.

Approved architectural rule

Shared lifecycle states with guaranteed cleanup on all listed terminal/failure paths. No sole dependence on AN_AttackComplete.

Deferred implementation choices

Per-ability cancel/interrupt policy details; exact failsafe timer values.

Dependencies

C-003, C-007, C-008, C-009, C-010.

Runtime validation obligation

Complete and interrupted montages both clear locks; death mid-ability cleans up. (RE-2A1-019–022 blocked.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-012 — PlayerState and pawn ownership contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

For players: PlayerState owns ASC, AttributeSet, and cross-pawn state intended to survive respawn. Pawn owns avatar representation, movement, animation, equipment, transient physical state, and pawn-specific targeting and presentation. Possession and pawn replacement must explicitly reinitialize ASC actor info. Enemy self-owned ASC remains valid and must expose a correct ASC accessor.

Confirmed evidence

Static: docs 06, 09. Runtime: RE-2A1-007, 027, 028.

Approved architectural rule

Player ASC/AttributeSet on PlayerState; pawn is Avatar. Re-InitAbilityActorInfo on possess/replace. Enemy ASC self-owned with corrected GetASC accessor (existing nullptr via PlayerState path is a defect to fix under this contract).

Deferred implementation choices

Exact enemy accessor fix packaging (native interface vs override).

Alternatives

Move player ASC to pawn — Rejected unless future redesign approved.

Dependencies

C-002, C-008, C-013.

Runtime validation obligation

Post-respawn Owner/Avatar; enemy ASC via corrected accessor. Tool inaccessibility ≠ absence (RE-2A1-028).

Approval question

Resolved — Owner approved 2026-07-17.

---

C-013 — HUD data-flow contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

The ASC Overlay/widget-controller path is the only supported gameplay HUD data path. Retire UpdatePlayerHUD. No UI-owned authoritative resource values. Idempotent HUD creation. No duplicate overlays after possession, respawn, or travel. Data driven by replicated ASC attributes. Stamina UI added only after canonical stamina initialization exists. UI cannot mutate gameplay state directly.

Confirmed evidence

Static: docs 11, 07 S10. Runtime: RE-2A1-008, 009.

Approved architectural rule

Overlay/widget-controller only. UpdatePlayerHUD retired. Idempotent HUD. No duplicate overlays. Stamina UI gated on C-001/C-002 initialization. UI read-only for gameplay state.

Deferred implementation choices

Rebind vs recreate Overlay implementation detail (must remain idempotent).

Alternatives

Implement UpdatePlayerHUD as second SoT — Rejected.

Dependencies

C-001, C-002, C-008, C-012.

Runtime validation obligation

One Overlay after spawn and respawn; bars track ASC. (RE-2A1-022 respawn untested.)

Approval question

Resolved — Owner approved 2026-07-17.

---

C-014 — Pickup authority and replication contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

The server owns pickup collection. The server must validate the overlap or collection request, validate the collector, apply the result once, destroy or deactivate the pickup, replicate consistent pickup existence, prevent duplicate collection, and attribute the effect or mutation. Client-overlap RPC is rejected as the default architecture. Client-side effects may occur only after authoritative collection.

Confirmed evidence

Static: doc 12. Runtime: RE-2A1-016, 017, 018.

Approved architectural rule

Server-owned validate → apply once → destroy/deactivate → replicate existence. Cosmetics after authoritative collection. Non-replicated pickups forbidden for network gameplay without explicit server visibility model.

Deferred implementation choices

Exact replication property / dormant pickup pooling strategy.

Alternatives

Alternative	Status
Server-owned overlap apply + replicate	Approved
Client-overlap RPC as default	Rejected
SP non-rep prototypes as MP model	Rejected

Dependencies

C-003, C-006, C-012.

Runtime validation obligation

One apply; ASC change; destroyed on all clients. (RE-2A1-018, 023, 026 blocked.)

Approval question

Resolved — Owner approved 2026-07-17; client-overlap RPC rejected as default.

---

C-015 — Runtime observability contract

State: Approved
Owner decision date: 2026-07-17

Owner decision

Implementation must make observable: character identity, network role, ASC OwnerActor, ASC AvatarActor, current/max attributes, active Gameplay Effects, granted abilities, ability lifecycle state, resource commitments, authoritative damage events, death transitions, respawn transitions, pickup application count.

Permitted mechanisms: structured logs, debugger inspection, Ability System inspection, a bounded temporary test harness. A permanent debug UI is not required.

Confirmed evidence

Runtime tool limits: RE-2A1-015, 023, 028, 031.

Approved architectural rule

Minimum observability list above is required before trusting reconstruction claims. Permanent debug UI not required. Tool inaccessibility is not runtime absence.

Deferred implementation choices

• Exact temporary observability implementation (logs vs harness packaging).

Dependencies

Supports validation of all contracts.

Runtime validation obligation

Each listed field obtainable in a controlled session.

Approval question

Resolved — Owner approved 2026-07-17.

---

Approved architecture boundary summary

Canonical dependency chain

flowchart TD
  attrs[CanonicalASC_C001_C002]
  resource[SharedServerResourceBoundary_C003_C004]
  dmgHeal[AuthoritativeDamageHealing_C005_C006]
  death[IdempotentDeath_C007]
  respawn[GameModeOwnedRespawn_C008]
  hud[ASCDrivenHUD_C013]
  ability[AuthoritativeAbilityLifecycle_C009_C010_C011]
  migrate[CharacterMigration]
  enemy[EnemyReconstruction]
  pickups[ServerOwnedReplicatedPickups_C014]
  observe[Observability_C015]
  attrs --> resource
  resource --> dmgHeal
  dmgHeal --> death
  death --> respawn
  resource --> hud
  respawn --> hud
  resource --> ability
  ability --> migrate
  dmgHeal --> enemy
  death --> enemy
  resource --> pickups
  observe -.-> attrs
  observe -.-> dmgHeal
  observe -.-> ability
  observe -.-> pickups

Text form: Canonical ASC attributes → shared server resource boundary → authoritative damage/healing → idempotent death → GameMode-owned respawn → ASC-driven HUD → authoritative ability lifecycle → character migration → enemy reconstruction → server-owned replicated pickups.

Ownership and authority bullets

• PlayerState owns persistent player ASC state.
• Pawn is the player avatar.
• Enemy ASC is self-owned and requires a corrected accessor.
• Multicast animation is presentation-only.
• Legacy shadow values are temporary, one-way, named, and removable.
• No per-character reconstruction may begin before the shared contracts are planned and the initial Phase 2A implementation sequence is approved.

Rejected alternatives (explicit)

Item	Status
Bidirectional ASC↔legacy synchronization	Rejected
Client-overlap RPC as default pickup model	Rejected
Legacy DEPRECATED vars as authoritative end state	Rejected
Multicast/cosmetic notify as sole gameplay authority	Rejected
UpdatePlayerHUD as second resource SoT	Rejected
Pawn as sole respawn orchestrator	Rejected

Deferred implementation choices (not open architecture conflicts)

Choice	Related
Exact default-GE mapping mechanism	C-002
Gameplay Effect versus ExecutionCalculation details for damage	C-005
Exact authoritative animation-timing mechanism	C-010
Exact temporary observability implementation	C-015
Whether any real consumer requires a temporary legacy shadow	C-004

Runtime validation obligations (not architecture approval blockers)

Area	Evidence
Enhanced Input ability execution	RE-2A1-015, 019, 021; RT-002/004/005
AnimNotify execution roles	RE-2A1-019, 021
Ability cost mutation	RE-2A1-014, 015
Interruption and cleanup	RE-2A1-020; RT-004B
Player damage/death/respawn	RE-2A1-022; RT-006
Two-client replication	RE-2A1-023–026; RT-007–010
Remote character selection	Depends on RE-2A1-023
Pickup authority and visibility	RE-2A1-017, 018; RT-003/010
Enemy attribute mutation	RE-2A1-028, 030; RT-011
Session behavior	Phase 2E; not closed by 2A1

Integrity statement

Markdown-only architecture approval pass. No Unreal assets, source, configuration, plugins, or maps modified. No Unreal MCP or PIE used. No Phase 2A3 implementation planning begun.