You are responsible for a comprehensive **game destruction, edge-case, hidden-bug, and regression-elimination pass**.

Assume:

> **Every implemented system probably contains at least one state, timing, lifecycle, boundary, interruption, sequencing, repetition, or cross-system bug that ordinary happy-path play has not exposed yet.**

Your job is to find those bugs.

Then fix them.

This is not merely a QA report.

This is an:

> **attack → reproduce → diagnose → fix → validate → attack again**

task.

Do not stop after:

- generating test cases;
- producing a bug list;
- identifying suspicious code;
- writing recommendations;
- documenting reproduction steps;
- suggesting that bugs be fixed later.

For every meaningful issue that can be safely reproduced and sufficiently understood:

> **implement the fix.**

The goal is:

> **Make the existing game significantly harder to break through normal play, abnormal play, rapid input, unusual sequencing, interruptions, state transitions, long sessions, and realistic edge cases.**

---

# Core Philosophy

Normal development naturally over-tests:

> **what the developer expected the player to do.**

This pass focuses heavily on:

> **what happens when the player does something unexpected but still plausible.**

Examples:

- clicking twice;
- clicking ten times;
- rapidly alternating actions;
- cancelling at the worst possible moment;
- changing target during an action;
- opening or closing UI during transitions;
- dying during an interaction;
- disconnecting during a save;
- moving while another action completes;
- repeating an action hundreds or thousands of times;
- triggering two systems on the same frame or tick;
- loading unusual but valid state;
- reaching exact boundary values;
- leaving and returning repeatedly;
- destroying an object while another system still references it.

Do not assume a path is safe because:

> **players probably won't do that.**

If the game's normal controls permit it, players eventually will.

---

# Primary Mission

Find and eliminate:

- reproducible gameplay bugs;
- hidden state bugs;
- invalid state transitions;
- race conditions;
- timing-dependent failures;
- lifecycle failures;
- stale references;
- duplicate actions;
- lost actions;
- stuck states;
- orphaned state;
- boundary-condition failures;
- rapid-input bugs;
- interruption bugs;
- cancellation bugs;
- sequencing bugs;
- load/save edge cases;
- entity lifecycle issues;
- UI/gameplay desynchronization;
- client/server disagreement where applicable;
- unexpected cross-system interactions;
- long-session degradation;
- regression-prone logic.

Focus on **existing implemented functionality**.

Do not invent new systems merely so they can be tested.

---

# Explicitly Out of Scope

This is not primarily:

- a feature-development sprint;
- an art-direction pass;
- visual polish;
- UI beautification;
- a game-feel pass;
- balance work;
- economy redesign;
- content expansion;
- broad architecture cleanup;
- repository cleanup;
- broad performance optimization;
- accessibility expansion.

Small architectural changes are allowed when required to eliminate a confirmed bug safely.

Small UI, animation, VFX, audio, networking, persistence, or performance changes are allowed when they directly fix a confirmed failure.

Do not let those areas become unrelated cleanup campaigns.

---

# Do Not Manufacture Bugs

Aggressive QA does **not** mean treating every unusual behavior as incorrect.

Before changing something, determine whether it is:

- a confirmed defect;
- inconsistent with established gameplay rules;
- an invalid state;
- clearly accidental;
- capable of corrupting state;
- capable of trapping the player;
- capable of crashing or throwing;
- likely to produce unpredictable behavior;
- capable of duplicating or losing important state.

Do not "fix":

- deliberate mechanics;
- intentional limitations;
- intentional cooldowns;
- intentional animation commitments;
- intentional server authority;
- intended failure states;

merely because another design might feel smoother.

Distinguish:

> **weird**

from:

> **wrong.**

---

# Preserve Existing Behavior

Except where correcting confirmed defects, preserve:

- gameplay rules;
- progression;
- balance;
- timing;
- persistence formats;
- network protocols;
- public APIs;
- entity IDs;
- data representation;
- save compatibility;
- world state;
- input model;
- authoritative ownership.

A QA fix that accidentally redesigns gameplay is a regression.

---

# Preserve Existing Work

Before substantive modifications, inspect the project's version-control state where available.

Do not:

- overwrite unrelated modifications;
- revert unfamiliar work;
- delete ambiguous files;
- use destructive version-control commands merely to simplify the worktree;
- accidentally absorb unrelated work into bug fixes.

When an existing modification overlaps a bug:

1. inspect it;
2. determine its apparent purpose;
3. preserve that intent;
4. integrate carefully;
5. leave the area unchanged if safe ownership cannot be established.

A QA pass that destroys legitimate development work is a failed QA pass.

---

# Investigate Before Asking Questions

Use the project itself as evidence.

