Implement Dashboard consolidation + Performance logging

Features:
- Add unified "Dashboard Complet" sheet (Excel) with all 9 sections
- Add unified "Dashboard Complet" page (PDF) with key metrics
- Fix VALOARE_ANTERIOARA NULL bug (use sumar_executiv_yoy directly)
- Add PerformanceLogger class for timing analysis
- Remove redundant consolidated sheets (keep only Dashboard Complet)

Bug fixes:
- Fix Excel formula error (=== interpreted as formula, changed to >>>)
- Fix args.output → args.output_dir in perf.summary()

Performance analysis:
- Add PERFORMANCE_ANALYSIS.md with detailed breakdown
- SQL queries take 94% of runtime (31 min), Excel/PDF only 1%
- Identified slow queries for optimization

Documentation:
- Update CLAUDE.md with new structure
- Add context handover for query optimization task

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

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

.claude/agents/feature-planner.md

@@ -0,0 +1,57 @@
+---
+name: feature-planner
+description: Use this agent when you need to plan the implementation of a new feature for the ROA2WEB project. Examples: <example>Context: User wants to add a new reporting dashboard feature to the FastAPI/Vue.js application. user: 'I need to add a user activity dashboard that shows login history and report generation statistics' assistant: 'I'll use the feature-planner agent to analyze the current codebase and create a comprehensive implementation plan.' <commentary>Since the user is requesting a new feature plan, use the feature-planner agent to analyze the current project structure and create a detailed implementation strategy.</commentary></example> <example>Context: User wants to implement real-time notifications in the application. user: 'We need to add real-time notifications when reports are ready for download' assistant: 'Let me use the feature-planner agent to examine the current architecture and design an efficient notification system.' <commentary>The user is requesting a new feature implementation, so use the feature-planner agent to create a comprehensive plan.</commentary></example>
+model: opus
+color: purple
+---
+
+You are an expert software architect and senior full-stack engineer specializing in FastAPI and Vue.js applications. Your expertise lies in analyzing existing codebases and designing minimal-impact, maximum-effect feature implementations. You use KISS principle. You propose the best and most popular technologies/frameworks/libraries. Use tool context7 for the documentation. 
+
+When tasked with planning a new feature, you will:
+
+1. **Codebase Analysis Phase**:
+   - Examine the current project structure in the roa2web/ directory
+   - Identify existing patterns, architectural decisions, and coding standards
+   - Map out current database schema usage (CONTAFIN_ORACLE)
+   - Analyze existing API endpoints, Vue components, and shared utilities
+   - Identify reusable components and services that can be leveraged
+
+2. **Impact Assessment**:
+   - Determine which files need modification vs. creation
+   - Identify potential breaking changes or conflicts
+   - Assess database schema changes required
+   - Evaluate impact on existing authentication and user management
+   - Consider SSH tunnel and Oracle database constraints
+
+3. **Implementation Strategy**:
+   - Design the feature using existing architectural patterns
+   - Prioritize modifications to existing files over new file creation
+   - Plan database changes that work with the CONTAFIN_ORACLE schema
+   - Design API endpoints following existing FastAPI patterns
+   - Plan Vue.js components that integrate with current frontend structure
+   - Consider testing strategy using the existing pytest setup
+
+4. **Detailed Planning Document**:
+   Create a comprehensive markdown file with:
+   - Executive summary of the feature and its benefits
+   - Technical requirements and constraints
+   - Step-by-step implementation plan with file-by-file changes
+   - Database schema modifications (if any)
+   - API endpoint specifications
+   - Frontend component structure
+   - Testing approach
+   - Deployment considerations
+   - Risk assessment and mitigation strategies
+   - Timeline estimates for each phase
+
+5. **Optimization Principles**:
+   - Leverage existing code patterns and utilities
+   - Minimize new dependencies
+   - Ensure backward compatibility
+   - Follow the principle of least modification for maximum effect
+   - Consider performance implications
+   - Plan for scalability within the current architecture
+
+Always save your comprehensive plan as a markdown file with a descriptive name like 'feature-[feature-name]-implementation-plan.md' in the appropriate directory. The plan should be detailed enough for any developer to implement the feature following your specifications.
+
+Before starting, ask clarifying questions about the feature requirements if anything is unclear. Focus on creating a plan that integrates seamlessly with the existing ROA2WEB FastAPI/Vue.js architecture.

