From 6aab068876b0680a980df2f6115ed70d8382f436 Mon Sep 17 00:00:00 2001 From: Trevor Date: Fri, 17 Jul 2026 08:20:29 -0700 Subject: [PATCH] Document Phase 2A2b owner approval of shared gameplay contracts. Record Approved and Approved-with-Conditions decisions, reject bidirectional sync and client-overlap pickup RPC, and keep runtime validation as non-blocking obligations. Co-authored-by: Cursor --- .../Phase2/02-Phase2A-OpenDecisions.md | 162 ++- .../Phase2/03-SharedGameplayContracts.md | 1182 ++++++----------- .../Phase2/04-Phase2A-DecisionRegister.md | 366 +++-- 3 files changed, 667 insertions(+), 1043 deletions(-) diff --git a/Documentation/Phase2/02-Phase2A-OpenDecisions.md b/Documentation/Phase2/02-Phase2A-OpenDecisions.md index 86ca6084..bc4a0f28 100644 --- a/Documentation/Phase2/02-Phase2A-OpenDecisions.md +++ b/Documentation/Phase2/02-Phase2A-OpenDecisions.md @@ -1,109 +1,131 @@ -# Phase 2A1 — Open Decisions +# Phase 2A — Open Decisions and Validation Obligations | Field | Value | |---|---| | Status | Draft | | Date | 2026-07-17 | | Phase 2A1 Git commit | `aa0058a0` | -| Phase 2A2a reconciliation commit base | `9919faab` | -| Rule | Options listed in the historical table were not selected in Phase 2A1. Phase 2A2a adds **Proposed** contract links only — **none Approved**. | +| Phase 2A2a commit | `c2fa15db` | +| Phase 2A2b base commit | `c2fa15db` | +| Why Draft remains | Runtime validation obligations are incomplete; architecture contracts are owner-approved but not runtime-proven | -Decisions that remain open after Phase 1 static archaeology plus Phase 2A1 runtime evidence. Do not treat this document as an approved architecture contract. +Architecture questions C-001 through C-015 are **Resolved by owner decision** (2026-07-17). This document no longer holds open architecture conflicts for those contracts. It preserves validation obligations, deferred implementation choices, and historical evidence. + +Contracts: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md) (Status: Complete). Register: [`04-Phase2A-DecisionRegister.md`](04-Phase2A-DecisionRegister.md) (Status: Complete). --- -## Phase 2A2a reconciliation +## Phase 2A2b — Owner decision reconciliation | Field | Value | |---|---| -| Pass | 2A2a — Evidence-to-contract reconciliation | -| Status | Draft | -| Contract document | [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md) | -| Decision register | [`04-Phase2A-DecisionRegister.md`](04-Phase2A-DecisionRegister.md) | +| Pass | 2A2b — Apply owner contract approvals | +| Owner decision date | 2026-07-17 | +| Architecture status | C-001–C-015 resolved | -### Classification of each Phase 2A1 open decision +### Architecture questions resolved by owner decision -| Decision | Classification | Contract link(s) | Notes | +| Decision | Classification | Contract | Owner state | |---|---|---|---| -| Canonical health source of truth | Addressed by Proposed Contract | [C-001](03-SharedGameplayContracts.md#c-001--canonical-player-resource-source-of-truth) | ASC sole SoT Proposed; not Approved | -| Canonical mana source of truth | Addressed by Proposed Contract | [C-001](03-SharedGameplayContracts.md#c-001--canonical-player-resource-source-of-truth), [C-003](03-SharedGameplayContracts.md#c-003--resource-access-boundary) | Merged into C-001 resource SoT + C-003 access | -| Canonical stamina source of truth | Addressed by Proposed Contract | [C-001](03-SharedGameplayContracts.md#c-001--canonical-player-resource-source-of-truth), [C-002](03-SharedGameplayContracts.md#c-002--character-default-attribute-initialization) | ASC SoT Proposed; UI deferred via C-013; whether stamina required for 2B remains design-adjacent | -| Temporary legacy mirror during reconstruction | Addressed by Proposed Contract | [C-004](03-SharedGameplayContracts.md#c-004--legacy-compatibility-policy) | ASC→legacy one-way Recommended; bidirectional Rejected by Existing Evidence | -| Where damage must enter shared framework | Addressed by Proposed Contract + Blocked by Missing Runtime Evidence | [C-005](03-SharedGameplayContracts.md#c-005--damage-contract) | Boundary Proposed; runtime damage path not exercised (RE-2A1-022) | -| Where death threshold evaluation must occur | Addressed by Proposed Contract + Blocked by Missing Runtime Evidence | [C-007](03-SharedGameplayContracts.md#c-007--death-contract) | ASC Health ≤ 0 Proposed; death PIE not run | -| Whether AnimNotifies may trigger authoritative gameplay | Addressed by Proposed Contract + Blocked by Missing Runtime Evidence | [C-009](03-SharedGameplayContracts.md#c-009--authority-contract), [C-010](03-SharedGameplayContracts.md#c-010--animation-responsibility-contract) | Notify-as-sole-authority prohibited as end state; chain not observed | -| Required interruption and cleanup contract | Addressed by Proposed Contract + Blocked by Missing Runtime Evidence | [C-011](03-SharedGameplayContracts.md#c-011--ability-lifecycle-and-cleanup-contract) | Lifecycle Proposed; interrupt test blocked (RE-2A1-020) | -| Required respawn and HUD lifecycle contract | Addressed by Proposed Contract + Blocked by Missing Runtime Evidence | [C-008](03-SharedGameplayContracts.md#c-008--respawn-contract), [C-013](03-SharedGameplayContracts.md#c-013--hud-data-flow-contract) | GM/PC ownership + Overlay-only Proposed; RT-006 blocked | -| Pickup authority model | Addressed by Proposed Contract + Blocked by Test Environment | [C-014](03-SharedGameplayContracts.md#c-014--pickup-authority-and-replication-contract) | Server authority Proposed; overlap/2P not run | -| PlayerState versus pawn ownership boundaries | Addressed by Proposed Contract | [C-012](03-SharedGameplayContracts.md#c-012--playerstate-and-pawn-ownership-contract) | Keep ASC on PlayerState Proposed; enemy accessor still defective | -| How to enable 2-client PIE for remaining evidence | Blocked by Test Environment | — (environment / harness; not a gameplay SoT contract) | See still-blocked list; C-015 observability | -| Enhanced Input injection for automated ability tests | Blocked by Test Environment | — (harness; blocks validation of C-009/C-010/C-011) | See still-blocked list | +| Canonical health source of truth | Resolved by owner decision | [C-001](03-SharedGameplayContracts.md#c-001--canonical-player-resource-source-of-truth) | Approved | +| Canonical mana source of truth | Resolved by owner decision | C-001, [C-003](03-SharedGameplayContracts.md#c-003--resource-access-boundary) | Approved | +| Canonical stamina source of truth | Resolved by owner decision | C-001, [C-002](03-SharedGameplayContracts.md#c-002--character-default-attribute-initialization) | Approved / Approved with Conditions (init) | +| Temporary legacy mirror during reconstruction | Resolved by owner decision | [C-004](03-SharedGameplayContracts.md#c-004--legacy-compatibility-policy) | Approved (transitional only) | +| Where damage must enter shared framework | Resolved by owner decision | [C-005](03-SharedGameplayContracts.md#c-005--damage-contract) | Approved | +| Where death threshold evaluation must occur | Resolved by owner decision | [C-007](03-SharedGameplayContracts.md#c-007--death-contract) | Approved | +| Whether AnimNotifies may trigger authoritative gameplay | Resolved by owner decision | [C-009](03-SharedGameplayContracts.md#c-009--authority-contract), [C-010](03-SharedGameplayContracts.md#c-010--animation-responsibility-contract) | Approved / Approved with Conditions | +| Required interruption and cleanup contract | Resolved by owner decision | [C-011](03-SharedGameplayContracts.md#c-011--ability-lifecycle-and-cleanup-contract) | Approved | +| Required respawn and HUD lifecycle contract | Resolved by owner decision | [C-008](03-SharedGameplayContracts.md#c-008--respawn-contract), [C-013](03-SharedGameplayContracts.md#c-013--hud-data-flow-contract) | Approved with Conditions / Approved | +| Pickup authority model | Resolved by owner decision | [C-014](03-SharedGameplayContracts.md#c-014--pickup-authority-and-replication-contract) | Approved | +| PlayerState versus pawn ownership boundaries | Resolved by owner decision | [C-012](03-SharedGameplayContracts.md#c-012--playerstate-and-pawn-ownership-contract) | Approved | +| How to enable 2-client PIE for remaining evidence | Validation obligation / environment | — | Not an architecture SoT conflict | +| Enhanced Input injection for automated ability tests | Validation obligation / environment | — | Not an architecture SoT conflict | -### Duplicate / superseded handling +### Deferred implementation choices (not open architecture conflicts) + +| Choice | Related contract | Resolve during | +|---|---|---| +| Exact default-GE mapping mechanism | C-002 | Implementation planning / bounded init batch | +| Gameplay Effect versus ExecutionCalculation details for damage | C-005 | Implementation planning / damage batch | +| Exact authoritative animation-timing mechanism | C-010 | Implementation planning / ability framework | +| Exact temporary observability implementation | C-015 | Implementation planning / harness | +| Whether any real consumer requires a temporary legacy shadow | C-004 | Consumer inventory during migration planning | + +### Runtime validation obligations + +These remain validation obligations. They are **not** architecture approval blockers. Tool inaccessibility is not runtime absence. + +| Area | Status | Evidence IDs | Related contracts | +|---|---|---|---| +| Enhanced Input ability execution | Blocked by Test Environment / Tool Limitation | RE-2A1-015, 019, 021; RT-002/004/005 | C-009, C-010, C-011 | +| AnimNotify execution roles | Blocked by Missing Runtime Evidence | RE-2A1-019, 021 | C-009, C-010 | +| Ability cost mutation | Blocked by Missing Runtime Evidence / Tool Limitation | RE-2A1-014, 015 | C-003, C-004 | +| Interruption and cleanup | Blocked by Test Environment | RE-2A1-020; RT-004B | C-011 | +| Player damage / death / respawn | Blocked by Missing Implementation / Tool Limitation | RE-2A1-022; RT-006 | C-005, C-007, C-008 | +| Two-client replication | Blocked by Test Environment / Tool Limitation | RE-2A1-023–026; RT-007–010 | C-009, C-014 | +| Remote character selection | Blocked by Test Environment | Depends on RE-2A1-023 | C-008 related / 2E | +| Pickup authority and visibility | Blocked by Test Environment / Tool Limitation | RE-2A1-017, 018; RT-003/010 | C-014 | +| Enemy attribute mutation | Blocked by Missing Runtime Evidence / Tool Limitation | RE-2A1-028, 030; RT-011 | C-005, C-012 | +| Session behavior | Still open for Phase 2E | Not closed by 2A1 | Outside 2A contracts | + +### Defects and limitations still accounted for + +| Observation | Handling | +|---|---| +| `PlayerFirstSpawn` Accessed None; spawn still succeeds | C-008 failure modes; validation during respawn/spawn work | +| Amazonian/Paladin legacy defaults differ; legacy health at 0 | C-001/C-004/C-007; migration must not leave lethal legacy writers | +| ASC defaults identical; no active default GE; no granted GAs | C-002 Approved with Conditions | +| Enhanced Input / multi-client PIE tooling limits | Validation obligations; C-015 | +| Enemy inspector cannot read attributes | C-012 corrected accessor; C-015; not treated as ASC absence | + +### Duplicate / superseded (historical) | Topic | Classification | Disposition | |---|---|---| -| Separate health / mana / stamina “canonical SoT” rows | Duplicate (resolved into one contract) | Historical rows retained below; proposal unified under **C-001** (+ init C-002, access C-003) | -| Legacy mirror vs dual SoT options overlapping C-001 | Superseded by C-004 recommendation | Historical options retained; recommendation lives in contracts/register | +| Separate health/mana/stamina SoT rows | Duplicate → unified under C-001 | Historical table retained below | +| Legacy mirror options | Superseded by C-004 owner decision | Bidirectional Rejected | -### Explicit remaining blocked runtime areas +--- -These remain **explicitly blocked** and must stay visible until evidence exists. Tool inaccessibility is **not** runtime absence. +## Historical — Phase 2A2a reconciliation (preserved) -| Area | Status | Evidence IDs | -|---|---|---| -| Enhanced Input ability execution | Blocked by Test Environment / Tool Limitation | RE-2A1-015, 019, 021 | -| AnimNotify authority | Blocked by Missing Runtime Evidence | RE-2A1-019, 021 (chain not executed) | -| Ability cost mutation | Blocked by Missing Runtime Evidence / Tool Limitation | RE-2A1-014, 015 | -| Ability interruption | Blocked by Test Environment | RE-2A1-020 | -| Player damage / death / respawn | Blocked by Missing Implementation / Tool Limitation | RE-2A1-022 | -| Two-client replication | Blocked by Test Environment / Tool Limitation | RE-2A1-023–026 | -| Remote character selection | Blocked by Test Environment | Depends on multi-client (RE-2A1-023) | -| Pickup authority and visibility | Blocked by Test Environment / Tool Limitation | RE-2A1-017, 018 | -| Enemy attribute mutation | Blocked by Missing Runtime Evidence / Tool Limitation | RE-2A1-028, 030 | -| Session behavior | Still Open (Phase 2E scope) | Not closed by 2A1; outside 2A2a contracts | +Phase 2A2a classified decisions as Addressed by Proposed Contract only. Owner approval occurred in 2A2b. The 2A2a classifications are superseded by the 2A2b table above but retained for continuity. -### New defects and limitations accounted for in contracts - -| Observation | Contract handling | +| Pass | Status | |---|---| -| `PlayerFirstSpawn` Accessed None during normal spawn; spawn still succeeds | C-008 failure modes / transitional spawn path | -| Amazonian vs Paladin legacy defaults differ; both legacy health begin at 0 | C-001, C-004; death-threshold risk under C-007 | -| ASC defaults stable across inspected characters; no active default GE; no granted GAs | C-002 | -| Enhanced Input unavailable via current automation | C-009–C-011 validation blocked; C-015 | -| Multi-client PIE unavailable via authorized tooling | C-009, C-014 validation blocked; env decisions remain | -| Enemy attributes inaccessible via current inspector | C-012 / C-015 — tool limit ≠ absence (RE-2A1-027 vs 028) | +| 2A2a | Proposed contracts; none Approved | +| 2A2b | Owner Approved / Approved with Conditions | --- ## Historical Phase 2A1 open-decision table (preserved) -The following table is the Phase 2A1 inventory. It is preserved for evidence continuity. Classifications above supersede “options only” for proposal purposes; **no option is Approved**. +The following table is the Phase 2A1 inventory. Evidence references are retained. Architecture options in this table are historical; owner outcomes live in docs `03`/`04` and the 2A2b section above. | Decision | Static evidence | Runtime evidence | Options | Blocking unknown | Required approval | |---|---|---|---|---|---| -| Canonical health source of truth | Dual pools: ASC `Health`/`MaxHealth` vs `DEPRECATED_CurrentHealth`/`MaxHealth`; combat uses legacy; potions use ASC | ASC init 75/100 confirmed; Amazonian/Paladin legacy Current/Max Health = **0** at spawn; Overlay binds ASC | A) ASC only immediately B) Legacy only during reconstruction C) ASC canonical with temporary legacy mirror D) Character-specific transitional policy | Whether death/combat must keep working on legacy-zero characters before mirror | Phase 2A2 architecture contract | -| Canonical mana source of truth | Abilities use `DEPRECATED_*Mana` + `FCanUseMana`; potions modify ASC Mana | ASC Mana 25/50; Paladin legacy Mana 100/100; Amazonian legacy Mana 0/0; Paladin Ability004ManaCost CDO = 0 | A) ASC only B) Legacy only during reconstruction C) ASC + mirror D) Per-ability migration | Ability cost mutation path not runtime-proven (input Tool Limitation) | Phase 2A2 | -| Canonical stamina source of truth | ASC Stamina attrs present; no stamina widget; no stamina pickup | ASC Stamina 0/0; Amazonian legacy stamina 85/100; Paladin legacy stamina 0/0 | A) ASC only B) Legacy only C) Defer stamina until after health/mana D) Remove stamina until redesigned | Whether stamina is required for Phase 2B ability framework | Phase 2A2 + design | -| Temporary legacy mirror during reconstruction | No sync code found | Confirmed divergent values at spawn; Overlay shows ASC while combat vars are legacy zeros | A) One-way ASC→legacy B) One-way legacy→ASC C) Bidirectional during transition D) No mirror; switch cutover | Which systems still read legacy at runtime (death path not executed) | Phase 2A2 | -| Where damage must enter shared framework | Player ApplyDamage + legacy health; potions via GE; enemy inbound Missing | Damage path not exercised (no enemy attack; ability input Tool Limitation) | A) Gameplay Effect Execution only B) Shared native damage API writing ASC C) Keep ApplyDamage adapter to ASC D) Hybrid | Runtime authority of ApplyDamage vs GE still unverified | Phase 2A2 after RT damage evidence | -| Where death threshold evaluation must occur | Amazonian AnyDamage → subtract legacy health → ≤0 PlayerDeath | Not observed; legacy health already 0 at spawn implies immediate death-threshold risk if AnyDamage fires | A) ASC Health ≤0 B) Legacy ≤0 C) Shared Predicates on ASC with legacy shim D) Tag-based death | Whether AnyDamage runs with CurrentHealth=0 | Phase 2A2 + optional targeted death PIE | -| Whether AnimNotifies may trigger authoritative gameplay | Static: UseAbility* from AN_*; Multicast montage; server notify evaluation assumed | Ability/notify chain not executed (Enhanced Input Tool Limitation) | A) Forbid authoritative notify gameplay B) Allow only on Authority with validation C) Move timing to Ability Tasks D) Keep notify for VFX only | Server vs client notify execution roles unknown at runtime | Phase 2A2 after RT-004/008 | -| Required interruption and cleanup contract | AN_AttackComplete clears CurrentlyAttacking; montage complete pins unconnected; interrupt may skip cleanup | Interrupt test blocked; cleanup not observed | A) Ability Task end states B) Cancel tags C) Explicit EndAbility + force clear CurrentlyAttacking D) Montage blend-out notify required | Which existing actions can interrupt without asset edits | Phase 2A2 / 2B | -| Required respawn and HUD lifecycle contract | Server_RespawnPlayer ~2s; Overlay recreate risk; stale widgets possible | RT-006 blocked — respawn/HUD recreation not observed | A) Destroy+recreate Overlay each possess B) Rebind existing Overlay C) HUD owned by PC only D) PlayerState-driven Overlay | Post-respawn Owner/Avatar and Overlay instance counts | Phase 2A2 after RT-006 | -| Pickup authority model | No authority gate; `bReplicates=false`; overlap→GE→destroy | HealthPotion runtime `bReplicates=false` confirmed; overlap/GE apply not observed | A) Server-only overlap apply + replicate actor B) Server RPC from client overlap C) GAS cue + server GE only D) Keep local for SP prototypes | Duplicate apply / client desync still unverified in MP | Phase 2A2 / 2E after RT-010 | -| PlayerState versus pawn ownership boundaries | ASC on `ARIRPlayerState`; pawn caches via InitAbilityActorInfo; Overlay via HUD | PS ASC works; pawn attribute query works; enemy ASC component present but inspector rejects actor | A) Keep ASC on PlayerState for players B) Move ASC to pawn C) Dual ownership with clear Avatar rules D) Enemy-specific ASC init contract | Enemy ASC InitAbilityActorInfo / interface exposure at runtime | Phase 2A2 | -| How to enable 2-client PIE for remaining evidence | MCP `StartPIE` lacks NumberOfPlayers; PlayIn settings exist | Read: playNumberOfClients=1, PIE_Standalone; non-persisting UI set not achieved; config save unauthorized | A) Manual editor Play settings (user) then re-run RT-007–010 B) Authorize transient SetSectionProperties without Save if possible C) Defer MP until harness exists D) Dedicated listen-server process (out of scope) | Whether editor can raise clients without writing config | Environment / user authorization | -| Enhanced Input injection for automated ability tests | Input maps IA_Ability_* in IMC_PlayerDefault | Slate PressKey does not activate abilities; OS injection blocked by policy | A) Manual human-driven ability tests B) Authorize OS input for evidence harness C) Temporary debug console activate (unauthorized now) D) Automation Driver outside MCP | Cannot close AnimNotify/authority decisions without ability fire | Environment / Phase 2A validation harness | +| Canonical health source of truth | Dual pools: ASC `Health`/`MaxHealth` vs `DEPRECATED_CurrentHealth`/`MaxHealth`; combat uses legacy; potions use ASC | ASC init 75/100 confirmed; Amazonian/Paladin legacy Current/Max Health = **0** at spawn; Overlay binds ASC | A) ASC only immediately B) Legacy only during reconstruction C) ASC canonical with temporary legacy mirror D) Character-specific transitional policy | Whether death/combat must keep working on legacy-zero characters before mirror | Phase 2A2 architecture contract — **Resolved 2A2b C-001** | +| Canonical mana source of truth | Abilities use `DEPRECATED_*Mana` + `FCanUseMana`; potions modify ASC Mana | ASC Mana 25/50; Paladin legacy Mana 100/100; Amazonian legacy Mana 0/0; Paladin Ability004ManaCost CDO = 0 | A) ASC only B) Legacy only during reconstruction C) ASC + mirror D) Per-ability migration | Ability cost mutation path not runtime-proven (input Tool Limitation) | **Resolved 2A2b C-001/C-003** | +| Canonical stamina source of truth | ASC Stamina attrs present; no stamina widget; no stamina pickup | ASC Stamina 0/0; Amazonian legacy stamina 85/100; Paladin legacy stamina 0/0 | A) ASC only B) Legacy only C) Defer stamina until after health/mana D) Remove stamina until redesigned | Whether stamina is required for Phase 2B ability framework | **Resolved 2A2b C-001/C-002**; UI gated by C-013 | +| Temporary legacy mirror during reconstruction | No sync code found | Confirmed divergent values at spawn; Overlay shows ASC while combat vars are legacy zeros | A) One-way ASC→legacy B) One-way legacy→ASC C) Bidirectional during transition D) No mirror; switch cutover | Which systems still read legacy at runtime (death path not executed) | **Resolved 2A2b C-004**; whether any shadow consumer needed remains Deferred | +| Where damage must enter shared framework | Player ApplyDamage + legacy health; potions via GE; enemy inbound Missing | Damage path not exercised (no enemy attack; ability input Tool Limitation) | A) Gameplay Effect Execution only B) Shared native damage API writing ASC C) Keep ApplyDamage adapter to ASC D) Hybrid | Runtime authority of ApplyDamage vs GE still unverified | **Resolved 2A2b C-005**; ExecCalc Deferred | +| Where death threshold evaluation must occur | Amazonian AnyDamage → subtract legacy health → ≤0 PlayerDeath | Not observed; legacy health already 0 at spawn implies immediate death-threshold risk if AnyDamage fires | A) ASC Health ≤0 B) Legacy ≤0 C) Shared Predicates on ASC with legacy shim D) Tag-based death | Whether AnyDamage runs with CurrentHealth=0 | **Resolved 2A2b C-007**; validation obligation remains | +| Whether AnimNotifies may trigger authoritative gameplay | Static: UseAbility* from AN_*; Multicast montage; server notify evaluation assumed | Ability/notify chain not executed (Enhanced Input Tool Limitation) | A) Forbid authoritative notify gameplay B) Allow only on Authority with validation C) Move timing to Ability Tasks D) Keep notify for VFX only | Server vs client notify execution roles unknown at runtime | **Resolved 2A2b C-009/C-010**; timing mechanism Deferred | +| Required interruption and cleanup contract | AN_AttackComplete clears CurrentlyAttacking; montage complete pins unconnected; interrupt may skip cleanup | Interrupt test blocked; cleanup not observed | A) Ability Task end states B) Cancel tags C) Explicit EndAbility + force clear CurrentlyAttacking D) Montage blend-out notify required | Which existing actions can interrupt without asset edits | **Resolved 2A2b C-011**; validation obligation remains | +| Required respawn and HUD lifecycle contract | Server_RespawnPlayer ~2s; Overlay recreate risk; stale widgets possible | RT-006 blocked — respawn/HUD recreation not observed | A) Destroy+recreate Overlay each possess B) Rebind existing Overlay C) HUD owned by PC only D) PlayerState-driven Overlay | Post-respawn Owner/Avatar and Overlay instance counts | **Resolved 2A2b C-008/C-013**; validation obligation remains | +| Pickup authority model | No authority gate; `bReplicates=false`; overlap→GE→destroy | HealthPotion runtime `bReplicates=false` confirmed; overlap/GE apply not observed | A) Server-only overlap apply + replicate actor B) Server RPC from client overlap C) GAS cue + server GE only D) Keep local for SP prototypes | Duplicate apply / client desync still unverified in MP | **Resolved 2A2b C-014**; option B rejected as default | +| PlayerState versus pawn ownership boundaries | ASC on `ARIRPlayerState`; pawn caches via InitAbilityActorInfo; Overlay via HUD | PS ASC works; pawn attribute query works; enemy ASC component present but inspector rejects actor | A) Keep ASC on PlayerState for players B) Move ASC to pawn C) Dual ownership with clear Avatar rules D) Enemy-specific ASC init contract | Enemy ASC InitAbilityActorInfo / interface exposure at runtime | **Resolved 2A2b C-012** | +| How to enable 2-client PIE for remaining evidence | MCP `StartPIE` lacks NumberOfPlayers; PlayIn settings exist | Read: playNumberOfClients=1, PIE_Standalone; non-persisting UI set not achieved; config save unauthorized | A) Manual editor Play settings (user) then re-run RT-007–010 B) Authorize transient SetSectionProperties without Save if possible C) Defer MP until harness exists D) Dedicated listen-server process (out of scope) | Whether editor can raise clients without writing config | Environment / validation harness — remains open | +| Enhanced Input injection for automated ability tests | Input maps IA_Ability_* in IMC_PlayerDefault | Slate PressKey does not activate abilities; OS injection blocked by policy | A) Manual human-driven ability tests B) Authorize OS input for evidence harness C) Temporary debug console activate (unauthorized now) D) Automation Driver outside MCP | Cannot close AnimNotify/authority decisions without ability fire | Environment / validation harness — remains open | ## Explicitly not decided here - Final Gameplay Ability class layout -- Final attribute set schema changes -- Whether to delete `DEPRECATED_*` in Phase 2A -- Per-character reconstruction order changes -- Approval of any C-001–C-015 contract (owner action required) +- Final attribute set schema changes beyond approved SoT +- Whether to delete `DEPRECATED_*` in a specific batch +- Per-character reconstruction start (blocked until Phase 2A implementation sequence approved) +- Exact deferred implementation choices listed above -## Next authorized step (outside this batch) +## Next authorized step -Wait for explicit owner approval of Proposed contracts before Phase 2A2b, Phase 2A3 implementation planning, or any Unreal implementation. Do not begin Phase 2B. +Wait for explicit authorization before **Phase 2A3** implementation planning. Do not begin Unreal implementation or Phase 2B from this document alone. diff --git a/Documentation/Phase2/03-SharedGameplayContracts.md b/Documentation/Phase2/03-SharedGameplayContracts.md index f3a91452..e3cd4c7c 100644 --- a/Documentation/Phase2/03-SharedGameplayContracts.md +++ b/Documentation/Phase2/03-SharedGameplayContracts.md @@ -1,17 +1,19 @@ -# Phase 2A2a — Shared Gameplay Contracts +# Phase 2A — Shared Gameplay Contracts | Field | Value | |---|---| -| Status | Draft | +| Status | Complete | | Date | 2026-07-17 | -| Phase | 2A2a — Shared gameplay contract proposal | -| Starting Git commit | `9919faab` | +| 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 | All contracts are **Proposed**. None are Approved. No implementation in this pass. | +| 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 -Translate accepted Phase 1 static archaeology and Phase 2A1 runtime evidence into proposed shared gameplay contracts. These contracts define architectural boundaries for review. They do not authorize implementation, asset changes, or Phase 2B. +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 @@ -21,22 +23,20 @@ Translate accepted Phase 1 static archaeology and Phase 2A1 runtime evidence int | 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 | -| Recommendation | Proposed architectural choice (not observed fact) | -| Required approval | Exact question for the project owner | -| Deferred validation | Runtime test still required before trusting the rule | +| 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 used in this pass +## Decision states -Proposed · Alternative · Deferred · Blocked by Runtime Evidence · Blocked by Design Decision · Rejected by Existing Evidence - -**Do not use Approved.** +Approved · Approved with Conditions · Deferred · Rejected · Rejected by Existing Evidence ## Continuity | Check | Result | |---|---| -| Phase 2A1 evidence reviewed | Yes — `00`, `01`, `02` under `Documentation/Phase2/` | -| Starting `git rev-parse HEAD` | `9919faab4aa667cad4b4156bfa46c2d9f2113e40` | +| 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`](00-Phase2A-RuntimeBaseline.md), [`01-Phase2A-RuntimeEvidenceIndex.md`](01-Phase2A-RuntimeEvidenceIndex.md), [`02-Phase2A-OpenDecisions.md`](02-Phase2A-OpenDecisions.md), [`04-Phase2A-DecisionRegister.md`](04-Phase2A-DecisionRegister.md). @@ -45,17 +45,22 @@ Cross-links: [`00-Phase2A-RuntimeBaseline.md`](00-Phase2A-RuntimeBaseline.md), [ # C-001 — Canonical player resource source of truth -**State:** Proposed +**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, so UI and combat can disagree. +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 (`DEPRECATED_CurrentHealth`, mana costs, etc.). +- Abilities and Amazonian inbound damage use DEPRECATED floats. - Consumable GEs modify ASC attributes only. - No sync between ASC and DEPRECATED pools. @@ -63,1162 +68,722 @@ Combat, death, ability costs, potions, and HUD currently read different resource | Kind | Evidence | |---|---| -| Static | Docs `05`, `06` §8, `01` P0 dual-resource risk — combat uses legacy; potions/Overlay use ASC; sync Missing | -| Runtime | RE-2A1-001/012: ASC Health 75/100, Mana 25/50, Stamina 0/0 for Amazonian and Paladin | -| Runtime | RE-2A1-004/005: Amazonian legacy health/mana 0; stamina 85/100 | -| Runtime | RE-2A1-013: Paladin legacy Mana 100/100 vs ASC 25/50; legacy Health 0/0 | +| 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 | -| Inference | Amazonian AnyDamage writing legacy health=0 is at immediate death-threshold risk if that path fires | -### Proposed rule +### 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. +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. -Spawn divergence is treated as a **confirmed 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 attributes for gameplay and UI. -- Writing ASC attributes through shared authoritative boundaries (C-003, C-005, C-006). -- Temporary ASC→legacy shadow copies for unconverted read-only consumers (C-004). +- 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. -- Silent acceptance of ASC/legacy disagreement as intended design. ### Transitional behavior -Until each consumer is migrated, an ASC→legacy one-way shadow may keep unconverted readers consistent (C-004). Legacy writers must be migrated or blocked before they can overwrite ASC. +ASC→legacy one-way shadow only under C-004. Legacy writers must be migrated or blocked. ### Dependencies -C-002 (initialization), C-003 (access boundary), C-004 (legacy policy). +C-002, C-003, C-004. ### Migration impact -Ability costs, Amazonian AnyDamage/death, Cleric heal, Overlay (already ASC), any remaining `Server_UpdateHUD` callers, future stamina systems. +Ability costs, Amazonian AnyDamage/death, Cleric heal, Overlay, `Server_UpdateHUD` callers, stamina systems. -### Runtime validation required +### Runtime validation obligation -- After init policy lands: ASC and any permitted shadow values match at spawn for each playable. -- Potion heal changes ASC and Overlay; combat damage changes ASC Health. -- Death fires from ASC Health ≤ 0, not legacy zero alone. +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 leaves one system on ASC and another on legacy → desync returns. -- Shadow omitted while legacy death still active → false immediate death or immortal combat. +Partial migration desync; shadow omitted while legacy death still active. ### Approval question -**Do you approve ASC AttributeSet as the sole canonical source of truth for Health, MaxHealth, Mana, MaxMana, Stamina, and MaxStamina, with DEPRECATED Blueprint resource variables treated as non-authoritative?** +**Resolved** — Owner approved 2026-07-17. --- # C-002 — Character default attribute initialization -**State:** Proposed (recommended option A) +**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. Missing character defaults fail silently via native Init*, producing incorrect balance and hiding misconfiguration. +All inspected characters spawn with identical native ASC defaults. Orphan character default GEs are unreferenced. Stamina ASC remains 0/0. ### Current implementation -- `URIRAttributeSet` ctor: InitHealth(75), InitMaxHealth(100), InitMana(25), InitMaxMana(50); Stamina/MaxStamina not Init'd. -- `BP_PlayerState.DefaultAttributesGameplayEffect` = None. -- Orphan GEs (`GE_*_DefaultAttributes`) exist per character but have **0 referencers** and do not modify Max* attributes. -- Legacy CDO defaults differ per character (Amazonian stamina 85/100; Paladin mana 100/100; both health 0). +- 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 — orphan default GEs; native Init fallback; Max* absent on default GEs | -| Runtime | RE-2A1-001/012 — ASC identical for Amazonian and Paladin | -| Runtime | RE-2A1-002 — no active default GE at spawn | -| Runtime | RE-2A1-011 — CDO explains legacy zeros / character-specific legacy stamina/mana | -| Tool limitation | N/A for spawn values (observed) | +| Static | Doc `06` §§2–4 | +| Runtime | RE-2A1-001, 002, 011, 012 | -### Options compared +### Approved architectural rule -| Option | Description | Fit to evidence | -|---|---|---| -| **A. Character-specific default GE** | Pawn/class selects a default GE; server applies after ASC actor info valid | Best fit — assets and `DefaultAttributesGameplayEffect` property already exist | -| B. Shared init GE + SetByCaller | One GE; magnitudes passed per class | Viable; fewer assets; more native glue | -| C. Native initialization service | Explicit server service sets all six attrs | Viable; strongest fail-visible control; bypasses existing GE assets | -| D. Other | e.g. hybrid GE for currents + native Max* | Possible but adds dual paths | +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. -### Proposed rule (Recommendation: Option A) +### Deferred implementation choices -Character defaults are applied on the **authoritative server** only after ASC OwnerActor/AvatarActor are valid. Every character receives **explicit** current and maximum Health, Mana, and Stamina. Stamina may not rely on an uninitialized native default. Initialization must be deterministic on initial spawn and respawn. A missing character default assignment must **fail visibly** (log/assert/fatal in development) rather than silently falling back to identical native Init* values. +- Exact data mapping mechanism (class→GE selection / asset wiring). -Existing orphan GEs must be completed (including MaxHealth/MaxMana/MaxStamina) before they are treated as production defaults. Incomplete GEs are migration work, not a license to keep silent Init*. +### Alternatives (historical) -**Alternatives retained:** B, C (Proposed alternatives, not rejected). +| 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 behavior +### Allowed / Prohibited / Transitional -- Server ApplyGameplayEffect of character default GE after InitAbilityActorInfo. -- Explicit Max* and current values in that GE (or immediate companion apply). -- Visible failure when class data / GE assignment is missing. - -### Prohibited behavior - -- Silent native-only fallback that leaves all classes at 75/100/25/50/0/0. -- Client-authoritative default attribute application. -- Relying on uninitialized Stamina ASC as “zero by design” without an explicit assignment. - -### Transitional behavior - -Until GEs are completed, temporary use of Option C for Max* fill is acceptable only if documented as transitional and still fails visibly when class data is missing. +As in conditions: server-only after actor info; no silent native/CDO fallback; no duplicate apply. ### Dependencies -C-001, C-012 (ASC on PlayerState / re-init on possess). +C-001, C-012. ### Migration impact -`ARIRPlayerState`, character class data, orphan `GE_*_DefaultAttributes`, spawn and respawn paths, Gunslinger (no GE today). +PlayerState, character GEs (must include Max*), Gunslinger missing GE, spawn/respawn. -### Runtime validation required +### Runtime validation obligation -- Per playable: ASC currents and maxes match class policy after spawn and after respawn. -- Missing GE assignment produces a visible error in a controlled test. -- No active unintended GEs beyond the intended default apply. - -### Failure modes - -- GE overrides current without Max* → clamps/UI break. -- Apply before actor info valid → no-op or wrong Owner. -- Respawn skips reapply → stale or zeroed attributes. +Per-class ASC after spawn/respawn; missing assignment visible error; no duplicate GE apply. ### Approval question -**Do you approve Option A (character-specific default Gameplay Effect applied server-side after ASC actor info is valid), with visible failure on missing assignment and mandatory explicit current+max Health/Mana/Stamina?** +**Resolved** — Owner approved with conditions 2026-07-17. --- # C-003 — Resource-access boundary -**State:** Proposed +**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 -Gameplay mutates resources through ad-hoc Blueprint variables, `FCanUseMana`, `ApplyDamage`, and GEs without a single authoritative interface. Incremental migration risks two authoritative stores. +Ad-hoc DEPRECATED floats, `FCanUseMana`, `ApplyDamage`, and GEs create dual writers. ### Current implementation -- Ability graphs read/write DEPRECATED mana/health/damage floats. -- Potions apply ASC GEs via EffectActor. -- Overlay reads ASC. -- No shared resource API above ASC for costs/affordability. +Abilities use DEPRECATED mana/health; potions use ASC GEs; Overlay uses ASC; no shared API above ASC. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `05` resource inventory; `06` legacy/GAS boundary; `07` S9 | -| Runtime | RE-2A1-001–005, 012–013 — dual values at spawn | -| Runtime | Ability cost mutation path not exercised (RE-2A1-015/019/021 Tool Limitation) | +Static: docs `05`, `06`, `07` S9. Runtime: RE-2A1-001–005, 012–015 (cost path not exercised). -### Proposed rule +### Approved architectural rule -New gameplay may not directly read or write DEPRECATED resource variables. Resource reads, affordability checks, costs, restoration, and maximum-value queries use a **shared authoritative interface** that operates on ASC attributes. Cost validation and mutation occur **atomically on the server**. +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. -### Allowed behavior +### Deferred implementation choices -- Server: check affordability → commit cost → proceed, or fail without partial mutation. -- Reads of current/max via the shared interface. -- Migrated abilities calling the interface instead of DEPRECATED floats. +Exact interface surface / native vs Blueprint-callable packaging. -### Prohibited behavior +### Alternatives -- New code writing DEPRECATED resource vars as authority. -- Client-side cost commitment. -- Dual-write of ASC and DEPRECATED as both authoritative. - -### Transitional behavior - -Migrate each dependent path to the interface **before** that path is considered converted. Until conversion, that path may still touch DEPRECATED vars under C-004 constraints, but must not invent a second ASC writer. Prefer converting cost/death/heal writers first. +Per-system ad-hoc ASC reads — Rejected (recreates dual writers). ### Dependencies C-001, C-002, C-004, C-006. -### Migration impact +### Runtime validation obligation -`FCanUseMana`, all DEPRECATED_*ManaCost call sites, RecoverPlayerHealth, Amazonian AnyDamage, future GA costs. - -### Runtime validation required - -- Ability cost reduces ASC Mana once; Overlay updates; legacy shadow (if present) matches. -- Failed affordability leaves attributes unchanged. - -### Failure modes - -- Interface bypass leaves stray DEPRECATED writers. -- Non-atomic check-then-spend races under replication. +Cost reduces ASC once; failed affordability leaves attributes unchanged. (RE-2A1-015 Tool Limitation.) ### Approval question -**Do you approve a shared server-authoritative ASC resource interface as the only allowed read/write path for new gameplay resource access, with atomic cost validation and mutation?** +**Resolved** — Owner approved 2026-07-17. --- # C-004 — Legacy compatibility policy -**State:** Proposed (recommended option C; bidirectional Rejected by Existing Evidence) +**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 is becoming canonical. Bidirectional sync would create competing writers and feedback loops. Legacy writers must not silently overwrite ASC. +Unconverted legacy readers still exist while ASC becomes canonical. ### Current implementation -No sync code. ASC and DEPRECATED diverge at spawn. Overlay uses ASC; combat vars use legacy. +No sync. ASC and DEPRECATED diverge at spawn. ### Confirmed evidence -| Kind | 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 | |---|---| -| Static | Doc `06` — legacy-resource synchronization Missing | -| Runtime | RE-2A1-004/005/013 — divergent spawn values | -| Inference | Bidirectional sync with Amazonian health=0 and ASC=75 would create writer conflict | - -### Options evaluated - -| Option | Verdict | -|---|---| -| A. Bidirectional synchronization | **Rejected by Existing Evidence** — competing writers; feedback-loop risk | -| B. Legacy→ASC synchronization | Rejected as primary policy — would promote non-authoritative / zeroed legacy into ASC | -| **C. ASC→legacy one-way shadow** | **Recommended (Proposed)** for temporary unconverted read-only consumers | -| D. No synchronization; migrate each path before use | Preferred when a path can cut over in one change; compatible with C | - -### Proposed rule - -Temporary **one-way ASC→legacy** compatibility shadows are allowed only where an unconverted **read-only** consumer still requires DEPRECATED floats. Legacy **direct writers** must not silently overwrite canonical ASC values. Prefer Option D cutover when feasible. Bidirectional sync is prohibited. - -### Allowed behavior - -- After ASC mutation, optionally push values into DEPRECATED vars for legacy UI/gates not yet migrated. -- Document each shadow consumer and remove it when migrated. - -### Prohibited behavior - -- Bidirectional sync. -- Legacy AnyDamage / cost writers updating ASC without going through C-003/C-005/C-006. -- Indefinite shadow without a migration owner. - -### Transitional behavior - -Shadow is temporary scaffolding during reconstruction. Each shadowed consumer must be listed and retired. +| 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. -### Migration impact +### Runtime validation obligation -Amazonian AnyDamage, `FCanUseMana` readers, `Server_UpdateHUD` callers, any BP reading DEPRECATED health/mana. - -### Runtime validation required - -- With shadow on: after ASC heal/damage, shadowed legacy matches ASC. -- Legacy writer attempt cannot change ASC without shared boundary. - -### Failure modes - -- Forgotten shadow → legacy death on zero. -- Accidental reverse write → ASC corrupted. +Shadow matches ASC after mutation; legacy cannot overwrite ASC. ### Approval question -**Do you approve ASC→legacy one-way shadow only for temporary read-only consumers, with bidirectional sync prohibited and legacy writers forbidden from silently overwriting ASC?** +**Resolved** — Owner approved as transitional only 2026-07-17. --- # C-005 — Damage contract -**State:** Proposed (ExecutionCalculation design Deferred) +**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 -Player damage uses `ApplyDamage` into legacy health (Amazonian) or has no enemy consumer. Potions use ASC GEs. There is no single server entry for validated damage. +Fragmented ApplyDamage / legacy health / missing enemy consumers. ### Current implementation -- Paladin/Amazonian/Cleric UseAbility* / ChargeBox: Authority `ApplyDamage`. -- Amazonian `ReceiveAnyDamage` subtracts DEPRECATED_CurrentHealth. -- Enemy: no ReceiveAnyDamage / health mutation (Implementation Missing). -- No project GameplayEffectExecutionCalculation subclasses. +Authority ApplyDamage on abilities; Amazonian AnyDamage → DEPRECATED health; enemy reception Missing; no project ExecCalc subclasses. ### Confirmed evidence -| Kind | 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 | |---|---| -| Static | Docs `05`, `09`, `06` — ApplyDamage vs missing enemy reception; ASC Health unbridged | -| Runtime | RE-2A1-022 — player damage/death path blocked (enemy attack Missing; ability input Tool Limitation) | -| Runtime | RE-2A1-027/030 — enemy components present; damage reception not observed | - -### Proposed rule - -One **server-authoritative damage entry boundary** for player and enemy targets: - -| Step | Owner | -|---|---| -| Who may request damage | Abilities, overlaps, environmental actors, future AI — as **requests** only | -| Who validates | Server damage boundary | -| Target validity | Server (alive, damageable, team/filter rules) | -| Magnitude calculation | Server (data asset / ability / curve — implementation later) | -| Mitigation | Server (block/armor tags — design later) | -| Health change | Server writes **ASC Health** via shared resource path | -| Instigator / causer | Recorded on the authoritative damage event | -| Duplicate prevention | Server dedupe (e.g. ability instance / window / hit ID) | -| Death evaluation | Trigger C-007 after Health change | -| Legacy ApplyDamage | Transitional **adapter** into this boundary; not a second SoT | - -**Not chosen now:** final GameplayEffectExecutionCalculation design. Retained as Alternative for later approval if GAS execution is preferred after 2B. - -### Allowed behavior - -- Server-only Health reduction through the boundary. -- Transitional ApplyDamage → adapter → ASC. -- Presentation multicast after authoritative apply. - -### Prohibited behavior - -- Client-authoritative Health writes. -- AnimNotify as sole damage authority without server validation (see C-009/C-010). -- Damage that mutates only DEPRECATED health after cutover. - -### Transitional behavior - -Keep Authority-gated UseAbility ApplyDamage call sites temporarily, but route Health mutation into ASC via adapter. Enemy reception remains blocked until Phase 2D implements the consumer under this contract. +| 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. -### Migration impact +### Runtime validation obligation -All ApplyDamage call sites; Amazonian AnyDamage; future enemy inbound damage; block absorb design (Paladin 002). - -### Runtime validation required - -- Controlled damage reduces ASC Health once; Overlay updates; no double apply. -- Death triggers at ASC ≤ 0. -- **Blocked today:** ability-driven and enemy-driven damage (Tool Limitation / Missing Implementation). - -### Failure modes - -- Adapter forgotten → legacy and ASC diverge again. -- No dedupe → double hits from multicast notifies. +Single ASC Health reduction; no double apply; death at ≤ 0. (RE-2A1-022 blocked.) ### Approval question -**Do you approve a single server-authoritative damage entry that writes ASC Health, with legacy ApplyDamage limited to a transitional adapter, and ExecutionCalculation design deferred?** +**Resolved** — Owner approved 2026-07-17; ExecCalc deferred. --- # C-006 — Healing and resource restoration contract -**State:** Proposed +**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 -Healing exists as Cleric `RecoverPlayerHealth` (legacy) and consumable GEs (ASC). No shared clamp/attribution policy. - -### Current implementation - -- Cleric UseAbility002: Authority heal via DEPRECATED recover interface. -- Potions/food: GE Instant/Duration on ASC Health/Mana. -- No AttributeSet PostGameplayEffectExecute clamp-to-max. +Dual heal paths (Cleric legacy recover vs ASC GEs); no clamp policy. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `05` Cleric 002; `06` GE inventory; `12` pickups | -| Runtime | RE-2A1-018 — consumable overlap not executed (movement/input blocked) | -| Runtime | ASC MaxHealth/MaxMana exist; Overlay binds them | +Static: docs `05`, `06`, `12`. Runtime: RE-2A1-018. -### Proposed rule +### Approved architectural rule -- Restoration is **server-authoritative**. -- Values clamp to the attribute’s Max* unless an approved GE explicitly documents over-resource permission. -- Source attribution recorded (instigator, GE class, ability ID). -- Gameplay Effects and shared restore services both enter the **same resource boundary** (C-003). -- UI updates only by observing replicated ASC changes. -- Overheal / over-mana / over-stamina **not permitted** by default. -- Consumables use the same boundary (apply GE or service on server). +Server-authoritative restoration via C-003; clamp to Max*; source attribution; ASC mutation; HUD via attribute delegates only; no over-resource by default. -### Allowed behavior +### Deferred implementation choices -- Server GE heal/mana restore; shared RestoreResource API; clamp to max. -- Cosmetic feedback after authoritative change. - -### Prohibited behavior - -- Client-side Health/Mana increases. -- Unclamped restores that leave Current > Max without explicit approval. -- Healing only DEPRECATED health while ASC remains unchanged. - -### Transitional behavior - -Cleric recover path adapts to ASC via C-003; potions already on ASC remain preferred pattern. +Whether any future tagged GE may explicitly allow over-resource (none approved now). ### Dependencies -C-001, C-003, C-014 (pickup apply). +C-001, C-003, C-014. -### Migration impact +### Runtime validation obligation -Cleric 002, EffectActor GEs, any DEPRECATED recover paths, future HoT/MoT. - -### Runtime validation required - -- Heal at full Health does not exceed MaxHealth. -- Potion +25 Health updates ASC and Overlay once. -- **Blocked today:** pickup overlap apply (RE-2A1-018). - -### Failure modes - -- Dual heal systems → Overlay shows ASC heal while combat uses legacy. -- Missing clamp → invalid Current > Max. +Clamp at max; potion apply once; Overlay update. (RE-2A1-018 blocked.) ### Approval question -**Do you approve server-authoritative restoration through the shared ASC resource boundary, clamping to Max* by default, with consumables and ability heals using the same path?** +**Resolved** — Owner approved 2026-07-17. --- # C-007 — Death contract -**State:** Proposed +**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 is evaluated from DEPRECATED health on Amazonian; ASC Health is unused for death. Animation can force enemy `IsDead` false. No idempotent shared death transition. - -### Current implementation - -- Amazonian: AnyDamage → subtract DEPRECATED_CurrentHealth → PlayerDeath if ≤ 0. -- Base: PlayerDeath / Client_PlayerDeath / IsDead replicated bool. -- Enemy ABP forces IsDead false every update; no damage reception. -- `State.Dead` tag Present but Unreferenced. +Death from DEPRECATED health; enemy ABP forces IsDead false; no idempotent shared transition. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `05` Amazonian death; `09` enemy death incomplete; `10` ABP death states | -| Runtime | RE-2A1-006 — IsDead false at spawn | -| Runtime | RE-2A1-004/013 — legacy health 0 at spawn (death-threshold risk if AnyDamage fires) | -| Runtime | RE-2A1-022 — death/respawn not observed | +Static: docs `05`, `09`, `10`. Runtime: RE-2A1-004, 006, 013, 022. -### Proposed rule +### Approved architectural rule -- Death is evaluated from **canonical ASC Health**. -- Health ≤ 0 is evaluated **authoritatively on the server**. -- Death transition is **idempotent** — a player or enemy cannot execute the death transition twice. -- Dead state is **replicated**. -- Movement, abilities, collision, animation, and interaction respond to **one shared death state**. -- Animation does **not** own the authoritative death decision. +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. -**Player vs enemy separation:** same Health≤0 evaluation and idempotent dead state; players proceed to C-008 respawn; enemies proceed to destroy/loot/presentation policy (Phase 2D) without player respawn. +### Deferred implementation choices -### Allowed behavior - -- Server sets replicated dead state once; cancels abilities; disables input/movement as configured. -- ABP reads replicated dead state for Death animation only. - -### Prohibited behavior - -- AnimBP forcing alive over authoritative dead state. -- Death decided solely from DEPRECATED health after cutover. -- Re-entrant PlayerDeath without guard. - -### Transitional behavior - -Until Amazonian AnyDamage is migrated, treat legacy≤0 as transitional trigger that must also drive ASC Health to 0 / call the shared death entry — not a second SoT. +Whether `State.Dead` tag becomes the replicated carrier (implementation planning). ### Dependencies -C-001, C-005, C-008 (players), C-011 (ability cancel on death). +C-001, C-005, C-008 (players), C-011. -### Migration impact +### Runtime validation obligation -Amazonian AnyDamage, PlayerDeath, enemy death ABP, future tags (`State.Dead`). - -### Runtime validation required - -- Damage to ASC 0 triggers death once; second damage does not re-enter. -- ABP plays death from replicated state. -- **Blocked today:** RT-006 (RE-2A1-022). - -### Failure modes - -- Legacy health 0 at spawn + AnyDamage → instant death while Overlay shows 75. -- Enemy ABP clears IsDead → corpse walks. +One death transition; no re-entry; ABP follows replicated state. (RE-2A1-022 blocked.) ### Approval question -**Do you approve authoritative, idempotent death evaluated from ASC Health ≤ 0, with animation as presentation-only and player/enemy differing only in post-death lifecycle?** +**Resolved** — Owner approved 2026-07-17. --- # C-008 — Respawn contract -**State:** Proposed +**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 -Respawn/HUD recreation paths exist but are unverified. Risk of dying pawn owning its replacement, duplicate overlays, stale widgets, and skipped ASC re-init. - -### Current implementation - -- `Server_RespawnPlayer` / `PlayerRespawn` SpawnActor+Possess paths on base / PC / GM. -- Overlay created from `InitAbilityActorInfo` when local HUD present. -- Char-select `PlayerFirstSpawn` emits Accessed None warning but still spawns (RE-2A1-010). +Unverified respawn/HUD recreation; risk of pawn-owned replacement and duplicate overlays. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `07` S8; `11` spawn/respawn; `03` PC_Character | -| Runtime | RE-2A1-010 — PlayerFirstSpawn Accessed None; spawn still succeeds | -| Runtime | RE-2A1-022 — respawn not observed (RT-006 blocked) | +Static: docs `07` S8, `11`. Runtime: RE-2A1-010, 022. -### Proposed rule +### Approved architectural rule -- **GameMode and PlayerController** own the server-side respawn request and timing. The destroyed/dying pawn must **not** be the sole authority that initiates its replacement. -- Ordering: mark dead → cancel abilities (C-011) → schedule respawn delay → destroy or detach old pawn → spawn replacement → **re-Init ASC OwnerActor/AvatarActor** → reapply character defaults (C-002) → Possess → restore input → **idempotent HUD bind** (C-013). -- PlayerState persists across pawn replacement. -- Duplicate-respawn prevention: ignore respawn requests while already pending or while not dead. +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. -### Allowed behavior +### Deferred implementation choices -- Server GM/PC timer-driven respawn. -- Reuse PlayerState ASC; refresh Avatar to new pawn. +Exact timer values and SpawnActor parameter packaging. -### Prohibited behavior +### Alternatives -- Client-authoritative respawn. -- Multiple concurrent respawn schedules for one player. -- Skipping default attribute reapplication. - -### Transitional behavior - -Existing `Server_RespawnPlayer` on the pawn may forward a request to PC/GM but must not unilaterally complete the lifecycle without GM/PC ownership. +Pawn-owned sole `Server_RespawnPlayer` as primary owner — Rejected. ### Dependencies C-002, C-007, C-012, C-013. -### Migration impact +### Runtime validation obligation -`BP_PlayerCharacterBase` death/respawn, `PC_Character`, `GM_Dungeoneer`, HUD InitOverlay. - -### Runtime validation required - -- One death → one respawn; ASC defaults restored; Overlay instance count stable; input restored. -- **Blocked today:** RE-2A1-022. - -### Failure modes - -- Double Overlay; stale widget bound to destroyed pawn; ASC Avatar still old pawn; spawn warning becomes hard failure. +One death → one respawn; ASC Owner/Avatar correct; one Overlay. (RE-2A1-022 blocked.) ### Approval question -**Do you approve GameMode + PlayerController ownership of server respawn lifecycle (pawn must not solely replace itself), including ASC re-init, default reapplication, possession, input restore, and idempotent HUD bind?** +**Resolved** — Owner approved with ownership clarification 2026-07-17. --- # C-009 — Authority contract -**State:** Proposed +**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 gameplay timing depends on Multicast montage AnimNotify evaluation. Interrupt and server/client notify roles are unverified. Clients must submit intent only. - -### Current implementation - -``` -Input → Server_Ability_* → Multicast_PlayMontage → AnimNotify → UseAbility* (Authority gate) / SetIsAttacking -``` - -Montage OnCompleted/OnBlendOut/OnInterrupted pins unwired. Cleanup often via `AN_AttackComplete`. +Legacy notify-driven gameplay on Multicast montage evaluation. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `05`, `10` — notify-driven gameplay; Authority Switch inside UseAbility*; Networking Risk | -| Runtime | RE-2A1-015/019/021 — ability chain not executed (Enhanced Input Tool Limitation) | -| Runtime | RE-2A1-023–026 — two-client replication not run | +Static: docs `05`, `10`. Runtime: RE-2A1-015, 019, 021, 023–026. -### Proposed rule +### Approved architectural rule -- Clients submit **intent**. -- Server validates state, target, resource cost, cooldown, and gameplay result. -- Multicast events are **presentation-only** unless a narrowly documented exception is later approved. -- Client or multicast animation evaluation **cannot be the sole authority** for damage, healing, spawning, costs, or state transitions. -- Replicated state is written only by its authoritative owner. +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. -### Allowed behavior +### Deferred implementation choices -- Server RPC intent → server commit → replicate state → multicast montage/SFX/VFX. -- Server-owned timing windows that *correlate* with animation (C-010) without requiring notify-as-authority. - -### Prohibited behavior - -- Gameplay results that only occur if a multicast notify runs. -- Client writing Health/Mana/IsDead/CurrentlyAttacking as authority. - -### Transitional behavior - -Legacy notify→UseAbility Authority bodies may remain temporarily but must be treated as **technical debt**. Migration moves hit commit to server Ability Tasks / validated windows. Document each remaining notify gameplay call site. +Narrow documented multicast exceptions (none approved now). ### Dependencies C-003, C-005, C-006, C-010, C-011. -### Migration impact +### Runtime validation obligation -All Server_Ability / Multicast_PlayMontage / AN_Ability_* paths; Phase 2B framework. - -### Runtime validation required - -- Listen-server + client: damage once on server; montage on both; no client-only Health change. -- **Blocked today:** Enhanced Input + multi-client PIE (RE-2A1-015, 023). - -### Failure modes - -- Server skips montage evaluation → missed hits under legacy design. -- Interrupt skips AN_AttackComplete → stuck CurrentlyAttacking. +Listen-server: damage once on server; montage both; no client Health write. (Enhanced Input + 2P blocked.) ### Approval question -**Do you approve client-intent / server-validation authority, with multicast limited to presentation, and AnimNotify forbidden as sole authority for damage, costs, or state transitions?** +**Resolved** — Owner approved 2026-07-17. --- # C-010 — Animation responsibility contract -**State:** Proposed +**State:** Approved with Conditions +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision / timing clarification -Animation currently gates hit windows and attack lockout cleanup. Need a clear cosmetic vs authoritative split while preserving timing feel. +Animation may own: visual playback, sound timing, cosmetic Niagara timing, camera presentation, cosmetic trails, presentation events. -### Current implementation +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. -AN_Ability_* triggers UseAbility*; AN_AttackComplete clears CurrentlyAttacking; ABPs read IsDead/IsBlocking/etc. for presentation. +Do not prescribe the exact replacement timing mechanism in this pass. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Doc `10` shared animation→ability architecture | -| Runtime | Notify chain not exercised (RE-2A1-019/021) | +Static: doc `10`. Runtime: RE-2A1-019–021. -### Proposed rule +### Approved architectural rule -**Animation may own:** +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. -- Visual playback -- Sound timing -- Cosmetic Niagara timing -- Camera presentation -- Cosmetic weapon-trail windows +### Deferred implementation choices -**Animation may not solely own:** +- Exact authoritative animation-timing mechanism (Ability Tasks, windows, etc.). -- Authoritative damage -- Cost commitment -- Target validation -- Death -- Respawn -- Guaranteed ability cleanup +### Alternatives -**Timing correlation:** Server (or server Ability Task) may open/close validated hit windows using durations/sections that match montage timing. Cosmetic notifies may fire predicted VFX. Authoritative commit remains server-side even if a notify is skipped. - -### Allowed behavior - -- Montage playback from server-triggered multicast. -- Cosmetic notifies. -- Server tasks waiting on montage events as *hints* with failsafe timeouts (C-011). - -### Prohibited behavior - -- Sole reliance on AN_AttackComplete for cleanup. -- Damage that only applies inside a multicast notify without prior/server validation path. - -### Transitional behavior - -Existing notify gameplay remains until Phase 2B replaces it under C-009/C-011. +Notify-authoritative hit windows as end state — Rejected. ### Dependencies C-009, C-011, C-007. -### Migration impact +### Runtime validation obligation -AN_Ability_001–004, AN_AttackComplete, Multicast_PlayMontage pins, character ABPs. - -### Runtime validation required - -- Interrupt mid-montage still cleans ability state without AN_AttackComplete. -- **Blocked today:** RE-2A1-020. - -### Failure modes - -- Cosmetic-only migration that still requires notify for damage. -- Desynced VFX vs server hit window (acceptable if documented; damage must still be correct). +Interrupt cleanup without AN_AttackComplete. (RE-2A1-020 blocked.) ### Approval question -**Do you approve animation as cosmetic-only for authority purposes, with server-owned timing correlation allowed, and notify-driven authoritative gameplay prohibited as the end state?** +**Resolved** — Owner approved with timing clarification 2026-07-17. --- # C-011 — Ability lifecycle and cleanup contract -**State:** Proposed +**State:** Approved +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision -Most Server_Ability_*_End bodies are empty. Cleanup depends on AN_AttackComplete. Interrupt may leave CurrentlyAttacking stuck. +Adopt shared lifecycle: Requested → Validated → Committed → Active → Ending → Completed | Canceled | Interrupted | Failed. -### Current implementation +Define guaranteed cleanup for: normal completion, input release, validation failure, montage start failure, interruption, death, pawn destruction, target invalidation, timeout or failsafe. -Gates on CurrentlyAttacking/IsDead; Ends mostly empty; AN_AttackComplete clears attacking; montage interrupt pins unwired. +AN_AttackComplete cannot be the only cleanup path. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Static | Docs `05`, `07` S3/S12, `10` | -| Runtime | RE-2A1-020 — interrupt test blocked | +Static: docs `05`, `07` S3/S12, `10`. Runtime: RE-2A1-020. -### Proposed rule +### Approved architectural rule -Shared lifecycle states: +Shared lifecycle states with guaranteed cleanup on all listed terminal/failure paths. No sole dependence on AN_AttackComplete. -`Requested → Validated → Committed → Active → Ending → Completed | Canceled | Interrupted | Failed` +### Deferred implementation choices -| Event | Required behavior | -|---|---| -| Resource commitment | On Validated→Committed; atomic (C-003) | -| Cooldown commitment | On Commit (when cooldowns exist) | -| Montage start failure | → Failed; release commit if policy requires; clear attacking | -| Normal completion | → Completed; clear locks; EndAbility equivalent | -| Input release | Route to Ending/Canceled per ability policy | -| Interruption | → Interrupted; **guaranteed** cleanup without AN_AttackComplete | -| Death during ability | Cancel → Interrupted/Canceled; C-007 | -| Pawn destruction | Force cleanup; no dangling timers | -| Target invalidation | End or fail per ability; no further damage commits | -| Timeout / failsafe | Absolute cleanup timer independent of montage | - -**No ability may depend solely on AN_AttackComplete for guaranteed state cleanup.** - -### Allowed behavior - -- Explicit EndAbility / cancel tags / Ability Task end states. -- Failsafe timers. - -### Prohibited behavior - -- Cleanup only via montage end notify. -- Leaving CurrentlyAttacking true after interrupt/death. - -### Transitional behavior - -Wire montage OnInterrupted/OnBlendOut **or** native failsafe while notifies remain. +Per-ability cancel/interrupt policy details; exact failsafe timer values. ### Dependencies C-003, C-007, C-008, C-009, C-010. -### Migration impact +### Runtime validation obligation -All playable ability Begin/End/UseAbility paths; Phase 2B shared framework. - -### Runtime validation required - -- Full montage: lockout clears. -- Interrupt: lockout clears without AN_AttackComplete. -- Death mid-ability: cleanup + no further damage. -- **Blocked today:** RE-2A1-019–022. - -### Failure modes - -- Stuck attack lockout; orphan timers; double cost on retry. +Complete and interrupted montages both clear locks; death mid-ability cleans up. (RE-2A1-019–022 blocked.) ### Approval question -**Do you approve the shared ability lifecycle states and the rule that cleanup must be guaranteed without sole dependence on AN_AttackComplete?** +**Resolved** — Owner approved 2026-07-17. --- # C-012 — PlayerState and pawn ownership contract -**State:** Proposed +**State:** Approved +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision -Need clear persistent vs transient ownership across respawn. Enemy ASC ownership differs and GetASC via PlayerState returns nullptr for enemies. - -### Current implementation - -- Players: ASC + AttributeSet on `ARIRPlayerState`; InitAbilityActorInfo Owner=PS, Avatar=Character on PossessedBy / OnRep_PlayerState. -- Enemies: ASC on self; InitAbilityActorInfo(this,this); interface GetASC → PlayerState → nullptr. +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 -| Kind | Evidence | -|---|---| -| Static | Doc `06` ownership detail; `09` enemy GetASC defect | -| Runtime | RE-2A1-007 — PS ASC; pawn query resolves same set | -| Runtime | RE-2A1-027/028 — enemy ASC components present; inspector rejects actor (Tool Limitation / possible init gap) | +Static: docs `06`, `09`. Runtime: RE-2A1-007, 027, 028. -### Proposed rule +### Approved architectural rule -**PlayerState owns:** +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). -- Persistent player ASC -- Persistent AttributeSet -- Cross-pawn player state intended to survive respawn +### Deferred implementation choices -**Pawn owns:** +Exact enemy accessor fix packaging (native interface vs override). -- Avatar representation -- Movement -- Equipment components -- Transient physical state -- Animation -- Pawn-specific targeting and presentation +### Alternatives -**On possession / pawn replacement:** re-InitAbilityActorInfo; bind Overlay if local; teardown transient pawn state on old pawn. **Enemies** keep self-owned ASC with a separate init/accessor contract (fix GetASC for non-PlayerState owners in Phase 2D/2E). - -### Allowed behavior - -- Cache ASC pointer on pawn from PlayerState. -- Persistent attributes survive pawn destroy. - -### Prohibited behavior - -- Moving player ASC to pawn without an approved redesign. -- Expecting enemy GetASC-via-PlayerState to succeed. - -### Transitional behavior - -Keep current player PS ownership. Document enemy accessor as Existing Baseline Defect until fixed under this contract’s enemy clause. +Move player ASC to pawn — Rejected unless future redesign approved. ### Dependencies C-002, C-008, C-013. -### Migration impact +### Runtime validation obligation -`ARIRPlayerCharacter`, `ARIRPlayerState`, enemy GetASC, EffectActor targeting. - -### Runtime validation required - -- After respawn: OwnerActor still PlayerState; Avatar is new pawn; attributes persist then defaults reapplied per C-002. -- Enemy ASC readable via corrected accessor (deferred). -- Tool inaccessibility ≠ runtime absence (RE-2A1-028). - -### Failure modes - -- Avatar not updated → abilities target wrong actor. -- Enemy potions destroy without apply (nullptr ASC). +Post-respawn Owner/Avatar; enemy ASC via corrected accessor. Tool inaccessibility ≠ absence (RE-2A1-028). ### Approval question -**Do you approve keeping player ASC/AttributeSet on PlayerState with pawn as Avatar only, and treating enemy self-ASC as a separate ownership/init contract?** +**Resolved** — Owner approved 2026-07-17. --- # C-013 — HUD data-flow contract -**State:** Proposed +**State:** Approved +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision -Dual HUD paths: Overlay (ASC) works structurally; legacy `UpdatePlayerHUD` unimplemented. Respawn may recreate overlays. Stamina UI missing. - -### Current implementation - -- `ARIRHUD::InitOverlay` → OverlayWidgetController → Health/Mana bars. -- `Server_UpdateHUD` → `UpdatePlayerHUD` unimplemented on PC. -- No stamina widget. +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 -| Kind | Evidence | -|---|---| -| Static | Docs `11`, `06`, `07` S10 | -| Runtime | RE-2A1-008/009 — Overlay bars present; WBP_PlayerHUD spawned; no stamina widget | -| Runtime | Respawn Overlay duplication not observed (RT-006 blocked) | +Static: docs `11`, `07` S10. Runtime: RE-2A1-008, 009. -### Proposed rule +### Approved architectural rule -- Gameplay HUD reads ASC attributes through the Overlay / widget-controller path. -- Legacy `UpdatePlayerHUD` route is **retired** (remove or leave dead; do not implement as second SoT). -- No UI independently stores authoritative resources. -- HUD creation is **idempotent**. -- Respawn and travel must not create duplicate overlays. -- Stamina presentation is added **only after** C-001/C-002 are approved. -- UI reflects replicated authoritative state and does **not** drive gameplay state. +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. -### Allowed behavior +### Deferred implementation choices -- Rebind existing Overlay to new pawn/ASC avatar on respawn. -- Progress bars from attribute delegates. +Rebind vs recreate Overlay implementation detail (must remain idempotent). -### Prohibited behavior +### Alternatives -- Implementing UpdatePlayerHUD as a parallel authoritative HUD. -- UI writing Health/Mana. -- Unconditional InitOverlay without duplicate guard. - -### Transitional behavior - -Leave unimplemented UpdatePlayerHUD as dead code until removal; do not repair it. +Implement UpdatePlayerHUD as second SoT — Rejected. ### Dependencies C-001, C-002, C-008, C-012. -### Migration impact +### Runtime validation obligation -`RIRHUD`, Overlay widgets, BPI_PlayerController UpdatePlayerHUD, Server_UpdateHUD callers. - -### Runtime validation required - -- One Overlay after spawn and after respawn. -- Bars track ASC only. -- **Blocked:** respawn path (RE-2A1-022). - -### Failure modes - -- Duplicate overlays; stale bar bound to destroyed pawn; stamina UI before SoT approval. +One Overlay after spawn and respawn; bars track ASC. (RE-2A1-022 respawn untested.) ### Approval question -**Do you approve Overlay/widget-controller as the sole gameplay HUD data path, retirement of UpdatePlayerHUD, idempotent HUD creation, and deferred stamina UI until attribute contracts are approved?** +**Resolved** — Owner approved 2026-07-17. --- # C-014 — Pickup authority and replication contract -**State:** Proposed +**State:** Approved +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision -EffectActor pickups have no authority gate and `bReplicates=false`, risking desync and duplicate apply. Overlap apply not runtime-proven. - -### Current implementation - -Overlap → ApplyEffectToTarget → DestroyActor; no SwitchHasAuthority; bReplicates=false; destroy even if ASC null. +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 -| Kind | 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 | |---|---| -| Static | Doc `12` Authority Risk matrix | -| Runtime | RE-2A1-017 — HealthPotion `bReplicates=false` | -| Runtime | RE-2A1-016 — pickups present in Test01 | -| Runtime | RE-2A1-018 — overlap/GE apply not executed | - -### Proposed rule - -- Server owns overlap validation. -- Server applies the effect or mutation. -- Server destroys or deactivates the pickup. -- All clients receive a **consistent pickup-existence** state. -- A pickup applies **at most once** per valid collection. -- Cosmetic presentation may occur on clients **after** authoritative collection. -- Non-replicated pickups must **not** be used for network gameplay without an explicit server-owned spawning/visibility model. - -### Allowed behavior - -- Replicated pickup actors; server authority gate; server GE apply; server destroy. -- SP prototype with documented non-replicated model only if never used in MP as-is. - -### Prohibited behavior - -- Client-only destroy/apply for MP pickups. -- Relying on `bReplicates=false` EffectActors for listen-server gameplay. - -### Transitional behavior - -SP Test01 may keep current actors until 2E reconstruction, but they are classified Authority Risk and must not be treated as MP-correct. +| 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 (GetASC for enemies). +C-003, C-006, C-012. -### Migration impact +### Runtime validation obligation -Four EffectActor pickups; gold path (separate AddGold defect); Phase 2E. - -### Runtime validation required - -- Server apply once; ASC changes; actor gone on all clients. -- **Blocked today:** movement/input and 2P (RE-2A1-018, 023, 026). - -### Failure modes - -- Double GE apply; client destroy without server apply; enemy touch destroys without heal. +One apply; ASC change; destroyed on all clients. (RE-2A1-018, 023, 026 blocked.) ### Approval question -**Do you approve server-owned pickup validation/apply/destroy with replicated existence, at-most-once collection, and a ban on non-replicated pickups for network gameplay without an explicit server visibility model?** +**Resolved** — Owner approved 2026-07-17; client-overlap RPC rejected as default. --- # C-015 — Runtime observability contract -**State:** Proposed +**State:** Approved +**Owner decision date:** 2026-07-17 -### Problem being solved +### Owner decision -Reconstruction needs inspectable evidence. Phase 2A1 showed tool gaps (Enhanced Input, multi-client, enemy ASC inspector). Observability must be defined without requiring permanent debug UI yet. +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. -### Current implementation - -Ad-hoc MCP/ObjectTools/AbilitySystemInspector during Phase 2A1; no project harness. +Permitted mechanisms: structured logs, debugger inspection, Ability System inspection, a bounded temporary test harness. A permanent debug UI is not required. ### Confirmed evidence -| Kind | Evidence | -|---|---| -| Runtime | Tool limitations RE-2A1-015, 023, 028, 031 | -| Inference | Without logs/harness, C-005–C-011/C-014 cannot close | +Runtime tool limits: RE-2A1-015, 023, 028, 031. -### Proposed rule +### Approved architectural rule -Before reconstruction claims are trusted, the following must be inspectable via logs, debugger, Ability System inspection, or a future temporary test harness: +Minimum observability list above is required before trusting reconstruction claims. Permanent debug UI not required. Tool inaccessibility is not runtime absence. -- Character identity -- ASC OwnerActor and AvatarActor -- Current/max attributes -- Active Gameplay Effects -- Granted abilities -- Ability lifecycle state -- Authoritative damage events -- Death transitions -- Respawn transitions -- Pickup application count -- Network role +### Deferred implementation choices -Permanent debug UI is **not** required yet. - -### Allowed behavior - -- Structured log categories; temporary console/cheats in development builds; automation hooks. - -### Prohibited behavior - -- Treating tool inaccessibility as proof of runtime absence. -- Shipping permanent debug HUD as a substitute for contracts. - -### Transitional behavior - -Use manual PIE + logging until harness exists; environment decisions for 2-client PIE and Enhanced Input remain open (see `02`). +- Exact temporary observability implementation (logs vs harness packaging). ### Dependencies -All contracts for validation; harness work may be Phase 2A3 planning. +Supports validation of all contracts. -### Migration impact +### Runtime validation obligation -Logging helpers; future test harness; no gameplay SoT change. - -### Runtime validation required - -- Each listed field obtainable in a controlled session for player pawn; enemy attributes once accessor fixed. - -### Failure modes - -- False “missing ASC” from inspector limits; unverifiable MP claims. +Each listed field obtainable in a controlled session. ### Approval question -**Do you approve the minimum observability list above as a prerequisite for trusting reconstruction, without requiring permanent debug UI yet?** +**Resolved** — Owner approved 2026-07-17. --- -# Architectural recommendation summary +# Approved architecture boundary summary -## 1. Recommended canonical architecture - -ASC attributes on PlayerState are the sole resource SoT. Character default GEs initialize explicit current+max H/M/S on the server after actor info is valid. All gameplay resource mutation flows through a shared server interface. Damage and healing write ASC through one authoritative boundary. Death evaluates ASC Health ≤ 0 idempotently. GameMode/PC own respawn. HUD reads Overlay/ASC only. Abilities use client intent → server validate → presentation multicast, with server-owned lifecycle/cleanup. Enemies and pickups consume the same damage/resource rules under later phases. - -## 2. Transitional architecture - -- ASC→legacy one-way shadow for unconverted read-only consumers. -- ApplyDamage adapter into ASC damage boundary. -- Notify-timed UseAbility retained as debt until Ability Tasks / validated windows. -- SP non-replicated pickups tolerated only as known Authority Risk until 2E. - -## 3. Prohibited transitional patterns - -- Bidirectional ASC↔legacy sync -- Legacy writers silently overwriting ASC -- Multicast AnimNotify as sole gameplay authority -- Silent native Init* fallback hiding missing character defaults -- Non-replicated pickups used as-is for network gameplay -- Implementing UpdatePlayerHUD as a second resource SoT -- Treating tool limitation as runtime absence - -## 4. Decisions requiring owner approval - -All C-001 through C-015 approval questions above. None are Approved in this pass. - -## 5. Decisions blocked by runtime evidence - -| Area | Blocking evidence | Related contracts | -|---|---|---| -| Enhanced Input ability execution | RE-2A1-015/019/021 | C-009, C-010, C-011 | -| AnimNotify authority roles | Not observed | C-009, C-010 | -| Ability cost mutation | Not observed; Ability004 cost CDO=0 | C-003, C-004 | -| Ability interruption | RE-2A1-020 | C-011 | -| Player damage/death/respawn | RE-2A1-022 | C-005, C-007, C-008 | -| Two-client replication | RE-2A1-023–026 | C-009, C-014 | -| Remote character selection | Not run (needs 2P) | C-008 related / 2E | -| Pickup authority and visibility | RE-2A1-018 | C-014 | -| Enemy attribute mutation | RE-2A1-028/030 | C-005, C-012 | -| Session behavior | Deferred to 2E; not in 2A1 matrices | Outside 2A2a contracts | - -## 6. Phase 2A3 implementation-planning prerequisites - -1. Owner review of Proposed contracts (still no Approved stamp until explicitly granted). -2. Plan for remaining blocked runtime evidence (input harness, 2-client PIE authorization, controlled damage actor if approved). -3. Migration sequencing: C-001/C-002/C-003/C-004 → C-005/C-006/C-007 → C-008/C-013 → C-009–C-011 → C-014 with 2E. -4. Observability harness outline per C-015. -5. Explicit non-goals: no Phase 2B ability rewrite; no Unreal edits in 2A2a. - -## Dependency diagram +## Canonical dependency chain ```mermaid flowchart TD - attrs[CanonicalAttributes_C001_C002] - resource[SharedResourceBoundary_C003_C004] - dmgHeal[DamageHealing_C005_C006] - death[Death_C007] - respawn[Respawn_C008] - hud[HUD_C013] - ability[AbilityLifecycle_C009_C010_C011] + 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[Pickups_C014] + pickups[ServerOwnedReplicatedPickups_C014] observe[Observability_C015] attrs --> resource resource --> dmgHeal @@ -1237,6 +802,53 @@ flowchart TD 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 -This document is Markdown-only architecture design. No Unreal assets, source, configuration, plugins, or maps were modified. No Unreal MCP or PIE was used in Phase 2A2a. No contract is Approved. +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. diff --git a/Documentation/Phase2/04-Phase2A-DecisionRegister.md b/Documentation/Phase2/04-Phase2A-DecisionRegister.md index 5432a712..3b796a6e 100644 --- a/Documentation/Phase2/04-Phase2A-DecisionRegister.md +++ b/Documentation/Phase2/04-Phase2A-DecisionRegister.md @@ -2,35 +2,50 @@ | Field | Value | |---|---| -| Status | Draft | +| Status | Complete | | Date | 2026-07-17 | -| Phase | 2A2a | -| Starting Git commit | `9919faab` | -| Rule | All entries are **Proposed**, **Alternative**, **Deferred**, or **Blocked**. None are **Approved**. | +| Phase | 2A2b — Owner decisions applied | +| Starting Git commit | `c2fa15db` | +| Owner decision date | 2026-07-17 | +| Rule | Every C-001–C-015 entry has an owner state: Approved, Approved with Conditions, Deferred (sub-choice), or Rejected (alternative). | -Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Open-decision reconciliation: [`02-Phase2A-OpenDecisions.md`](02-Phase2A-OpenDecisions.md). +Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Open decisions / validation obligations: [`02-Phase2A-OpenDecisions.md`](02-Phase2A-OpenDecisions.md). --- ## Summary table -| Decision | Recommendation | Confidence | Blocking issue | Approval required | -|---|---|---|---|---| -| C-001 | ASC AttributeSet sole SoT for H/M/S currents and maxes | High | None for proposal; combat cutover needs death PIE later | Yes | -| C-002 | Option A — character-specific default GE after ASC actor info valid | Medium | Orphan GEs lack Max*; must fail visibly if missing | Yes | -| C-003 | Shared server ASC resource interface; atomic costs | High | Cost mutation path not runtime-proven | Yes | -| C-004 | ASC→legacy one-way shadow only; bidirectional rejected | High | Which consumers still need shadow until migrated | Yes | -| C-005 | Server damage boundary writing ASC; ApplyDamage as adapter; ExecCalc deferred | Medium | Damage/death path not exercised (RE-2A1-022) | Yes | -| C-006 | Server restore via same boundary; clamp to Max*; no over-resource by default | Medium | Pickup/heal overlap not observed (RE-2A1-018) | Yes | -| C-007 | Death from ASC Health ≤ 0; idempotent; anim presentation-only | Medium | Death path not observed; legacy health 0 at spawn risk | Yes | -| C-008 | GameMode + PC own respawn; ASC re-init; idempotent HUD | Medium | Respawn not observed (RE-2A1-022) | Yes | -| C-009 | Client intent; server validate; multicast presentation-only | Medium | Ability + 2P paths blocked (RE-2A1-015, 023) | Yes | -| C-010 | Animation cosmetic; server timing correlation; no notify authority | Medium | Notify chain not executed | Yes | -| C-011 | Shared lifecycle; guaranteed cleanup without sole AN_AttackComplete | Medium | Interrupt test blocked (RE-2A1-020) | Yes | -| C-012 | Player ASC on PlayerState; pawn Avatar; enemy self-ASC separate | High | Enemy inspector Tool Limitation (RE-2A1-028) | Yes | -| C-013 | Overlay-only HUD; retire UpdatePlayerHUD; defer stamina UI | High | Respawn Overlay duplication untested | Yes | -| C-014 | Server pickup validate/apply/destroy; replicate existence; ban naked non-rep MP pickups | Medium | Overlap apply + 2P blocked | Yes | -| C-015 | Minimum observability list; no permanent debug UI required yet | Medium | Harness not built; env limits remain | Yes | +| Decision | Owner state | Recommendation (locked) | Confidence | Validation obligation | Approval required | +|---|---|---|---|---|---| +| C-001 | Approved | ASC sole SoT for H/M/S currents and maxes | High | Combat/death cutover PIE (RE-2A1-022) | Resolved | +| C-002 | Approved with Conditions | Character-specific default GE; six attrs; fail visible; no duplicate init | Medium | Spawn/respawn per-class ASC; duplicate-init guard | Resolved | +| C-003 | Approved | Shared server ASC resource boundary; atomic costs | High | Cost mutation path (RE-2A1-015) | Resolved | +| C-004 | Approved (transitional) | ASC→legacy one-way named shadow; end state no shadow | High | Shadow inventory; no reverse write | Resolved | +| C-005 | Approved | Server damage boundary → ASC Health; ApplyDamage adapter only | Medium | Damage/death PIE (RE-2A1-022) | Resolved | +| C-006 | Approved | Server restore via boundary; clamp Max*; no over-resource default | Medium | Pickup/heal apply (RE-2A1-018) | Resolved | +| C-007 | Approved | Death from ASC Health ≤ 0; idempotent; anim presentation | Medium | Death path (RE-2A1-022) | Resolved | +| C-008 | Approved with Conditions | GameMode orchestrates; PC handoff; pawn reports only | Medium | Respawn/HUD (RE-2A1-022) | Resolved | +| C-009 | Approved | Client intent; server validate; multicast presentation-only | Medium | Ability + 2P (RE-2A1-015, 023) | Resolved | +| C-010 | Approved with Conditions | Animation presentation; timing signal into lifecycle; no sole notify authority | Medium | Interrupt/notify (RE-2A1-019–020) | Resolved | +| C-011 | Approved | Shared lifecycle; guaranteed cleanup; not sole AN_AttackComplete | Medium | Interrupt/death mid-ability (RE-2A1-020–022) | Resolved | +| C-012 | Approved | Player ASC on PlayerState; pawn Avatar; enemy self-ASC + corrected accessor | High | Respawn Owner/Avatar; enemy accessor (RE-2A1-028) | Resolved | +| C-013 | Approved | Overlay-only HUD; retire UpdatePlayerHUD; defer stamina UI | High | Overlay idempotence after respawn | Resolved | +| C-014 | Approved | Server pickup ownership; client-overlap RPC rejected as default | Medium | Overlap + 2P (RE-2A1-018, 023) | Resolved | +| C-015 | Approved | Minimum observability list; no permanent debug UI required | Medium | Harness/logs deliver listed fields | Resolved | + +--- + +## Explicit rejected and deferred marks + +| Item | Status | Notes | +|---|---|---| +| Bidirectional legacy synchronization | **Rejected** | C-004 | +| Client-overlap RPC as default pickup model | **Rejected** | C-014 | +| GameplayEffectExecutionCalculation choice | **Deferred** | C-005 — not selected | +| Exact default-GE mapping mechanism | **Deferred** | C-002 | +| Exact authoritative animation-timing mechanism | **Deferred** | C-010 | +| Exact temporary observability implementation | **Deferred** | C-015 | +| Whether any real consumer requires a temporary legacy shadow | **Deferred** | C-004 | --- @@ -40,17 +55,19 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-001 | | Title | Canonical player resource source of truth | -| State | Proposed | -| Recommended option | ASC attributes are sole SoT for Health, MaxHealth, Mana, MaxMana, Stamina, MaxStamina; DEPRECATED vars non-authoritative | -| Alternatives | Keep legacy SoT during reconstruction only (rejected as primary); character-specific transitional dual-SoT (rejected — prolongs P0) | -| Static evidence | `05-LegacyAbilityArchitecture.md` resource inventory; `06-PartialGASArchitecture.md` §8 legacy/GAS boundary; `01-ExecutiveSummary.md` P0 dual resources | +| State | Approved | +| Owner decision | ASC attributes sole authoritative source for Health, MaxHealth, Mana, MaxMana, Stamina, MaxStamina; DEPRECATED vars not authoritative | +| Approval conditions | None | +| Recommended option | ASC AttributeSet sole SoT | +| Alternatives | Legacy-only SoT — Rejected as end state; dual-SoT — Rejected | +| Static evidence | `05`, `06` §8, `01` P0 | | Runtime evidence | RE-2A1-001, 004, 005, 012, 013; RT-001, RT-002 | -| Benefits | One truth for UI, combat, potions, death; removes spawn divergence class of bugs | -| Risks | Breaking unconverted legacy readers if shadow/cutover incomplete | -| Migration impact | Abilities, Amazonian death, Cleric heal, HUD, future stamina | -| Blocking unknowns | Whether AnyDamage fires with legacy health already 0 | -| Runtime validation | Post-init ASC match; potion vs combat both mutate ASC; death from ASC | -| Approval question | Do you approve ASC AttributeSet as the sole canonical source of truth for Health, MaxHealth, Mana, MaxMana, Stamina, and MaxStamina, with DEPRECATED Blueprint resource variables treated as non-authoritative? | +| Benefits | One truth for UI, combat, potions, death | +| Risks | Unconverted legacy readers break without shadow/cutover | +| Migration impact | Abilities, Amazonian death, Cleric heal, HUD, stamina | +| Blocking unknowns | N/A for architecture approval | +| Validation obligation | Post-init ASC; potion+combat mutate ASC; death from ASC (RE-2A1-022) | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -60,17 +77,18 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-002 | | Title | Character default attribute initialization | -| State | Proposed | -| Recommended option | A — Character-specific default Gameplay Effect selected by pawn/class; server apply after ASC actor info valid; explicit current+max H/M/S; visible fail on missing assignment | -| Alternatives | B — Shared init GE + SetByCaller; C — Native initialization service; hybrid Max* fill transitional | -| Static evidence | `06-PartialGASArchitecture.md` §§2–4 default GE matrix; native Init*; DefaultAttributesGameplayEffect=None | -| Runtime evidence | RE-2A1-001, 002, 011, 012 — identical ASC; no active GE; CDO legacy defaults | -| Benefits | Per-class balance; reuses existing GE assets/property; deterministic spawn/respawn | -| Risks | Existing orphan GEs omit Max*; incomplete GE applied → broken clamps | -| Migration impact | PlayerState, character GEs, Gunslinger missing GE, spawn/respawn | -| Blocking unknowns | Final per-class balance numbers (design); Gunslinger defaults | -| Runtime validation | Per-class ASC after spawn/respawn; missing assignment visible error | -| Approval question | Do you approve Option A (character-specific default Gameplay Effect applied server-side after ASC actor info is valid), with visible failure on missing assignment and mandatory explicit current+max Health/Mana/Stamina? | +| State | Approved with Conditions | +| Owner decision | Character-specific default Gameplay Effects with listed constraints | +| Approval conditions | Server-only; after ASC actor info + avatar valid; deterministic spawn/respawn; all six attrs; no native stamina fallback; no Blueprint CDO reliance; visible failure if missing; prevent duplicate init | +| Recommended option | Option A — character-specific default GE | +| Alternatives | B SetByCaller; C native service — historical alternatives; exact mapping **Deferred** | +| Static evidence | `06` §§2–4 | +| Runtime evidence | RE-2A1-001, 002, 011, 012 | +| Benefits | Per-class balance; deterministic init | +| Risks | Orphan GEs lack Max*; duplicate apply | +| Migration impact | PlayerState, GEs, Gunslinger, spawn/respawn | +| Validation obligation | Per-class ASC spawn/respawn; missing config visible; no duplicate GE | +| Approval question | Resolved — approved with conditions 2026-07-17 | --- @@ -80,17 +98,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-003 | | Title | Resource-access boundary | -| State | Proposed | -| Recommended option | Shared authoritative ASC interface; atomic server cost check+mutate; no new DEPRECATED direct access | -| Alternatives | Per-system ad-hoc ASC reads (rejected — recreates dual writers) | -| Static evidence | `05` FCanUseMana / DEPRECATED costs; `07` S9; `06` boundary | -| Runtime evidence | RE-2A1-014, 015 — cost path not proven; Ability004ManaCost CDO=0 | -| Benefits | Incremental migration without two SoTs; consistent affordability | -| Risks | Bypass of interface during hasty BP edits | -| Migration impact | All cost/heal/damage resource call sites | -| Blocking unknowns | Exact FCanUseMana body edge cases; cost timing vs montage | -| Runtime validation | Cost reduces ASC once; failed affordability no mutation | -| Approval question | Do you approve a shared server-authoritative ASC resource interface as the only allowed read/write path for new gameplay resource access, with atomic cost validation and mutation? | +| State | Approved | +| Owner decision | Shared server-authoritative ASC boundary for all new reads, affordability, costs, restoration, max queries, gates; atomic cost commit | +| Approval conditions | None | +| Alternatives | Per-system ad-hoc ASC — Rejected | +| Static evidence | `05`, `07` S9, `06` | +| Runtime evidence | RE-2A1-014, 015 | +| Validation obligation | Cost reduces ASC once; failed affordability no mutation | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -100,17 +115,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-004 | | Title | Legacy compatibility policy | -| State | Proposed | -| Recommended option | C — ASC→legacy one-way shadow for temporary read-only consumers; prefer D cutover when possible | -| Alternatives | D — No sync / migrate first; A bidirectional **Rejected by Existing Evidence**; B legacy→ASC rejected as primary | -| Static evidence | `06` sync Missing; `01` P0 dual pools | -| Runtime evidence | RE-2A1-004, 005, 013 — divergent spawn; Overlay ASC vs combat legacy | -| Benefits | Avoids feedback loops; protects ASC from zeroed legacy writers | -| Risks | Shadow forgotten; legacy writer still active | -| Migration impact | AnyDamage, FCanUseMana readers, Server_UpdateHUD | -| Blocking unknowns | Full runtime inventory of legacy readers during death/ability | -| Runtime validation | Shadow matches after ASC change; legacy cannot overwrite ASC | -| Approval question | Do you approve ASC→legacy one-way shadow only for temporary read-only consumers, with bidirectional sync prohibited and legacy writers forbidden from silently overwriting ASC? | +| State | Approved (transitional only) | +| Owner decision | ASC→legacy one-way shadow only for named read-only consumers with removal condition; ASC authoritative; no legacy write-through; bidirectional Rejected; end state no shadow; Option D preferred when migratable | +| Approval conditions | Named consumer + removal condition required per shadow | +| Alternatives | A Bidirectional — **Rejected**; B Legacy→ASC primary — Rejected; D no-sync preferred when migratable | +| Static evidence | `06` sync Missing | +| Runtime evidence | RE-2A1-004, 005, 013 | +| Validation obligation | Shadow matches ASC; inventory whether any shadow consumer needed (**Deferred** choice) | +| Approval question | Resolved — approved transitional 2026-07-17 | --- @@ -120,17 +132,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-005 | | Title | Damage contract | -| State | Proposed | -| Recommended option | Single server damage boundary writing ASC Health; legacy ApplyDamage as transitional adapter; ExecutionCalculation deferred | -| Alternatives | Pure GE ExecutionCalculation (Deferred/Alternative); keep ApplyDamage+legacy health (Rejected as end state) | -| Static evidence | `05` ApplyDamage paths; `09` enemy reception Missing; `06` no ExecCalc project subclasses | -| Runtime evidence | RE-2A1-022, 027, 030 — damage not observed; enemy components present | -| Benefits | One entry for players/enemies; dedupe; death hook | -| Risks | Adapter gap during migration; enemy consumer still Missing | -| Migration impact | All ApplyDamage sites; Amazonian AnyDamage; Phase 2D enemies | -| Blocking unknowns | Runtime authority of hit windows; block absorb design | -| Runtime validation | Single ASC Health reduction; no double hit; death trigger | -| Approval question | Do you approve a single server-authoritative damage entry that writes ASC Health, with legacy ApplyDamage limited to a transitional adapter, and ExecutionCalculation design deferred? | +| State | Approved | +| Owner decision | One server damage boundary: validate source/target; preserve instigator/causer; magnitude; mitigation at one boundary; mutate ASC Health; dedupe; death eval; observable damage event; ApplyDamage adapter only | +| Approval conditions | None for boundary; ExecCalc not approved | +| Alternatives | Final GE ExecutionCalculation — **Deferred**; legacy ApplyDamage+DEPRECATED health end state — Rejected | +| Static evidence | `05`, `09`, `06` | +| Runtime evidence | RE-2A1-022, 027, 030 | +| Validation obligation | Single ASC Health reduction; no double hit; death trigger | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -140,17 +149,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-006 | | Title | Healing and resource restoration contract | -| State | Proposed | -| Recommended option | Server restore via shared ASC boundary; clamp to Max*; consumables same path; no over-resource by default | -| Alternatives | Allow overheal via tagged GEs only (future design) | -| Static evidence | `05` Cleric recover; `06`/`12` potion GEs; no AttributeSet clamp | -| Runtime evidence | RE-2A1-018 — pickup apply not run | -| Benefits | Overlay and combat agree; potions/abilities consistent | -| Risks | Cleric transitional dual heal if not adapted | -| Migration impact | Cleric 002, EffectActors, DEPRECATED recover | -| Blocking unknowns | Intended overheal design (none evidenced) | -| Runtime validation | Clamp at max; potion +25 once; Overlay update | -| Approval question | Do you approve server-authoritative restoration through the shared ASC resource boundary, clamping to Max* by default, with consumables and ability heals using the same path? | +| State | Approved | +| Owner decision | Authoritative restore via shared boundary; clamp to max; attribute source; update ASC; HUD via delegates; no over-resource by default | +| Approval conditions | None | +| Alternatives | Overheal via tagged GEs — not approved now | +| Static evidence | `05`, `06`, `12` | +| Runtime evidence | RE-2A1-018 | +| Validation obligation | Clamp at max; potion once; Overlay update | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -160,17 +166,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-007 | | Title | Death contract | -| State | Proposed | -| Recommended option | Authoritative idempotent death from ASC Health ≤ 0; shared replicated dead state; anim presentation-only | -| Alternatives | Tag-only State.Dead as primary (Deferred until tags wired); legacy≤0 SoT (Rejected as end state) | -| Static evidence | `05` Amazonian death; `09` enemy IsDead forced false; `10` ABP Death | -| Runtime evidence | RE-2A1-006, 004, 013, 022 — IsDead false; legacy health 0; death not observed | -| Benefits | Idempotent; aligns Overlay and death; fixes enemy ABP ownership of truth | -| Risks | Instant death if legacy path fires before ASC cutover | -| Migration impact | PlayerDeath, Amazonian AnyDamage, enemy death ABP, tags | -| Blocking unknowns | Whether AnyDamage runs at legacy 0; Paladin inbound damage path | -| Runtime validation | One death transition; no re-entry; ABP follows replicated state | -| Approval question | Do you approve authoritative, idempotent death evaluated from ASC Health ≤ 0, with animation as presentation-only and player/enemy differing only in post-death lifecycle? | +| State | Approved | +| Owner decision | Death from ASC Health ≤ 0; authoritative; idempotent; one replicated dead state; cancel abilities; disable movement/interaction; anim presentation; shared death definition for player/enemy | +| Approval conditions | None | +| Alternatives | Legacy≤0 SoT — Rejected as end state | +| Static evidence | `05`, `09`, `10` | +| Runtime evidence | RE-2A1-004, 006, 013, 022 | +| Validation obligation | One transition; no re-entry; ABP follows replicated state | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -180,17 +183,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-008 | | Title | Respawn contract | -| State | Proposed | -| Recommended option | GameMode + PlayerController own server respawn lifecycle; pawn does not solely replace itself | -| Alternatives | Pawn-owned Server_RespawnPlayer as sole owner (Rejected as primary) | -| Static evidence | `07` S8; `11` PlayerRespawn / PlayerFirstSpawn | -| Runtime evidence | RE-2A1-010 — spawn warning; RE-2A1-022 — respawn untested | -| Benefits | Clear ownership; ASC/HUD rebind; duplicate-respawn guard | -| Risks | Existing pawn respawn graphs need rewiring; PlayerFirstSpawn warning | -| Migration impact | GM_Dungeoneer, PC_Character, base death/respawn, HUD | -| Blocking unknowns | Exact timer (~2s) intent; Overlay recreate vs rebind preference in practice | -| Runtime validation | One respawn; ASC Owner/Avatar correct; defaults reapplied; one Overlay | -| Approval question | Do you approve GameMode + PlayerController ownership of server respawn lifecycle (pawn must not solely replace itself), including ASC re-init, default reapplication, possession, input restore, and idempotent HUD bind? | +| State | Approved with Conditions | +| Owner decision | GameMode owns orchestration; PlayerController owns handoff (request/state/possess/input/HUD); dying pawn reports only — must not create/possess replacement | +| Approval conditions | Must cover duplicate-request prevention, timing, destroy, spawn, PlayerState persistence, ASC avatar teardown/re-init, default reapply, possession, input restore, HUD idempotence | +| Alternatives | Pawn-owned sole respawn — Rejected | +| Static evidence | `07` S8, `11` | +| Runtime evidence | RE-2A1-010, 022 | +| Validation obligation | One respawn; Owner/Avatar correct; one Overlay | +| Approval question | Resolved — approved with clarification 2026-07-17 | --- @@ -200,17 +200,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-009 | | Title | Authority contract | -| State | Proposed | -| Recommended option | Client intent → server validate/commit → multicast presentation-only; notify not sole authority | -| Alternatives | Allow Authority-gated notify gameplay indefinitely (Rejected as end state); documented narrow exceptions (Deferred) | -| Static evidence | `05`/`10` Input→Server→Multicast→AN→UseAbility | -| Runtime evidence | RE-2A1-015, 019, 021, 023–026 — ability/2P not observed | -| Benefits | Predictable MP; removes interrupt/notify authority risk | -| Risks | Timing feel change during migration; temporary dual patterns | -| Migration impact | All ability network paths; Phase 2B | -| Blocking unknowns | Server vs client notify evaluation roles at runtime | -| Runtime validation | Listen-server damage once; montage both; no client Health write | -| Approval question | Do you approve client-intent / server-validation authority, with multicast limited to presentation, and AnimNotify forbidden as sole authority for damage, costs, or state transitions? | +| State | Approved | +| Owner decision | Client intent; server validates life, ability, target, range, resources, cost, cooldown, result; authoritative owners write replicated state; multicast presentation-only | +| Approval conditions | None | +| Alternatives | Notify-as-sole-authority end state — Rejected | +| Static evidence | `05`, `10` | +| Runtime evidence | RE-2A1-015, 019, 021, 023–026 | +| Validation obligation | Listen-server damage once; montage both | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -220,17 +217,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-010 | | Title | Animation responsibility contract | -| State | Proposed | -| Recommended option | Animation owns cosmetics; may correlate timing; must not solely own damage/cost/death/respawn/cleanup | -| Alternatives | Keep notify-authoritative hit windows (Rejected as end state) | -| Static evidence | `10-AnimationDependencies.md` shared architecture and Networking Risk | -| Runtime evidence | RE-2A1-019–021 — notify path not run | -| Benefits | Clear cosmetic vs authority split; preserves timing via server windows | -| Risks | VFX desync vs hits; migration cost for montages | -| Migration impact | AN_Ability_*, AN_AttackComplete, Multicast_PlayMontage | -| Blocking unknowns | Exact notify trigger times (Manual Editor) | -| Runtime validation | Interrupt cleanup without AN_AttackComplete; hits still server-valid | -| Approval question | Do you approve animation as cosmetic-only for authority purposes, with server-owned timing correlation allowed, and notify-driven authoritative gameplay prohibited as the end state? | +| State | Approved with Conditions | +| Owner decision | Animation owns presentation; may emit timing signal evaluated on authority; cannot be sole gameplay authority; signals enter ability lifecycle; cleanup not blocked by missing notify | +| Approval conditions | Exact timing mechanism not prescribed this pass — **Deferred** | +| Alternatives | Notify-authoritative hits as end state — Rejected | +| Static evidence | `10` | +| Runtime evidence | RE-2A1-019–021 | +| Validation obligation | Interrupt cleanup without AN_AttackComplete | +| Approval question | Resolved — approved with timing clarification 2026-07-17 | --- @@ -240,17 +234,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-011 | | Title | Ability lifecycle and cleanup contract | -| State | Proposed | -| Recommended option | Shared lifecycle states; guaranteed cleanup on interrupt/death/destroy/timeout; no sole AN_AttackComplete dependence | -| Alternatives | Montage blend-out notify required (insufficient alone); cancel tags + EndAbility (compatible Alternative) | -| Static evidence | `05` empty Ends; `07` S3/S12; `10` unwired montage pins | -| Runtime evidence | RE-2A1-020 — interrupt blocked | -| Benefits | No stuck CurrentlyAttacking; safe death mid-ability | -| Risks | Under-specified per-ability cancel policy | -| Migration impact | All Begin/End/UseAbility; Phase 2B framework | -| Blocking unknowns | Which existing actions can interrupt without asset edits | -| Runtime validation | Complete and interrupted montages both clear locks | -| Approval question | Do you approve the shared ability lifecycle states and the rule that cleanup must be guaranteed without sole dependence on AN_AttackComplete? | +| State | Approved | +| Owner decision | Shared lifecycle states; guaranteed cleanup for listed paths; AN_AttackComplete cannot be only cleanup path | +| Approval conditions | None | +| Alternatives | Montage-notify-only cleanup — Rejected | +| Static evidence | `05`, `07` S3/S12, `10` | +| Runtime evidence | RE-2A1-020 | +| Validation obligation | Complete + interrupted clear locks; death mid-ability | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -260,17 +251,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-012 | | Title | PlayerState and pawn ownership contract | -| State | Proposed | -| Recommended option | Keep player ASC/AttributeSet on PlayerState; pawn Avatar; enemy self-ASC separate contract | -| Alternatives | Move ASC to pawn (Rejected unless redesign approved); dual ownership unclear Avatar rules (Rejected) | -| Static evidence | `06` ownership; `09` enemy GetASC nullptr | +| State | Approved | +| Owner decision | PlayerState owns ASC/AttributeSet/cross-pawn state; pawn owns avatar/movement/anim/equipment/transient/targeting presentation; re-InitAbilityActorInfo on possess/replace; enemy self-ASC valid with corrected accessor | +| Approval conditions | None | +| Alternatives | Move ASC to pawn — Rejected unless redesign | +| Static evidence | `06`, `09` | | Runtime evidence | RE-2A1-007, 027, 028 | -| Benefits | Survives respawn; matches existing native design | -| Risks | Enemy accessor defect continues until 2D/2E fix | -| Migration impact | InitAbilityActorInfo, EffectActor GetASC, enemies | -| Blocking unknowns | Whether enemy InitAbilityActorInfo fully exposes ASC to inspector | -| Runtime validation | Post-respawn Owner/Avatar; enemy ASC via corrected accessor | -| Approval question | Do you approve keeping player ASC/AttributeSet on PlayerState with pawn as Avatar only, and treating enemy self-ASC as a separate ownership/init contract? | +| Validation obligation | Post-respawn Owner/Avatar; enemy ASC via corrected accessor | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -280,17 +268,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-013 | | Title | HUD data-flow contract | -| State | Proposed | -| Recommended option | Overlay/widget-controller only; retire UpdatePlayerHUD; idempotent HUD; defer stamina UI | -| Alternatives | Implement UpdatePlayerHUD as second path (Rejected); recreate Overlay every possess without guard (Rejected) | -| Static evidence | `11` HUD matrix; `07` S10 unimplemented UpdatePlayerHUD | -| Runtime evidence | RE-2A1-008, 009 — Overlay present; no stamina widget | -| Benefits | Single UI SoT; avoids duplicate overlays | -| Risks | Respawn rebind bugs if InitOverlay not idempotent | -| Migration impact | RIRHUD, Overlay, Server_UpdateHUD callers | -| Blocking unknowns | Exact Overlay instance counts after respawn | -| Runtime validation | One Overlay spawn+respawn; bars track ASC | -| Approval question | Do you approve Overlay/widget-controller as the sole gameplay HUD data path, retirement of UpdatePlayerHUD, idempotent HUD creation, and deferred stamina UI until attribute contracts are approved? | +| State | Approved | +| Owner decision | Overlay/widget-controller only; retire UpdatePlayerHUD; no UI SoT; idempotent HUD; no duplicate overlays; ASC-driven; stamina UI after canonical stamina init; UI cannot mutate gameplay | +| Approval conditions | None | +| Alternatives | UpdatePlayerHUD as second path — Rejected | +| Static evidence | `11`, `07` S10 | +| Runtime evidence | RE-2A1-008, 009 | +| Validation obligation | One Overlay spawn+respawn; bars track ASC | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -300,17 +285,14 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-014 | | Title | Pickup authority and replication contract | -| State | Proposed | -| Recommended option | Server validate/apply/destroy; replicated existence; at-most-once; ban non-rep MP pickups without server visibility model | -| Alternatives | Server RPC from client overlap (Alternative); SP-only non-rep prototypes documented (transitional only) | -| Static evidence | `12-Pickups-And-Effects.md` Authority Risk | +| State | Approved | +| Owner decision | Server owns validate/apply-once/destroy-or-deactivate/replicate existence/dedupe/attribute; client-overlap RPC **Rejected** as default; client cosmetics after authoritative collection | +| Approval conditions | None | +| Alternatives | Client-overlap RPC default — **Rejected**; SP non-rep as MP model — Rejected | +| Static evidence | `12` | | Runtime evidence | RE-2A1-016, 017, 018 | -| Benefits | Consistent MP; prevents double apply | -| Risks | Requires actor replication enablement; enemy null ASC destroy side effect | -| Migration impact | Four EffectActors; Phase 2E; GetASC fix interaction | -| Blocking unknowns | Duplicate apply under 2P; sphere overlap details | -| Runtime validation | One apply; ASC change; destroyed on all clients | -| Approval question | Do you approve server-owned pickup validation/apply/destroy with replicated existence, at-most-once collection, and a ban on non-replicated pickups for network gameplay without an explicit server visibility model? | +| Validation obligation | One apply; ASC change; destroyed on all clients | +| Approval question | Resolved — approved 2026-07-17 | --- @@ -320,23 +302,31 @@ Companion: [`03-SharedGameplayContracts.md`](03-SharedGameplayContracts.md). Ope |---|---| | Decision ID | C-015 | | Title | Runtime observability contract | -| State | Proposed | -| Recommended option | Minimum inspectable set via logs/debugger/ASC inspect/future harness; no permanent debug UI required yet | -| Alternatives | Permanent debug HUD (Deferred); do nothing (Rejected — blocks reconstruction trust) | -| Static evidence | `13-Unknowns-And-RuntimeQuestions.md` runtime groups; `15` handoff | -| Runtime evidence | RE-2A1-015, 023, 028, 031 — tool/environment limits | -| Benefits | Makes blocked areas closable; prevents false negatives from tools | -| Risks | Harness scope creep; env still blocks Enhanced Input / 2P | -| Migration impact | Logging; temporary harness; not gameplay SoT | -| Blocking unknowns | How to enable 2-client PIE without config save; Enhanced Input injection | -| Runtime validation | Each listed field obtainable in controlled session | -| Approval question | Do you approve the minimum observability list as a prerequisite for trusting reconstruction, without requiring permanent debug UI yet? | +| State | Approved | +| Owner decision | Observable: identity, net role, Owner/Avatar, attrs, active GEs, granted abilities, lifecycle, resource commitments, damage/death/respawn events, pickup apply count; via logs/debugger/ASC inspect/bounded harness; no permanent debug UI required | +| Approval conditions | None | +| Alternatives | Exact harness packaging — **Deferred**; permanent debug UI — not required | +| Static evidence | `13`, `15` | +| Runtime evidence | RE-2A1-015, 023, 028, 031 | +| Validation obligation | Each listed field obtainable in controlled session | +| Approval question | Resolved — approved 2026-07-17 | --- +## Approved architecture boundary summary + +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. + +- 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. + ## Register integrity -- No decision recorded as Approved. -- Recommendations are Proposed only. -- Bidirectional sync recorded as Rejected by Existing Evidence under C-004. -- ExecutionCalculation under C-005 is Deferred / Alternative, not selected. +- Every C-001–C-015 has an owner state. +- Status: Complete. +- Runtime validation obligations are recorded but do not reopen architecture approval. +- No Unreal implementation authorized by this register alone.