Inspect relevant:

- source code;
- runtime behavior;
- automated tests;
- logs;
- state machines;
- event flows;
- network flows;
- save/load logic;
- entity lifecycle;
- project history;
- existing documentation;
- bug comments;
- TODO/FIXME markers;
- assertions;
- error handling;
- crash logs where available;
- callers and references.

Ask for clarification only when:

- intended behavior genuinely cannot be determined;
- fixing the issue requires a product decision;
- several materially different outcomes are equally plausible;
- required external systems are unavailable;
- a destructive migration requires approval;
- proceeding would create substantial uncertainty or risk.

Do not ask questions merely because reproduction is difficult.

---

# Observe Runtime Behavior

Where practical, run the game.

Do not perform destructive QA entirely by reading source code.

Use the strongest evidence available:

- actual gameplay;
- controlled runtime scenarios;
- automated tests;
- debug instrumentation;
- logs;
- state inspection;
- network inspection;
- save/load fixtures;
- existing recorded reproduction steps.

If the game cannot be run in the available environment, state that limitation and perform the strongest source-level and automated investigation possible.

Do not claim runtime reproduction when none occurred.

---

# Implementation Over Reporting

The audit exists to generate a **bug-fixing queue**.

Do not spend most of the task producing:

- giant test matrices;
- massive reports;
- theoretical edge cases;
- speculative concerns;
- hypothetical bugs without evidence.

Once an issue is reproducible and sufficiently understood:

> **fix it.**

Then test:

1. the original reproduction;
2. the normal expected path;
3. nearby related cases;
4. likely regression paths.

Then continue hunting.

---

# Destructive Testing Loop

Use this continuously:

> **Identify system → establish invariants → attack assumptions → reproduce failure → determine root cause → fix → validate → attack again**

Do not merely test once after fixing.

Try to break the corrected behavior again using:

- different timing;
- reversed sequencing;
- repetition;
- interruption;
- cancellation;
- boundary values;
- transitions;
- target destruction;
- simultaneous state changes.

---

# 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 must still be able to execute this prompt sequentially.

Good independent QA areas may include:

- movement/pathfinding;
- combat;
- gathering;
- crafting;
- inventory/equipment;
- NPC/dialogue;
- quests;
- UI;
- world objects;
- save/load;
- multiplayer;
- spawn/despawn.

Do not allow independent workstreams to simultaneously make conflicting changes to shared:

- entity state;
- interaction routing;
- persistence schemas;
- networking foundations;
- inventory models;
- global lifecycle systems;
- authoritative state.

For shared problems:

1. gather evidence;
2. establish root cause;
3. define one coherent fix;
4. implement centrally;
5. validate from multiple directions.

---

# Severity Queue

Use approximately:

## P0 — Critical

Examples:

- crash;
- data corruption;
- save corruption;
- security-relevant state failure;
- permanent progression loss;
- server instability;
- severe duplication exploit;
- unrecoverable softlock;
- catastrophic authoritative desynchronization.

Fix immediately.

## P1 — Major

Examples:

- reproducible gameplay softlock;
- stuck controls;
- broken combat state;
- lost items;
- duplicate rewards;
- serious inventory corruption;
- major disconnect-state bug;
- repeatedly invalid state;
- major quest breakage;
- important feature becoming unusable.

Prioritize heavily.

## P2 — Moderate

Examples:

- interaction failing under certain sequencing;
- incorrect feedback with functional recovery;
- temporary stuck state with workaround;
- duplicate minor effects;
- inconsistent state transitions;
- NPC/object state mismatch;
- edge-case UI/gameplay disagreement.

Fix where safely reproducible.

## P3 — Minor

Examples:

- tiny state oddities;
- rare low-impact sequencing issues;
- incorrect minor messaging;
- harmless duplicate callbacks;
- small defects exposed during testing.

Handle after more meaningful issues.

---

# Bug Evidence Standard

For every meaningful confirmed bug, establish internally:

## Severity

P0 / P1 / P2 / P3.

## System

What functionality is affected?

## Reproduction

What is the shortest reliable reproduction sequence?

## Expected

What should happen?

## Actual

What happens instead?

## Invariant Violated

What rule or state guarantee was broken?

## Root Cause

Why does the defect occur?

## Fix

What was changed?

## Regression Validation

What was tested after the fix?

Do not spend excessive effort polishing bug-report prose.

The report exists to support implementation and verification.

---

# Establish System Invariants

Before attacking a system, determine what must always remain true.

Examples follow.

## Inventory

- item counts cannot unintentionally become negative;
- transfers conserve item ownership;
- capacity rules remain valid;
- equipment ownership is unambiguous;
- one item cannot exist in multiple authoritative locations unintentionally.

