Tiny Chaos: new chat handoff

Updated 2026-10-30. This page supersedes older plans where they conflict. Inspect the live working tree before making changes; later work may be uncommitted.

Use the playable-game roadmap for the current dependency-ordered milestones, including the common scene, ability/player completion, new input and keybindings, and next-version readiness. This handoff provides supporting context.

For operational rules and a concrete first batch, start with agent work instructions.

Owner's replacement method: preserve authored data, IDs, bindings and required behavior first; remove the legacy implementation, then implement the new one without a fallback. Record incomplete transfers and continue in connected batches; intermediate breakage is acceptable and checks come after a coherent integration. This applies to the planned input replacement, not existing systems that only need wiring fixes.

Current objective and budget

Finish the new player and ability system to a first playable integration. The owner is low on usage quota and wants connected batches, concise updates and no confirmation for routine implementation. Do not restart the architecture or audit every ability before making progress. Fix main gameplay, enemy, menu, stage, spawner, input and GameManager wiring where needed for the playable path, using their existing systems; a separate overhaul of those areas is out of scope.

Latest owner direction: pursue the planned shared gameplay scene for released stages instead of separately repairing the old Arena 1–3 scenes. Reuse existing stage data and gameplay, enemy, reward and manager systems; make the adjustments needed for integration. The existing Gameplay.unity is a tested development foundation, not a finished production arena. Add the required common production bindings and compose stage-specific environments from the existing content. First bring one selected stage through the full loop, then connect the remaining environments and stage data. Do not delete old scenes until their contents and behavior have been accounted for and migrated.

Scene comparison: all three arenas put the same MapGenerator on the main camera and point it at a scene tilemap and ornament parent. Noise settings are identical; their RuleTiles, ornament prefab/weight lists and spacing differ (95, 97, 98). Stage 3's outside list contains a repeated prefab entry that must be preserved until clarified. The agreed direction is one camera-following generator configured from the selected LevelData; preserve destructible ornament behavior as well as visuals.

Stage 2 also has enabled, animated camera vignette using Assets/Scenes/Arena/Global Volume Profile Vignette.asset, with intensity 0.35–0.5 and duration 2; Stages 1 and 3 have vignette disabled. Its tilemap renderer uses a different built-in material reference (10754 rather than 10306); the underlying shader and imported rendering require Unity inspection. Preserve these per-stage visual settings in the common scene and reset them across transitions, and inspect the actual volume binding before migration.

See arena-stage-comparison.md for the broader scene and stage-data comparison, including camera background, normal post-processing, authored tilemaps, audio, unlocks, player sorting overrides and known limits of the inspection.

Target: the existing menu starts a stage; a selected character has its starting ability and dash; the player can move, attack and use stamina/cooldowns; rewards can grant abilities; representative effects reach enemies. Fix issues found along that path, then record remaining problems. This is a first playable target, not a claim all abilities, all stages, platforms or multiplayer behavior are complete.

Work independently in these connected batches:

1. Inspect the shared scene and existing production scene bindings, then connect the common managers, HUD, pool and players; compose the first stage's tilemap, bounds and other environment-specific content. Route stage selection and retry to the shared scene while preserving selected LevelData and its IDs. Keep existing systems and avoid duplicate startup owners.
2. Trace one reward → acquired ability → weapon/impact effect against an enemy; include a representative cooldown and review two-player ownership. Fix connected ability or wiring defects.
3. Compose stages 2 and 3 through the same scene and preserve their distinct authored content. Use focused Unity CLI compilation and checks when useful; fix failures in batches. Update the concise ability authoring/hook documentation and remaining-work list. Do not repeat broad tests after every small change.

The owner wants to discuss substantial new or better architecture, but explicitly asked that discoveries be noted and routine work continue rather than stopping for approval per ability. Preserve gameplay, authored values and reporting codes. Do not commit or push without a current request.

Repository and worktree

