Task 3: Step 2 complete - plan sub-tasks for bug fixes
Build and Publish Mana Loop Docker Image / build-and-publish (push) Successful in 6m42s

This commit is contained in:
Refactoring Agent
2026-04-27 10:53:08 +02:00
parent 5f1f72d892
commit 06778f96b3
22 changed files with 508 additions and 0 deletions
+103
View File
@@ -0,0 +1,103 @@
You are a senior Next.js developer working on the Mana Loop game located at
/home/user/repos/Mana-Loop.
## Step 1 — Orient yourself
Read docs/task3.md and docs/task3_progress.md to understand the current task
and what has already been completed. Do not redo completed work.
## Step 2 — Plan sub-tasks
Before writing any code, break the work below into sub-task files at
docs/task3/subtask_N.md (one per logical unit). Each file must include:
- Scope (which files/components are affected)
- Acceptance criteria (how to verify the fix is correct)
- Dependencies on other sub-tasks (so parallel agents don't conflict)
Create a matching docs/task3/subtask_N_progress.md for each sub-task and
keep it updated as work proceeds. Use a top-level docs/task3/todo.md to
track overall progress.
## Step 3 — Execute sub-tasks
Use parallel sub-agents for independent sub-tasks. Sub-tasks that touch the
same component must run sequentially. After each sub-task, update its
progress file and the top-level todo.md.
---
## Bug fixes to implement
### UI / Combat
1. [SpireModeUI] Floor health display does not update reactively when health
changes — it should reflect the current value after every spell cast.
2. [SpireModeUI] "Climb Down" button exits the spire immediately. It should
instead trigger floor-by-floor combat downward, and only allow the player
to exit once they have reached and cleared the bottom floor.
3. [SpireTab] Current Floor stat is always the bottom floor from the player's
perspective at this tab — making it misleading. Redesign this as a "Spire
Stats" view and move ClimbSpireButton here. Move the activity log into
SpireModeUI instead.
4. [DebugTab] Causes a crash — investigate the error, fix the root cause, and
verify the tab renders without errors.
5. [Header] Remove the pause button from the header row.
### Equipment & Crafting
6. [EquipmentTab] When a 2-handed staff is equipped, the offhand slot should
be visibly disabled/occupied so the player cannot equip anything there.
7. [CraftingTab — Design phase] Only show enchantments compatible with items
the player currently owns.
8. [CraftingTab — Prepare & Apply phases] Consolidate disenchanting into the
Prepare step:
- The button should read "Start Preparation — this will remove existing
enchantments" when the item has existing enchantments.
- Once prepared, the item receives a "Ready for Enchantment" tag.
- The Apply phase should only allow applying enchantments to items tagged
"Ready for Enchantment".
### Skills & Mana
9. [SkillsTab] Replace the "Elemental Attunement" skill with per-mana-type
capacity upgrades. Each upgrade should cost mana of its own type to
research.
10. [Mana system] Mana conversion rates (from attunements) should be deducted
from the raw mana regeneration rate. Example: 3.8 raw regen 0.2
transference conversion = 3.6 effective raw regen.
11. [SkillsTab] "Effect Research" enchantment skills (listed under Effect
Research) should cost both Transference mana and the relevant elemental
mana type (e.g. Fire Spell Research costs Transference + Fire).
12. [SkillsTab] Move all skills in the "Research" category to the "Mana"
category. Move "Meditation Focus" from "Study" to "Mana" as well.
13. [SkillsTab] Remove the "Disenchanting" skill entirely.
### Stats
14. [StatsTab] Add a clear breakdown of each mana type, showing: current
value, capacity, regen rate, and any modifiers affecting them (attunements,
conversion drains, etc.).
### Investigation tasks (produce a written finding, then fix or flag)
15. [Essence Refining] Verify whether this effect works correctly across all
enchantment types. Document which enchantment types it cannot apply to
(e.g. spell enchantments) and either fix those cases or flag them as
out-of-scope with a clear explanation.
---
## Step 4 — UI audit (run after all bugs above are resolved)
Do a full pass of the UI for polish issues and UX inconsistencies. Write your
findings to docs/task3/ui_audit_report.md with sections:
- Visual inconsistencies
- UX friction points
- Missing feedback / empty states
- Suggested improvements (with priority: high / medium / low)
## Step 5 — Effects & skills audit
Scan all effects, skills, and enchantments for logic that is broken,
incomplete, or never triggers. Write findings to
docs/task3/effects_audit_report.md in the same format.
+25
View File
@@ -0,0 +1,25 @@
# Sub-Task 1: Spire UI Fixes (Bugs 1, 2, 3)
## Scope
- **Components affected**:
- `components/SpireModeUI.tsx` (Floor health display, Climb Down button, activity log)
- `components/SpireTab.tsx` (Redesign as Spire Stats, move ClimbSpireButton here)
- Spire state management (hooks/context for spire floor tracking, health, combat state)
- **Files potentially affected**:
- `store/spireSlice.ts` or similar state management for spire
- `types/spire.ts` if type definitions need updates
## Acceptance Criteria
1. **Bug 1**: Floor health display in SpireModeUI updates reactively after every spell cast (verify by casting spells in spire and observing health change immediately)
2. **Bug 2**: "Climb Down" button triggers floor-by-floor combat downward; player can only exit spire after reaching and clearing bottom floor (verify by climbing down multiple floors, confirm exit only at bottom)
3. **Bug 3**:
- SpireTab redesigned as "Spire Stats" view (no longer shows misleading Current Floor stat)
- ClimbSpireButton moved from SpireModeUI to SpireTab
- Activity log moved from SpireTab to SpireModeUI
4. No regressions in other spire functionality
## Dependencies
- None (can be executed first)
## Estimated Complexity
- Medium (3 linked UI components + state management)
+24
View File
@@ -0,0 +1,24 @@
# Sub-Task 10: Essence Refining Investigation (Bug 15)
## Scope
- **Core files to investigate**:
- Essence Refining effect logic (e.g., `effects/essenceRefining.ts` or similar)
- All enchantment type definitions (e.g., `data/enchantments.ts`, `types/enchantments.ts`)
- Enchantment application logic (to check compatibility)
- **Files potentially affected**:
- Any enchantment type that Essence Refining cannot apply to (fix or flag)
- Documentation for Essence Refining effect
## Acceptance Criteria
1. Verify Essence Refining effect works across all enchantment types
2. Document which enchantment types it cannot apply to (e.g., spell enchantments)
3. Either:
- Fix cases where it should apply but doesn't, OR
- Flag out-of-scope cases with clear explanation
4. Write findings to `docs/task3/essence_refining_findings.md`
## Dependencies
- None (independent investigation task)
## Estimated Complexity
- Medium (testing multiple enchantment types + documentation)
+15
View File
@@ -0,0 +1,15 @@
# Sub-Task 10 Progress: Essence Refining Investigation
## Status: Pending
## Completed Steps
- [ ] Locate Essence Refining effect logic
- [ ] List all enchantment types in the game
- [ ] Test Essence Refining on each enchantment type
- [ ] Document compatible/incompatible types
- [ ] Fix or flag incompatible cases
- [ ] Write findings to essence_refining_findings.md
- [ ] Commit and push changes
## Notes
(Add test results here)
+14
View File
@@ -0,0 +1,14 @@
# Sub-Task 1 Progress: Spire UI Fixes
## Status: Pending
## Completed Steps
- [ ] Read and understand SpireModeUI, SpireTab component code
- [ ] Fix floor health reactivity (Bug 1)
- [ ] Fix Climb Down button behavior (Bug 2)
- [ ] Redesign SpireTab, move ClimbSpireButton and activity log (Bug 3)
- [ ] Test all changes
- [ ] Commit and push changes
## Notes
(Add notes as work proceeds)
+19
View File
@@ -0,0 +1,19 @@
# Sub-Task 2: DebugTab Crash Fix (Bug 4)
## Scope
- **Components affected**:
- `components/DebugTab.tsx` (root cause of crash)
- Potentially related debug utilities or data fetching hooks used by DebugTab
- **Files potentially affected**:
- Any imports or dependencies used by DebugTab (e.g., debug data sources, formatting utilities)
## Acceptance Criteria
1. DebugTab no longer causes a crash (verify by navigating to DebugTab in the UI)
2. DebugTab renders all intended content without errors in browser console
3. Root cause of crash is identified and fixed (e.g., null reference, missing data, syntax error)
## Dependencies
- None (independent sub-task)
## Estimated Complexity
- Low-Medium (depends on crash root cause)
+13
View File
@@ -0,0 +1,13 @@
# Sub-Task 2 Progress: DebugTab Crash Fix
## Status: Pending
## Completed Steps
- [ ] Reproduce DebugTab crash and check browser/console errors
- [ ] Identify root cause of crash
- [ ] Implement fix
- [ ] Test DebugTab renders without errors
- [ ] Commit and push changes
## Notes
(Add crash details and fix notes here)
+20
View File
@@ -0,0 +1,20 @@
# Sub-Task 3: Header Pause Button Removal (Bug 5)
## Scope
- **Components affected**:
- `components/Header.tsx` (remove pause button from header row)
- Potentially header-related styles or layout components
- **Files potentially affected**:
- `components/layout/Header.tsx` if header is nested
- Style files (CSS/SCSS/Tailwind) related to header if button styles need cleanup
## Acceptance Criteria
1. Pause button is completely removed from the header row (verify visually in UI)
2. No broken layout or spacing issues in header after removal
3. No references to removed pause button remain in code (check for unused imports/handlers)
## Dependencies
- None (independent sub-task)
## Estimated Complexity
- Low (simple component removal)
+13
View File
@@ -0,0 +1,13 @@
# Sub-Task 3 Progress: Header Pause Button Removal
## Status: Pending
## Completed Steps
- [ ] Locate pause button in Header component
- [ ] Remove pause button and related code
- [ ] Clean up unused imports/handlers
- [ ] Verify header layout is intact
- [ ] Commit and push changes
## Notes
(Add details here)
+22
View File
@@ -0,0 +1,22 @@
# Sub-Task 4: EquipmentTab 2H Offhand Disable (Bug 6)
## Scope
- **Components affected**:
- `components/EquipmentTab.tsx` (offhand slot logic)
- Equipment slot rendering components (e.g., `EquipmentSlot.tsx`)
- Item type checking logic (to detect 2-handed weapons)
- **Files potentially affected**:
- `types/items.ts` (item type definitions for 2-handed weapons)
- `store/equipmentSlice.ts` or similar state management for equipment
- `utils/itemUtils.ts` for item type helper functions
## Acceptance Criteria
1. When a 2-handed staff (or any 2-handed weapon) is equipped in mainhand, offhand slot is visibly disabled/occupied (verify visually: grayed out, tooltip indicating why)
2. Player cannot equip any item in offhand while 2-handed weapon is equipped (verify via UI and state checks)
3. Equipping a 2-handed weapon automatically clears any existing offhand item (if required by game logic)
## Dependencies
- None (independent sub-task)
## Estimated Complexity
- Medium (item type logic + UI state management)
+14
View File
@@ -0,0 +1,14 @@
# Sub-Task 4 Progress: EquipmentTab 2H Offhand Disable
## Status: Pending
## Completed Steps
- [ ] Understand current equipment slot logic
- [ ] Implement 2-handed weapon check
- [ ] Disable offhand slot UI when 2H weapon equipped
- [ ] Prevent offhand equipping via state logic
- [ ] Test with 2H staff and other weapons
- [ ] Commit and push changes
## Notes
(Add details here)
+22
View File
@@ -0,0 +1,22 @@
# Sub-Task 5: CraftingTab Design Phase Compatibility (Bug 7)
## Scope
- **Components affected**:
- `components/CraftingTab.tsx` (Design phase section)
- Enchantment data sources (e.g., `data/enchantments.ts`)
- Player inventory state (to check owned items)
- **Files potentially affected**:
- `utils/craftingUtils.ts` (enchantment compatibility logic)
- `types/crafting.ts` (enchantment-item compatibility types)
- `store/inventorySlice.ts` or similar for player item data
## Acceptance Criteria
1. In CraftingTab Design phase, only enchantments compatible with items the player currently owns are shown (verify by checking UI with different inventory states)
2. Compatibility is determined by enchantment type (e.g., weapon enchantments only show if player owns weapons)
3. No performance issues when filtering enchantments
## Dependencies
- None (independent, but Sub-Task 6 depends on this if modifying same CraftingTab file)
## Estimated Complexity
- Medium (data filtering + UI update)
+13
View File
@@ -0,0 +1,13 @@
# Sub-Task 5 Progress: CraftingTab Design Phase Compatibility
## Status: Pending
## Completed Steps
- [ ] Understand CraftingTab Design phase logic
- [ ] Implement enchantment compatibility filtering
- [ ] Test with various player inventory states
- [ ] Verify only compatible enchantments shown
- [ ] Commit and push changes
## Notes
(Add details here)
+23
View File
@@ -0,0 +1,23 @@
# Sub-Task 6: CraftingTab Prepare/Apply Disenchant Consolidation (Bug 8)
## Scope
- **Components affected**:
- `components/CraftingTab.tsx` (Prepare and Apply phases)
- Item state management (add "Ready for Enchantment" tag)
- Enchantment removal logic (disenchanting during Prepare step)
- **Files potentially affected**:
- `store/craftingSlice.ts` or similar for crafting state
- `types/items.ts` (add "Ready for Enchantment" tag to item types)
- `utils/craftingUtils.ts` (disenchant logic, tag management)
## Acceptance Criteria
1. **Prepare step button text**: Shows "Start Preparation — this will remove existing enchantments" when item has existing enchantments; otherwise default text
2. **Prepare step outcome**: After successful preparation, item receives "Ready for Enchantment" tag (verify via item state/UI)
3. **Apply phase restriction**: Only items tagged "Ready for Enchantment" can have enchantments applied
4. Disenchanting is fully consolidated into Prepare step (no separate disenchant UI)
## Dependencies
- Sub-Task 5 (both modify CraftingTab, must run sequentially)
## Estimated Complexity
- High (multi-phase UI + state management + tagging)
+15
View File
@@ -0,0 +1,15 @@
# Sub-Task 6 Progress: CraftingTab Prepare/Apply Disenchant Consolidation
## Status: Pending
## Completed Steps
- [ ] Review Sub-Task 5 completion (ensure no conflicts)
- [ ] Implement Prepare step button text logic
- [ ] Add "Ready for Enchantment" tag to item state
- [ ] Restrict Apply phase to tagged items
- [ ] Consolidate disenchanting into Prepare step
- [ ] Test full Design-Prepare-Apply flow
- [ ] Commit and push changes
## Notes
(Add details here)
+26
View File
@@ -0,0 +1,26 @@
# Sub-Task 7: SkillsTab Modifications (Bugs 9, 11, 12, 13)
## Scope
- **Components affected**:
- `components/SkillsTab.tsx` (all skill-related UI)
- Skill data definitions (e.g., `data/skills.ts`)
- Skill category logic (Research, Mana, Study categories)
- Skill cost calculation logic
- **Files potentially affected**:
- `types/skills.ts` (skill type definitions, categories)
- `store/skillsSlice.ts` or similar for skill state
- `utils/skillUtils.ts` (cost calculation, category checks)
- Mana system files (for per-mana capacity upgrades in Bug 9)
## Acceptance Criteria
1. **Bug 9**: "Elemental Attunement" skill replaced with per-mana-type capacity upgrades; each upgrade costs mana of its own type to research
2. **Bug 11**: "Effect Research" enchantment skills cost both Transference mana and relevant elemental mana (e.g., Fire Spell Research costs Transference + Fire)
3. **Bug 12**: All skills in "Research" category moved to "Mana" category; "Meditation Focus" moved from "Study" to "Mana"
4. **Bug 13**: "Disenchanting" skill completely removed from SkillsTab
5. No broken skill UI or missing skills after changes
## Dependencies
- None (independent, but all skill changes are sequential within this sub-task)
## Estimated Complexity
- High (multiple skill system changes + UI updates)
+15
View File
@@ -0,0 +1,15 @@
# Sub-Task 7 Progress: SkillsTab Modifications
## Status: Pending
## Completed Steps
- [ ] Understand current skill data structure and SkillsTab UI
- [ ] Remove "Elemental Attunement" skill, add per-mana capacity upgrades (Bug 9)
- [ ] Update Effect Research skill costs (Bug 11)
- [ ] Move Research category skills to Mana, Meditation Focus to Mana (Bug 12)
- [ ] Remove "Disenchanting" skill (Bug 13)
- [ ] Test all skill changes in UI
- [ ] Commit and push changes
## Notes
(Add details here)
+23
View File
@@ -0,0 +1,23 @@
# Sub-Task 8: Mana System Conversion Regen Deduction (Bug 10)
## Scope
- **Core files affected**:
- Mana system logic (e.g., `utils/manaUtils.ts`, `hooks/useMana.ts`)
- Mana regeneration calculation functions
- Mana state management (e.g., `store/manaSlice.ts`)
- **Files potentially affected**:
- `types/mana.ts` (mana type definitions, conversion rates)
- Any components displaying mana regen rates (to show effective vs raw regen)
- StatsTab (will be updated in Sub-Task 9 to show conversion drains)
## Acceptance Criteria
1. Mana conversion rates (from attunements) are deducted from raw mana regeneration rate
2. Example: 3.8 raw regen 0.2 transference conversion = 3.6 effective raw regen (verify via calculation checks)
3. Effective regen is used for all mana regeneration in-game
4. Conversion drains are properly tracked and available for UI display (needed for Sub-Task 9)
## Dependencies
- None (independent, but Sub-Task 9 depends on this)
## Estimated Complexity
- Medium (mana calculation logic update)
+14
View File
@@ -0,0 +1,14 @@
# Sub-Task 8 Progress: Mana System Conversion Regen Deduction
## Status: Pending
## Completed Steps
- [ ] Understand current mana regen calculation logic
- [ ] Implement conversion rate deduction from raw regen
- [ ] Verify calculation with example values
- [ ] Update any UI elements showing regen rates (if needed)
- [ ] Test mana regen in-game
- [ ] Commit and push changes
## Notes
(Add calculation details here)
+25
View File
@@ -0,0 +1,25 @@
# Sub-Task 9: StatsTab Mana Breakdown (Bug 14)
## Scope
- **Components affected**:
- `components/StatsTab.tsx` (add mana breakdown section)
- Mana system data (current value, capacity, regen rate, modifiers)
- **Files potentially affected**:
- `utils/manaUtils.ts` (export mana breakdown data)
- `store/manaSlice.ts` (provide modifiers like attunements, conversion drains)
- `types/stats.ts` (if stats types need updates)
## Acceptance Criteria
1. StatsTab shows clear breakdown for each mana type including:
- Current value
- Capacity
- Regen rate (effective, after conversion deductions from Bug 10)
- Modifiers affecting them (attunements, conversion drains, etc.)
2. Breakdown is visually clear and easy to read
3. Data updates reactively when mana state changes
## Dependencies
- Sub-Task 8 (requires conversion drain data from Bug 10 fix)
## Estimated Complexity
- Medium (UI update + data integration)
+14
View File
@@ -0,0 +1,14 @@
# Sub-Task 9 Progress: StatsTab Mana Breakdown
## Status: Pending
## Completed Steps
- [ ] Review Sub-Task 8 completion (get conversion drain data)
- [ ] Design mana breakdown UI for StatsTab
- [ ] Implement data fetching for each mana type's stats
- [ ] Add modifiers display (attunements, conversion drains)
- [ ] Test reactive updates
- [ ] Commit and push changes
## Notes
(Add UI design notes here)
+36
View File
@@ -0,0 +1,36 @@
# Task 3 Progress Tracker
## Overall Status: Planning Complete, Ready for Execution
---
## Sub-Tasks
| ID | Sub-Task | Status | Dependencies | Assigned |
|----|----------|--------|--------------|----------|
| 1 | Spire UI Fixes (Bugs 1,2,3) | Pending | None | |
| 2 | DebugTab Crash Fix (Bug4) | Pending | None | |
| 3 | Header Pause Button Removal (Bug5) | Pending | None | |
| 4 | EquipmentTab 2H Offhand Disable (Bug6) | Pending | None | |
| 5 | CraftingTab Design Phase Compatibility (Bug7) | Pending | None | |
| 6 | CraftingTab Prepare/Apply Disenchant Consolidation (Bug8) | Pending | Sub-Task 5 | |
| 7 | SkillsTab Modifications (Bugs9,11,12,13) | Pending | None | |
| 8 | Mana System Conversion Regen Deduction (Bug10) | Pending | None | |
| 9 | StatsTab Mana Breakdown (Bug14) | Pending | Sub-Task 8 | |
| 10 | Essence Refining Investigation (Bug15) | Pending | None | |
---
## Completed Work
- [x] Step 1: Oriented with task3.md
- [x] Step 2: Sub-tasks planned and documented
- [ ] Step 3: Sub-tasks executed
- [ ] Step 4: UI Audit completed
- [ ] Step 5: Effects & Skills Audit completed
---
## Notes
- Sub-tasks that touch the same component run sequentially
- Independent sub-tasks can be executed in parallel via sub-agents
- Update progress files after each sub-task completion