Add Claude Code configuration

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

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

.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/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.

chatbot/infrastructura.md

@@ -0,0 +1,141 @@
+# Infrastructura Chatbot Maria
+
+## Componente
+
+| Componenta | Locație | IP | Port |
+|------------|---------|-----|------|
+| Flowise | LXC 104 | 10.0.20.161 | 3000 |
+| ngrok tunnel | LXC 104 | 10.0.20.161 | - |
+| Pagina chatbot | romfast.ro | - | 443 |
+
+## Configurare Flowise
+
+**Serviciu systemd**: `/etc/systemd/system/flowise.service`
+
+```ini
+[Unit]
+Description=Flowise Service
+After=network.target
+
+[Service]
+User=root
+Group=root
+ExecStart=/usr/bin/npx flowise start
+Restart=always
+Environment=PORT=3000
+Environment=FLOWISE_USERNAME=admin
+Environment=FLOWISE_PASSWORD=parola28
+Environment=CORS_ORIGINS=https://www.romfast.ro,https://romfast.ro
+WorkingDirectory=/root/.flowise
+Environment=FLOWISE_DATABASE_PATH=/root/.flowise/database.sqlite
+
+[Install]
+WantedBy=multi-user.target
+```
+
+**Comenzi utile**:
+```bash
+# Status
+pct exec 104 -- systemctl status flowise
+
+# Restart
+pct exec 104 -- systemctl restart flowise
+
+# Logs
+pct exec 104 -- journalctl -u flowise -f
+```
+
+## Configurare ngrok
+
+**Configurare**: `/root/.config/ngrok/ngrok.yml`
+
+```yaml
+version: "2"
+authtoken: 2mo9quiDc23B6U3TtTqWJEleEfM_jYeD1KYe9u7njaaQMZg2
+tunnels:
+  web:
+    proto: http
+    addr: http://10.0.20.161:3000
+    domain: mutual-special-koala.ngrok-free.app
+```
+
+**Serviciu systemd**: `/etc/systemd/system/ngrok.service`
+
+**URL public**: https://mutual-special-koala.ngrok-free.app
+
+**API endpoint chatbot**:
+```
+POST https://mutual-special-koala.ngrok-free.app/api/v1/prediction/d4911620-07fe-41f8-adb4-f2f52d6ec766
+```
+
+**Comenzi utile**:
+```bash
+# Status
+pct exec 104 -- systemctl status ngrok
+
+# Restart
+pct exec 104 -- systemctl restart ngrok
+
+# Verificare tunel activ
+pct exec 104 -- curl -s http://localhost:4040/api/tunnels
+
+# Verificare versiune
+pct exec 104 -- /usr/local/bin/ngrok --version
+
+# Actualizare ngrok
+pct exec 104 -- /usr/local/bin/ngrok update
+```
+
+## Troubleshooting
+
+### Eroare CORS
+**Simptom**: Browser-ul afișează eroare CORS când se încarcă chatbot-ul.
+
+**Cauza**: Flowise nu are configurată variabila `CORS_ORIGINS`.
+
+**Soluție**: Adaugă în `/etc/systemd/system/flowise.service`:
+```
+Environment=CORS_ORIGINS=https://www.romfast.ro,https://romfast.ro
+```
+Apoi: `systemctl daemon-reload && systemctl restart flowise`
+
+### Eroare ngrok versiune veche (ERR_NGROK_121)
+**Simptom**: În logs apare:
+```
+Your ngrok-agent version "3.16.0" is too old. The minimum supported agent version is "3.19.0"
+```
+
+**Cauza**: ngrok a fost actualizat dar serviciul nu a fost restartat. Procesul vechi continuă să ruleze.
+
+**Soluție**:
+```bash
+# Actualizare (dacă nu e deja făcută)
+pct exec 104 -- /usr/local/bin/ngrok update
+
+# IMPORTANT: Restart după actualizare
+pct exec 104 -- systemctl restart ngrok
+```
+
+### Verificare rapidă că totul funcționează
+```bash
+# Test local Flowise
+pct exec 104 -- curl -s http://localhost:3000/ | head -5
+
+# Test tunel ngrok
+curl -s "https://mutual-special-koala.ngrok-free.app/api/v1/prediction/d4911620-07fe-41f8-adb4-f2f52d6ec766" \
+  -X POST -H "Content-Type: application/json" \
+  -d '{"question":"test"}'
+```
+
+## Pagina web
+
+URL: https://www.romfast.ro/chatbot_maria.html
+
+Pagina încarcă widget-ul Flowise care se conectează la endpoint-ul ngrok.
+
+## Istoric incidente
+
+### 2025-12-30: Chatbot nu funcționa (CORS + ngrok versiune)
+- **Problemă 1**: Flowise nu avea CORS configurat
+- **Problemă 2**: ngrok rula versiunea 3.16.0 (actualizată dar nerestartat din octombrie)
+- **Soluție**: Adăugat CORS_ORIGINS și restart la ambele servicii