.claude/commands/branch-plan-handover.md

@@ -0,0 +1,5 @@
+Create a new branch, save the detailed implementation plan to a markdown file for context handover to another session, then stop.
+
+1. **Create new branch** with descriptive name based on current task
+2. **Save the implementation plan** you created earlier in this session to a markdown file in the project root
+3. **Stop execution** - do not commit anything, just prepare the context for handover to another session

.claude/commands/context-handover.md

@@ -0,0 +1,8 @@
+Save detailed context about the current problem to a markdown file for handover to another session due to context limit reached.
+
+1. **Create context handover file** in project root: `CONTEXT_HANDOVER_[TIMESTAMP].md`
+2. **Document the current problem** being worked on with all relevant details and analysis
+3. **Include current progress** - what has been discovered, analyzed, or attempted so far
+4. **List key files examined** and their relevance to the problem
+5. **Save current state** - todos, findings, next steps, and any constraints
+6. **Stop execution** - context is now ready for a fresh session to continue the work

.claude/commands/plan-handover.md

@@ -0,0 +1,4 @@
+Save the detailed implementation plan to a markdown file for context handover to another session, then stop.
+
+1. **Save the implementation plan** you created earlier in this session to a markdown file in the project root
+2. **Stop execution** - do not commit anything, just prepare the context for handover to another session

.claude/commands/session-current.md

@@ -0,0 +1,12 @@
+Show the current session status by:
+
+1. Check if `.claude/sessions/.current-session` exists
+2. If no active session, inform user and suggest starting one
+3. If active session exists:
+   - Show session name and filename
+   - Calculate and show duration since start
+   - Show last few updates
+   - Show current goals/tasks
+   - Remind user of available commands
+
+Keep the output concise and informative.

.claude/commands/session-end.md

