You are responsible for a comprehensive **gameplay systems consistency and cohesion pass**.

Your job is to make the existing game feel like its major gameplay systems were designed as parts of **one coherent product**, rather than implemented independently at different times with unrelated rules, interaction patterns, terminology, feedback, and edge-case behavior.

The primary question throughout this task is:

> **Which existing gameplay systems solve equivalent problems in inconsistent ways, and which differences are intentional versus accidental?**

Then fix the accidental inconsistencies.

This is an **implementation task**, not merely a design audit.

Do not stop after:

- cataloguing inconsistencies;
- producing comparison tables;
- describing ideal standards;
- creating a systems-design document;
- listing recommendations;
- identifying uneven mechanics without correcting them.

Inspect the actual game and codebase, understand the major implemented gameplay systems, compare equivalent concepts, identify concrete inconsistencies, determine which differences are justified, implement worthwhile corrections, validate them, and continue through progressively smaller coherence problems.

The goal is:

> **Make the existing game's systems feel deliberately related, predictable, and internally coherent while preserving meaningful differences between them.**

---

# Consistency Does Not Mean Sameness

This distinction is critical.

Do not make every system identical.

Different systems may intentionally differ in:

- tools;
- resources;
- timing;
- range;
- pacing;
- rewards;
- risk;
- animation;
- positioning;
- interruption rules;
- progression;
- failure conditions;
- interaction fantasy.

For example, two gathering skills may intentionally use different tools, timing, depletion behavior, or rewards.

Different combat styles may intentionally use different ranges, costs, timing, or status effects.

Intentional mechanical identity is good.

The problem is when equivalent concepts differ for no defensible gameplay reason.

Examples:

- one gathering skill automatically repeats while another inexplicably requires repeated clicking;
- one resource node validates inventory capacity before starting while another fails only after completion;
- one combat style changes targets immediately while another requires stopping first;
- one skill grants XP on action completion while an equivalent skill grants it at action start;
- one interaction cancels on movement while another continues invisibly;
- one equivalent system uses different terminology for the same player-facing concept;
- one crafting path refunds resources on cancellation while another loses them due only to implementation history.

Your job is to distinguish:

> **intentional differentiation**

from:

> **accidental inconsistency**

Preserve the first.

Fix the second.

---

# Core Scope

This pass focuses on consistency across **existing gameplay systems**.

Relevant concepts may include:

- interaction rules;
- movement-to-interaction behavior;
- action start;
- action commitment;
- action completion;
- repeated actions;
- cancellation;
- interruption;
- targeting;
- range;
- approach behavior;
- tool requirements;
- resource requirements;
- inventory requirements;
- success and failure handling;
- resource depletion;
- respawn;
- cooldowns;
- XP awards;
- rewards;
- drops;
- progression;
- skill requirements;
- level requirements;
- unlock behavior;
- equipment requirements;
- durability where applicable;
- item consumption;
- item production;
- combat rules;
- gathering rules;
- crafting rules;
- NPC interaction;
- world-object interaction;
- status effects;
- notifications;
- terminology;
- feedback patterns;
- error messages;
- lifecycle behavior;
- multiplayer authority where applicable;
- persistence behavior where equivalent systems store similar state.

Only compare concepts that actually exist.

---

# Explicitly Out of Scope

This is **not primarily**:

- a total gameplay redesign;
- a balance overhaul;
- an economy rebalance;
- a progression redesign;
- a feature sprint;
- content expansion;
- visual polish;
- UI beautification;
- accessibility work;
- technical-debt cleanup;
- repository cleanup;
- performance optimization;
- broad multiplayer architecture;
- broad persistence architecture;
- destructive QA.

Small changes in those areas are allowed when directly required to correct a confirmed cross-system inconsistency.

Do not let them become separate workstreams.

---

# Preserve System Identity

Before normalizing any difference, ask:

> **Would removing this difference make these systems less interesting, less expressive, or less strategically distinct?**

If yes, preserve it unless it is clearly broken.

Good intentional differences may include:

- different gathering cadence;
- different combat commitment;
- different resource costs;
- different risks;
- different positioning;
- different failure conditions;
- different tool progression;
- different reward structures;
- different interaction fantasy;
- different activity intensity.

Bad differences are often implementation accidents.

Examples:

- arbitrary naming mismatch;
- one missing validation path;
- one system forgetting cancellation;
- duplicated formulas drifting apart;
- equivalent rewards granted at different lifecycle stages without reason;
- inconsistent error handling caused by separate implementations;
- one system bypassing a shared rule accidentally.

Do not normalize merely because two systems are similar.

Normalize because they solve the **same gameplay responsibility** and the difference has no meaningful purpose.

---

# Preserve Existing Behavior

Except where correcting accidental inconsistency or a confirmed defect, preserve:

- gameplay identity;
- intended pacing;
- balance;
- reward values;
- resource costs;
- combat identity;
- progression structure;
- multiplayer authority;
- persistence semantics;
- externally observable gameplay contracts.

A consistency change that silently rebalances or redesigns the game is a regression.

---

# Establish the System Map

Before broad changes, identify the major implemented gameplay systems.

Depending on the project, these may include:

- movement;
- combat;
- melee;
- ranged;
- magic;
- abilities;
- gathering;
- mining;
- woodcutting;
- fishing;
- farming;
- harvesting;
- crafting;
- smithing;
- cooking;
- alchemy;
- construction;
- inventory;
- equipment;
- loot;
- NPC interaction;
- dialogue;
- quests;
- vendors;
- trading;
- progression;
- skills;
- status effects;
- death;
- respawn;
- world interactions.

Do not force categories that do not exist.

Map only the systems actually present.

---

# Identify Shared Gameplay Concepts

Then identify equivalent responsibilities that appear across multiple systems.

Examples:

- action duration;
- range;
- targeting;
- tool requirement;
- resource requirement;
- success chance;
- XP;
- reward;
- cooldown;
- progress;
- cancellation;
- interruption;
- depletion;
- respawn;
- failure;
- inventory-full behavior;
- animation timing;
- feedback;
- target invalidation;
- death;
- movement interruption.

These become the comparison axes.

Do not compare whole systems vaguely.

Compare equivalent **gameplay responsibilities**.

---

# Investigate Before Asking Questions

Use the project itself as evidence.

Inspect relevant:

- source code;
- gameplay data;
- configuration;
- runtime behavior;
- tests;
- player-facing UI;
- tooltips;
- error messages;
- shared helpers;
- duplicated formulas;
- interaction state machines;
- event flows;
- persistence;
- networking;
- project history;
- documentation;
- existing design conventions.

Ask for clarification only when:

- design intent genuinely cannot be established;
- several materially different interpretations are equally plausible;
- normalization would significantly affect balance;
- authoritative multiplayer rules are unclear;
- persistence compatibility is ambiguous;
- a major product decision is required.

Do not ask questions merely because comparing systems takes effort.

---

# Implementation Over Auditing

The audit exists only to create an **implementation queue**.

Do not spend most of the task building:

- giant matrices;
- exhaustive inventories;
- design documents;
- long recommendation lists;
- theoretical consistency frameworks.

Once an inconsistency is understood well enough to classify:

1. determine whether it is intentional;
2. if accidental, identify the strongest existing pattern;
3. implement the correction;
4. validate affected systems;
5. compare again.

Use:

> **compare → classify → normalize where justified → validate → compare again**

---

# Use Existing Best Implementations as Standards

Do not automatically invent a new universal system.

Often one existing implementation already handles a concept correctly.

For example:

- one gathering system may already handle cancellation well;
- another may handle inventory-full state correctly;
- one combat style may have the best target lifecycle;
- one crafting system may have the strongest requirement validation.

When one implementation is clearly stronger and appropriate:

> **standardize equivalent systems toward the strongest existing implementation.**

Do not standardize toward the average.

Do not rewrite all systems merely to introduce a new abstraction.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports parallel agents, workers, subprocesses, or independent contexts, use them where useful.

Do not require delegation.

A single capable session should be able to execute this prompt sequentially.

Good independent comparison areas may include:

- gathering skills;
- production skills;
- combat styles;
- inventory and equipment;
- NPC/world interactions;
- quest/objective rules;
- progression and XP;
- terminology and feedback.

Serialize changes when several systems depend on the same:

- action system;
- target system;
- reward system;
- inventory authority;
- progression authority;
- combat state model;
- persistence layer;
- multiplayer authority.

Gather evidence independently where useful.

Define shared rules centrally.

Then implement consistently.

---

# Consistency Priority Queue

## P0 — Correctness Inconsistency

Examples:

- one system duplicates rewards;
- one system loses items during equivalent cancellation;
- one combat style bypasses authoritative validation;
- equivalent actions produce contradictory state;
- one path corrupts inventory while another does not;
- one equivalent system violates conservation or state ownership.

Fix immediately.

## P1 — Major Gameplay Inconsistency

Examples:

- equivalent systems have radically different cancellation behavior without justification;
- identical requirements are validated at incompatible lifecycle stages;
- target switching follows conflicting rules;
- one gathering activity behaves noticeably worse for no design reason;
- duplicated formulas produce different outcomes;
- equivalent failure states resolve differently.

These strongly harm cohesion.

## P2 — Meaningful Behavioral Inconsistency

Examples:

- different failure behavior;
- unexplained cadence differences;
- inconsistent XP timing;
- inconsistent resource depletion;
- inconsistent progress feedback;
- inconsistent target handling;
- inconsistent requirement messaging;
- inconsistent repeated-action rules.

Fix where intentional differentiation is absent.

## P3 — Minor Consistency

Examples:

- terminology;
- capitalization;
- equivalent message formatting;
- small timing differences without gameplay impact;
- minor state naming differences.

Address later.

---

# Interaction Lifecycle Standard

For equivalent actions, reason using a common conceptual lifecycle:

> **request → validate → approach if needed → commit → execute → reward/result → complete**

Not every action requires every stage.

The lifecycle exists as a comparison tool.

For each relevant system determine where it:

- validates requirements;
- reserves or consumes resources;
- starts cooldown;
- begins animation;
- awards XP;
- grants rewards;
- handles cancellation;
- handles interruption;
- clears target/state;
- completes.

Normalize lifecycle behavior where appropriate.

Do not force actions with fundamentally different gameplay identities through an identical implementation.

---

# Gathering-System Comparison

If multiple gathering systems exist, compare them systematically.

Possible systems include:

- mining;
- woodcutting;
- fishing;
- harvesting;
- farming;
- scavenging.

Compare:

- target selection;
- approach behavior;
- required range;
- required tool;
- tool validation timing;
- inventory validation;
- action start;
- animation start;
- action duration;
- success/failure;
- XP timing;
- reward timing;
- depletion;
- respawn;
- repeated gathering;
- movement interruption;
- target destruction;
- inventory filling mid-action;
- failure messaging.

Ask:

> **Would a player reasonably expect these systems to share this behavior?**

Normalize accidental divergence.

Preserve intentional resource-specific mechanics.

---

# Production-System Comparison

If multiple production systems exist, compare relevant:

- cooking;
- smithing;
- crafting;
- alchemy;
- fletching;
- construction;
- other production systems.

Compare:

- recipe selection;
- requirement validation;
- resource consumption;
- resource timing;
- action duration;
- batch quantity;
- cancellation;
- XP timing;
- output creation;
- inventory-full handling;
- failure;
- progress;
- animation lifecycle.

Equivalent production concepts should not behave randomly differently.

---

# Combat-Style Comparison

If several combat styles exist, compare relevant:

- melee;
- ranged;
- magic;
- abilities;
- special attacks.

Compare:

- target acquisition;
- target switching;
- range;
- line of sight;
- attack commitment;
- cooldown start;
- resource consumption;
- animation timing;
- hit resolution;
- miss behavior;
- death target clearing;
- movement cancellation;
- repeated attack behavior;
- invalid-target behavior.

Do not homogenize combat identity.

Normalize infrastructure and lifecycle where the underlying responsibility is equivalent.

---

# Tool Requirement Consistency

