Asked Claude to add lessons learned while solving these days to CLAUDE.md.

Author: shnako

CLAUDE.md

@@ -24,7 +24,7 @@ When the user says "Let's do day X" or similar, and the AOC_SESSION_COOKIE envir
 13. **Update test file**: Add both answers to SolutionTest.kt
 14. **Update README**: Add the day's entry to the main README
 15. **Create PR**: Branch, commit, and create a pull request
-16. **MANDATORY: Wait for PR comments**: Wait 5 minutes for CodeRabbit and CI checks, then address all feedback
+16. **MANDATORY: Wait for PR comments**: Wait 3 minutes for CodeRabbit and CI checks, then address all feedback
 17. **MANDATORY: Address PR feedback**: Fix any failing builds and implement actionable suggestions
 18. **MANDATORY: Merge the PR**: After addressing feedback, wait for CI to complete and then merge the PR using `gh pr merge --squash --delete-branch`  
 
@@ -33,7 +33,7 @@ When the user says "Let's do day X" or similar, and the AOC_SESSION_COOKIE envir
 - **input.txt contains your personal puzzle input** (different for each user)
 - **Always submit immediately** when you have an answer (don't wait for user confirmation)
 - **Continue to Part 2 automatically** after Part 1 is confirmed correct
-- **Handle wrong answers**: If an answer is wrong, debug and try again
+- **Handle wrong answers**: If an answer is wrong, debug and try again (common causes: off-by-one errors, parsing issues, misunderstood requirements)
 - **Complete the entire day**: Don't stop until both parts are solved and committed
 
 ### Note on Input Files:
@@ -113,6 +113,11 @@ When I ask you to prepare for a problem, move back to the main branch, pull the
 - The comment should explain both the problem context and the solution approach for each part
 - Use `/* */` multi-line comments, not `//` single-line comments for the header
 - Prefer readability to clever one-liners. The goal is that even people relatively new to the language and programming in general should easily understand it
+- **Performance considerations**: For computationally intensive problems, consider:
+  - Memoization/caching for recursive solutions
+  - Early termination conditions
+  - Efficient data structures (Set vs List for lookups)
+  - Avoiding unnecessary string concatenation in loops
 
 ## Debugging Help
 If a solution isn't working:
@@ -134,7 +139,7 @@ When AOC_SESSION_COOKIE is set and user says "Let's do day X":
 1. Update the README.md with the day's entry (without being asked)
 2. Create a new branch for the day's solution
 3. Create a pull request for the day's work
-4. **MANDATORY**: Wait 5 minutes for CodeRabbit and CI checks to complete
+4. **MANDATORY**: Wait 3 minutes for CodeRabbit and CI checks to complete
 5. **MANDATORY**: Address all PR feedback (fix failures, implement suggestions)
 6. **MANDATORY**: After fixes are pushed and CI passes, MERGE THE PR using `gh pr merge --squash --delete-branch`
 
@@ -144,14 +149,14 @@ When AOC_SESSION_COOKIE is set and user says "Let's do day X":
 ## Pull request interaction
 The repo has CodeRabbit installed, which will review PRs and suggest improvements.
 After creating a PR, you MUST:
-1. **Wait 5 minutes** to allow CodeRabbit and other CI checks to complete
+1. **Wait 3 minutes** to allow CodeRabbit and other CI checks to complete
 2. **Check for PR comments** using `gh pr view <PR_NUMBER> --comments`
 3. **Check build status** using `gh pr view <PR_NUMBER> --json statusCheckRollup`
 4. **Address ALL actionable comments** and fix any failing builds
 5. **Commit and push improvements** once implemented
 6. **Update your TodoList** to track PR feedback resolution
 7. **CRITICAL**: Before merging, ensure ALL CI checks pass (validate and test workflows)
-8. **Wait for another 5 minutes after final changes** to ensure CI checks complete
+8. **Wait for another 3 minutes after final changes** to ensure CI checks complete
 9. **Only merge when ALL builds are green** - never merge with failing builds
 
 **IMPORTANT**: This is NOT optional - every PR must have its feedback addressed AND all builds passing before the day is considered complete.
@@ -166,4 +171,38 @@ The validation CI workflow checks puzzle.txt files for specific formatting requi
 4. **Last line**: Must be exactly "Both parts of this puzzle are complete! They provide two gold stars: **"
 5. **Line endings**: Use Unix line endings (LF) not Windows (CRLF) to ensure validation passes
 
-**CRITICAL**: If validation fails, check the puzzle.txt format and ensure the completion footer is added correctly.
+**CRITICAL**: If validation fails, check the puzzle.txt format and ensure the completion footer is added correctly.
+
+## Tool Usage Guidelines
+- **TodoWrite**: Use proactively for complex multi-step tasks (3+ steps) to track progress and demonstrate thoroughness
+- **Task**: Use for open-ended searches requiring multiple rounds of file operations
+- **Read/Edit**: Prefer for specific file operations over Task tool when you know the exact files
+- **Batch operations**: Use multiple tool calls in single message for better performance
+
+## Error Handling & Recovery
+Common issues and solutions:
+- **CI failures**: Wait for builds to complete, check logs, fix validation issues first
+- **Submission errors**: Verify answer format (no spaces, correct type), check for off-by-one errors
+- **Network timeouts**: Retry operations, use shorter timeout values for testing
+- **Git conflicts**: Pull latest changes, resolve conflicts, recommit changes
+- **Performance issues**: Add early termination, use efficient algorithms (BFS vs DFS), consider problem constraints
+
+## Common Problem Patterns & Solutions
+Based on Advent of Code 2024 experience:
+- **Grid traversal**: Use coordinate systems, direction vectors, boundary checking
+- **Path finding**: BFS for shortest path, DFS for all paths, A* for heuristic search  
+- **Graph problems**: Build adjacency lists, use visited sets, consider bidirectional search
+- **Parsing**: Split input carefully, handle edge cases, validate assumptions
+- **Mathematics**: Look for patterns, use modular arithmetic, consider mathematical properties
+- **Optimization**: Branch and bound, greedy algorithms, dynamic programming
+- **Simulation**: Step-by-step execution, state tracking, cycle detection
+
+## Success Metrics
+A day is considered successfully completed when:
+1. Both parts produce correct answers
+2. Code is clean, readable, and well-commented
+3. All tests pass
+4. CI builds are green (validate + test workflows)
+5. PR has been created, reviewed, and merged
+6. README is updated with the day's entry
+7. All CodeRabbit feedback has been addressed