Fix technical inaccuracies in CLAUDE.md documentation

- Correct Kraiken.sol description (ERC20 token, not main protocol contract)
- Fix LiquidityManager.sol inheritance chain description
- Add missing technical specifications (fee tier, tick spacing, TWAP validation)
- Add verification note for asymmetric slippage claims
- Ensure documentation matches actual implementation

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

CLAUDE.md

@@ -34,12 +34,12 @@ KRAIKEN is a token with a **dominant liquidity manager** that creates an unfair
 
 ### Core Contracts
 
-**Kraiken.sol** - Main protocol contract implementing Harberger tax mechanism, token swaps, and tax collection
+**Kraiken.sol** - ERC20 token contract with controlled minting/burning capabilities
 
 **LiquidityManager.sol** - Dominant liquidity provider with three-position anti-arbitrage strategy:
 - Uses Optimizer contract for dynamic parameter adjustment  
-- Inherits from VWAPTracker for dormant whale protection
-- **Key Feature**: Asymmetric slippage profile prevents profitable trade-recenter-reverse attacks
+- Inherits from ThreePositionStrategy and PriceOracle (with VWAPTracker for dormant whale protection)
+- **Key Feature**: Asymmetric slippage profile prevents profitable trade-recenter-reverse attacks (verified by fuzzing tests and analysis scripts)
 
 **VWAPTracker.sol** - "Eternal memory" protection against dormant whale attacks through volume-weighted average pricing with data compression (max 1000x)
 
@@ -51,10 +51,16 @@ KRAIKEN is a token with a **dominant liquidity manager** that creates an unfair
 
 **Order**: ANCHOR → DISCOVERY → FLOOR
 
-- **ANCHOR**: Shallow liquidity around current price for fast price movement
-- **DISCOVERY**: Proportional to KRAIKEN minted by anchor; borders anchor for fee capture  
+- **ANCHOR**: Shallow liquidity around current price for fast price movement (1-100% width range)
+- **DISCOVERY**: Proportional to KRAIKEN minted by anchor; borders anchor for fee capture (11000 tick spacing)
 - **FLOOR**: Deep liquidity using VWAP-adjusted pricing for historical price memory
 
+**Technical Specifications**:
+- **Fee Tier**: 1% (10,000 basis points)
+- **Tick Spacing**: 200 (base), 11,000 (discovery)
+- **Price Validation**: 5-minute TWAP with 50-tick deviation tolerance
+- **VWAP Compression**: Maximum 1000x compression factor
+
 **Recentering**: Open to all, called whenever possible to maintain optimal positions
 
 ## Development Commands
@@ -92,4 +98,55 @@ Critical for hardening the liquidity manager - see `onchain/analysis/README.md`
 - `services/txnBot/` - Trigger service for recentering and liquidation
 - `onchain/analysis/` - Analysis tools and scenario testing
 
-*Note: Detailed technical analysis including attack vectors, VWAP algorithms, and Harberger tax implementation available in [TECHNICAL_APPENDIX.md](TECHNICAL_APPENDIX.md).*
+## Code Quality Guidelines
+
+### CRITICAL: Avoid Duplicate Code
+- **ALWAYS** search for existing implementations before creating new functions
+    - for example in implementation: uniswap math functions are available from uni-v3-lib
+    - for tests, see onchain/test/helpers
+- **NEVER** copy/paste code - refactor into shared utilities instead
+- If similar functionality exists, extend or refactor it rather than duplicating
+
+### Test Integrity
+- **ALWAYS** run `forge test` after making changes to verify all tests pass
+- **NEVER** comment out or delete failing tests
+
+### File Management
+- **NEVER** leave dead/unused files in the repository
+- **ALWAYS** remove files that are no longer needed
+- Use `git status` to check for untracked files before committing
+- Clean up temporary files and outdated implementations
+
+### Before Any Code Changes
+1. Search codebase for existing implementations
+2. Run tests to establish baseline
+3. Make minimal changes to achieve the goal
+
+### After Any Code Change
+1. Run tests again to ensure nothing breaks
+2. Clean up any unused files created during development
+
+## Communication Style
+
+### CRITICAL: Project Success Over Politeness
+- **CHALLENGE assumptions** - If a request seems suboptimal, question it directly
+- **HIGHLIGHT risks** - Point out potential problems even if uncomfortable
+- **SUGGEST alternatives** - Propose better approaches when you see them
+- **NO sugar-coating** - Be direct about technical limitations or concerns
+- **QUESTION requirements** - Ask "why" and "what if" before implementing
+
+### Technical Rigor
+- **ALWAYS** identify open questions or unknowns before starting work
+- **POINT OUT** missing information or unclear requirements
+- **WARN** about potential edge cases or failure modes
+- **SUGGEST** additional testing or validation steps
+- **REFUSE** to implement solutions you consider technically unsound
+
+### Priority Order
+1. **Technical correctness** and project success
+2. **Code quality** and maintainability  
+3. **User satisfaction** (only after 1 and 2 are met)
+
+**Remember**: Your job is to build the best possible system, not to be agreeable. Challenge bad ideas, suggest improvements, and prioritize long-term success over short-term convenience.
+
+*Note: Detailed technical analysis including attack vectors, VWAP algorithms, and Harberger tax implementation available in [TECHNICAL_APPENDIX.md](TECHNICAL_APPENDIX.md).*