- New IRON-CLAD RULE: Always search docs before making suggestions or asking questions
- Purpose: Prevent wasting user time with already-answered questions
- Examples: TradingView rate limits, roadmap features, known bugs, configuration
- Workflow: Read request → Search docs → Check if answered → THEN respond
- Applies to: Features, bugs, config, architecture, deployment, troubleshooting
- Red flags: User says 'we already documented this' or 'check docs first'
- Why: User spent months documenting comprehensively, 'NOTHING gets lost' principle
- Impact: Respect user's documentation effort, save time = save money in financial system
Files modified:
- .github/copilot-instructions.md (line ~103-150, added Rule #5 with examples and workflow)
- Added explicit onboarding workflow at top of file
- 4-step sequence: copilot-instructions → docs/README → README → explore
- Lists all 8 documentation subdirectories with descriptions
- Emphasizes 'NOTHING gets lost' principle
- Ensures new agents have clear entry point without manual explanation
- Pitfall #68: Smart Entry using webhook percentage as signal price
* Root cause: TradingView webhook price field contained percentage (70.80) instead of market price (42.50)
* Impact: 97% pullback calculations made Smart Entry impossible to trigger
* Fix: Use Pyth current price instead of webhook price
* Commit: 7d0d38a
- Pitfall #69: Direction-specific leverage thresholds not explicit
* Made LONG/SHORT leverage assignment explicit even though values same
* Improves code clarity and maintainability
* Commit: 58f812f
Both fixes deployed Dec 3, 2025, 09:02:45 CET (timestamp verified)
Bug: 23 duplicate Telegram notifications with P&L compounding (-7.96 to -,129.24)
Cause: Multiple monitoring loops passed has() check before any deleted from Map
Fix: Use Map.delete() atomic return value as deduplication lock
Result: First caller deletes and proceeds, subsequent callers return immediately
Related: #48-49 (TP1 P&L compound), #59-61 (external closure duplicates)
Deployed: Dec 2, 2025 17:32:52 UTC (commit 93dd950)
Bug: Multiple monitoring loops detect ghost simultaneously
- Loop 1: has(tradeId) → true → proceeds
- Loop 2: has(tradeId) → true → ALSO proceeds (race condition)
- Both send Telegram notifications with compounding P&L
Real incident (Dec 2, 2025):
- Manual SHORT at $138.84
- 23 duplicate notifications
- P&L compounded: -$47.96 → -$1,129.24 (23× accumulation)
- Database shows single trade with final compounded value
Fix: Map.delete() returns true if key existed, false if already removed
- Call delete() FIRST
- Check return value
proceeds
- All other loops get false → skip immediately
- Atomic operation prevents race condition
Pattern: This is variant of Common Pitfalls #48, #49, #59, #60, #61
- All had "check then delete" pattern
- All vulnerable to async timing issues
- Solution: "delete then check" pattern
- Map.delete() is synchronous and atomic
Files changed:
- lib/trading/position-manager.ts lines 390-410
Related: DUPLICATE PREVENTED message was working but too late
CRITICAL UPDATES to AI assistant instructions:
1. MANDATORY GIT WORKFLOW (DO NOT SKIP):
- Added explicit requirement: implement → test → verify → document → commit → push
- Made git commits NON-OPTIONAL for all significant changes
- Added to both general prompt and copilot-instructions.md
- Rationale: Agent has pattern of skipping documentation/commits
2. CHALLENGE USER IDEAS:
- Added requirement to think critically about user requests
- Instruction: "Think freely and don't hold back"
- Goal: Find BEST solution, not just A solution
- Push back on ideas that don't make sense
- Ask "is there a simpler/faster/safer way?"
3. COMPREHENSIVE DOCUMENTATION SECTION:
- Replaced brief documentation note with full workflow guide
- Added 80+ lines of detailed documentation requirements
- Includes examples, red flags, mindset principles
- Emphasizes: "Git commit + Documentation = Complete work"
Files modified:
- .github/prompts/general prompt.prompt.md (added sections 5a, 6, updated 7-8)
- .github/copilot-instructions.md (comprehensive documentation workflow)
User mandate: "I am sick and tired of reminding you" - this makes it automatic.
Impact: Future implementations will ALWAYS include documentation and git commits as part of standard workflow, not as afterthoughts.
- ProxyJump (-J) doesn't work from Docker container
- Changed to nested SSH: hop -> target
- Proper command escaping for nested SSH
- Worker2 (srv-bd-host01) only accessible via worker1 (pve-nu-monitor01)
- Created /api/cluster/logs endpoint to read coordinator.log
- Added real-time log display in cluster UI (updates every 3s)
- Shows last 100 lines of coordinator.log in terminal-style display
- Includes manual refresh button
- Improves debugging experience - no need to SSH for logs
User feedback: 'why dont we add the output of the log at the bottom of the page so i know whats going on'
This addresses poor visibility into coordinator errors and failures.
Next step: Fix SSH timeout issue blocking worker execution.
USER MANDATE (Dec 1, 2025): Documentation MUST go hand-in-hand with EVERY git commit.
This is NOT optional. This is NOT a suggestion. This is MANDATORY.
Changes:
- Elevated documentation section to #1 PRIORITY status
- Added user's direct quote: 'this HAS to go hand in hand'
- Expanded from 15 lines to 100+ lines with comprehensive guidelines
- Added 'Why This is #1 Priority' section with user's frustration quote
- Added explicit 'When Documentation is MANDATORY' checklist
- Added 'The Correct Mindset' section emphasizing it's part of the work
- Added 4 scenario examples showing what MUST be documented
- Added 'Red Flags' section to catch missing documentation
- Added 'Integration with Existing Sections' guide
- Made it crystal clear: Code without documentation = INCOMPLETE WORK
This addresses user's repeated reminders about documentation being mandatory.
Future AI agents will now see this as the #1 priority it is.
NO MORE PUSHING CODE WITHOUT DOCUMENTATION UPDATES.
- Document database-first architecture pattern
- Include problem, root cause, and solution details
- Add verification methodology with before/after examples
- Document cluster control system (Start/Stop buttons)
- Include database schema and operational state
- Add lessons learned about infrastructure vs business logic
- Reference STATUS_DETECTION_FIX_COMPLETE.md for full details
- Current state: 2 workers active, processing 4000 combinations
- Removed v10 TradingView indicator (moneyline_v10_momentum_dots.pinescript)
- Removed v10 penalty system from signal-quality.ts (-30/-25 point penalties)
- Removed backtest result files (sweep_*.csv)
- Updated copilot-instructions.md to remove v10 references
- Simplified direction-specific quality thresholds (LONG 90+, SHORT 80+)
Rationale:
- 1,944 parameter combinations tested in backtest
- All top results IDENTICAL (568 trades, $498 P&L, 61.09% WR)
- Momentum parameters had ZERO impact on trade selection
- Profit factor 1.027 too low (barely profitable after fees)
- Max drawdown -$1,270 vs +$498 profit = terrible risk-reward
- v10 penalties were blocking good trades (bug: applied to wrong positions)
Keeping v9 as production system - simpler, proven, effective.
- Bug: Execute endpoint calculated quality but never validated it
- Three trades executed at quality 30/50/50 (threshold: 90/95)
- All three stopped out, confirming low quality = losing trades
- Root cause: TradingView sent incomplete data (metrics=0, old v5) + missing validation after timeframe check
- Fix: Added validation block lines 193-213 in execute/route.ts
- Returns HTTP 400 if quality < minQualityScore
- Deployed: Nov 27, 2025 23:16 UTC (commit cefa3e6)
- Lesson: Calculate ≠ Validate - minQualityScore must be enforced at ALL execution pathways
This documents the CRITICAL FIX from commit cefa3e6.
Per Nov 27 mandatory documentation rules, work is INCOMPLETE without copilot-instructions.md updates.
CRITICAL: Added iron-clad rule that copilot-instructions.md MUST be updated
for every significant change. User is 'sick and tired' of reminding.
New mandatory section explains:
- When to update this file (8 specific scenarios)
- Why it's the primary knowledge base for future developers
- Automatic workflow: Change → Code → Test → Update Docs → Commit
1-Minute Data Collection documented:
- Direction field is meaningless (TradingView artifact)
- Analysis should ignore direction for timeframe='1'
- Focus on ADX/ATR/RSI/volume/price position metrics
- Example correct vs wrong SQL queries
This is NON-NEGOTIABLE going forward.
- Position Manager section: Complete Phase 7.3 documentation with real-time ADX queries
- Documented adaptive multiplier logic: acceleration bonus, deceleration penalty, combined 3.16× max
- Added example calculation showing 2.15× wider trail vs old static system
- When Making Changes section: Added Phase 7.3 verification steps and log monitoring
- Trailing stop changes: Updated with new adaptive system details and testing procedures
- References: PHASE_7.3_ADAPTIVE_TRAILING_DEPLOYED.md and 1MIN_DATA_ENHANCEMENTS_ROADMAP.md
PROBLEM: Rebuilding container 4-6 times per session when most changes don't need it
- Every rebuild: 40-70 seconds downtime
- Recent session: 200 seconds downtime that could've been 50 seconds
- Rebuilding for documentation (should be git only)
- Rebuilding for n8n workflows (should be manual import)
- Rebuilding for ENV changes (should be restart only)
SOLUTION: Created comprehensive guide on what actually needs rebuilds
ZERO DOWNTIME (just commit):
- Documentation (.md files)
- Workflows (.json, .pinescript)
- Hot-reload endpoints (roadmap reload)
RESTART ONLY (5-10 seconds):
- ENV variable changes (.env)
- Database schema (prisma migrate + generate)
REBUILD REQUIRED (40-70 seconds):
- Code changes (.ts, .tsx, .js)
- Dependencies (package.json)
- Dockerfile changes
SMART BATCHING:
- Group multiple code changes into ONE rebuild
- Example: 6 fixes → 1 rebuild = 50s total (not 6× rebuilds = 300s)
CREATED FILES:
- docs/ZERO_DOWNTIME_CHANGES.md (comprehensive guide with examples)
- Updated copilot-instructions.md (quick decision matrix)
EXPECTED IMPACT:
- 60-80% reduction in rebuild frequency
- 60-80% reduction in downtime per session
- Better workflow: batch changes, test together, deploy once
User was right: We were rebuilding WAY too often unnecessarily ✅
Updated Indicator Version Tracking section:
- Changed v8 from PRODUCTION to ARCHIVED (Nov 18-26)
- Added v9 as new PRODUCTION SYSTEM (Nov 26+)
- Documented v9 momentum-based SHORT filter (ADX + Price Position)
- Removed RSI filter rationale (RSI 50+ has best 68.2% WR)
- Added data evidence from 95 SHORT trade analysis
- Documented first day results: 2 losses, both blocked by momentum filter
Updated Stop Hunt Revenge System section:
- Added 'Revenge Timing Enhancement - 90s Confirmation' subsection
- Documented Nov 26 retest problem (would stop at $137.50 before $144.50 move)
- Explained Option 2 approach (90s = 1.5 minutes confirmation)
- Added implementation code snippets from stop-hunt-tracker.ts
- User insight: ATR not suitable (measures volatility, not S/R)
- Status: DEPLOYED Nov 26, 20:52:55 CET, VERIFIED
Related commits:
- 2017cba: v9 SHORT quality improvements - momentum-based filtering
- 40ddac5: Revenge timing Option 2 - 90s confirmation (DEPLOYED)
- Multi-Timeframe section: Added Nov 26 implementation note
- Quality scoring now calculated for ALL timeframes (not just 5min)
- Data collection signals get real quality scores (not hardcoded 0)
- BlockedSignal records include full quality metadata
- Enables SQL: WHERE signalQualityScore >= minScoreRequired
- Execute Trade workflow: Added timeframe routing logic
- When Making Changes: Added item #19 for multi-timeframe updates
- Reflects implementation in commit dbada47
- Complete architecture overview with ASCII diagram
- Database replication configuration and verification
- DNS failover monitor details (systemd service)
- Automatic failover sequence explanation
- Live test results from Nov 25, 2025 (90s detection, 0s downtime)
- Critical operational notes (firewall, ports, health checks)
- Manual failover and secondary update procedures
- Documentation references (DEPLOY_SECONDARY_MANUAL.md, HA_SETUP_ROADMAP.md)
- When making changes guidance for HA environment
Status: PRODUCTION READY ✅
All phases tested and validated with zero-downtime failover/failback
Created comprehensive agent prompt emphasizing:
- Mandatory reading of full copilot-instructions.md (4,400+ lines)
- VERIFICATION MANDATE must be understood before any work
- This is a real money system - every bug costs money
- Never declare 'done/fixed/working' without 100% verification
- Proper workflow: read → code → deploy → verify → document
Key Requirements:
- Check container timestamp > commit timestamp before declaring deployed
- Add logging to confirm changes execute
- Test in production with real data
- Check Common Pitfalls (60+ documented bugs) before coding
- Show verification results as proof, not just code appearance
Financial Stakes:
- User building from $901 → $100,000+ with this system
- Manual restarts = system failure
- Unverified changes = financial risk
- Every change affects real money positions
Prompt ensures agents understand the verification ethos and financial responsibility before starting any work.
REAL MONEY SYSTEM - NO EXCEPTIONS ON VERIFICATION
Changes:
- Moved VERIFICATION MANDATE to very top of copilot-instructions.md
- Added clear visual separators with ⚠️ and 🚨 emojis
- Made it unmissable: Must be read before any other instructions
- Added explicit definition of what 'working' means vs does NOT mean
- Emphasized: Deployment ≠ Working without verification
Added concrete example (Nov 25, 2025 Health Monitor Bug):
- What went wrong: Declared 'working' without testing
- What should have been done: Add logging, test API, verify errors recorded
- Lesson: Never trust code appearance, always verify with real data
Why this matters:
- User building from $901 → $100,000+ with this system
- Every unverified change is financial risk
- This is not a hobby project - it's user's financial future
- Declaring something working without proof = causing financial loss
Development Ethos:
- NEVER say done/finished without testing
- NEVER skip verification for 'simple' changes
- ALWAYS double-check new development for 100% functionality
- Code appearance ≠ Code correctness
- Deployment ≠ Feature working
This is mandatory for all AI agents working on this codebase.
User Request: Distinguish between SL and Trailing SL in analytics overview
Changes:
1. Position Manager:
- Updated ExitResult interface to include 'TRAILING_SL' exit reason
- Modified trailing stop exit (line 1457) to use 'TRAILING_SL' instead of 'SL'
- Enhanced external closure detection (line 937) to identify trailing stops
- Updated handleManualClosure to detect trailing SL at price target
2. Database:
- Updated UpdateTradeExitParams interface to accept 'TRAILING_SL'
3. Frontend Analytics:
- Updated last trade display to show 'Trailing SL' with special formatting
- Purple background/border for TRAILING_SL vs blue for regular SL
- Runner emoji (🏃) prefix for trailing stops
Impact:
- Users can now see when trades exit via trailing stop vs regular SL
- Better understanding of runner system performance
- Trailing stops visually distinct in analytics dashboard
Files Modified:
- lib/trading/position-manager.ts (4 locations)
- lib/database/trades.ts (UpdateTradeExitParams interface)
- app/analytics/page.tsx (exit reason display)
- .github/copilot-instructions.md (Common Pitfalls #61, #62)
- Added Adaptive Leverage System section in Architecture Overview
- Documented quality-based leverage tiers (95+ = 15x, 90-94 = 10x)
- Added configuration details and helper function usage
- Updated Configuration System with adaptive leverage integration
- Modified Execute Trade workflow to show early quality calculation
- Added critical execution order note (quality MUST be calculated before sizing)
- Added item #13 in When Making Changes section for adaptive leverage modifications
- Fixed numbering sequence (was duplicate 11s, now sequential 1-18)
- Cross-referenced ADAPTIVE_LEVERAGE_SYSTEM.md for complete details
Documented Nov 23, 2025 bug where monitoring loop created array snapshot
before async processing, causing removed trades to be processed twice.
Real incident:
- Trade cmibdii4k0004pe07nzfmturo (manual closure)
- 97% size reduction detected
- First iteration removed trade from Map
- Second iteration processed stale reference
- Result: Duplicate Telegram notifications
Fix: Added activeTrades.has() guard at start of checkTradeConditions()
Prevents duplicate processing when trade removed during loop iteration
Also documented:
- Quality threshold .env discrepancy (81 vs 91)
- Settings UI restart requirement
- Why Next.js modules need container restart for env changes
Related to Common Pitfall #59 (Layer 2 ghost detection duplicates)
but different trigger - normal monitoring vs rate limit storm detection
Updates to copilot-instructions.md:
- Multi-Timeframe Price Tracking System section enhanced
- BlockedSignalTracker purpose clarified: validates quality 91 threshold
- Current Status updated with Nov 22 enhancement details
- First false negative result documented (quality 80, +0.52% missed profit)
Signal Quality Scoring section:
- Added 'Threshold Validation In Progress' subsection
- User observation documented: 'green dots shot up'
- Data collection criteria defined (20-30 blocked signals)
- Decision framework added: Keep 91 vs lower to 85 vs adjust weights
- Possible outcomes listed for data-driven optimization
Next Steps:
- Continue collecting quality-blocked signal data (2-4 weeks)
- Target: 20-30 signals with complete price tracking
- SQL analysis: Compare blocked signal win rate vs executed trades
- Decision: Validate quality 91 threshold or adjust based on data
Purpose: Complete documentation of missed opportunity discovery and
validation plan for quality threshold optimization.