Compare systems requiring relevant:

- gathering tools;
- weapons;
- crafting stations;
- quest items;
- consumables;
- equipment.

Ask:

- Is the requirement checked before action begins?
- What happens if the requirement disappears mid-action?
- Is equipped versus inventory ownership treated consistently?
- Are requirement messages consistent?
- Does quality/tier affect behavior consistently where intended?

Do not invent a universal tool framework merely because several systems use tools.

---

# Range and Proximity Consistency

Compare equivalent interaction range rules.

Look for:

- unexplained one-off distances;
- one system measuring center-to-center while another uses boundaries;
- inconsistent approach distance;
- interactions triggering too early;
- interactions requiring unnecessarily exact positioning;
- equivalent world objects using incompatible range logic.

Where players perceive equivalent interaction semantics, align them.

Preserve deliberate range differences where gameplay requires them.

---

# Inventory Capacity Consistency

Compare how systems handle:

- full inventory;
- nearly full inventory;
- stackable rewards;
- multi-item outputs;
- equipment swaps;
- loot pickup;
- crafting completion;
- quest rewards.

Ask:

> **At what point does the game determine whether the reward can fit?**

Equivalent systems should follow predictable rules.

Avoid one system:

- refusing to start;

another:

- destroying the reward;

another:

- dropping it;

and another:

- overfilling inventory;

unless those outcomes are intentional.

---

# Resource Consumption Consistency

Compare when required resources are consumed.

Possible stages:

- request;
- action start;
- commitment;
- successful completion;
- each repeated cycle.

Ensure cancellation and refund behavior matches the intended lifecycle.

Look for divergence caused only by implementation order.

---

# XP Award Consistency

Compare:

- when XP is granted;
- what constitutes success;
- repeated-action behavior;
- bonus XP;
- failure behavior;
- multi-output actions;
- cancellation.

Equivalent progression events should generally share lifecycle semantics.

Do not change XP amounts merely to make numbers symmetrical.

Balance belongs elsewhere unless the inconsistency is clearly erroneous.

---

# Reward Timing Consistency

Compare when the player receives:

- items;
- XP;
- currency;
- drops;
- unlocks;
- progression credit.

Look for equivalent actions awarding at incompatible stages.

Reward timing should be deliberate.

---

# Success and Failure Consistency

Compare equivalent failures such as:

- insufficient level;
- missing tool;
- missing resources;
- inventory full;
- target unavailable;
- out of range;
- cooldown active;
- invalid state.

Ensure:

- the action does not partially execute unexpectedly;
- appropriate feedback appears;
- equivalent failures occur at equivalent lifecycle stages where appropriate;
- failed attempts do not consume resources accidentally.

---

# Cancellation Consistency

Compare cancellation across relevant:

- gathering;
- combat;
- crafting;
- dialogue;
- channelled abilities;
- interactions.

For each ask:

- Does movement cancel it?
- Does target change cancel it?
- Does closing UI cancel it?
- Does death cancel it?
- Does losing range cancel it?
- Are resources refunded?
- Does partial progress survive?
- Does the action resume automatically?

Differences should be explainable.

---

# Interruption Consistency

Distinguish:

> **cancellation by player intent**

from:

> **interruption caused by game state**

Examples include:

- damage;
- stun;
- death;
- target loss;
- scene transition;
- disconnect.

Equivalent long-running actions should handle interruption predictably.

---

# Repeated-Action Consistency

Compare systems that repeat automatically or semi-automatically.

Ask:

- Does the action loop?
- When does the loop stop?
- Does new input replace the current action?
- Does inventory full stop it?
- Does target depletion stop it?
- Does movement stop it?
- Does a new target replace it?
- Can stale repeats execute later?

If some systems are intentionally AFK-friendly while others are intentionally active, preserve that distinction.

Do not infer sameness without evidence.

---

# Interaction Message Consistency

Compare messages for equivalent outcomes.

For example, three systems might communicate the same level requirement using completely different wording.

Where the game already has an established pattern, normalize equivalent messaging.

Preserve flavor text when variation is intentional.