## Combat

- dead entities cannot perform normal attacks;
- one action produces the intended number of results;
- target state remains valid;
- cooldowns cannot become permanently stuck;
- rewards do not fire more times than intended.

## Movement

- movement completion does not leave the player permanently "moving";
- path failure does not trap control;
- destroyed targets cannot retain active approach behavior;
- cancelled movement does not complete later unexpectedly.

## Persistence

- save/load round trips preserve valid state;
- failed saves do not partially corrupt authoritative state;
- invalid data fails safely;
- loading does not duplicate transient runtime state.

## Transactions

- assets are neither duplicated nor lost;
- completion occurs atomically where required;
- retries cannot repeat successful mutations;
- disconnects do not produce ambiguous ownership.

Attack **invariants**, not merely screens.

---

# Rapid Input Attack

Aggressively test:

- double-clicking;
- repeated clicking;
- spam clicking;
- button mashing;
- alternating actions;
- rapidly changing targets;
- move → attack → move → attack;
- open → close → open;
- equip → unequip → equip;
- start → cancel → start;
- rapid menu changes.

Look for:

- duplicate execution;
- stale callbacks;
- lost input;
- state corruption;
- action queues growing without bound;
- animation spam;
- network spam;
- stuck states;
- incorrect cooldown behavior.

Do not "fix" rapid input by blindly debouncing everything.

Correct the state model where possible.

A robust system should tolerate rapid valid input rather than merely reject it.

---

# Exact-Timing Attack

Test transitions at the worst plausible moments.

Examples:

- cancel immediately before completion;
- move on the same tick an action resolves;
- target dies during attack wind-up;
- player dies during interaction;
- disconnect while an action resolves;
- inventory changes while crafting completes;
- scene changes while a callback is pending;
- cooldown expires as another action requests use;
- save occurs while state is transitioning.

These moments expose stale assumptions and accidental ordering dependencies.

---

# Same-Frame / Same-Tick Review

Search specifically for logic whose correctness accidentally depends on execution order.

Examples:

- target dies and despawns in the same tick;
- an item is removed and used in the same tick;
- a level increases while a reward callback resolves;
- movement finishes while an attack begins;
- disconnect and persistence update occur together;
- an entity is destroyed while an event referencing it is dispatched.

Where order matters, make that dependency explicit.

Do not rely on incidental callback ordering.

---

# Interruption Attack

Interrupt one legitimate system with another.

Examples:

- move while gathering;
- attack while interacting;
- change equipment during combat;
- close interface during a transaction;
- open dialogue during movement;
- die while crafting;
- lose target during cast;
- remove a required item during an action;
- unload an area while an object is active.

Determine whether the action should:

- cancel;
- continue;
- complete;
- queue another action;
- fail cleanly.

Make the behavior explicit and stable.

---

# Cancellation Attack

For every cancellable action, test cancellation:

- immediately;
- halfway through;
- one frame or tick before completion;
- repeatedly;
- after target disappearance;
- during network latency;
- during animation transitions;
- during state changes.

Look for:

- lost resources;
- duplicate refunds;
- stale progress;
- locked controls;
- orphaned animation;
- callbacks resolving after cancellation;
- retained targets;
- duplicate state cleanup.

Cancellation should result in **one stable final state**.

---

# Boundary-Value Attack

Test relevant numerical boundaries.

Examples:

- zero items;
- one item;
- maximum capacity;
- exactly full inventory;
- one slot over capacity;
- zero health;
- maximum health;
- zero currency;
- large bounded currency values;
- level boundaries;
- XP exactly at a threshold;
- zero cooldown;
- exact timer expiration;
- very large counts;
- empty names;
- maximum text lengths;
- negative malformed values reaching trusted boundaries.

Look for:

- off-by-one errors;
- overflow;
- underflow;
- invalid state;
- formatting failures;
- duplicated reward triggers;
- skipped progression thresholds.

---

# Range and Distance Attack

Test:

- exactly at interaction range;
- just inside range;
- just outside range;
- moving across the boundary;
- target moving across the boundary;
- obstacles appearing;
- target disappearing;
- line-of-sight changing at completion.

Look for:

- oscillation;
- repeated start/stop;
- interaction at invalid distance;
- inability to interact at valid distance;
- completion after range has become invalid;
- inconsistent client/server range decisions.

---

# Target Lifecycle Attack

For target-based systems test:

- target selected then destroyed;
- target dies;
- target despawns;
- target changes area;
- target becomes invalid;
- another player removes or consumes the target;
- references are reused;
- target is replaced.

No subsystem should retain unsafe assumptions about entities that no longer exist.

