You are responsible for a comprehensive **content-completeness, unfinished-implementation, partial-migration, and half-built-system pass**.

Your job is to find functionality that the existing project **clearly started implementing but never properly finished**, then complete it safely.

The primary question throughout this task is:

> **What already exists in this project but is still stubbed, placeholder, disconnected, partially migrated, happy-path-only, disabled, incorrectly wired, or obviously unfinished?**

Then finish that work.

This is an **implementation task**, not merely an unfinished-content audit.

Do not stop after:

- listing TODOs;
- identifying placeholders;
- documenting stubs;
- finding disabled controls;
- locating incomplete systems;
- identifying partially migrated code;
- producing a completion backlog;
- recommending what should be finished later.

For every meaningful incomplete path where intended behavior can be established from project evidence:

> **complete it.**

Use continuously:

> **inspect → prove intent → complete → validate → reinspect**

The goal is:

> **Leave behind the same game, but with substantially fewer stubs, placeholders, disconnected paths, incomplete states, partial migrations, and half-finished systems.**

---

# Absence Is Not Incompleteness

This distinction is critical.

Do not ask:

> **What features could this game use?**

Ask:

> **What did this project already start building but never properly finish?**

A missing feature is not automatically unfinished.

Examples of things that may simply not exist by design:

- mounts;
- trading;
- PvP;
- controller support;
- achievements;
- crafting queues;
- advanced settings;
- alternate game modes.

Do not invent them merely because similar games often have them.

Require evidence that the project intended the functionality.

Acceptable evidence may include:

- existing code;
- existing data;
- existing UI;
- assets;
- tests;
- call sites;
- event registrations;
- documentation;
- comments tied to concrete implementation;
- migrations;
- configuration;
- sibling implementations;
- partially wired systems;
- disabled production paths;
- placeholder content attached to otherwise functional systems.

If intent cannot be established:

> **do not guess.**

Classify the finding as uncertain and leave it unchanged.

---

# Core Scope

Inspect only incomplete work that is clearly backed by existing project evidence.

Relevant areas may include:

## Gameplay Systems

- movement;
- combat;
- abilities;
- targeting;
- gathering;
- crafting;
- inventory;
- equipment;
- loot;
- progression;
- XP;
- skills;
- death;
- respawn;
- status effects;
- cooldowns;
- quests;
- dialogue;
- world interaction.

## Content

- NPCs;
- enemies;
- items;
- equipment;
- recipes;
- resources;
- quests;
- dialogue trees;
- abilities;
- spells;
- objects;
- interactables;
- shops;
- loot tables;
- progression entries.

## UI

- buttons;
- menus;
- windows;
- panels;
- settings;
- tooltips;
- status displays;
- inventory UI;
- character UI;
- dialogue UI;
- quest UI;
- crafting UI;
- combat UI;
- loading/error states.

## Presentation Integration

Where existing systems already imply it:

- animation hooks;
- audio hooks;
- VFX hooks;
- icon references;
- state feedback;
- transition feedback.

## Persistence

- save/load;
- serializers;
- migrations;
- old/new field transitions;
- persisted settings;
- account data;
- player state;
- world state.

## Multiplayer

Where applicable:

- replication;
- server handlers;
- authority checks;
- session lifecycle;
- disconnect/reconnect;
- incomplete messages or RPCs;
- client/server registration.

## Platform Integration

Where already present:

- achievements;
- cloud saves;
- authentication;
- overlays;
- rich presence;
- platform IDs;
- entitlement handling;
- platform-specific settings.

## Production Configuration

- development mocks still reachable;
- test values in production paths;
- placeholder metadata;
- incomplete configuration transitions;
- disabled production implementations.

Only complete functionality that demonstrably exists in partial form.

---

# Explicitly Out of Scope

This is **not primarily**:

- a new-feature sprint;
- a design ideation pass;
- a content expansion;
- a gameplay redesign;
- a balance overhaul;
- a visual-art overhaul;
- a broad technical-debt cleanup;
- repository cleanup;
- performance optimization;
- a networking rewrite;
- a persistence redesign;
- a platform migration;
- a speculative architecture project.

Small structural changes are allowed when necessary to finish an evidenced incomplete implementation safely.

Do not allow completion work to become unrelated redesign.

---

# Preserve Existing Product Intent

When completing unfinished work, preserve established:

- mechanics;
- pacing;
- balance;
- progression;
- visual identity;
- input model;
- save compatibility;
- protocol behavior;
- multiplayer authority;
- platform behavior;
- terminology;
- content tone.