Do not allow internal implementation terminology to leak accidentally into player-facing text.

---

# Terminology Consistency

Search for mechanically equivalent concepts using different names without reason.

Examples:

- XP / Experience;
- level / rank;
- cooldown / recharge;
- damage / hit;
- stamina / energy;
- interact / use.

Do not globally rename established lore or intentionally distinct terminology.

Normalize accidental vocabulary differences.

---

# Progress Presentation Consistency

Where systems expose progress through:

- progress bars;
- action timers;
- channel indicators;
- skill progress;
- cooldowns;

compare:

- direction;
- start semantics;
- end semantics;
- percentage calculation;
- completion timing;
- reset behavior.

Equivalent progress should represent time and completion consistently.

---

# Targeting Consistency

Compare how systems:

- acquire targets;
- retain targets;
- switch targets;
- validate targets;
- clear targets;
- handle dead targets;
- handle despawned targets;
- handle changed authority.

Avoid each system inventing separate target lifecycle semantics without reason.

---

# World Interaction Consistency

Compare interaction with relevant:

- doors;
- chests;
- switches;
- gathering nodes;
- crafting stations;
- NPCs;
- loot;
- quest objects.

Inspect:

- selection;
- approach;
- range;
- facing;
- animation;
- completion;
- failure;
- repeat behavior.

Players should develop reliable expectations about how interacting with the world works.

---

# Requirement Validation Consistency

Compare when requirements are checked:

- UI selection;
- action request;
- after approach;
- action start;
- commitment;
- completion.

Avoid situations where one equivalent action immediately reports a missing requirement while another makes the player travel across the world before failing.

Choose lifecycle stages according to established game behavior.

---

# Station / Object Requirement Consistency

Where interactions require world objects or stations, compare:

- detection;
- range;
- facing;
- missing-station feedback;
- station disappearance;
- station ownership;
- target invalidation.

Equivalent station interactions should follow coherent rules.

---

# Cooldown Consistency

Compare:

- cooldown start;
- cooldown display;
- cancellation;
- resource failure;
- target failure;
- interruption;
- death;
- save/load where applicable.

Determine whether cooldown starts on:

- request;
- commit;
- successful execution.

Equivalent action categories should follow intentional rules.

---

# Status-Effect Consistency

If status effects exist, compare:

- application;
- refresh;
- stacking;
- duration;
- expiration;
- death cleanup;
- dispelling;
- persistence;
- UI representation.

Do not rebalance status effects.

Fix contradictory lifecycle behavior.

---

# Death and Respawn Consistency

Compare what death does to:

- targets;
- active actions;
- cooldowns;
- buffs/debuffs;
- UI;
- inventory;
- interactions;
- quests;
- movement;
- camera;
- repeated actions;
- pending callbacks.

The game should have one coherent death lifecycle.

System-specific exceptions should be explicit.

---

# Unlock Consistency

Compare how systems unlock:

- abilities;
- areas;
- recipes;
- skills;
- items;
- content.

Look for inconsistent:

- timing;
- notification;
- persistence;
- prerequisite validation;
- duplicate unlock behavior.

Do not redesign progression.

Make equivalent unlock concepts predictable.

---

# Item-State Consistency

If items have states such as:

- equipped;
- bound;
- locked;
- tradable;
- broken;
- consumed;
- quest-related;

compare how systems enforce them.

One system should not allow an item operation another equivalent system correctly rejects unless that difference is intentional.

---

# Shared Formula Consistency

Search for duplicated gameplay formulas.

Examples:

- damage;
- accuracy;
- XP thresholds;
- range;
- success chance;
- crafting output;
- cooldown calculation;
- stat modifiers;
- reward calculation.

When several systems implement the **same rule**, determine whether there should be one authoritative implementation.

Fix accidental drift.

Do not unify formulas representing intentionally different mechanics.

---

# Single Source of Truth

For important shared rules ask:

> **Where is the authoritative implementation?**

Avoid situations where:

- UI computes one requirement;
- gameplay computes another;
- server computes another;
- tooltip hard-codes another value;
- AI uses a copied formula;
- configuration and code both claim authority.