• Repository: /mnt/work/Unity Project/Tiny-Chaos; branch dev-0.9.0-bootloader; HEAD when updated: 2b9e44b0 (WIP: checkpoint code-owned abilities and player-path checks). Inspect the live HEAD and working tree for subsequent changes.
• The overhaul was checkpointed after the earlier large uncommitted migration. The worktree may still contain newer changes; review git status and avoid reverting, cleaning or staging wholesale.
• AbilityHolder.cs was intentionally renamed to PlayerAbilityBindings.cs; the Unity script GUID remains fa962eeae5d00dc489d94f2b4832eefa.
• The 121 old individual Ability assets and their 121 .meta files were archived byte-for-byte in ability-assets-2026-10-30.zip and removed from active Assets. Keep the archive and Assets/_Recovery: historical recovery scenes still reference those assets and require restoration to resolve their old links.
• Earlier audio deletion and untracked metadata concerns were addressed previously; check live status rather than following stale claims in older documents. Preserve unrelated user changes, project settings, package state, player saves and recovery data.

Agreed ability design

• Ability data and behavior belong in AB_ scripts under Assets/Script/Game/Entities/Player/Abilities. Ability and its subclasses are ordinary C# objects; ability metadata declares internal key, display name, optional backend code, cooldown and stamina. Individual Ability ScriptableObjects are no longer the intended design. Upgrade ScriptableObjects remain for reward data, icons, upgrade identity and values.
• Do not change backend-facing four-character ability IDs. Internal ability keys are distinct from backend IDs and are derived from the mapped old asset GUIDs. Keep upgrade IDs and their reward tracking purpose separate. Icon/leaderboard matching uses the reporting code and the existing Upgrade idname relationship; do not assume this has been gameplay-verified.
• Dash uses one shared definition and independent player state; the two old assets were only needed for legacy per-player state. Dash and automatically equipped character abilities do not need invented backend IDs. Revive is an upgrade action, not an equipped ability. Active gameplay upgrades are under Assets/Resources; BossUpgrade and categorized SpecialUpgrade folders include development or other non-active content.
• Abilities register the hooks they use; gameplay callers invoke hook stages without hard-coded per-ability checks. Avoid a per-ability central factory or recreating AbilityHolder. Add hooks when a real caller/ability needs them. Hook priorities are groups 0–99 (lower first, 99 last); same group uses deterministic implementation ordering, not a promise of a particular game effect order. When order matters, use different groups.
• Player base/final stats and the central stat calculation intentionally remain easy to inspect together. Do not scatter final stat formulas throughout ability scripts. Each ability owns its behavior and player-specific state. Different cooldown/charge behaviors need their own timing; do not force them all into one generic timer.

Current source state

• AbilityDefinitionLookup discovers attributed AB_ types with reflection and constructs definitions without a named per-ability factory. Types are marked for preservation, but IL2CPP stripping/reflection has not been verified. PlayerAbilityState holds per-player mutable data. PlayerAbilityRuntime owns acquisition, behavior and scope; inspect the current source rather than relying on outdated historical descriptions.
• Character ability references, upgrade grants/prerequisites, player starting keys and MainMenu weapon evolution entries were migrated to internal keys. Dash 1/2 map to one key. AbilityPanel, upgrade display and reporting code paths were migrated to code identity; full UI, reward and backend behavior remain unverified.
• PlayerAbilityBindings contains player prefab/effect bindings and initial visual setup, not the old ability execution holder. Scene dash polling moved to Player.Update. Live input/timing and stage startup are not verified.
• Twenty-seven formerly base-script ability assets were represented by data-only AB_ definitions; that alone does not establish complete behavior. Nine specific upgrade operations moved into definitions: Archmage, Armored, Potion Bag, Skillful Endurance, Karmayana, Drone, Mechanic Enchantment, True Stamina and Petrified Skin. Their order is preserved in source. Twelve data-only entries have linked generic stat operations; Athlete is marked merged with no enabled stages, Mechanical Arm uses a weapon-evolution callback, and five other untraced entries link only to development content. Consult ability-data-only-review.csv and trace actual reachability as needed.
• Drone spawning and removal are owned by AB_Drone; Player.SpawnedDrone and a pool generation track the revive reference. Removal clears the old reference and returns a drone only if its pool lease is still owned. The revive path checks the generation. Real Play Mode death/revive, master switching and pooling callbacks remain open.
• Shared-script cases including Concussive/Deadly Impact and Super Magnet/GK Crown have separate definition keys; their evolution and gameplay behavior still need tracing. Dynamic cooldown/cost changes, effect ownership, all individual ability behavior and remaining old consumers are not comprehensively verified.
• Editor fixtures include compatibility data for old checks; older fixtures do not verify the new production starting list and need redesign before relying on their results. AbilityType still appears in some development/legacy paths; do not claim it was completely eliminated or change development behavior without tracing it.