The objective is:

> **finish what was started**

not:

> **reinterpret what the product should have been.**

Prefer the smallest robust implementation that matches existing conventions.

---

# Preserve Existing Work

Before substantive changes, inspect version-control state where available.

Do not:

- overwrite unrelated modifications;
- revert unfamiliar work;
- delete ambiguous files;
- remove partially completed work merely because its purpose is initially unclear;
- use destructive version-control commands to simplify investigation.

If current unfinished work overlaps active modifications:

1. inspect them;
2. determine apparent intent;
3. preserve that intent;
4. integrate carefully;
5. avoid replacing ongoing work with speculative completion.

---

# Evidence Standard

Before completing a finding, establish why it is genuinely unfinished.

Useful evidence includes one or more of:

- TODO/FIXME linked to implemented functionality;
- method exists but is empty;
- handler returns success without performing work;
- UI control exists but has no handler;
- data exists but is never registered;
- animation exists but is never triggered;
- setting is stored but never applied;
- new schema fields exist but old callers remain;
- one sibling implementation is complete while another equivalent one lacks required lifecycle behavior;
- test clearly expects unfinished functionality;
- production path still uses a mock;
- code explicitly throws `NotImplemented`;
- migration is started but not fully wired;
- call site expects behavior the callee does not provide;
- feature has normal path but lacks necessary existing failure/cancel lifecycle.

One weak hint is not enough for a large implementation.

The larger the change, the stronger the evidence should be.

---

# Intent Confidence

Classify incomplete findings internally.

## High Confidence

Intent is obvious from multiple pieces of project evidence.

Implement.

## Medium Confidence

Intent is strongly suggested by existing patterns and sibling implementations.

Investigate further.

Implement only when behavior can be established safely.

## Low Confidence

Only vague comments, dead code, abandoned prototypes, or speculative naming suggest intent.

Do not complete automatically.

Report instead.

---

# Implementation Over Auditing

The audit exists to produce an **implementation queue**.

Do not spend most of the task:

- cataloguing every TODO;
- listing every disabled branch;
- documenting every placeholder;
- building giant spreadsheets of incomplete files;
- speculating about future functionality.

Once a meaningful finding is sufficiently proven:

> **finish it.**

Then validate:

1. intended normal path;
2. required failure states;
3. lifecycle behavior;
4. persistence/network behavior where applicable;
5. neighboring sibling behavior;
6. regression risk.

---

# Execution Strategy

Work autonomously where possible.

If the environment supports independent agents, workers, subprocesses, or parallel contexts, use them where they materially improve coverage.

Do not require delegation.

A single capable session must still be able to execute the task sequentially.

Good independent investigation areas may include:

- UI completeness;
- gameplay stubs;
- content registration;
- persistence migration;
- platform integration;
- animation/audio/VFX wiring;
- networking handlers;
- placeholder/residue audit.

Serialize modifications involving shared:

- schemas;
- progression rules;
- protocols;
- multiplayer authority;
- persistence;
- common gameplay foundations;
- shared registration systems.

Do not let independent workstreams invent contradictory completion behavior.

For high-risk work involving:

- persistent player data;
- currency;
- transactions;
- authoritative multiplayer state;
- migrations;
- protocol changes;

use additional fresh-context review where possible.

---

# Priority Queue

## P0 — Dangerous Incomplete Implementation

Examples:

- stub causes corruption;
- incomplete transaction duplicates value;
- missing authority check;
- unfinished migration destroys data;
- no-op persistence path silently loses progress;
- incomplete lifecycle causes crash;
- partial implementation leaves unrecoverable state.

Fix immediately.

## P1 — Major Player-Facing Incompleteness

Examples:

- button visibly exists but does nothing;
- menu cannot complete intended action;
- important setting saves but has no effect;
- production feature still returns placeholder behavior;
- quest cannot complete;
- normal gameplay reaches `NotImplemented`;
- required integration exists but cannot function;
- feature is visibly half-built during ordinary play.

Prioritize heavily.

## P2 — Significant Incomplete Behavior

Examples:

- missing cancel/failure lifecycle;
- sibling system lacks expected state;
- partial migration leaves old/new disagreement;
- animation or feedback wiring missing;
- data is implemented but never registered;
- UI still reads obsolete source;
- one path bypasses newer implementation.

Spend substantial effort here.

## P3 — Residue

Examples:

- harmless placeholder text;
- unused temporary label;
- obsolete comment;
- low-impact development residue;
- minor disconnected decorative asset.

