Add context files for Task 2 sub-agents
Build and Publish Mana Loop Docker Image / build-and-publish (push) Successful in 1m46s
Build and Publish Mana Loop Docker Image / build-and-publish (push) Successful in 1m46s
This commit is contained in:
Refactoring Agent
@@ -0,0 +1,34 @@
|
||||
# Task 2: ActionButtons Rework - Context
|
||||
|
||||
## Task Description
|
||||
**Priority task from task2.md**
|
||||
|
||||
### Requirements:
|
||||
1. **Remove Manual Selection:** Remove buttons that allow players to manually choose their action.
|
||||
2. **Automatic Transition:** Automatically switch the state to 'Meditate' whenever a Study or Crafting task finishes.
|
||||
3. **Status Display:** Replace buttons with a read-only 'Current Activity' indicator.
|
||||
|
||||
### Current Implementation:
|
||||
- ActionButtons component is in `/home/user/repos/Mana-Loop/src/components/game/ActionButtons.tsx`
|
||||
- The component currently shows buttons for: meditate, climb, study, craft, repair, convert, design, prepare, enchant
|
||||
- `currentAction` state comes from the game store
|
||||
- Buttons allow manual selection of actions
|
||||
|
||||
### What Needs To Be Done:
|
||||
1. Read `src/components/game/ActionButtons.tsx` to understand current implementation
|
||||
2. Remove the manual selection buttons (or make them read-only)
|
||||
3. Find where Study and Crafting actions complete (look in store.ts or crafting-slice.ts)
|
||||
4. Add logic to automatically set `currentAction` to 'meditate' when Study or Crafting completes
|
||||
5. Replace buttons with a read-only "Current Activity" indicator showing the current action
|
||||
6. Test the changes
|
||||
7. Commit with message: "Task 2: ActionButtons rework - remove manual selection, auto-transition to Meditate"
|
||||
|
||||
### Key Files To Examine:
|
||||
- `src/components/game/ActionButtons.tsx` - main component to modify
|
||||
- `src/lib/game/store.ts` - likely contains action completion logic
|
||||
- `src/lib/game/crafting-slice.ts` - crafting completion logic
|
||||
|
||||
### Implementation Notes:
|
||||
- Study completes when `studyProgress` finishes
|
||||
- Crafting completes when `preparationProgress` or `enchantProgress` finishes
|
||||
- Need to track these completion events and trigger the Meditate transition
|
||||
@@ -0,0 +1,33 @@
|
||||
# Task 8: Combat UI - Casting Bar Animation Fix - Context
|
||||
|
||||
## Task Description
|
||||
**Bug Fix from task2.md**
|
||||
|
||||
### Problem:
|
||||
The "Casting Bar" progress animation doesn't fill correctly during spell casting.
|
||||
|
||||
### Current Implementation:
|
||||
- Casting bar is likely in a Combat-related component
|
||||
- Search for "CastingBar" or "casting" in components folder
|
||||
- Progress animation probably uses a Progress component or div with width styling
|
||||
|
||||
### What Needs To Be Done:
|
||||
1. Search for "CastingBar" or "casting" in `src/components/game/` to find the relevant component
|
||||
2. Read the component to understand the current implementation
|
||||
3. Find the bug in the progress animation:
|
||||
- Is the progress value being calculated correctly?
|
||||
- Is the CSS/style correct for the progress bar?
|
||||
- Is the animation updating properly?
|
||||
4. Fix the bug so the progress bar fills correctly during casting
|
||||
5. Test the changes
|
||||
6. Commit with message: "Task 2: Fix Combat UI Casting Bar progress animation"
|
||||
|
||||
### Key Files To Examine:
|
||||
- Search for files containing "CastingBar" or "casting" in `src/components/game/`
|
||||
- Look for Progress components or div elements with dynamic width
|
||||
|
||||
### Common Issues To Check:
|
||||
- Progress value calculation (should be percentage 0-100)
|
||||
- CSS transitions/animations
|
||||
- State updates during casting
|
||||
- Re-rendering issues
|
||||
@@ -0,0 +1,44 @@
|
||||
# Task 10: Crafting - Prepare/Design Limits - Context
|
||||
|
||||
## Task Description
|
||||
**From task2.md:** Disable "Prepare" for non-enchanted items; limit "Design" to gear types currently owned.
|
||||
|
||||
## Current Implementation:
|
||||
- Crafting system involves:
|
||||
- `src/components/game/tabs/CraftingTab.tsx` - main crafting UI
|
||||
- `src/components/game/crafting/EnchantmentPreparer.tsx` - Prepare stage
|
||||
- `src/lib/game/crafting-slice.ts` - crafting logic
|
||||
- `currentAction` can be 'design', 'prepare', 'enchant'
|
||||
- "Prepare" stage is for preparing equipment for enchanting
|
||||
|
||||
## What Needs To Be Done:
|
||||
|
||||
### Part 1: Disable "Prepare" for non-enchanted items
|
||||
1. Read `EnchantmentPreparer.tsx` to understand current logic
|
||||
2. Currently shows "Prepare" option for non-enchanted items
|
||||
3. **Clarify**: Does this mean:
|
||||
- Disable the "Prepare" button if the item is NOT enchanted?
|
||||
- Or disable if there are no enchanted items to disenchant?
|
||||
4. Make the appropriate changes to disable "Prepare" based on the requirement
|
||||
|
||||
### Part 2: Limit "Design" to gear types currently owned
|
||||
1. Read `CraftingTab.tsx` to understand the "Design" stage
|
||||
2. Find where gear types are listed for design
|
||||
3. Filter to only show gear types that the player currently owns (has blueprints for)
|
||||
4. This might involve checking `store.lootInventory.blueprints` or similar
|
||||
|
||||
### Final Steps:
|
||||
5. Test the changes
|
||||
6. Commit with message: "Task 2: Crafting - disable Prepare for non-enchanted items, limit Design to owned gear types"
|
||||
|
||||
## Key Files:
|
||||
- `src/components/game/tabs/CraftingTab.tsx` - Design and Prepare stages
|
||||
- `src/components/game/crafting/EnchantmentPreparer.tsx` - Prepare logic
|
||||
- `src/lib/game/crafting-slice.ts` - crafting state management
|
||||
- `src/lib/game/data/equipment.ts` - equipment types definition
|
||||
|
||||
## Implementation Notes:
|
||||
- "Prepare" is the action of preparing equipment for enchanting
|
||||
- Non-enchanted items might refer to items that don't have enchantments yet
|
||||
- "Design" stage lets players design enchantments for gear types
|
||||
- Limit to "owned" gear types = types that the player has blueprints for (in `lootInventory.blueprints`)
|
||||
@@ -0,0 +1,32 @@
|
||||
# Task 5: DebugTab Update - Invoker Debug Buttons - Context
|
||||
|
||||
## Task Description
|
||||
**From task2.md:** Add Invoker Debugging Buttons to manually trigger/force Pacts with different Guardians.
|
||||
|
||||
## Current Implementation:
|
||||
- DebugTab is likely in `/home/user/repos/Mana-Loop/src/components/game/debug/` or similar
|
||||
- Pact system involves Guardians and signing pacts with them
|
||||
- DebugTab already has some debugging features
|
||||
|
||||
## What Needs To Be Done:
|
||||
1. Find the DebugTab component (search for "DebugTab" or look in `src/components/game/debug/`)
|
||||
2. Read the component to understand current implementation
|
||||
3. Find how Pacts work:
|
||||
- Look for "pact" related functions in the store (`store.ts` or similar)
|
||||
- Understand what signing a pact does (what state changes)
|
||||
4. Add buttons to manually trigger/force Pacts with different Guardians:
|
||||
- Each Guardian should have a button
|
||||
- Clicking the button forces a pact with that Guardian
|
||||
5. Test the implementation
|
||||
6. Commit with message: "Task 2: DebugTab Update - add Invoker Debugging Buttons for Pacts"
|
||||
|
||||
## Key Files To Examine:
|
||||
- `src/components/game/debug/` - DebugTab component
|
||||
- `src/lib/game/store.ts` - Pact-related functions
|
||||
- Look for Guardian definitions (maybe in `constants/` or `data/`)
|
||||
|
||||
## Implementation Notes:
|
||||
- Pacts are likely stored in the game state
|
||||
- Forcing a pact might involve calling a function like `store.signPact(guardianId)`
|
||||
- The buttons should be clearly labeled with Guardian names
|
||||
- Consider adding confirmation dialogs to prevent accidental clicks
|
||||
@@ -0,0 +1,29 @@
|
||||
# Task 2: Research Locking in SkillsTab - Context
|
||||
|
||||
## Task Description
|
||||
**From task2.md:** Prevent switching research topics while a study action is in progress in the SkillsTab.
|
||||
|
||||
## Current Implementation:
|
||||
- SkillsTab component is in `/home/user/repos/Mana-Loop/src/components/game/SkillsTab.tsx`
|
||||
- Another version exists at `/home/user/repos/Mana-Loop/src/components/game/tabs/SkillsTab.tsx`
|
||||
- Research topics/skills can be selected for studying
|
||||
- The `currentAction` state in the game store tracks if "study" is in progress
|
||||
|
||||
## What Needs To Be Done:
|
||||
1. Read `src/components/game/SkillsTab.tsx` to understand current implementation
|
||||
2. Find where research topics/skills are selected
|
||||
3. Check if `store.currentAction === 'study'` (study is in progress)
|
||||
4. Disable topic switching/selection while study is in progress
|
||||
5. Show a message like "Cannot switch topics while studying" or disable the UI elements
|
||||
6. Test the changes
|
||||
7. Commit with message: "Task 2: Research Locking - prevent switching topics while study in progress"
|
||||
|
||||
## Key Files:
|
||||
- `src/components/game/SkillsTab.tsx` - main component to modify
|
||||
- `src/lib/game/store.ts` - contains `currentAction` state
|
||||
|
||||
## Implementation Notes:
|
||||
- The study action is started when a skill is selected for study
|
||||
- While `currentAction === 'study'`, the player should not be able to switch to a different research topic
|
||||
- Consider graying out or disabling the skill selection buttons
|
||||
- Show a tooltip or message explaining why switching is disabled
|
||||
@@ -0,0 +1,39 @@
|
||||
# Task 6: System Integrity - Show Component Names Fix - Context
|
||||
|
||||
## Task Description
|
||||
**From task2.md:** Fix the "Show Component Names" debug option. Following the recent refactor, ensure this works for all components. Check for missing `displayName` properties or wrappers that might be masking component identities in the DOM/DevTools.
|
||||
|
||||
## Current Implementation:
|
||||
- "Show Component Names" is in `src/components/game/debug/GameStateDebug.tsx` (line 28)
|
||||
- Uses `useDebug()` hook from `src/lib/game/debug-context.tsx`
|
||||
- `DebugName` wrapper component shows component names visually (yellow label) when enabled
|
||||
- `DebugName` is currently used in `src/app/page.tsx` to wrap major components
|
||||
|
||||
## How It Works:
|
||||
1. `GameStateDebug.tsx` has a Switch for "Show Component Names"
|
||||
2. When enabled, `showComponentNames` becomes true
|
||||
3. `DebugName` wrapper shows a yellow label with the component name
|
||||
4. Components need to be wrapped with `<DebugName name="ComponentName">...</DebugName>`
|
||||
|
||||
## What Needs To Be Done:
|
||||
1. Ensure `DebugName` wrapper is used for ALL components (not just top-level ones in page.tsx)
|
||||
2. Check for missing `displayName` properties on components:
|
||||
- `displayName` helps with React DevTools identification
|
||||
- Components wrapped with `React.memo()`, `React.forwardRef()`, etc. might lose their name
|
||||
- Fix by setting `ComponentName.displayName = "ComponentName"`
|
||||
3. Check for wrappers masking component identities:
|
||||
- Search for `React.memo`, `React.forwardRef`, higher-order components
|
||||
- Ensure `displayName` is set on these
|
||||
4. Test that "Show Component Names" works correctly for all components
|
||||
5. Commit with message: "Task 2: System Integrity - Fix Show Component Names for all components"
|
||||
|
||||
## Key Files:
|
||||
- `src/lib/game/debug-context.tsx` - DebugName component and hook
|
||||
- `src/components/game/debug/GameStateDebug.tsx` - Switch for showing names
|
||||
- `src/app/page.tsx` - Currently uses DebugName for top-level components
|
||||
- Search for `React.memo` and `forwardRef` in `src/components/`
|
||||
|
||||
## Implementation Notes:
|
||||
- The `DebugName` wrapper adds a visual label - this is for the in-game debug view
|
||||
- The `displayName` property is for React DevTools - this is a separate concern
|
||||
- Both should be fixed for full debugging support
|
||||
@@ -0,0 +1,37 @@
|
||||
# Task 3: SpireTab Overhaul - Context
|
||||
|
||||
## Task Description
|
||||
**Feature Rework from task2.md**
|
||||
|
||||
### Requirements:
|
||||
1. **'Climb the Spire':** Create an entry button navigating to a dedicated, locked "Spire Mode."
|
||||
2. **Exit Condition:** Player must "climb down" to exit.
|
||||
3. **Persistent UI:** Only ManaDisplay and CalendarDisplay remain. Display Spire info and Golems.
|
||||
|
||||
### Current Implementation:
|
||||
- SpireTab component is in `/home/user/repos/Mana-Loop/src/components/game/SpireTab.tsx`
|
||||
- Currently shows Spire-related content in the main game UI
|
||||
- Game state/progression managed in `src/lib/game/store.ts`
|
||||
|
||||
### What Needs To Be Done:
|
||||
1. Read `src/components/game/SpireTab.tsx` to understand current implementation
|
||||
2. Create a "Climb the Spire" button that enters a new "Spire Mode"
|
||||
3. Implement Spire Mode as a separate UI state:
|
||||
- Only show ManaDisplay, CalendarDisplay, Spire info, and Golems
|
||||
- Hide all other UI elements
|
||||
4. Add an "Climb Down" button to exit Spire Mode and return to normal game
|
||||
5. The Spire Mode should be "locked" until the player chooses to enter it
|
||||
6. Test the implementation
|
||||
7. Commit with message: "Task 2: SpireTab Overhaul - add Climb the Spire button, implement Spire Mode with exit condition"
|
||||
|
||||
### Key Files To Examine:
|
||||
- `src/components/game/SpireTab.tsx` - main component to modify
|
||||
- `src/components/game/ManaDisplay.tsx` - needs to remain visible in Spire Mode
|
||||
- `src/components/game/CalendarDisplay.tsx` - needs to remain visible in Spire Mode
|
||||
- `src/lib/game/store.ts` - manage Spire Mode state
|
||||
|
||||
### Implementation Notes:
|
||||
- Consider adding a `spireMode: boolean` state to the game store
|
||||
- Spire Mode is a simplified UI - only essential info
|
||||
- "Climb the Spire" button should be in SpireTab
|
||||
- "Climb Down" button should be visible in Spire Mode to exit
|
||||
Reference in New Issue
Block a user