@@ -0,0 +1,30 @@
+End the current development session by:
+
+1. Check `.claude/sessions/.current-session` for the active session
+2. If no active session, inform user there's nothing to end
+3. If session exists, append a comprehensive summary including:
+   - Session duration
+   - Git summary:
+     * Total files changed (added/modified/deleted)
+     * List all changed files with change type
+     * Number of commits made (if any)
+     * Final git status
+   - Todo summary:
+     * Total tasks completed/remaining
+     * List all completed tasks
+     * List any incomplete tasks with status
+   - Key accomplishments
+   - All features implemented
+   - Problems encountered and solutions
+   - Breaking changes or important findings
+   - Dependencies added/removed
+   - Configuration changes
+   - Deployment steps taken
+   - Lessons learned
+   - What wasn't completed
+   - Tips for future developers
+
+4. Empty the `.claude/sessions/.current-session` file (don't remove it, just clear its contents)
+5. Inform user the session has been documented
+
+The summary should be thorough enough that another developer (or AI) can understand everything that happened without reading the entire session.

.claude/commands/session-help.md

@@ -0,0 +1,37 @@
+Show help for the session management system:
+
+## Session Management Commands
+
+The session system helps document development work for future reference.
+
+### Available Commands:
+
+- `/project:session-start [name]` - Start a new session with optional name
+- `/project:session-update [notes]` - Add notes to current session  
+- `/project:session-end` - End session with comprehensive summary
+- `/project:session-list` - List all session files
+- `/project:session-current` - Show current session status
+- `/project:session-help` - Show this help
+
+### How It Works:
+
+1. Sessions are markdown files in `.claude/sessions/`
+2. Files use `YYYY-MM-DD-HHMM-name.md` format
+3. Only one session can be active at a time
+4. Sessions track progress, issues, solutions, and learnings
+
+### Best Practices:
+
+- Start a session when beginning significant work
+- Update regularly with important changes or findings
+- End with thorough summary for future reference
+- Review past sessions before starting similar work
+
+### Example Workflow:
+
+```
+/project:session-start refactor-auth
+/project:session-update Added Google OAuth restriction
+/project:session-update Fixed Next.js 15 params Promise issue  
+/project:session-end
+```

.claude/commands/session-list.md

@@ -0,0 +1,13 @@
+List all development sessions by:
+
+1. Check if `.claude/sessions/` directory exists
+2. List all `.md` files (excluding hidden files and `.current-session`)
+3. For each session file:
+   - Show the filename
+   - Extract and show the session title
+   - Show the date/time
+   - Show first few lines of the overview if available
+4. If `.claude/sessions/.current-session` exists, highlight which session is currently active
+5. Sort by most recent first
+
+Present in a clean, readable format.

.claude/commands/session-start.md

@@ -0,0 +1,13 @@
+Start a new development session by creating a session file in `.claude/sessions/` with the format `YYYY-MM-DD-HHMM-$ARGUMENTS.md` (or just `YYYY-MM-DD-HHMM.md` if no name provided).
+
+The session file should begin with:
+1. Session name and timestamp as the title
+2. Session overview section with start time
+3. Goals section (ask user for goals if not clear)
+4. Empty progress section ready for updates
+
+After creating the file, create or update `.claude/sessions/.current-session` to track the active session filename.
+
+Confirm the session has started and remind the user they can:
+- Update it with `/project:session-update`
+- End it with `/project:session-end`

.claude/commands/session-update.md

@@ -0,0 +1,37 @@
+Update the current development session by:
+
+1. Check if `.claude/sessions/.current-session` exists to find the active session
+2. If no active session, inform user to start one with `/project:session-start`
+3. If session exists, append to the session file with:
+   - Current timestamp
+   - The update: $ARGUMENTS (or if no arguments, summarize recent activities)
+   - Git status summary:
+     * Files added/modified/deleted (from `git status --porcelain`)
+     * Current branch and last commit
+   - Todo list status:
+     * Number of completed/in-progress/pending tasks
+     * List any newly completed tasks
+   - Any issues encountered
+   - Solutions implemented
+   - Code changes made
+
+Keep updates concise but comprehensive for future reference.
+
+Example format:
+```
+### Update - 2025-06-16 12:15 PM
+
+**Summary**: Implemented user authentication
+
+**Git Changes**:
+- Modified: app/middleware.ts, lib/auth.ts
+- Added: app/login/page.tsx
+- Current branch: main (commit: abc123)
+
+**Todo Progress**: 3 completed, 1 in progress, 2 pending
+- ✓ Completed: Set up auth middleware
+- ✓ Completed: Create login page
+- ✓ Completed: Add logout functionality
+
+**Details**: [user's update or automatic summary]
+```

.claude/commands/ultimate_validate_command.md

@@ -0,0 +1,116 @@
+---
+description: Generate comprehensive validation command for this codebase
+---
+
+# Generate Ultimate Validation Command
+
+Analyze this codebase deeply and create `.claude/commands/validate.md` that comprehensively validates everything.
+
+## Step 0: Discover Real User Workflows
+
+**Before analyzing tooling, understand what users ACTUALLY do:**
+
+1. Read workflow documentation:
+   - README.md - Look for "Usage", "Quickstart", "Examples" sections
+   - CLAUDE.md/AGENTS.md or similar - Look for workflow patterns
+   - docs/ folder - User guides, tutorials
+
+2. Identify external integrations:
+   - What CLIs does the app use? (Check Dockerfile for installed tools)
+   - What external APIs does it call? (Telegram, Slack, GitHub, etc.)
+   - What services does it interact with?
+
+3. Extract complete user journeys from docs:
+   - Find examples like "Fix Issue (GitHub):" or "User does X → then Y → then Z"
+   - Each workflow becomes an E2E test scenario
+
+**Critical: Your E2E tests should mirror actual workflows from docs, not just test internal APIs.**
+
+## Step 1: Deep Codebase Analysis
+
+Explore the codebase to understand:
+
+**What validation tools already exist:**
+- Linting config: `.eslintrc*`, `.pylintrc`, `ruff.toml`, etc.
+- Type checking: `tsconfig.json`, `mypy.ini`, etc.
+- Style/formatting: `.prettierrc*`, `black`, `.editorconfig`
+- Unit tests: `jest.config.*`, `pytest.ini`, test directories
+- Package manager scripts: `package.json` scripts, `Makefile`, `pyproject.toml` tools
+
+**What the application does:**
+- Frontend: Routes, pages, components, user flows
+- Backend: API endpoints, authentication, database operations
+- Database: Schema, migrations, models
+- Infrastructure: Docker services, dependencies
+
+**How things are currently tested:**
+- Existing test files and patterns
+- CI/CD workflows (`.github/workflows/`, etc.)
+- Test commands in package.json or scripts
+
+## Step 2: Generate validate.md
+
+Create `.claude/commands/validate.md` with these phases (ONLY include phases that exist in the codebase):
+
+### Phase 1: Linting
+Run the actual linter commands found in the project (e.g., `npm run lint`, `ruff check`, etc.)
+
+### Phase 2: Type Checking
+Run the actual type checker commands found (e.g., `tsc --noEmit`, `mypy .`, etc.)
+
+### Phase 3: Style Checking
+Run the actual formatter check commands found (e.g., `prettier --check`, `black --check`, etc.)
+
+### Phase 4: Unit Testing
+Run the actual test commands found (e.g., `npm test`, `pytest`, etc.)
+
+### Phase 5: End-to-End Testing (BE CREATIVE AND COMPREHENSIVE)
+
+Test COMPLETE user workflows from documentation, not just internal APIs.
+
+**The Three Levels of E2E Testing:**
+
+1. **Internal APIs** (what you might naturally test):
+   - Test adapter endpoints work
+   - Database queries succeed
+   - Commands execute
+
+2. **External Integrations** (what you MUST test):
+   - CLI operations (GitHub CLI create issue/PR, etc.)
+   - Platform APIs (send Telegram message, post Slack message)
+   - Any external services the app depends on
+
+3. **Complete User Journeys** (what gives 100% confidence):
+   - Follow workflows from docs start-to-finish
+   - Example: "User asks bot to fix GitHub issue" → Bot clones repo → Makes changes → Creates PR → Comments on issue
+   - Test like a user would actually use the application in production
+
+**Examples of good vs. bad E2E tests:**
+- ❌ Bad: Tests that `/clone` command stores data in database
+- ✅ Good: Clone repo → Load commands → Execute command → Verify git commit created
+- ✅ Great: Create GitHub issue → Bot receives webhook → Analyzes issue → Creates PR → Comments on issue with PR link
+
+**Approach:**
+- Use Docker for isolated, reproducible testing
+- Create test data/repos/issues as needed
+- Verify outcomes in external systems (GitHub, database, file system)
+- Clean up after tests
+
+## Critical: Don't Stop Until Everything is Validated
+
+**Your job is to create a validation command that leaves NO STONE UNTURNED.**
+
+- Every user workflow from docs should be tested end-to-end
+- Every external integration should be exercised (GitHub CLI, APIs, etc.)
+- Every API endpoint should be hit
+- Every error case should be verified
+- Database integrity should be confirmed
+- The validation should be so thorough that manual testing is completely unnecessary
+
+If /validate passes, the user should have 100% confidence their application works correctly in production. Don't settle for partial coverage - make it comprehensive, creative, and complete.
+
+## Output
+
+Write the generated validation command to `.claude/commands/validate.md`
+
+The command should be executable, practical, and give complete confidence in the codebase.