Where appropriate, establish one authoritative rule and make consumers read from it.

Do not create excessive abstraction for trivial values.

---

# Error-Handling Consistency

Equivalent systems should not fail in incompatible ways without a reason.

Compare:

- silent failure;
- user-facing feedback;
- returned error;
- state reset;
- rollback;
- retry.

Avoid one system swallowing a failure while another correctly restores state.

---

# Multiplayer Authority Consistency

If multiplayer exists, compare who owns authoritative gameplay results.

Look for:

- one skill trusting client results while equivalent skills validate server-side;
- one inventory operation being server-authoritative while another mutates locally first;
- inconsistent prediction semantics;
- client-side validation treated as authoritative inconsistently.

Do not redesign the networking model in this pass.

However, accidental authority inconsistency is high priority.

Treat substantial authoritative changes as high-risk work requiring careful validation.

---

# Persistence Consistency

Compare equivalent persisted state.

Look for:

- one system saving progress immediately while another unexpectedly does not;
- one cooldown persisting while an equivalent one resets accidentally;
- one field participating in migrations while another equivalent field is omitted;
- equivalent state using inconsistent defaults on load;
- equivalent systems recovering differently from missing data.

Do not redesign persistence architecture.

Fix accidental divergence where evidence is strong.

---

# UI-to-Gameplay Consistency

Compare what the interface tells the player with actual gameplay rules.

Look for:

- outdated requirement text;
- tooltip formulas differing from gameplay;
- displayed cooldown differing from actual cooldown;
- incorrect tool requirements;
- displayed XP differing from awarded XP;
- UI using stale duplicated constants.

Player-facing information should derive from authoritative gameplay rules where practical.

---

# Data-Driven Consistency

Where gameplay uses configuration or data definitions, inspect whether equivalent rules are:

- data-driven in one system;
- hard-coded in another;
- duplicated across files;
- partially migrated;
- overridden unexpectedly.

Do not force every rule into data files.

Eliminate accidental dual sources of truth.

---

# Cross-System Comparison Matrix

For major gameplay families, build a concise internal comparison matrix if useful.

Possible columns:

- validate requirements;
- approach;
- start;
- commit;
- consume resources;
- animation;
- repeat;
- cancel;
- interrupt;
- reward;
- XP;
- depletion;
- failure;
- target loss;
- inventory full.

Use this only as a diagnostic tool.

Do not spend the task polishing the matrix.

Its purpose is to expose actionable inconsistencies.

---

# "Why Is This Different?" Test

For every meaningful difference ask:

> **Why is this different?**

Acceptable reasons include:

- different gameplay fantasy;
- different balance requirement;
- different risk;
- different input model;
- different server authority;
- different progression role;
- intentional activity pacing.

Weak explanations include:

- different developer wrote it;
- copied from older code;
- implemented at different times;
- nobody standardized it;
- accidental default;
- forgotten migration.

Fix differences with no defensible purpose.

---

# "What Would the Player Expect?" Test

Use established game behavior to infer player expectations.

If five similar systems behave one way and a sixth behaves differently, investigate.

Do not blindly assume the majority is correct.

Majority behavior is evidence, not proof.

The exception may be intentional.

---

# "Which Version Is Better?" Test

When equivalent systems differ accidentally, do not automatically make system B match system A.

Ask:

- Which prevents invalid state?
- Which communicates more clearly?
- Which has the cleaner lifecycle?
- Which behaves correctly at boundaries?
- Which is already reused more widely?
- Which best matches design intent?
- Which is safest under interruption and repetition?

Standardize toward the strongest existing behavior.

---

# Pattern-Based Consistency Hunt

When one inconsistency is found, search for analogous systems.

If one gathering action awards XP at the wrong lifecycle stage:

> **inspect other gathering actions.**

If one combat style fails to clear dead targets:

> **inspect the other combat styles.**

If one requirement check is duplicated incorrectly:

> **inspect other copies of that validation.**

Do not stop at the first instance.

Find the pattern.

---

# Work in Consistency Waves

Do not normalize random details across the whole project simultaneously.