Address after meaningful functional incompleteness.

---

# TODO / FIXME Hunt

Search for:

- `TODO`;
- `FIXME`;
- `XXX`;
- `HACK`;
- `TEMP`;
- `NotImplemented`;
- similar project conventions.

Classify each.

Possible classifications:

- genuine unfinished feature;
- bug note;
- future enhancement;
- technical-debt note;
- obsolete comment;
- intentionally deferred work.

Do not treat every TODO as work that must be implemented.

Require surrounding evidence.

---

# Stub Hunt

Search for functions or methods that:

- return default values unconditionally;
- return `null` unexpectedly;
- return success without mutation;
- contain only logging;
- throw `NotImplemented`;
- contain empty bodies;
- contain temporary hardcoded outputs;
- immediately short-circuit intended behavior.

For each ask:

> **Is this actually called by a production path?**

Then:

> **What does surrounding code expect it to do?**

Complete production-relevant stubs with clear intent.

Do not resurrect unused abandoned prototypes.

---

# No-Op Handler Hunt

Inspect:

- button handlers;
- RPC handlers;
- event listeners;
- state callbacks;
- command handlers;
- menu actions;
- platform callbacks.

Look for handlers that:

- fire;
- acknowledge;
- log;
- close UI;

without performing the intended action.

A control that visibly accepts input but does nothing is often stronger evidence of incompleteness than a missing control.

---

# Fake Success Hunt

Search for paths that claim completion without performing real work.

Examples:

- returns `true`;
- sends success response;
- displays completed message;
- marks UI done;
- closes workflow;

while durable/gameplay state is unchanged.

These are especially dangerous around:

- purchases;
- saves;
- rewards;
- platform operations;
- networking;
- settings.

Fix confirmed cases.

---

# Placeholder Hunt

Search player-visible production paths for:

- `TODO`;
- `TBD`;
- `Lorem ipsum`;
- `Placeholder`;
- `Test`;
- temporary names;
- engine defaults;
- fake values;
- dummy icons;
- development URLs;
- sample content;
- hardcoded mock values.

Do not replace unknown content with invented copy.

If intended value cannot be established, report it instead.

---

# Production Mock Hunt

Search for mocks or test implementations that may still be active in real runtime.

Examples:

- fake authentication;
- mock inventory;
- dummy platform service;
- fake API response;
- test player data;
- sample save;
- static economy value;
- hardcoded success response.

Determine whether the mock is:

- test-only;
- development-only;
- intentional fallback;
- accidentally used in production.

Replace only confirmed production leakage.

---

# Disabled Path Hunt

Search for functionality disabled through:

- `false`;
- feature flags;
- commented registration;
- hidden controls;
- disabled menu items;
- debug conditions;
- temporary early returns.

Do not automatically re-enable it.

Determine:

- why it was disabled;
- whether surrounding implementation is complete;
- whether project evidence shows it was intended for current product;
- whether disabling is deliberate.

A disabled abandoned experiment is not automatically unfinished production work.

---

# Orphaned UI Hunt

Look for UI that exists but is not properly connected.

Examples:

- button without handler;
- setting without application;
- tooltip without source;
- panel that never opens;
- screen opens but cannot close;
- control changes local value but not gameplay;
- UI references obsolete state;
- visible option is disabled despite implemented backend.

Use surrounding UI and sibling screens as evidence.

---

# Settings Completeness Pass

For each implemented setting trace:

> **UI control → value change → runtime application → persistence → reload**

Look for settings that:

- display but do nothing;
- apply but do not save;
- save but do not apply;
- reset unexpectedly;
- reference obsolete configuration;
- work only during the current session.

Complete only existing intended settings.

Do not invent new settings.

---

# Content Registration Hunt

Search for implemented data that never becomes available because registration is missing.

Examples:

- item exists but is absent from item registry;
- recipe exists but is never loaded;
- enemy exists but cannot spawn;
- NPC definition exists but is never placed;
- ability exists but is not registered;
- quest exists but cannot start;
- dialogue exists but is never referenced.

Before wiring it in, establish whether the content is intended to be active rather than abandoned.

---

# Missing Reference Hunt

Inspect for:

- empty IDs;
- stale paths;
- missing resource references;
- old enum values;
- forgotten registration;
- scene/prefab references;
- missing icon/animation references.

Where the intended reference can be established from project evidence, repair it.

Do not guess between several plausible assets.

---

# Partial Migration Hunt

Search aggressively for old and new implementations coexisting.