Validate target references before delayed or asynchronous completion.

---

# Spawn / Despawn Attack

Repeatedly:

- spawn;
- despawn;
- respawn;
- destroy;
- recreate.

Apply this to relevant:

- enemies;
- NPCs;
- players;
- world objects;
- loot;
- effects;
- interactables.

Look for:

- duplicate registration;
- stale global collections;
- leaked listeners;
- leaked timers;
- invisible colliders;
- phantom interactions;
- duplicate IDs;
- stale UI references;
- orphaned target state.

---

# Scene / Zone Transition Attack

If the game changes areas, test transitions:

- during movement;
- during combat;
- during dialogue;
- during gathering;
- while UI is open;
- while async work is pending;
- repeatedly and rapidly;
- into and out of the same area many times.

Look for:

- duplicated objects;
- retained state;
- missing objects;
- stale references;
- callbacks into unloaded scenes;
- resource leaks;
- incorrectly persistent UI;
- duplicated listeners;
- invalid player-control state.

---

# Inventory Attack

If inventory exists, test:

- full inventory;
- nearly full inventory;
- empty inventory;
- stack splitting;
- stack merging;
- transferring;
- dropping;
- picking up;
- using the last item;
- using while moving;
- using while another action is pending;
- an item being removed by another system;
- repeated clicking;
- simultaneous reward and consumption;
- inventory mutation during UI updates.

Attack conservation:

> **Items should not mysteriously appear or disappear.**

Track authoritative ownership through each path.

---

# Equipment Attack

Where equipment exists, test:

- equip;
- unequip;
- swap;
- replace occupied slot;
- equip during combat;
- remove during another action;
- rapidly alternate equipment;
- invalid equipment type;
- inventory full while unequipping;
- equipped item removed externally;
- equipment changed during stat calculation.

Look for:

- duplicates;
- lost items;
- stat stacking;
- stale bonuses;
- visual/logic disagreement;
- multiple authoritative owners.

---

# Combat Attack

If combat exists, aggressively test:

- attacking dead targets;
- target death mid-action;
- rapidly switching target;
- movement during attacks;
- attacking while already attacking;
- ability spam;
- exact cooldown boundaries;
- resource reaching zero;
- player death during action;
- enemy despawn;
- range changes;
- line-of-sight changes;
- simultaneous deaths;
- interruption during wind-up;
- interruption during recovery.

Check invariants:

- no duplicate damage;
- no attacks from invalid entities;
- target state clears correctly;
- cooldown remains valid;
- rewards occur exactly as intended;
- dead actors cannot later complete stale attacks.

---

# Damage / Health Attack

Test:

- exact lethal damage;
- overkill;
- healing at zero;
- healing at maximum;
- damage and healing in the same tick;
- damage after death;
- repeated death callbacks;
- respawn after unusual death sequences.

Look for:

- invalid negative health;
- duplicate death;
- duplicate drops;
- repeated XP/rewards;
- resurrection errors;
- stale combat state.

---

# Gathering / Repetitive Interaction Attack

If gathering or equivalent systems exist, test:

- target despawns during action;
- another player depletes the resource;
- inventory fills during action;
- required tool is removed;
- player moves before completion;
- target is clicked repeatedly;
- target changes;
- player dies;
- resource respawns while an old callback remains pending.

Check:

- reward exactly once;
- progression exactly once;
- resource state exactly once;
- clean action-state exit.

---

# Crafting Attack

If crafting or production exists, test:

- exactly enough resources;
- one resource short;
- inventory fills at completion;
- ingredients removed during crafting;
- repeated starts;
- cancellation;
- quantity boundaries;
- UI closing;
- death;
- disconnect;
- simultaneous inventory changes;
- completion retried after transient failure.

Check conservation:

> **Inputs must be consumed and outputs created exactly according to intended rules.**

---

# NPC / Dialogue Attack

Where applicable, test:

- NPC disappears;
- player moves away;
- dialogue reopens rapidly;
- multiple dialogue triggers;
- combat starts during dialogue;
- area changes;
- options clicked repeatedly;
- quest state changes during dialogue;
- dialogue owner is destroyed.

Look for:

- duplicate progression;
- stale dialogue;
- impossible options;
- controls remaining locked;
- callbacks targeting invalid NPC state.

---

# Quest / Objective Attack

If quests exist, test:

- objective triggered twice;
- completion event repeated;
- required item acquired before quest starts;
- target killed before objective activates;
- save/load mid-quest;
- abandon/restart where supported;
- required NPC unavailable;
- objective order bypass;
- completion during another transition.

Look for:

- duplicate rewards;
- impossible progression;
- permanently blocked quests;
- invalid intermediate states;
- missing retroactive credit where rules require it.