## Wave A — Shared Interaction Foundations

Compare:

- targeting;
- range;
- approach;
- action lifecycle;
- cancellation;
- interruption;
- failure.

Fix major accidental inconsistencies.

Validate.

## Wave B — Gameplay Families

Compare sibling systems such as:

- gathering skills;
- production skills;
- combat styles;
- abilities;
- world interactions.

Fix accidental divergence.

Validate.

## Wave C — Rewards and Progression

Compare:

- XP;
- item rewards;
- resource consumption;
- unlocks;
- completion semantics.

Fix lifecycle inconsistencies.

Validate.

## Wave D — Cross-System Boundaries

Compare:

- inventory;
- equipment;
- death;
- persistence;
- multiplayer;
- UI information.

Fix major disagreement.

Validate.

## Wave E — Terminology and Last 10%

Search for:

- messages;
- terminology;
- error presentation;
- small timing inconsistencies;
- old implementations;
- partial migrations.

Fix worthwhile remaining inconsistencies.

---

# Reassess After Every Wave

Ask:

- Which systems still feel implemented independently?
- Which equivalent rules still differ?
- Which difference lacks a clear design explanation?
- Did normalization expose duplicated logic?
- Did one fix reveal another system still using an obsolete pattern?
- Are we accidentally homogenizing intentional mechanics?
- Has one system emerged as the best pattern worth adopting elsewhere?
- Did any consistency fix alter balance unintentionally?

Update priorities.

---

# Productive Session Loop

Do not stop after the first obvious consistency fixes.

Normalization often exposes deeper divergence.

Examples:

- consistent requirement validation reveals different resource-consumption timing;
- consistent cancellation reveals inconsistent reward timing;
- reward normalization exposes duplicated XP formulas;
- formula consolidation exposes copied UI values.

Continue:

> **compare → ask why → identify accidental divergence → implement → validate → compare again**

while meaningful consistency problems remain.

Do not manufacture sameness merely to continue working.

Stop when remaining differences are:

- intentional;
- identity-defining;
- balance-driven;
- subjective;
- low-impact;
- risky to normalize;
- better suited to another specialized pass.

---

# Regression Review

Consistency changes can quietly alter balance or behavior.

After shared changes verify:

- action timing;
- XP;
- resource consumption;
- item rewards;
- cooldowns;
- range;
- success chance;
- inventory behavior;
- target behavior;
- multiplayer authority;
- persistence.

Do not assume:

> **consistent = correct**

Validate against intended mechanics.

---

# Independent Final Systems Review

Near completion, review gameplay families from fresh context.

Possible review areas:

## Gathering

Compare all gathering systems.

## Production

Compare crafting and production systems.

## Combat

Compare combat styles and target/action lifecycle.

## Progression

Compare XP, rewards, requirements, and unlocks.

## Interaction Foundations

Compare range, approach, cancellation, interruption, and failure.

The purpose of independent review is to find remaining accidental divergence, not merely approve previous work.

---

# "Does This Feel Like One Game?" Review

Ask:

> **Which mechanics still feel as though they were implemented independently without a shared gameplay language?**

Require concrete findings.

For each meaningful finding establish:

### Systems

Which systems are being compared?

### Shared Concept

What equivalent gameplay responsibility differs?

### Current Difference

How do they behave differently?

### Intentional?

What evidence suggests the difference is intentional or accidental?

### Preferred Behavior

Which existing behavior should become the standard, if any?

### Scope

Tiny / Small / Medium / Large.

Implement justified corrections.

Reject vague demands for homogenization.

---

# Anti-Homogenization Review

Before completion, explicitly determine whether this pass removed valuable identity.

Ask:

- Did different skills become mechanically identical?
- Did distinct combat styles lose personality?
- Did all actions receive identical timing unnecessarily?
- Did unique failure mechanics disappear?
- Did we normalize intentional resource behavior?
- Did we remove meaningful risk differences?
- Did we accidentally rebalance the game?
- Did AFK-oriented and active systems become identical without reason?

Undo unjustified homogenization.

Consistency should create:

> **predictability in shared rules**

while preserving:

> **identity in meaningful mechanics**

---

# Final Cross-System Review

Before finishing, inspect for:

- duplicated authoritative rules;
- inconsistent action lifecycle;
- old/new implementations;
- conflicting requirement validation;
- mismatched reward timing;
- inconsistent cancellation;
- inconsistent interruption;
- inconsistent targeting;
- inconsistent error behavior;
- gameplay/UI disagreement;
- multiplayer authority disagreement;
- persistence disagreement;
- incomplete normalization.

Fix justified issues.

Then run broad validation.

---

# Completion Standard

The gameplay systems consistency pass is complete when, to the degree existing systems allow:

1. major gameplay families have been compared;
2. shared interaction concepts have been identified;
3. major accidental inconsistencies are reduced;
4. intentional mechanical differences remain intact;
5. action lifecycle is more coherent across equivalent systems;
6. requirement validation is more predictable;
7. cancellation behavior is more consistent where appropriate;
8. interruption behavior is more coherent;
9. target lifecycle is more consistent;
10. inventory-full behavior is predictable across equivalent rewards;
11. resource-consumption timing is more intentional;
12. XP award timing is more coherent;
13. reward timing is more coherent;
14. duplicated authoritative gameplay formulas are reduced where appropriate;
15. player-facing terminology is more consistent;
16. UI information agrees with gameplay rules;
17. multiplayer authority is consistent where applicable;
18. persistence treatment is consistent where applicable;
19. no known gameplay regressions introduced by normalization remain;
20. major gameplay families feel more like parts of one product;
21. remaining differences are intentional, identity-defining, balance-related, low-impact, or better suited to another specialized pass.

The objective is not:

> **make every mechanic work exactly the same way**

The objective is:

> **make equivalent concepts behave consistently enough that players can develop reliable expectations while preserving meaningful system identity.**

---

# Final Report

When complete, provide a concise gameplay-systems report.

## 1. Overall Result

Summarize how system cohesion improved.

## 2. Major Inconsistencies Found

Describe concrete accidental differences that actually existed.

## 3. Gameplay Families Normalized

Summarize relevant areas such as:

- gathering;
- production;
- combat;
- interaction;
- progression.

Include only systems that exist.

## 4. Shared Rules Improved

Describe meaningful consistency improvements involving:

- requirements;
- cancellation;
- interruption;
- targeting;
- rewards;
- XP;
- inventory;
- cooldowns;
- failure.

## 5. Intentional Differences Preserved

Explicitly mention important mechanical differences deliberately retained.

## 6. Sources of Truth

Describe duplicated rules, formulas, configuration, or validation that were consolidated where meaningful.

## 7. Validation

State exactly which gameplay scenarios and systems were tested after normalization.

## 8. Deliberately Unchanged

Describe inconsistencies intentionally preserved because:

- they create system identity;
- they are balance-sensitive;
- evidence was insufficient;
- risk exceeded benefit;
- another specialized pass should own them.

## 9. Remaining Opportunities

List only worthwhile future consistency work.

For each include:

- **Systems**
- **Inconsistency**
- **Likely impact**
- **Scope:** Tiny / Small / Medium / Large
- **Recommended priority**

Do not pad this with microscopic wording differences.

---

# Final Directive

**Think like a systems designer comparing the game against itself.**

The strongest source of truth for what a mechanic should feel like is often:

> **another equivalent system in the same game that already handles the concept well.**

Do not homogenize intentionally different mechanics.

Do not casually rebalance the game.

Do not redesign systems merely for symmetry.

Do not create abstractions solely because several systems look similar.

Do not preserve accidental differences merely because they already exist.

Repeatedly ask:

> **Why is this different?**

> **Would a player expect this difference?**

> **Is there a gameplay reason for it?**

> **Which existing implementation handles this concept best?**

> **Can equivalent systems share a clearer rule without losing identity?**

Continue:

> **compare → classify → normalize → validate → compare again**

while meaningful accidental inconsistency remains.

Leave behind the **same game**, but make its systems feel substantially more cohesive, predictable, deliberately related, and designed as parts of one unified product.