Possible signs:

- old and new fields;
- old and new serializers;
- duplicate services;
- deprecated and replacement APIs both used;
- duplicated config values;
- compatibility shims that became permanent;
- callers split between old/new interfaces;
- duplicated authoritative state;
- half-converted database rows;
- new data models with old UI.

Ask:

> **Was this migration deliberately kept compatible, or simply never finished?**

Do not remove compatibility layers blindly.

Determine what existing data or callers still rely on them.

---

# Migration Completion Standard

For a confirmed incomplete migration:

1. identify old system;
2. identify intended new system;
3. map remaining callers;
4. map persisted data impact;
5. determine compatibility requirements;
6. complete remaining conversion;
7. remove obsolete source of truth only when safe;
8. validate old and new state.

Do not create a forced cleanup that breaks valid older data.

---

# Dual Source-of-Truth Hunt

Partial migrations frequently leave two systems claiming authority.

Examples:

- old field + new field;
- local UI value + authoritative gameplay value;
- old save format + new save format;
- client value + server value;
- legacy config + current config.

Determine intended authority.

Finish migration toward the correct source where evidence is clear.

Do not leave synchronization hacks between competing authorities if one should have been retired.

---

# Happy-Path-Only Hunt

An implemented feature may still be unfinished if it only handles the ideal path.

Inspect existing functionality for required behavior around:

- cancellation;
- failure;
- invalid target;
- unavailable resource;
- full inventory;
- destruction;
- death;
- reload;
- disconnect;
- timeout;
- interrupted animation;
- missing permission;
- stale state.

Do not add every imaginable edge case.

Add only lifecycle states clearly required by the existing feature.

---

# Cancellation Completeness

For cancellable actions, determine whether the feature already implies cancellation through:

- movement;
- UI;
- target changes;
- explicit cancel button;
- state transition.

If so, ensure cancellation:

- stops pending work;
- cleans up state;
- releases ownership;
- avoids reward;
- resets UI;
- does not later complete from stale callback.

Do not invent cancellation for committed actions where design evidence says none exists.

---

# Failure-State Completeness

For implemented operations determine what happens when expected prerequisites fail.

Examples:

- missing resource;
- missing tool;
- insufficient currency;
- target gone;
- full inventory;
- network failure;
- invalid save;
- unavailable platform service.

Avoid incomplete behavior such as:

- silent no-op;
- endless spinner;
- stuck state;
- partial mutation;
- fake success.

Use existing project error patterns.

---

# Loading / Pending State Completeness

Where async systems exist, inspect whether UI and gameplay correctly represent pending state.

Look for:

- action can be triggered repeatedly while pending;
- spinner never clears;
- UI closes before result;
- stale result applies after screen changed;
- pending state survives failure incorrectly.

Only add pending behavior when the operation genuinely requires it.

---

# Empty-State Completeness

For existing screens and systems inspect:

- empty inventory;
- no quests;
- no friends;
- no recipes;
- no results;
- no items;
- no available targets.

If the UI currently breaks, shows placeholders, or assumes non-empty data, complete the necessary empty state.

Do not create decorative empty-state experiences beyond project conventions.

---

# Missing Wiring Hunt

Find pieces that exist independently but were never connected.

Examples:

- control exists but handler missing;
- item exists but registry missing;
- recipe loads but menu ignores it;
- animation exists but event never fires;
- sound exists but trigger missing;
- setting persists but runtime never reads it;
- gameplay state changes but UI never observes it;
- server message exists but client handler missing;
- data loaded but discarded;
- save field written but never restored.

Trace the full path rather than fixing only one disconnected endpoint.

---

# Event / Signal Wiring Pass

Inspect event-driven systems for:

- event declared but never emitted;
- emitter exists but no listener;
- listener registered to obsolete event;
- duplicate old/new events;
- expected completion event omitted;
- callback never forwarded.

Use sibling implementations and call sites to infer intended flow.

Do not emit speculative events with no consumers.

---

# Animation Integration Pass

Where animation assets and gameplay states clearly exist, inspect whether intended animation lifecycle is wired.

Look for:

- animation exists but is never triggered;
- action starts animation but never stops;
- completion event never reaches gameplay;
- wrong state name;
- old animation reference after migration.

Do not turn this into an animation-polish pass.

Complete only missing integration.

---

# Audio Integration Pass

Where audio assets and clear trigger points already exist, inspect:

- event never triggered;
- wrong asset reference;
- playback path disabled;
- old/new audio API split.