---

# Loot and Reward Attack

Test:

- duplicate claim;
- rapid pickup;
- full inventory;
- disconnect during reward;
- target destroyed before pickup;
- multiple systems granting reward simultaneously;
- retries after uncertain completion.

Ensure:

- reward occurs the intended number of times;
- failure is recoverable;
- authoritative ownership is clear;
- retries are safe.

---

# XP and Level Boundary Attack

Test:

- exact XP threshold;
- multiple levels from one reward;
- huge XP reward;
- zero XP;
- malformed negative input at external boundaries;
- repeated reward callback;
- save/load around level-up.

Look for:

- skipped levels;
- duplicate unlocks;
- duplicate notifications;
- incorrect residual XP;
- invalid thresholds;
- reward processing more than once.

---

# UI / Gameplay State Attack

Test gameplay while interfaces change.

Examples:

- open/close inventory rapidly;
- select item then remove the item;
- target frame references destroyed target;
- dialogue closes while callback completes;
- menu blocks input inconsistently;
- UI action repeats before authoritative response;
- screen opens during state transition.

Look for UI displaying stale authoritative state.

The UI must not accidentally become a second source of truth.

---

# Save / Load Attack

If saving exists, test safely using disposable test data where appropriate.

Test:

- save during gameplay;
- save after major transitions;
- repeated saves;
- load immediately after saving;
- load older valid data;
- optional fields absent;
- empty collections;
- boundary values;
- area/scene state;
- inventory;
- quests;
- player location;
- persisted timers or cooldowns where supported.

Do not corrupt real user data during destructive testing.

Use isolated test saves or temporary environments where possible.

---

# Persistence Failure Attack

Where practical, test behavior during:

- write failure;
- malformed input;
- unavailable database;
- rejected transaction;
- partial request failure;
- timeout;
- retry.

Ensure failure does not leave:

- partially mutated authoritative state;
- false success UI;
- duplicate retry effects;
- corrupted local state;
- ambiguous ownership.

Treat persistence correctness as high risk.

---

# Disconnect / Reconnect Attack

For multiplayer games test:

- disconnect while moving;
- disconnect during combat;
- disconnect during loot;
- disconnect during trade;
- disconnect during save;
- disconnect during another transaction;
- reconnect after unusual state;
- repeated connect/disconnect.

Look for:

- duplicated entities;
- ghost players;
- orphaned combat targets;
- duplicate sessions;
- inventory/persistence disagreement;
- stale ownership;
- actions completing for disconnected players.

---

# Multiplayer Concurrency Attack

Where applicable, test simultaneous legitimate actions such as:

- two players looting the same object;
- two players interacting with the same resource;
- ownership changes occurring simultaneously;
- several attacks resolving as a target dies;
- simultaneous pickups;
- simultaneous transactions.

Focus on authoritative invariants.

Do not fake concurrency safety using client-side checks.

For substantial concurrency fixes, explicitly inspect:

- transaction boundaries;
- locking or atomic operations;
- idempotency;
- ordering;
- retries;
- authoritative ownership;
- rollback/failure behavior.

---

# Transaction Attack

For trades, marketplaces, purchases, exchanges, or equivalent systems, test:

- cancellation at the final moment;
- offered asset removed before completion;
- destination inventory full;
- disconnect;
- repeated acceptance;
- changing offer after acceptance;
- simultaneous completion attempts;
- retried network requests.

Ensure:

> **Assets cannot be duplicated or lost.**

Treat transaction correctness as high severity.

---

# Economy Integrity Attack

Without rebalancing the economy, determine whether bugs can:

- duplicate currency;
- create free items;
- bypass costs;
- consume costs twice;
- produce rewards twice;
- sell the same asset twice;
- claim rewards repeatedly.

These are QA defects even if exploit research is not the broader objective.

Fix confirmed state errors.

---

# Timer / Cooldown Attack

Test:

- zero duration;
- exact expiration;
- pause/resume;
- save/load;
- death;
- disconnect;
- repeated trigger;
- time drift;
- multiple timers for one action;
- timer owner destruction.

Look for:

- negative timers;
- permanently locked abilities;
- duplicate completion;
- timers surviving destroyed owners;
- state disagreement between timer and gameplay state.

---

# Event / Signal Attack

Inspect event-driven systems for:

- duplicate subscriptions;
- missing unsubscribe;
- listener called after owner destruction;
- repeated registration;
- callbacks firing twice;
- hidden ordering assumptions.

Repeatedly enter and leave systems to expose accumulating listeners.

---

# Async Callback Attack

Inspect asynchronous operations.

Invalidate the original owner/state while awaiting:

- file operations;
- network responses;
- database operations;
- delayed animation;
- timers;
- resource loading;
- pathfinding;
- background tasks.

When the callback returns, verify that:

- owner still exists;
- request is still current;
- target is still valid;
- expected state is still active;
- completion has not already occurred.

Stale asynchronous completion is a major source of hidden bugs.

---

# Lifecycle Symmetry Attack

For important objects inspect:

- create → destroy;
- subscribe → unsubscribe;
- register → unregister;
- start → stop;
- open → close;
- connect → disconnect;
- acquire → release;
- load → unload.

Every beginning should have a valid end.

Look for cleanup paths skipped by:

- early returns;
- errors;
- death;
- cancellation;
- disconnect;
- scene transitions.

---

# Repetition Attack

Repeat ordinary flows far more often than typical manual testing.

Examples:

- open/close screen 100 times;
- spawn/despawn repeatedly;
- change zones repeatedly;
- gather repeatedly;
- equip/unequip repeatedly;
- connect/disconnect repeatedly;
- start/cancel repeatedly.

Look for accumulating:

- memory;
- callbacks;
- duplicate state;
- UI objects;
- errors;
- latency;
- listeners;
- timers.

---

# Long-Session Attack

Where practical, run or simulate extended usage.

Look for:

- state drift;
- growing collections;
- accumulating timers;
- accumulating listeners;
- unbounded caches;
- stale entities;
- degrading performance;
- timestamp or rollover issues;
- periodic failures.

Not all bugs appear in short sessions.

---

# Pause / Focus / Background Attack

Where relevant to supported platforms, test:

- pause;
- resume;
- window focus loss;
- focus regain;
- minimized state;
- application suspension;
- platform resume.

Inspect:

- timers;
- input;
- audio where relevant;
- network state;
- movement;
- cooldowns;
- pending interactions.

Do not invent platform behavior for platforms the game does not support.

---

# Weird-but-Legal Sequence Testing

Try legitimate actions in unusual orders.

Examples:

> **Equip → attack → open inventory → unequip → move → switch target.**

> **Start gathering → open menu → fill inventory → return → cancel.**

> **Talk to NPC → combat starts → quest changes → NPC disappears.**

These sequences expose assumptions between individually functional systems.

---

# Cross-System Collision Matrix

Identify major implemented systems and deliberately combine them.

Potential axes include:

- movement;
- combat;
- inventory;
- equipment;
- dialogue;
- quests;
- gathering;
- crafting;
- death;
- area transitions;
- UI;
- save/load;
- multiplayer.

Ask:

> **What happens when System A changes state while System B is active?**

Prioritize combinations that are realistically possible.

Do not brute-force impossible theoretical combinations.

---

# Invalid Data Defense

Inspect boundaries receiving data from:

- network;
- persistence;
- files;
- configuration;
- database;
- external services;
- player-controlled input where relevant.

Test malformed but plausible values.

This is not a complete security audit.

Ensure malformed input does not trivially:

- crash;
- corrupt state;
- create impossible entities;
- bypass critical invariants;
- trigger duplicate mutations.

---

# Error Handling Attack

Search for:

- swallowed exceptions;
- ignored failures;
- empty catches;
- fallbacks leaving partial state;
- retries duplicating actions;
- errors logged but treated as success;
- partial mutations before failure.

Trigger failure branches where practical.

Verify the system returns to a stable state.

---

# Resource Exhaustion Boundaries

Where practical, test realistic upper bounds involving:

- maximum inventory;
- many entities;
- many notifications;
- large lists;
- long chat/history;
- many simultaneous effects;
- large save data;
- large but supported player counts.

Do not conduct absurd denial-of-service testing.

Use realistic stress intended to expose boundary defects.

---

# Pattern-Based Bug Hunting

When one bug is found, search for the **implementation pattern**, not merely that exact instance.

Examples:

If one system forgets to unsubscribe from an event:

> **inspect equivalent lifecycle systems.**

If one async interaction does not validate the target after awaiting:

> **inspect equivalent callbacks.**

If one reward path can execute twice:

> **inspect equivalent reward paths.**

If one action cleanup fails during cancellation:

> **inspect other cancellable actions.**

Do not blindly copy fixes.

Use one defect as evidence that the same mistaken assumption may exist elsewhere.

---

# Regression Test Creation

For meaningful bugs, add focused automated regression tests when the existing project infrastructure makes that practical.

A useful regression test should:

1. reproduce the original failure;
2. fail before the fix;
3. pass after the fix;
4. remain stable;
5. avoid over-specifying unrelated implementation details.

Do not create a large new testing framework merely to test one bug.

Follow existing project testing conventions.

---