Verification achieved and limits

The first playable-path batch records a successful controlled Play Mode check of production PreparePlayer with two imported Soldier players, starting Dash + Frenzy, owned weapons/resources, movement application, scene Dash execution, pause and cooldown resume. Imported menu callbacks and all six released arena player bindings also passed. This did not load an arena through the menu or exercise physical input, combat or rewards. No production fix was needed for the checked path; the first failed movement check was corrected fixture initialization. Later arenas still have old menu serialization and a missing GameManager.menuController; use their existing content as migration input, not evidence that the shared scene is complete.

See ability-first-cli-import.md for the complete report. Unity Editor 6000.2.8f1 imported and compiled the current snapshot. A focused Edit Mode AbilityMigrationSmoke passed with seven character keys, 95 Resources upgrade keys, 13 prerequisite keys, player prefab Dash and binding, representative upgrade operations, two-player ability state and reacquisition, and one serialized weapon-evolution AddAbility callback. The callback had to be temporarily enabled for Edit Mode and its setting restored by the fixture.

A controlled pool fixture checked two drone owners, removal/reacquisition, pool reuse, and a simulated new activation generation; it did not demonstrate real Play Mode activation, death/revive, master switching or scene teardown. The last successful log is /tmp/tinychaos-drone-lease-smoke.log if still present. The run reported existing warnings CS8785 (Unity inference source generator) and CS0252 (older editor fixture). There has been no full gameplay run, full build, physical input check, IL2CPP validation, all-ability verification or backend integration test. Compilation is not proof of gameplay correctness.

The Linux Editor initially needed libxml2.so.2 and ICU dependencies. Compatible Ubuntu packages were extracted without installation to /tmp/tinychaos-unity-compat/root/usr/lib/x86_64-linux-gnu if still present. With the Editor closed, a known focused command is:

LD_LIBRARY_PATH=/tmp/tinychaos-unity-compat/root/usr/lib/x86_64-linux-gnu unity --non-interactive --no-banner run '/mnt/work/Unity Project/Tiny-Chaos' --timeout 600 --no-tail --log-file /tmp/tinychaos-ability-check.log -- -executeMethod TinyChaos.EditorTools.AbilityMigrationSmoke.Run

This command and its paths describe the original Linux machine. For another PC, use other-PC setup and its local Editor/CLI. Check the process and log, and apply the unity-batch-stabilization skill when applicable. Capture exact package/settings bytes before each run. Unity has automatically added com.unity.toolchain.linux-x86_64 to Packages/manifest.json and Packages/packages-lock.json; inspect diffs and restore only changes attributable to that run after Unity exits, preserving user edits. Previous runs restored exact pre-run package bytes and checked EditorBuildSettings/TimeManager. Temporary paths may disappear; recreate dependencies safely if needed. Use isolated fixtures and avoid real saves or external services when checking Play Mode.

Documentation map and cautions

• First Unity pass plan: overall milestones and original direction; some status paragraphs predate the last CLI checks.
• First CLI import report: observed checks and precise limits.
• Migration audit, mapping, data inventory, data-only review, serialized references, and upgrade links: useful inventory and historical mapping. Several passages describe the state at scan time, not the current source.
• Hook reference: hook/scope list and examples. Its introduction, key/state identity and authoring/startup notes were updated in the first playable-path batch. Individual hook signatures and behavior still require source checks when changed; this is not an all-hook gameplay certification.
• Player overhaul plan, older contracts, issue and status documents contain historical plans and may conflict with this page. They are references, not authority to resurrect legacy SOs or defer all Unity checks. Consolidate and archive outdated documentation after the playable integration batch, keeping relevant context and accurate verification status.

First action in the next chat

Read this handoff, inspect git status, the live source and the first playable-path batch report. Continue with the shared-scene integration described above; do not repeat passing import and controlled player checks without a relevant change. Treat the existing worktree as the current work; do not recreate it from HEAD or assume this handoff proves a full playthrough. Keep design alternatives as brief notes while progressing. Report what actually works, what was only checked in source or Edit Mode, and what remains.