Do not create new audio design.

Wire existing intended content.

---

# VFX Integration Pass

Where VFX already exist and corresponding gameplay events clearly expect them, inspect:

- unused effect;
- missing spawn;
- effect never stops;
- wrong event mapping;
- stale prefab/resource reference.

Do not invent new effects.

Complete existing presentation integration.

---

# NPC Completeness Pass

For implemented NPCs inspect:

- spawn/placement;
- interaction;
- dialogue;
- shop/service;
- quest relationship;
- name/icon/state;
- persistence where applicable.

Look for NPCs that visibly exist but cannot perform their apparent existing function.

Do not invent personalities, dialogue, shops, or quests unsupported by project evidence.

---

# Quest Completeness Pass

For existing quests inspect:

- start condition;
- objective registration;
- objective progress;
- completion;
- reward;
- dialogue/state updates;
- persistence;
- reload behavior.

Look for:

- impossible objective;
- completion path missing;
- reward stub;
- quest starts but cannot advance;
- objective data exists but event never wired;
- quest resets accidentally on reload.

Do not write new quest content unless exact intended content already exists in project data.

---

# Item Completeness Pass

For existing items inspect:

- registration;
- acquisition;
- use;
- equipment behavior where applicable;
- tooltip/data;
- icon/reference;
- persistence;
- vendor/crafting integration where intended.

An unused item definition is not automatically incomplete.

Establish intended role first.

---

# Recipe Completeness Pass

For existing recipes inspect:

- registration;
- requirements;
- ingredient consumption;
- output;
- XP;
- UI availability;
- station requirement;
- unlock;
- persistence where relevant.

Look for recipes that exist in data but cannot be used because one integration step was omitted.

---

# Ability / Spell Completeness Pass

For existing abilities inspect:

- unlock;
- selection;
- resource cost;
- cooldown;
- targeting;
- execution;
- damage/effect;
- animation;
- feedback;
- multiplayer authority;
- persistence where relevant.

Look for abilities that are partially playable but lack one necessary state.

Do not invent new mechanics to make them more elaborate.

---

# World Object Completeness Pass

For existing interactable objects inspect:

- placement;
- collision;
- targeting;
- interaction;
- state changes;
- reset/respawn;
- persistence;
- multiplayer replication where applicable.

Look for objects that visually imply functionality because supporting code/data exists but cannot complete their intended interaction.

---

# Menu / Screen Completeness Pass

Inspect existing menus for:

- open;
- close;
- navigation;
- confirm;
- cancel;
- apply;
- reset;
- save;
- failure;
- loading;
- empty state.

A screen that opens but cannot complete its advertised workflow is unfinished.

Complete existing workflow only.

---

# Platform Integration Completeness

Where platform support clearly exists, inspect for partial implementation.

Examples:

- SDK initializes but achievements never unlock;
- achievement IDs exist but events are not wired;
- rich-presence strings exist but are never updated;
- cloud save wrapper exists but one side is never called;
- platform login UI exists but backend path is stubbed.

Do not implement platform features that have no repository evidence.

---

# Networking Completeness

Where multiplayer exists, inspect partially implemented:

- message types;
- RPC handlers;
- replication;
- authority validation;
- reconnect;
- late join;
- spawn/despawn;
- error paths.

Treat networking changes as higher risk.

Do not expand the networking protocol merely because another feature could use it.

---

# Persistence Completeness

Inspect for:

- save fields written but never loaded;
- fields loaded but never saved;
- migration created but not registered;
- new schema column unused;
- old serializer still active;
- logout path bypassing new save system;
- settings saved but ignored;
- migration version never incremented.

Preserve existing valid data.

Treat incomplete migrations as high risk.

---

# Sibling Comparison

Use complete sibling systems as evidence.

Examples:

- Mining compared with Woodcutting;
- one crafting station compared with another;
- one equipment slot compared with another;
- one settings screen compared with another;
- one network handler compared with another;
- one quest family compared with another.

Compare relevant:

- validation;
- registration;
- cancellation;
- interruption;
- depletion;
- rewards;
- persistence;
- failure;
- UI updates;
- cleanup.

If several equivalent systems handle a necessary responsibility and one does not, investigate whether the difference is intentional or unfinished.

Do not homogenize meaningful gameplay differences.

---

# Existing Best Implementation as Reference

When completing one sibling, prefer the strongest existing implementation when appropriate.

For example:

- copy the established error lifecycle;
- use the existing registration pattern;
- follow the current save pattern;
- use the same UI state model;
- use the same authority validation.