# Bug-Fix Standard

For each meaningful defect:

1. reproduce it where practical;
2. identify the violated invariant;
3. determine root cause;
4. implement the smallest robust fix;
5. avoid symptom-only patches where possible;
6. rerun the original reproduction;
7. test normal behavior;
8. test adjacent edge cases;
9. search for equivalent callers or patterns;
10. verify the fix does not create a second source of truth;
11. add regression coverage where valuable;
12. attack the fix again.

Avoid accumulating one-off flags or timing hacks such as:

- `isFixingBug`;
- `ignoreNextThing`;
- arbitrary delays;
- isolated special-case state;

unless the actual domain semantics genuinely require them.

Prefer correcting:

- ownership;
- lifecycle;
- state transitions;
- idempotency;
- validation;
- cancellation semantics;

over hiding symptoms.

---

# Work in QA Waves

Do not attack the project randomly.

## Wave A — Critical State and Lifecycle

Attack:

- crashes;
- softlocks;
- invalid states;
- lifecycle;
- duplicate actions;
- destruction;
- cancellation;
- serious corruption.

Fix and validate.

## Wave B — Core Gameplay Systems

Attack the project's highest-frequency loops.

Examples may include:

- movement;
- combat;
- gathering;
- inventory;
- crafting;
- interaction.

Fix and validate.

## Wave C — Cross-System Sequencing

Combine relevant:

- movement with combat;
- inventory with actions;
- quests with dialogue;
- death with active systems;
- scene transitions with pending work;
- UI with gameplay state.

Fix and validate.

## Wave D — Persistence / Multiplayer / Async

Where applicable attack:

- save/load;
- disconnect/reconnect;
- asynchronous callbacks;
- authoritative state;
- transactions;
- concurrency.

Treat these as higher-risk systems.

## Wave E — Long Tail

Attack:

- boundary values;
- repetition;
- long sessions;
- unusual sequencing;
- UI/gameplay disagreement;
- subtle stale-state failures.

---

# Reassess After Every Wave

Ask:

- Which system produced the most bugs?
- What mistaken assumption appeared repeatedly?
- Are multiple failures symptoms of one root cause?
- Did a fix expose another invalid state?
- Did we create new edge cases?
- Are similar systems making the same mistake?
- Are lifecycle bugs clustered around one ownership model?
- Are race-like failures clustered around shared state?
- Which high-frequency systems have not been attacked hard enough?

Reprioritize.

Do not mechanically follow an outdated initial test plan.

---

# Productive QA Loop

Do not stop after the first batch of bugs.

After meaningful fixes, perform another attack pass.

Fixes often expose deeper assumptions.

Continue:

> **attack → reproduce → diagnose → fix → validate → attack again**

while meaningful, reproducible, safely actionable defects remain.

Do not invent hypothetical bugs merely to continue working.

Stop when remaining findings are primarily:

- unproven;
- highly speculative;
- intentional behavior;
- extremely low impact;
- impossible to reproduce with available evidence;
- dependent on unavailable infrastructure;
- outside scope.

---

# "Try to Break the Game" Review

Near completion, perform a fresh destructive pass with this directive:

> **Assume the game is about to ship. Try to discover ways an ordinary but curious player could break existing functionality without modifying the game or using external exploit tooling.**

Focus on:

- unusual sequencing;
- rapid actions;
- interruption;
- boundary conditions;
- repeated actions;
- stale targets;
- transitions;
- save/load;
- reconnect;
- simultaneous state changes.

Require reproducible evidence.

Do not reward giant speculative bug lists.

---

# "What Would Players Discover in Week One?" Review

Ask:

> **What bugs would thousands of ordinary players probably discover simply by behaving differently from the developer?**

Consider:

- spam clicking;
- unexpected navigation;
- leaving areas mid-action;
- inventory boundaries;
- repeated rewards;
- simultaneous actions;
- unusual progression order;
- reconnect behavior;
- long sessions;
- UI timing;
- rapid target changes.

Prioritize realistic player behavior over exotic theoretical attacks.

---

# Independent Review of High-Risk Fixes

Where practical, use fresh context to challenge high-risk fixes involving:

- authoritative state;
- persistence;
- serialization;
- networking;
- concurrency;
- transactions;
- entity lifecycle shared across systems;
- large state-machine changes.

The review question is not:

> **Does this fix look good?**

Ask:

> **How can this fix still fail, duplicate state, lose state, leave stale references, violate ordering, or break adjacent behavior?**

Search actively for flaws.

---

# Anti-Overfix Review

Before completion, determine whether bug fixes made the game unnecessarily restrictive.

Ask:

- Did we block valid rapid input?
- Did we add excessive debounce?
- Did we prevent legitimate cancellation?
- Did we make interactions slower?
- Did we add unnecessary locks?
- Did we over-centralize state?
- Did we turn recoverable failures into hard failures?
- Did we add excessive defensive branches?
- Did we change intended gameplay?

A robust game should tolerate unusual input.

It should not merely reject everything unusual.

Undo unjustified restrictions.

---

# Final Regression Sweep

Before finishing:

1. rerun major baseline tests;
2. rerun important bug reproductions;
3. run normal happy-path gameplay;
4. test systems adjacent to major fixes;
5. inspect logs and errors;
6. verify no meaningful new warnings appeared;
7. inspect important state ownership;
8. run broad build/test validation;
9. rerun high-risk timing and lifecycle tests;
10. verify important fixes remain stable under repetition.

Major fixes must not create new failures elsewhere.

---

# Completion Standard

The QA destruction pass is complete when, to the degree available testing can establish:

1. critical gameplay paths were actively attacked;
2. high-frequency systems were tested beyond happy paths;
3. major lifecycle boundaries were inspected;
4. rapid-input behavior was tested;
5. interruption and cancellation were tested;
6. important target lifecycle behavior was tested;
7. major boundary values were tested;
8. repeated-action behavior was tested;
9. important cross-system combinations were tested;
10. save/load was attacked where applicable;
11. multiplayer and disconnect behavior were attacked where applicable;
12. meaningful confirmed bugs were fixed;
13. important bug fixes received regression validation;
14. duplicate rewards, items, or state discovered were eliminated;
15. discovered softlocks were eliminated;
16. important stale-state failures discovered were eliminated;
17. important lifecycle leaks discovered were eliminated;
18. significant stale asynchronous callback failures discovered were eliminated;
19. no known P0 or P1 issue found during the pass remains unfixed without a documented blocker;
20. high-risk fixes received additional scrutiny;
21. normal gameplay still behaves as intended;
22. no known regressions introduced by the fixes remain;
23. remaining findings are speculative, extremely low-impact, intentional, unavailable to reproduce, or outside scope.

The objective is not:

> **prove the game has zero bugs**

That is impossible.

The objective is:

> **aggressively reduce the class of bugs that normally survive happy-path development and are discovered only after real players begin doing unpredictable things.**

---

# Final Report

When complete, provide a concise QA engineering report.

## 1. Overall Result

Summarize the most important improvements to game robustness.

## 2. Critical / Major Bugs Fixed

List meaningful P0/P1 issues.

For each include concise:

- **System**
- **Symptom**
- **Root cause**
- **Fix**

## 3. Important Edge Cases Fixed

Summarize worthwhile P2/P3 defects by subsystem.

## 4. Systems Attacked

State which major systems received destructive testing.

## 5. Cross-System Testing

Summarize important combinations tested.

## 6. Persistence / Multiplayer

Include only if applicable.

Summarize important tests and fixes.

## 7. Regression Tests

Describe meaningful automated regression coverage added.

## 8. Validation

State exactly what was run, including relevant:

- test suites;
- manual/runtime sequences;
- stress tests;
- repetition tests;
- rapid-input tests;
- long-session tests;
- builds.

## 9. Deliberately Unchanged

Describe suspicious behavior intentionally preserved because:

- it is intended;
- reproduction was unreliable;
- evidence was insufficient;
- risk exceeded benefit;
- required external infrastructure was unavailable.

## 10. Remaining Risk

List only meaningful unresolved QA risks.

For each include:

- **Risk**
- **Reason unresolved**
- **Severity**
- **Relevant system**
- **Recommended next action**

Do not pad this section with theoretical edge cases.

---

# Final Directive

**Think like a destructive QA engineer who is also expected to fix what they break.**

Do not trust happy-path behavior.

Do not trust one successful run.

Do not assume players act patiently.

Do not assume systems complete in the expected order.

Do not assume targets still exist.

Do not assume callbacks return while their original state is still valid.

Do not assume an action occurs only once.

Do not assume players wait for animations.

Do not assume inventories have space.

Do not assume network requests arrive in a convenient order.

Require evidence.

Reproduce whenever practical.

Fix root causes rather than hiding symptoms.

After every meaningful bug ask:

> **How else can this same assumption be violated?**

> **Where else does the project make the same assumption?**

> **Can a player interrupt this at the worst possible moment?**

> **What happens if this occurs twice?**

> **What happens if the referenced thing disappears?**

Continue:

> **attack → reproduce → diagnose → fix → validate → attack again**

while meaningful defects remain.

Leave behind the **same game**, but make it substantially more resilient to real players doing strange, impatient, repetitive, badly timed, and completely legal things.