Merge pull request 'Update module dependency register and README with new epic documentation and refined next actions. Added SecurityTierZoneFlags module and clarified dependencies in the planning documents.' (#1) from docs/decomposition-follow-up into main

Reviewed-on: don/untitled-cyberpunk-mmo#1
main
don 2026-03-29 16:50:02 -04:00
commit 063974ca93
12 changed files with 850 additions and 5 deletions

View File

@ -453,9 +453,9 @@ Module template:
- Dependencies: E4.M1, backend world services.
- Stage target: Pre-production.
- **E4.M4 SecurityTierZoneFlags**
- Responsibility: High/contested/low-security tagging and client/server zone risk signaling.
- Responsibility: High/contested/low-security tagging and client/server zone risk signaling. `E6.M1` reads `SecurityTier` and `ZonePolicyState` from here; Epic 4 does not depend on Epic 6 modules.
- Key contracts: `SecurityTier`, `ZonePolicyState`, `ZoneEntryWarning`.
- Dependencies: E4.M1, E6.M1.
- Dependencies: E4.M1.
- Stage target: Prototype.
### Epic 5 Modules - PvE Combat and Encounter Content

View File

@ -18,8 +18,24 @@ This workspace contains detailed planning artifacts derived from the finalized m
3. Use stable IDs (E1, E1.M1, P1.M1, etc.) to preserve traceability.
4. Every new slice must reference telemetry and validation where applicable.
## Epic Files
| Epic | Document |
|------|----------|
| 1 - Core Player Runtime | [epics/epic_01_core_player_runtime.md](epics/epic_01_core_player_runtime.md) |
| 2 - Classless Progression | [epics/epic_02_classless_progression.md](epics/epic_02_classless_progression.md) |
| 3 - Crafting Economy | [epics/epic_03_crafting_economy.md](epics/epic_03_crafting_economy.md) |
| 4 - World Topology | [epics/epic_04_world_topology.md](epics/epic_04_world_topology.md) |
| 5 - PvE Combat | [epics/epic_05_pve_combat.md](epics/epic_05_pve_combat.md) |
| 6 - PvP Security | [epics/epic_06_pvp_security.md](epics/epic_06_pvp_security.md) |
| 7 - Quest / Faction | [epics/epic_07_quest_faction.md](epics/epic_07_quest_faction.md) |
| 8 - Social / Guild | [epics/epic_08_social_guild.md](epics/epic_08_social_guild.md) |
| 9 - LiveOps / Integrity | [epics/epic_09_liveops_integrity.md](epics/epic_09_liveops_integrity.md) |
Template for new epics or major revisions: [epics/_epic_template.md](epics/_epic_template.md)
## Next Actions
1. Copy `epics/_epic_template.md` into `epics/epic_01_core_player_runtime.md` through `epics/epic_09_liveops_integrity.md`.
2. Populate `modules/module_dependency_register.md` while decomposing epics.
3. Build milestone execution checklists in `milestones/phase_execution_plan.md`.
1. Expand slices into engineering tickets; keep module IDs aligned with the master plan.
2. Populate `modules/module_dependency_register.md` as contracts stabilize.
3. Refine `milestones/phase_execution_plan.md` with dates and owners when execution starts.

View File

@ -0,0 +1,86 @@
# Epic 1 - Core Player Runtime (Client Controls + Character Loop)
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 1
- Related modules: E1.M1, E1.M2, E1.M3, E1.M4
## Ownership and success (Level 1)
- **Ownership focus:** Gameplay Engineering + Technical Design
- **Success criteria:** Stable 3D isometric control loop feels responsive and readable across supported hardware tiers.
## Objective
Deliver the foundational client runtime: movement, locked isometric camera, world interaction and targeting, and ability input scaffolding so all other epics can attach gameplay, combat, and content without rewriting controls or presentation.
## Module Breakdown
### E1.M1 - InputAndMovementRuntime
- Responsibility: Character locomotion, click-to-move/path-follow baseline, interaction trigger range checks.
- Key contracts: `MoveCommand`, `PositionState`, `InteractionRequest`
- Dependencies: None
- Stage target: Prototype
### E1.M2 - IsometricCameraController
- Responsibility: Locked isometric camera follow, zoom bands, occlusion handling, no-rotation enforcement.
- Key contracts: `CameraState`, `ZoomBandConfig`, `OcclusionPolicy`
- Dependencies: E1.M1
- Stage target: Prototype
### E1.M3 - InteractionAndTargetingLayer
- Responsibility: World object selection, target lock, focus swap rules, hover/highlight feedback.
- Key contracts: `TargetState`, `InteractableDescriptor`, `SelectionEvent`
- Dependencies: E1.M1
- Stage target: Prototype
### E1.M4 - AbilityInputScaffold
- Responsibility: Hotbar bindings, cooldown slot UI hooks, ability activation request path to combat systems.
- Key contracts: `AbilityCastRequest`, `HotbarLoadout`, `CooldownSnapshot`
- Dependencies: E1.M3, E5.M1
- Stage target: Prototype
## Implementation Slices (Backlog-Ready)
### Slice 1 - Movement and position sync
- Scope: Server-authoritative or client-predicted movement baseline with `MoveCommand` / `PositionState` reconciliation suitable for multiplayer tests.
- Dependencies: E1.M1
- Acceptance criteria:
- Avatar moves reliably in the prototype district without rubber-banding artifacts above agreed thresholds.
- Interaction range checks use a single source of truth for distance.
- Telemetry hooks: `session_start`, movement sample or `position_tick` (lightweight), `interaction_attempt` failures.
### Slice 2 - Locked isometric camera
- Scope: E1.M2 end-to-end: follow-center, zoom bands, occlusion policy, no rotation.
- Dependencies: E1.M1
- Acceptance criteria:
- Camera never rotates; zoom stays within configured bands; player remains readable during motion.
- Telemetry hooks: `camera_zoom_changed` (optional throttled), occluder stress markers if needed for perf.
### Slice 3 - Interaction, targeting, and ability input wiring
- Scope: E1.M3 + E1.M4 with stub or live combat consumer for `AbilityCastRequest`.
- Dependencies: E1.M2, E5.M1 (minimum combat hook)
- Acceptance criteria:
- Players can select targets/interactables and fire hotbar-bound abilities when combat module accepts casts.
- Telemetry hooks: `target_changed`, `ability_cast_requested`, `ability_cast_denied` with reason codes.
## Risks and Mitigations
- Risk: Input latency or camera occlusion hides telegraphs in isometric view.
- Mitigation: Tune occlusion policy and feedback early; add readability checklist to prototype gates.
- Risk: Movement and interaction diverge between client prediction and server.
- Mitigation: Single reconciliation ruleset; log desync events via E9.M1 taxonomy.
## Definition of Done
- Functional behavior validated for prototype region.
- Dependencies on E5.M1 for E1.M4 are documented and integration-tested.
- Telemetry events emitted per slice where valid E9.M1 schema exists.
- No blocker defects for prototype demo of core loop.

View File

@ -0,0 +1,96 @@
# Epic 2 - Classless Skill and Progression Framework
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 2
- Related modules: E2.M1, E2.M2, E2.M3, E2.M4
## Ownership and success (Level 1)
- **Ownership focus:** Systems Design + Gameplay Engineering
- **Success criteria:** Any character can train all skills, and progression remains long-term without dead-end grinds.
## Objective
Provide a data-driven classless progression layer: skill definitions, XP awards, level curves, and eventually mastery/perk and pacing controls so gathering, crafting, and combat all feed one coherent progression model.
## Module Breakdown
### E2.M1 - SkillDefinitionRegistry
- Responsibility: Central catalog for skill metadata, category tags, unlock prerequisites.
- Key contracts: `SkillDef`, `SkillCategory`, `UnlockRequirement`
- Dependencies: None
- Stage target: Prototype
### E2.M2 - XpAwardAndLevelEngine
- Responsibility: XP award rules, level thresholds, level-up event generation.
- Key contracts: `XpGrantEvent`, `LevelCurve`, `LevelUpEvent`
- Dependencies: E2.M1
- Stage target: Prototype
- Note: E3.M1, E3.M2, and E5.M1 integrate by calling this engine; they are not dependencies for implementing E2.M2 (see Slice 3).
### E2.M3 - MasteryAndPerkUnlocks
- Responsibility: Mastery tracks and perk unlock state for non-class build expression.
- Key contracts: `MasteryTrack`, `PerkUnlockEvent`, `PerkState`
- Dependencies: E2.M2
- Stage target: Pre-production
### E2.M4 - ProgressionPacingControls
- Responsibility: Tuning knobs for progression velocity and catch-up policy enforcement.
- Key contracts: `XpModifierProfile`, `CatchUpRule`, `PacingPolicy`
- Dependencies: E2.M2, E9.M2
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Skill registry and prototype skills
- Scope: E2.M1 with at least three skills (one gathering, one crafting, one combat) loaded from data.
- Dependencies: None
- Acceptance criteria:
- All prototype activities reference skills by stable IDs.
- Invalid skill references fail validation in CI or at load time.
- Telemetry hooks: `skill_unlock` (if gating exists), schema validation metrics.
### Slice 2 - XP engine (E2.M2 core)
- Scope: Implement `XpGrantEvent`, `LevelCurve`, `LevelUpEvent`, and server-authoritative level resolution on top of `SkillDef` from E2.M1. No dependency on Epic 3 or Epic 5 modules beyond future call sites.
- Dependencies: E2.M1 (matches module-level E2.M2 → E2.M1 only).
- Acceptance criteria:
- XP and level-up can be triggered from tests or a stub caller without gathering/combat content.
- Curves and thresholds are data-driven and hot-reloadable or reloadable by policy agreed for prototype.
- Telemetry hooks: `xp_grant`, `level_up`, time-to-first-level-up (once integration slice fires real activity).
### Slice 3 - XP award integration at activity sites
- Scope: Wire gathering (E3.M1), crafting (E3.M2), and combat (E5.M1) to invoke the E2.M2 award API so the three prototype skill lines gain XP from real play.
- Dependencies: E2.M2, E3.M1, E3.M2, E5.M1 (integration prerequisites; not part of the E2.M2 module dependency list).
- Acceptance criteria:
- Visible XP and level-up feedback within first session from real gather/craft/combat actions.
- Telemetry hooks: `xp_grant`, `level_up`, time-to-first-level-up.
### Slice 4 - Mastery and pacing (pre-production)
- Scope: E2.M3 and E2.M4 for first mastery branch and global pacing policy.
- Dependencies: E2.M2, E9.M2
- Acceptance criteria:
- At least one mastery path unlocks a perk without blocking other skills.
- Pacing policy can be toggled for test cohorts without redeploy where possible.
- Telemetry hooks: `perk_unlock`, `pacing_profile_applied`.
## Risks and Mitigations
- Risk: XP faucets create runaway leveling in one skill.
- Mitigation: Diminishing returns per slice; monitor skill distribution via E9.M2.
- Risk: Classless identity feels flat without mastery expression.
- Mitigation: Ship E2.M3 early in pre-production with one flagship mastery line.
## Definition of Done
- Prototype uses E2.M1 + E2.M2 for all three skill lines.
- Pre-production adds E2.M3/E2.M4 with documented tuning workflow.
- Events align with baseline telemetry in master plan.

View File

@ -0,0 +1,99 @@
# Epic 3 - Crafting, Gathering, and Itemization Economy
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 3
- Related modules: E3.M1, E3.M2, E3.M3, E3.M4, E3.M5
## Ownership and success (Level 1)
- **Ownership focus:** Economy Design + Content Engineering
- **Success criteria:** Crafting is a primary progression lane with healthy supply-demand loops and consistent item relevance.
## Objective
Implement gathering from world nodes, item/inventory representation, recipe execution, and later durability/sinks and economy policy so players can complete gather-refine-craft-use loops that matter for combat and quests.
## Module Breakdown
### E3.M1 - ResourceNodeAndGatherLoop
- Responsibility: Node spawning, gather interaction, resource output events.
- Key contracts: `ResourceNodeDef`, `GatherResult`, `ResourceYieldTable`
- Dependencies: E1.M3, E2.M2
- Stage target: Prototype
### E3.M2 - RefinementAndRecipeExecution
- Responsibility: Raw-to-refined processing and recipe crafting execution pipeline.
- Key contracts: `RecipeDef`, `CraftRequest`, `CraftResult`
- Dependencies: E3.M1, E3.M3
- Stage target: Prototype
### E3.M3 - ItemizationAndInventorySchema
- Responsibility: Item definitions, rarity/quality fields, stackability and equipment metadata.
- Key contracts: `ItemDef`, `ItemInstance`, `InventorySlot`
- Dependencies: None
- Stage target: Prototype
### E3.M4 - SinkAndDurabilityLifecycle
- Responsibility: Item decay/consumption/repair sinks that sustain market demand.
- Key contracts: `DurabilityState`, `ItemSinkEvent`, `RepairCostRule`
- Dependencies: E3.M3, E8.M3
- Stage target: Pre-production
### E3.M5 - EconomyBalancePolicy
- Responsibility: Faucet/sink parameter set and guardrails for inflation/deflation.
- Key contracts: `EconomyPolicy`, `PriceBandRule`, `FaucetSinkRatio`
- Dependencies: E3.M4, E9.M2
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Items and inventory MVP
- Scope: E3.M3 with equipment/consumable slots sufficient for prototype loadouts and quests.
- Dependencies: None
- Acceptance criteria:
- Craft outputs and quest rewards land in inventory deterministically.
- Item schema versioned for forward-compatible migrations.
- Telemetry hooks: `item_created`, `inventory_full` / transfer failures.
### Slice 2 - Gather nodes and outputs
- Scope: E3.M1 with 4-6 node types and yield tables; awards crafting/gathering XP via E2.M2.
- Dependencies: E3.M3, E1.M3, E2.M2
- Acceptance criteria:
- Full gather interaction in prototype region without dupes or free resources.
- Telemetry hooks: `resource_gathered`, `gather_node_depleted`.
### Slice 3 - Recipes and crafting pipeline
- Scope: E3.M2 with 8-12 starter recipes per prototype minimums.
- Dependencies: E3.M1, E3.M3
- Acceptance criteria:
- Player completes gather to refine to usable item used in combat or quest.
- Telemetry hooks: `item_crafted`, `craft_failed` with reason, time-to-first-craft.
### Slice 4 - Sinks and economy policy (pre-production)
- Scope: E3.M4 + E3.M5 with tuning hooks and validation against outliers.
- Dependencies: E8.M3 (market settlement optional), E9.M2
- Acceptance criteria:
- At least one durable sink is live; policy alerts on faucet/sink ratio breaches.
- Telemetry hooks: `item_sink`, `repair_performed`, economy KPI aggregates.
## Risks and Mitigations
- Risk: Crafting bypassed by drops or NPC vendors.
- Mitigation: Prototype quest requires crafted item; monitor gather-to-craft conversion.
- Risk: Exploit duplication or negative stacks.
- Mitigation: Server-authoritative craft and inventory; integrity signals via E9.M4.
## Definition of Done
- Prototype gather-craft loop meets plan pass/fail gates.
- Pre-production adds sinks and policy with dashboard visibility.

View File

@ -0,0 +1,92 @@
# Epic 4 - World Topology and Zone Infrastructure
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 4
- Related modules: E4.M1, E4.M2, E4.M3, E4.M4
## Ownership and success (Level 1)
- **Ownership focus:** Online/Backend Engineering + World Design
- **Success criteria:** Mostly seamless open world runs reliably with predictable transitions and low-disruption handoffs.
## Objective
Represent the world as a zone graph with travel rules, security-tier signaling for PvP policy, and later spawn ecology and seamless handoffs so content scales from one district to regional scope without rewiring fundamentals.
## Module Breakdown
### E4.M1 - ZoneGraphAndTravelRules
- Responsibility: Regional zone graph, transition links, movement and travel constraints.
- Key contracts: `ZoneDef`, `ZoneEdge`, `TravelRule`
- Dependencies: None
- Stage target: Prototype
### E4.M2 - SpawnEcologyController
- Responsibility: Resource and NPC spawn profiles per zone, respawn pacing, depletion recovery.
- Key contracts: `SpawnProfile`, `RespawnRule`, `ZoneEcologyState`
- Dependencies: E4.M1, E3.M1, E5.M2
- Stage target: Pre-production
### E4.M3 - SeamlessHandoffAndRegionState
- Responsibility: Cross-region handoff behavior and region authority ownership boundaries.
- Key contracts: `RegionHandoffEvent`, `RegionAuthority`, `TransferState`
- Dependencies: E4.M1, backend world services
- Stage target: Pre-production
### E4.M4 - SecurityTierZoneFlags
- Responsibility: High/contested/low-security tagging and client/server zone risk signaling.
- Key contracts: `SecurityTier`, `ZonePolicyState`, `ZoneEntryWarning`
- Dependencies: E4.M1
- Stage target: Prototype
## Implementation Slices (Backlog-Ready)
### Slice 1 - Prototype district zone graph
- Scope: E4.M1 defining hub, PvE pocket, and edge zones with valid transitions.
- Dependencies: None
- Acceptance criteria:
- Server and client agree on current zone id for every player.
- Travel rules prevent illegal shortcuts.
- Telemetry hooks: `zone_enter`, `zone_exit`, invalid transition attempts.
### Slice 2 - Security tier tagging and UI hooks
- Scope: E4.M4 on E4.M1: per-zone `SecurityTier`, `ZonePolicyState`, and entry-warning payloads. E6.M1 subscribes to this data for PvP eligibility (implemented in Epic 6; no circular module dependency).
- Dependencies: E4.M1
- Acceptance criteria:
- Server-authoritative tier matches client display for each zone transition; entry-warning contract is stable for E6.M2 to consume.
- Telemetry hooks: `security_zone_enter`, `security_zone_exit` (aligned with PvP events).
### Slice 3 - Spawn ecology (pre-production)
- Scope: E4.M2 driving node and NPC densities per zone from data.
- Dependencies: E4.M1, E3.M1, E5.M2
- Acceptance criteria:
- No zone starvation or infinite respawn exploits in test scenarios.
- Telemetry hooks: `spawn_wave`, ecology depletion/recovery markers.
### Slice 4 - Seamless handoff spike (pre-production)
- Scope: E4.M3 minimal viable handoff between two regions with authority transfer.
- Dependencies: backend world services
- Acceptance criteria:
- Handoff completes without duplicate entities; rollback path documented.
- Telemetry hooks: `region_handoff_start`, `region_handoff_complete`, failures.
## Risks and Mitigations
- Risk: Zone/security inconsistencies between client and server.
- Mitigation: Server is source of truth; client prediction only for display.
- Risk: Premature seamless complexity for solo dev.
- Mitigation: Prototype stays single region; handoff is gated pre-production slice.
## Definition of Done
- Prototype zone and security signaling validated with Epic 6.
- Pre-production spawns and handoffs meet stage gates in master plan.

View File

@ -0,0 +1,91 @@
# Epic 5 - PvE Combat and Encounter Content
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 5
- Related modules: E5.M1, E5.M2, E5.M3, E5.M4
## Ownership and success (Level 1)
- **Ownership focus:** Combat Design + Encounter Design
- **Success criteria:** PvE combat delivers tactical depth, clear readability, and repeatable fun for solo and group play.
## Objective
Deliver tab-target combat resolution, NPC behaviors and telegraphs, encounter templates with rewards, and optional group scaling so PvE is the mandatory progression path with readable isometric presentation.
## Module Breakdown
### E5.M1 - CombatRulesEngine
- Responsibility: Tab-target combat state machine, hit resolution, cooldown/resource timing.
- Key contracts: `CombatAction`, `CombatResolution`, `ThreatState`
- Dependencies: E1.M3, E2.M2
- Stage target: Prototype
### E5.M2 - NpcAiAndBehaviorProfiles
- Responsibility: Enemy archetype behavior loops, aggro logic, telegraph scheduling.
- Key contracts: `NpcBehaviorDef`, `TelegraphEvent`, `AggroRule`
- Dependencies: E5.M1
- Stage target: Prototype
### E5.M3 - EncounterAndRewardTables
- Responsibility: Encounter setup templates, completion criteria, reward drop routing.
- Key contracts: `EncounterDef`, `RewardTable`, `EncounterCompleteEvent`
- Dependencies: E5.M1, E3.M3, E7.M2
- Stage target: Prototype
### E5.M4 - GroupCombatScaling
- Responsibility: Duo/squad scaling logic and anti-trivialization balancing hooks.
- Key contracts: `ScalingProfile`, `PartySizeModifier`, `CombatDifficultyBand`
- Dependencies: E5.M3, E8.M1
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Combat rules MVP
- Scope: E5.M1 with target lock, basic attacks, 4-6 abilities, cooldowns/resources per prototype scope.
- Dependencies: E1.M3, E2.M2
- Acceptance criteria:
- Combat readable in fixed isometric camera; no silent failures on ability deny.
- Telemetry hooks: `encounter_start`, `ability_used`, `player_death`, `enemy_defeat`.
### Slice 2 - NPC archetypes and telegraphs
- Scope: E5.M2 for three archetypes: melee pressure, ranged control, elite mini-boss.
- Dependencies: E5.M1
- Acceptance criteria:
- Telegraph timing matches UI feedback; aggro rules deterministic.
- Telemetry hooks: `telegraph_fired`, `npc_state_transition`.
### Slice 3 - Encounters and loot routing
- Scope: E5.M3 wired to E3.M3 and E7.M2 for rewards and quest progress.
- Dependencies: E5.M2, E3.M3, E7.M2
- Acceptance criteria:
- Completing defined encounters grants expected items/quest credit once.
- Telemetry hooks: `encounter_complete`, reward attribution.
### Slice 4 - Group scaling (pre-production)
- Scope: E5.M4 with party-sized modifiers behind E8.M1.
- Dependencies: E8.M1
- Acceptance criteria:
- Duo run remains challenging but fair; metrics show no trivial farm spike.
- Telemetry hooks: `party_combat_scaling_applied`.
## Risks and Mitigations
- Risk: Tab-target feels sluggish or opaque.
- Mitigation: Prototype readability gate; instrument time in combat and failure reasons.
- Risk: Loot tables desync from item schema.
- Mitigation: Shared validation in content pipeline; lint reward references.
## Definition of Done
- Prototype combat, archetypes, and encounters meet documented minimums in master plan.
- Telemetry covers combat health KPIs.

View File

@ -0,0 +1,91 @@
# Epic 6 - PvP Security Zones and Fairness Rules
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 6
- Related modules: E6.M1, E6.M2, E6.M3, E6.M4
## Ownership and success (Level 1)
- **Ownership focus:** Systems Design + Online Engineering + Trust/Safety
- **Success criteria:** PvP is compelling for participants while remaining fully optional and non-blocking for progression.
## Objective
Implement security-zone based PvP opt-in, clear consent and risk UX, reward parity with PvE/crafting paths, and later loss/anti-grief rules so PvE-first players never need PvP to progress.
## Module Breakdown
### E6.M1 - PvPEligibilityAndFlagState
- Responsibility: PvP enablement logic by zone state and explicit opt-in context.
- Key contracts: `PvPFlagState`, `EligibilityRule`, `PvPStateChanged`
- Dependencies: E4.M4
- Stage target: Prototype
### E6.M2 - ConsentAndRiskUxSignals
- Responsibility: Entry warnings, in-zone risk UI, and clear state communication for PvP status.
- Key contracts: `RiskPrompt`, `ZoneRiskState`, `PvPIndicatorState`
- Dependencies: E6.M1, E1.M2
- Stage target: Prototype
### E6.M3 - LossPenaltyAndAntiGriefRules
- Responsibility: Death/loss rules in PvP contexts plus spawn protection and abuse mitigation.
- Key contracts: `PvPLossRule`, `SpawnProtectionState`, `GriefingStrike`
- Dependencies: E6.M1, E9.M4
- Stage target: Pre-production
### E6.M4 - RewardParityEnforcer
- Responsibility: Guarantee functional equivalents for PvP rewards through PvE/crafting paths.
- Key contracts: `RewardParityMap`, `EquivalentPowerBand`, `ParityViolationAlert`
- Dependencies: E3.M2, E5.M3, E7.M2
- Stage target: Prototype
## Implementation Slices (Backlog-Ready)
### Slice 1 - Zone-based PvP flag core
- Scope: E6.M1 driven by E4.M4 security tiers; high-sec blocks combat between players.
- Dependencies: E4.M4
- Acceptance criteria:
- Server-enforced eligibility; no client-only PvP toggles.
- Telemetry hooks: `pvp_state_changed`, `pvp_zone_enter`, `pvp_zone_exit`.
### Slice 2 - Consent and risk UX
- Scope: E6.M2 prompts on low-sec entry and persistent in-HUD indicator.
- Dependencies: E6.M1, E1.M2
- Acceptance criteria:
- Non-PvP testers report clear understanding without coaching.
- Telemetry hooks: `risk_prompt_shown`, `risk_prompt_accepted`, `risk_prompt_declined`.
### Slice 3 - Reward parity validation
- Scope: E6.M4 enforcing mapping for prototype sidegrade example.
- Dependencies: E3.M2, E5.M3, E7.M2
- Acceptance criteria:
- Every PvP-only functional reward has validated PvE/crafting equivalent per policy.
- Telemetry hooks: `parity_violation`, `parity_grant_path_completed`.
### Slice 4 - Loss and anti-grief (pre-production)
- Scope: E6.M3 with spawn protection timers and strike escalation hooks to E9.M4.
- Dependencies: E9.M4
- Acceptance criteria:
- Repeat killer patterns detectable in tests; abused spawns protected.
- Telemetry hooks: `pvp_death`, `spawn_protection_applied`, `grief_flag_raised`.
## Risks and Mitigations
- Risk: PvP feels mandatory due to reward leakage.
- Mitigation: Parity enforcer blocks ship if mapping incomplete; KPI audit on non-PvP completion.
- Risk: Griefing destroys new-player trust.
- Mitigation: High-sec safe hubs; anti-grief telemetry and fast iteration on rules.
## Definition of Done
- Prototype passes PvP optionality and parity gates from master plan.
- Pre-production tightens loss and abuse response with operational hooks.

View File

@ -0,0 +1,91 @@
# Epic 7 - Questing, Narrative, and Faction Reputation
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 7
- Related modules: E7.M1, E7.M2, E7.M3, E7.M4
## Ownership and success (Level 1)
- **Ownership focus:** Narrative Design + Quest Design + Tools
- **Success criteria:** Quest content provides clear progression direction, worldbuilding depth, and durable midgame engagement.
## Objective
Provide a quest state machine and reward routing that ties gathering, crafting, and combat into guided and repeatable content, plus faction reputation and contract generation for midgame durability.
## Module Breakdown
### E7.M1 - QuestStateMachine
- Responsibility: Quest start/step/complete state transitions and persistence.
- Key contracts: `QuestDef`, `QuestStepState`, `QuestStateTransition`
- Dependencies: E3.M2, E5.M1
- Stage target: Prototype
### E7.M2 - RewardAndUnlockRouter
- Responsibility: Route quest outputs to XP, items, unlocks, and reputation.
- Key contracts: `QuestRewardBundle`, `UnlockGrant`, `RewardDeliveryEvent`
- Dependencies: E2.M2, E3.M3, E7.M1
- Stage target: Prototype
### E7.M3 - FactionReputationLedger
- Responsibility: Track faction standing and gate faction-specific contracts/content.
- Key contracts: `FactionStanding`, `ReputationDelta`, `FactionGateRule`
- Dependencies: E7.M1
- Stage target: Pre-production
### E7.M4 - ContractMissionGenerator
- Responsibility: Semi-procedural repeatable contract generation with difficulty/reward bands.
- Key contracts: `ContractTemplate`, `ContractSeed`, `ContractOutcome`
- Dependencies: E4.M1, E5.M3, E7.M3
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Quest core and persistence
- Scope: E7.M1 supporting branching steps and failure/reset rules for prototype chain.
- Dependencies: E3.M2, E5.M1
- Acceptance criteria:
- 3-5 onboarding quests + one chain requiring gather/craft/combat complete without duped rewards.
- Telemetry hooks: `quest_start`, `quest_step_complete`, `quest_complete`, funnel times.
### Slice 2 - Reward and unlock routing
- Scope: E7.M2 delivering XP, items, blueprint unlocks, and flags for world gates.
- Dependencies: E7.M1, E2.M2, E3.M3
- Acceptance criteria:
- Idempotent reward delivery; replays cannot double-claim.
- Telemetry hooks: `reward_delivery`, `unlock_granted`.
### Slice 3 - Faction ledger (pre-production)
- Scope: E7.M3 gating at least one faction line and mission set.
- Dependencies: E7.M1
- Acceptance criteria:
- Reputation deltas auditable; gates fail closed on tamper.
- Telemetry hooks: `reputation_delta`, `faction_gate_blocked`.
### Slice 4 - Contract generator (pre-production)
- Scope: E7.M4 emitting repeatable contracts from templates by zone difficulty.
- Dependencies: E4.M1, E5.M3, E7.M3
- Acceptance criteria:
- Generated contracts validate against economy and parity rules.
- Telemetry hooks: `contract_issued`, `contract_complete`, reward anomalies.
## Risks and Mitigations
- Risk: Quest scripting becomes engineering-heavy for solo dev.
- Mitigation: Data-first `QuestDef` schema; templates in decomposition tools path.
- Risk: Rewards break parity or economy.
- Mitigation: Lint bundles against E6.M4 and E3.M5 policies.
## Definition of Done
- Prototype quest counts and integrated chain meet master plan minimums.
- Pre-production adds faction + contracts with validation.

View File

@ -0,0 +1,91 @@
# Epic 8 - Social, Guild/Corp, and Cooperative Features
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 8
- Related modules: E8.M1, E8.M2, E8.M3, E8.M4
## Ownership and success (Level 1)
- **Ownership focus:** Social Systems + Online Services
- **Success criteria:** Players can easily form long-term social bonds and group structures that improve retention.
## Objective
Enable party assembly for cooperative play, player trade and marketplace settlement supporting crafting economy, chat with moderation hooks, and later guild/corp progression tied to faction/social goals.
## Module Breakdown
### E8.M1 - PartyAndMatchAssembly
- Responsibility: Party creation/invite/ready-state flow for cooperative activities.
- Key contracts: `PartyState`, `InviteEvent`, `RolePreference`
- Dependencies: E1.M3
- Stage target: Pre-production
### E8.M2 - GuildCorpProgressionState
- Responsibility: Guild/corp membership, rank permissions, and shared progression tracks.
- Key contracts: `GuildState`, `GuildRolePolicy`, `GuildProgressionEvent`
- Dependencies: E8.M1, E7.M3
- Stage target: Production
### E8.M3 - PlayerTradeAndMarketplace
- Responsibility: Listing, trade, purchase, and settlement flows for player economy.
- Key contracts: `MarketListing`, `TradeOffer`, `SettlementEvent`
- Dependencies: E3.M3, E3.M5
- Stage target: Pre-production
### E8.M4 - ChatModerationAndReporting
- Responsibility: Channel chat, report pipeline, moderation action logs and escalation hooks.
- Key contracts: `ChatMessageEvent`, `PlayerReport`, `ModerationAction`
- Dependencies: E9.M4
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Party invites and baseline sync
- Scope: E8.M1 for invite, accept, leave, and party-scoped instance hooks if needed.
- Dependencies: E1.M3
- Acceptance criteria:
- Party membership consistent server-side; UI reflects state.
- Telemetry hooks: `party_formed`, `party_disbanded`, invite failures.
### Slice 2 - Direct trade and listing MVP
- Scope: E8.M3 minimal trade window plus optional listings with fees tuned by E3.M5.
- Dependencies: E3.M3, E3.M5
- Acceptance criteria:
- Duplication and cancel-edge cases covered; settlement atomic on server.
- Telemetry hooks: `trade_completed`, `listing_created`, `purchase_completed`, fraud flags.
### Slice 3 - Chat and reporting
- Scope: E8.M4 with rate limits, report reasons, and audit log export path to E9.M4.
- Dependencies: E9.M4
- Acceptance criteria:
- Moderation can trace message id to action history in test.
- Telemetry hooks: `chat_message_sent`, `player_report filed`, `moderation_action`.
### Slice 4 - Guild/corp progression (production)
- Scope: E8.M2 with ranks, permissions, and shared contracts tied to E7.M3.
- Dependencies: E8.M1, E7.M3
- Acceptance criteria:
- Corp progress cannot be griefed by solo permission bypass.
- Telemetry hooks: `guild_progression_event`, permission denials.
## Risks and Mitigations
- Risk: Marketplace enables RMT/exploit duplication.
- Mitigation: Server settlement; integrity signals; economy policy alerts.
- Risk: Chat toxicity unsustainable for solo ops.
- Mitigation: Channel controls, strong report pipeline before scaling users.
## Definition of Done
- Pre-production delivers party, trade/market MVP, chat/reporting aligned to operational plan.
- Production gates guild features behind social health metrics.

View File

@ -0,0 +1,91 @@
# Epic 9 - LiveOps, Telemetry, and Game Integrity
## Source Anchors
- Master epic reference: [`cyberpunk_mmo_vision_86a57ef3.plan.md`](../../../cyberpunk_mmo_vision_86a57ef3.plan.md) — Core Epic Map, System Modules Epic 9
- Related modules: E9.M1, E9.M2, E9.M3, E9.M4
## Ownership and success (Level 1)
- **Ownership focus:** Live Operations + Data/Analytics + Security
- **Success criteria:** Team can operate, balance, and protect the game continuously post-launch with fast feedback loops.
## Objective
Establish event taxonomy, KPI visibility, remote balance tuning where safe, and integrity/incident workflows so solo operation can detect regressions, abuse, and economy drift early.
## Module Breakdown
### E9.M1 - TelemetryEventSchema
- Responsibility: Canonical event taxonomy covering session, progression, economy, combat, and PvP events.
- Key contracts: `TelemetryEvent`, `EventSchemaVersion`, `ClientEventEnvelope`
- Dependencies: None
- Stage target: Prototype
### E9.M2 - KpiDashboardsAndAlerting
- Responsibility: KPI aggregation, dashboard surfaces, trend alerts, and milestone gate signals.
- Key contracts: `KpiDefinition`, `AlertThreshold`, `MilestoneGateSignal`
- Dependencies: E9.M1
- Stage target: Pre-production
### E9.M3 - LiveBalanceControlPlane
- Responsibility: Runtime-safe tuning of combat, progression, and economy parameters.
- Key contracts: `BalancePatch`, `ConfigVersion`, `RolloutState`
- Dependencies: E9.M2, E5.M1, E2.M4, E3.M5
- Stage target: Production
### E9.M4 - IntegrityAndAbuseResponse
- Responsibility: Bot/exploit detection signals, incident triage, and response workflows.
- Key contracts: `IntegritySignal`, `IncidentTicket`, `EnforcementAction`
- Dependencies: E9.M1
- Stage target: Pre-production
## Implementation Slices (Backlog-Ready)
### Slice 1 - Baseline event SDK and schema versioning
- Scope: E9.M1 with client envelope, batching, privacy guardrails, and schema version bumps.
- Dependencies: None
- Acceptance criteria:
- Prototype funnel events match master plan baseline list; breaking changes versioned.
- Telemetry hooks: `schema_version_mismatch`, ingest errors.
### Slice 2 - Minimal dashboards for prototype gates
- Scope: E9.M2 dashboards A/B/E subset for onboarding, loop health, and PvP optionality.
- Dependencies: E9.M1
- Acceptance criteria:
- Each prototype pass/fail gate has at read one chart or query.
- Telemetry hooks: alert firing on thresholds defined in KPI section.
### Slice 3 - Integrity pipeline and incidents
- Scope: E9.M4 correlating integrity signals to tickets and enforcement actions with audit trail.
- Dependencies: E9.M1
- Acceptance criteria:
- Known exploit replay test produces ticket + action log.
- Telemetry hooks: `integrity_signal`, `incident_open`, `enforcement_action`.
### Slice 4 - Live balance control plane (production)
- Scope: E9.M3 applies signed `BalancePatch` bundles to combat/progression/economy knobs with rollout states.
- Dependencies: E9.M2, E5.M1, E2.M4, E3.M5
- Acceptance criteria:
- Rollback path for bad patch within agreed SLO; diff visible in ops UI.
- Telemetry hooks: `balance_patch_applied`, client config hash.
## Risks and Mitigations
- Risk: Telemetry noise obscures real issues.
- Mitigation: Decision-driven instrumentation rules from master plan; sampling strategy.
- Risk: Remote tuning causes live incidents.
- Mitigation: Staged rollout, automated rollback, parity checks with E6.M4/E3.M5.
## Definition of Done
- Prototype runs with E9.M1 + minimal E9.M2 visibility.
- Pre-production adds integrity workflows; production adds E9.M3 with governance.

View File

@ -11,6 +11,7 @@ Tracks cross-epic dependencies and contract readiness.
| E2.M2 | XpAwardAndLevelEngine | E2.M1 | XpGrantEvent, LevelUpEvent | Prototype | Planned |
| E3.M2 | RefinementAndRecipeExecution | E3.M1, E3.M3 | CraftRequest, CraftResult | Prototype | Planned |
| E5.M1 | CombatRulesEngine | E1.M3, E2.M2 | CombatAction, CombatResolution | Prototype | Planned |
| E4.M4 | SecurityTierZoneFlags | E4.M1 | SecurityTier, ZonePolicyState, ZoneEntryWarning | Prototype | Planned |
| E6.M1 | PvPEligibilityAndFlagState | E4.M4 | PvPFlagState, EligibilityRule | Prototype | Planned |
| E7.M1 | QuestStateMachine | E3.M2, E5.M1 | QuestStateTransition | Prototype | Planned |
| E9.M1 | TelemetryEventSchema | None | TelemetryEvent envelope | Prototype | Planned |