Do not create a new framework simply because one incomplete feature needs finishing.

---

# Registration Completeness

Many half-built systems fail because their implementation exists but is never registered.

Search for:

- registries;
- service containers;
- factories;
- event registration;
- content loaders;
- menu registration;
- command registration;
- platform callback registration;
- network handler registration.

Compare expected registration against complete siblings.

---

# Reference Completeness

For content-driven projects inspect whether data correctly references:

- IDs;
- assets;
- scenes;
- prefabs;
- icons;
- recipes;
- NPCs;
- quests;
- abilities;
- objects.

Look for valid implementation stranded by missing linkage.

---

# State-Machine Completeness

For implemented stateful systems, enumerate the states that actually exist.

Look for transitions that:

- lead nowhere;
- never occur;
- cannot exit;
- skip cleanup;
- reference removed states;
- have code only on one side.

Do not invent a more elaborate state machine.

Complete the required lifecycle.

---

# Branch Completeness

Search for branches where:

- success implemented, failure missing;
- one enum case omitted;
- one platform omitted despite supported configuration;
- one item type unhandled;
- default silently drops behavior;
- one state returns TODO.

Use exhaustive handling where the domain is finite and intended.

---

# Enum / Switch Audit

Inspect important exhaustive decisions.

Look for:

- new enum value added but not handled everywhere;
- default branch masking missing implementation;
- old value retained after migration;
- UI missing one state;
- serializer missing one variant.

Do not mechanically eliminate all default branches.

Use project semantics.

---

# Disabled Control Review

For visibly disabled controls inspect whether:

- feature is intentionally unavailable;
- prerequisite is unmet;
- backend is unfinished;
- control was temporarily disabled.

Do not enable controls simply because implementation exists nearby.

Require evidence that the feature is intended to be usable now.

---

# Hidden Feature Review

Likewise, hidden UI may represent:

- unfinished functionality;
- intentionally unreleased content;
- obsolete code;
- debug tooling.

Do not expose it automatically.

Only complete and expose when current product intent is well supported.

---

# Dead Code Is Not Automatically Unfinished

Do not confuse:

> **unused old implementation**

with:

> **unfinished current implementation**

Some code was abandoned intentionally.

Before reviving dead code ask:

- Is anything still referencing it?
- Does current data expect it?
- Does documentation establish it as current?
- Was it superseded?
- Is there a newer implementation?

Do not revive obsolete systems merely because they are incomplete.

---

# Test Evidence

Tests can strongly establish intent.

Inspect:

- failing tests;
- skipped tests;
- TODO tests;
- commented test cases;
- tests for sibling behavior.

But do not blindly implement old tests when production behavior clearly superseded them.

Use tests alongside current code and data.

---

# Comment Evidence

Comments can establish intent, but their reliability varies.

Strong comment:

> **TODO: apply saved UI scale after loading settings**

next to the settings loader.

Weak comment:

> **TODO: maybe add trading someday**

Do not implement speculative future ideas.

---

# History Evidence

Where version history is available and useful, inspect it when intent remains uncertain.

Look for:

- partially completed migration commits;
- temporarily disabled functionality;
- abandoned implementation;
- replacement system;
- documented blocker.

Do not spend excessive time archaeology-diving obvious current behavior.

---

# Pattern-Based Completion Hunt

When one incomplete pattern is found, search analogous code.

Examples:

If one settings value saves but does not apply:

> inspect other settings.

If one recipe is never registered:

> inspect neighboring recipes.

If one migration left an old caller:

> inspect remaining callers.

If one network RPC is missing authority validation:

> inspect related RPCs.

Do not blindly apply fixes.

Search for the repeated unfinished pattern.

---

# Implementation Standard

For every meaningful finding:

1. prove the functionality is incomplete;
2. establish intended behavior from project evidence;
3. identify affected systems;
4. preserve existing product constraints;
5. implement the smallest complete solution;
6. validate normal behavior;
7. validate required failure/lifecycle behavior;
8. search analogous implementations;
9. add focused regression coverage where practical.

Do not fake completion merely to satisfy a test.

Do not hide unfinished UI when the underlying functionality can safely be completed.

Do not report a stub as "resolved" by deleting its only visible entry point unless evidence says the feature should be removed.

---

# Regression Testing

For meaningful completions, add focused tests when existing infrastructure supports them.

Useful coverage may include:

- formerly inert control now works;
- missing registration now resolves;
- save field round-trips;
- migration completes;
- cancel state cleans up;
- failure path no longer sticks;
- network handler mutates expected authority;
- setting persists and applies.

Avoid building an entirely new test framework for a tiny completion.

---

# Work in Completion Waves

Do not modify random unfinished pieces across the entire project simultaneously.

## Wave A — Dangerous Stubs

Fix:

- corruption paths;
- fake persistence success;
- incomplete transactions;
- crashes;
- authoritative no-ops;
- broken migrations.

Validate.

## Wave B — Player-Facing Incomplete Features

Fix:

- inert controls;
- unusable menus;
- impossible quest/activity completion;
- settings that do nothing;
- visible placeholders;
- production stubs.

Validate.

## Wave C — Partial Migrations and Wiring

Fix:

- old/new drift;
- missing registrations;
- disconnected data;
- stale callers;
- duplicate sources of truth.

Validate.

## Wave D — Lifecycle Completeness

Fix clearly required:

- failure;
- cancellation;
- interruption;
- cleanup;
- loading;
- empty states.

Validate.

## Wave E — Presentation Integration

Complete existing:

- animation;
- audio;
- VFX;
- icons;
- status feedback;

only where project evidence clearly connects them to existing functionality.

## Wave F — Last 10%

Search for:

- placeholder residue;
- orphaned references;
- disabled production branches;
- unhandled enum cases;
- forgotten tests;
- incomplete sibling implementations.

---

# Reassess After Every Wave

Ask:

- What still looks placeholder?
- Which production path still contains a stub or mock?
- Which system remains half migrated?
- Which visible control lacks complete behavior?
- Which feature only works on the happy path?
- Which data exists but remains disconnected?
- Which state is written but never read?
- Which sibling still lacks an expected responsibility?
- Did a completion expose another incomplete dependency?
- Is remaining work actually evidenced or merely imagined?

Reprioritize.

---

# Productive Completion Loop

Do not stop after the first obvious stubs.

Half-implemented systems frequently expose deeper incomplete layers.

Examples:

- wiring a button exposes missing backend implementation;
- backend completion exposes missing persistence;
- persistence exposes partial migration;
- migration exposes stale UI;
- UI completion exposes missing failure state.

Continue:

> **inspect → prove intent → complete → validate → reinspect**

while clear, safely actionable unfinished work remains.

Do not manufacture features simply to continue working.

Stop when remaining findings are:

- speculative;
- intentionally disabled;
- clearly abandoned;
- future roadmap ideas;
- unsupported by current project evidence;
- dependent on product decisions;
- outside scope.

---

# Independent Final Completion Review

Near completion, review the project again from fresh context.

Ask:

> **What still looks half-implemented, placeholder, disconnected, or abandoned mid-migration?**

Require concrete evidence.

For each finding establish:

## System

Where is it?

## Evidence

What proves implementation was started?

## Missing Piece

What remains incomplete?

## Intended Behavior

What project evidence establishes the expected result?

## Risk

What happens if it remains incomplete?

## Scope

Tiny / Small / Medium / Large.

Implement justified findings.

Reject speculative additions.

---

# High-Risk Independent Review

Use additional scrutiny for completed work involving:

- persistence;
- migrations;
- inventory;
- currency;
- transactions;
- networking;
- multiplayer authority;
- account state;
- platform authentication.

Challenge:

- duplicate processing;
- stale state;
- partial failure;
- incompatible old data;
- race conditions;
- rollback/recovery;
- protocol compatibility.

Do not merely review whether code compiles.

Review whether completion is safe.

---

# Anti-Scope-Creep Review

Before completion, inspect the changes made during this pass.

Undo work that:

- invented unsupported features;
- turned completion into redesign;
- altered balance without necessity;
- changed gameplay identity;
- revived abandoned systems;
- removed required compatibility;
- created speculative abstractions;
- replaced working architecture unnecessarily;
- expanded the project beyond evidence-backed intent.

Ask:

> **Was this change required to finish something the project had already started?**

If not, reconsider it.

---

# Anti-Fake-Completion Review

Do not "finish" work by:

- hiding broken controls;
- deleting TODOs without implementation;
- returning placeholder success;
- skipping tests;
- replacing real behavior with mock data;
- suppressing errors;
- disabling a feature that is clearly intended to work;
- removing migration compatibility merely to simplify code.

Completion means:

> **the intended workflow now actually works**

not:

> **the evidence of incompleteness is gone.**

---

# Final Regression Review

Before finishing:

1. rerun relevant baseline functionality;
2. test newly completed workflows;
3. test sibling systems touched by shared changes;
4. test save/load where persistence changed;
5. test multiplayer behavior where networking changed;
6. inspect logs/errors;
7. run automated tests/build validation;
8. verify no new placeholders or dead paths were created.

Fix regressions.

---

# Completion Standard

The content-completeness pass is complete when, to the degree project evidence supports:

1. major production stubs have been identified;
2. meaningful TODO/FIXME functionality has been classified;
3. dangerous incomplete paths have been resolved;
4. visible inert controls are completed or intentionally classified;
5. major player-facing placeholders are removed where intended values are known;
6. partial migrations are completed or deliberately preserved;
7. duplicated old/new authoritative state is reduced where appropriate;
8. major missing registrations are fixed;
9. disconnected implemented content is wired where intent is clear;
10. settings behave through UI → runtime → persistence where intended;
11. clearly required failure states exist;
12. clearly required cancellation/cleanup states exist;
13. relevant animation/audio/VFX integration is completed where existing assets and hooks prove intent;
14. major content definitions intended for use are actually reachable;
15. no known P0 or P1 incomplete implementation remains without an explicit blocker;
16. high-risk persistence/networking/transaction changes received additional scrutiny;
17. no significant regression introduced by completion work remains;
18. speculative feature ideas were not implemented;
19. abandoned code was not revived without evidence;
20. remaining incomplete work is unsupported, intentionally deferred, product-dependent, high-risk beyond available evidence, or outside scope.

The objective is not:

> **finish every idea anyone ever left in the repository**

The objective is:

> **finish the functionality the current project clearly started building and still expects to work.**

---

# Final Report

When complete, provide a concise implementation-completeness report.

## 1. Overall Result

Summarize the largest improvements to project completeness.

## 2. Systems Completed

List meaningful systems or workflows that were genuinely unfinished and are now complete.

For each major item include:

- **System**
- **Evidence of prior incompleteness**
- **What was missing**
- **What was completed**

## 3. Player-Visible Unfinished Work Fixed

Summarize important fixes involving:

- controls;
- menus;
- placeholders;
- settings;
- content;
- gameplay paths.

## 4. Stubs and Integration Gaps

Summarize meaningful:

- no-op handlers;
- missing registrations;
- disconnected data;
- missing references;
- fake-success paths;
- missing event wiring.

## 5. Partial Migrations Resolved

Summarize relevant:

- old/new system drift;
- stale callers;
- duplicate sources of truth;
- serializer/schema transitions;
- compatibility work.

## 6. Lifecycle Completeness

Summarize clearly required:

- failure;
- cancellation;
- interruption;
- cleanup;
- loading;
- empty-state;

behavior added.

## 7. Validation

State exactly what was performed, including relevant:

- builds;
- tests;
- runtime checks;
- save/load validation;
- migration tests;
- multiplayer tests;
- UI workflow checks;
- content registration checks.

Do not imply testing occurred when it did not.

## 8. Deliberately Unimplemented

List noteworthy findings intentionally left unchanged because:

- evidence of intent was insufficient;
- functionality appears abandoned;
- it is clearly future roadmap work;
- completing it requires product decisions;
- another specialized pass should own it.

For each explain the reason briefly.

## 9. Remaining Incomplete Work

List only evidence-backed unfinished work that remains.

For each include:

- **System**
- **Evidence**
- **Missing work**
- **Severity**
- **Scope:** Tiny / Small / Medium / Large
- **Why unresolved**
- **Recommended next action**

Do not include speculative feature suggestions.

---

# Final Directive

**Do not search for features the game ought to have. Search for features the project already tried to build and failed to finish.**

Require evidence.

Do not treat absence as incompleteness.

Do not implement roadmap comments as current requirements.

Do not revive abandoned prototypes without proof.

Do not hide unfinished behavior when it can be safely completed.

Do not mistake deleting a stub for implementing the feature.

Do not guess unsupported product intent.

Repeatedly ask:

> **What proves this was intended to work?**

> **What part is actually missing?**

> **What does the surrounding project say the behavior should be?**

> **Is there a complete sibling that establishes the pattern?**

> **Is this unfinished, or merely absent by design?**

> **Can we complete this without redesigning the product?**

Continue:

> **inspect → prove intent → complete → validate → reinspect**

while clear, evidence-backed unfinished work remains.

Leave behind the **same game**, but with substantially fewer stubs, placeholders, disconnected paths, partial migrations, incomplete states, and half-finished systems.