flyee 0.1.0

package/core/skills/integration-completeness/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: integration-completeness
+description: Valida que componentes interativos (botões, forms) estão conectados às funções. Previne gaps UI→Function.
+---
+
+# Integration Completeness Validation
+
+> Garantir que componentes interativos estão **conectados** às funções, não apenas existem.
+
+---
+
+## 🎯 PROBLEMA
+
+Testes podem passar verificando:
+- ✅ Botão existe na tela
+- ✅ Função funciona isoladamente
+
+Mas **FALHAM** em verificar:
+- ❌ Clicar no botão chama a função
+
+---
+
+## 🔗 QUANDO USAR?
+
+| Workflow | Fase | Trigger |
+|----------|------|---------|
+| `/new-project` | Phase 5.2 | Após criar componentes UI |
+| `/new-task` | Phase 3.7 | Se feature tem UI interativa |
+| `/execute` | Durante implementação | Para cada componente |
+
+---
+
+## ✅ CHECKLIST DE VALIDAÇÃO
+
+Para **CADA componente interativo**, verificar:
+
+### Botões e Links
+```markdown
+[ ] onClick definido?
+[ ] onClick chama função correta?
+[ ] Função está importada?
+[ ] Teste verifica clique → ação?
+```
+
+### Forms
+```markdown
+[ ] onSubmit definido?
+[ ] onSubmit chama handler?
+[ ] preventDefault chamado?
+[ ] Teste verifica submit → ação?
+```
+
+### Inputs Controlados
+```markdown
+[ ] value ligado a state?
+[ ] onChange atualiza state?
+[ ] Teste verifica input → state?
+```
+
+---
+
+## 🧪 TEMPLATE DE TESTE DE INTEGRAÇÃO
+
+### Botão que chama função
+
+```typescript
+// ❌ INCOMPLETO - só verifica existência
+it('should have a login button', () => {
+    render(<LoginPage />);
+    expect(screen.getByRole('button', { name: /login/i })).toBeInTheDocument();
+});
+
+// ✅ COMPLETO - verifica conexão
+it('should call signIn when login button is clicked', async () => {
+    const mockSignIn = vi.fn();
+    render(<LoginPage onSignIn={mockSignIn} />);
+    
+    await userEvent.click(screen.getByRole('button', { name: /login/i }));
+    
+    expect(mockSignIn).toHaveBeenCalled();
+});
+```
+
+### Form que submete dados
+
+```typescript
+// ❌ INCOMPLETO
+it('should have a submit button', () => {
+    render(<ContactForm />);
+    expect(screen.getByRole('button', { name: /enviar/i })).toBeInTheDocument();
+});
+
+// ✅ COMPLETO
+it('should call onSubmit with form data', async () => {
+    const mockSubmit = vi.fn();
+    render(<ContactForm onSubmit={mockSubmit} />);
+    
+    await userEvent.type(screen.getByLabelText(/email/i), 'test@test.com');
+    await userEvent.click(screen.getByRole('button', { name: /enviar/i }));
+    
+    expect(mockSubmit).toHaveBeenCalledWith({ email: 'test@test.com' });
+});
+```
+
+---
+
+## 🚨 REGRAS CRÍTICAS
+
+### Para Testes
+
+| Tipo de Teste | O que verificar |
+|---------------|-----------------|
+| Existência | Componente renderiza |
+| **Interação** | Clique/submit dispara ação |
+| **Integração** | Ação produz efeito correto |
+
+### Para Implementação
+
+| Componente | Obrigatório |
+|------------|-------------|
+| `<button>` | `onClick` definido |
+| `<a>` | `href` ou `onClick` |
+| `<form>` | `onSubmit` definido |
+| `<input>` | `onChange` se controlado |
+
+---
+
+## 📋 GATE DE VERIFICAÇÃO
+
+Antes de marcar UI como completa:
+
+```markdown
+## Verificação de Integração
+
+### Componentes Interativos
+| Componente | Handler | Função | Teste |
+|------------|---------|--------|-------|
+| Botão Login Google | onClick | signInWithGoogle | ✅/❌ |
+| Botão Login GitHub | onClick | signInWithGitHub | ✅/❌ |
+| Form Newsletter | onSubmit | subscribeNewsletter | ✅/❌ |
+
+### Checklist
+- [ ] TODOS os handlers definidos?
+- [ ] TODOS os handlers têm testes de clique?
+- [ ] ZERO handlers vazios/placeholder?
+```
+
+---
+
+## ⚠️ ANTI-PATTERNS
+
+| ❌ Errado | ✅ Correto |
+|-----------|-----------|
+| `<button>Login</button>` | `<button onClick={handleLogin}>Login</button>` |
+| `onClick={() => {}}` | `onClick={signIn}` |
+| Teste só de existência | Teste de existência + interação |
+| Handler sem importar função | Handler importa e chama função |
+
+---
+
+## 🔍 DETECÇÃO RÁPIDA
+
+Buscar no código por componentes potencialmente desconectados:
+
+```bash
+# Botões sem onClick
+grep -r "<button" --include="*.tsx" | grep -v "onClick"
+
+# Forms sem onSubmit  
+grep -r "<form" --include="*.tsx" | grep -v "onSubmit"
+
+# Handlers vazios
+grep -r "onClick={() => {}}" --include="*.tsx"
+grep -r 'onClick={() => ""}' --include="*.tsx"
+```
+
+---
+
+## 🔍 Production Mock Detection (DATA INTEGRATION SCAN)
+
+> [!CAUTION]
+> Before marking implementation as complete, the agent MUST verify that NO production
+> page/route contains mock data.
+
+**Mandatory scan (run for EACH page/route in production path):**
+
+```markdown
+⚠️ DATA INTEGRATION SCAN — Implementation Complete?
+
+For EACH file in src/app/ (pages and routes):
+[ ] Pattern: `mock` (case insensitive) — ZERO occurrences?
+[ ] Pattern: `() => {}` or `() => { }` — ZERO noop callbacks?
+[ ] Pattern: `// TODO` in business logic — ZERO placeholders?
+[ ] Pattern: `// MVP:` — ZERO MVP flags?
+
+If ANY pattern found:
+→ LIST affected files
+→ FIX before marking implementation as complete
+→ Connect to database / implement real logic
+
+✅ ZERO mock patterns in production → CLEARED
+```
+
+**Recommended scan commands:**
+
+```bash
+grep -rn "mock" src/app/ --include="*.tsx" --include="*.ts" -l
+grep -rn "() => {}" src/app/ --include="*.tsx" --include="*.ts" -l
+grep -rn "// TODO" src/app/ --include="*.tsx" --include="*.ts" -l
+grep -rn "// MVP" src/app/ --include="*.tsx" --include="*.ts" -l
+```
+
+> **Historical Lesson:** Phase 5.2 had a gate "Components connected to backend" but no verification
+> mechanism. The agent marked it ✅ without checking. 7 files had `mockData`, `// MVP: mock response`,
+> and `onApprove={() => {}}` in production code.
+
+---
+
+> **Regra de Ouro:** Se o usuário pode clicar, o teste deve clicar.

package/core/skills/intelligent-routing/SKILL.md

@@ -0,0 +1,370 @@
+---
+name: intelligent-routing
+description: Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
+version: 1.0.0
+---
+
+# Intelligent Agent Routing
+
+**Purpose**: Automatically analyze user requests and route them to the most appropriate specialist agent(s) without requiring explicit user mentions.
+
+## Core Principle
+
+> **The AI should act as an intelligent Project Manager**, analyzing each request and automatically selecting the best specialist(s) for the job.
+
+## How It Works
+
+### 1. Request Analysis
+
+Before responding to ANY user request, perform automatic analysis:
+
+```mermaid
+graph TD
+    A[User Request: Add login] --> B[ANALYZE]
+    B --> C[Keywords]
+    B --> D[Domains]
+    B --> E[Complexity]
+    C --> F[SELECT AGENT]
+    D --> F
+    E --> F
+    F --> G[security-auditor + backend-specialist]
+    G --> H[AUTO-INVOKE with context]
+```
+
+### 2. Agent Selection Matrix
+
+**Use this matrix to automatically select agents:**
+
+| User Intent         | Keywords                                       | Selected Agent(s)                           | Auto-invoke? |
+| ------------------- | ---------------------------------------------- | ------------------------------------------- | ------------ |
+| **Authentication**  | "login", "auth", "signup", "password"          | `security-auditor` + `backend-specialist`   | ✅ YES       |
+| **UI Component**    | "button", "card", "layout", "style"            | `frontend-specialist`                       | ✅ YES       |
+| **Mobile UI**       | "screen", "navigation", "touch", "gesture"     | `mobile-developer`                          | ✅ YES       |
+| **API Endpoint**    | "endpoint", "route", "API", "POST", "GET"      | `backend-specialist`                        | ✅ YES       |
+| **Database**        | "schema", "migration", "query", "table"        | `database-architect` + `backend-specialist` | ✅ YES       |
+| **Bug Fix**         | "error", "bug", "not working", "broken"        | `debugger`                                  | ✅ YES       |
+| **Test**            | "test", "coverage", "unit", "e2e"              | `test-engineer`                             | ✅ YES       |
+| **Deployment**      | "deploy", "production", "CI/CD", "docker"      | `devops-engineer`                           | ✅ YES       |
+| **Security Review** | "security", "vulnerability", "exploit"         | `security-auditor` + `penetration-tester`   | ✅ YES       |
+| **Performance**     | "slow", "optimize", "performance", "speed"     | `performance-optimizer`                     | ✅ YES       |
+| **Product Def**     | "requirements", "user story", "backlog", "MVP" | `product-owner`                             | ✅ YES       |
+| **New Feature**     | "build", "create", "implement", "new app"      | `orchestrator` → multi-agent                | ⚠️ ASK FIRST |
+| **Complex Task**    | Multiple domains detected                      | `orchestrator` → multi-agent                | ⚠️ ASK FIRST |
+
+### 3. Pre-Execution Gate (MANDATORY for MODERATE/COMPLEX)
+
+> [!CAUTION]
+> **AFTER selecting an agent but BEFORE writing code**, the AI MUST complete the Pre-Execution Gate
+> for tasks classified as MODERATE or COMPLEX. This applies even without a slash command.
+
+| Complexity   | Gate Required? | Actions                                         |
+| ------------ | -------------- | ----------------------------------------------- |
+| **SIMPLE**   | ❌ No          | Proceed directly with agent response            |
+| **MODERATE** | ✅ Yes         | Context Gathering + Tracker Sync                 |
+| **COMPLEX**  | ✅ Yes (full)  | Context Gathering + History Check + Tracker Sync |
+
+**Gate Checklist:**
+
+```markdown
+⚠️ Pre-Execution Gate (MODERATE/COMPLEX tasks)
+
+[ ] Context Gathering: Read Flyee task + relevant docs (`docs/flows/`)
+[ ] History Check: Search for related past tasks, learn from bugs (COMPLEX only)
+[ ] Tracker Sync: Create or link to existing Flyee task
+
+❌ If ANY item unchecked → DO NOT write code
+✅ ALL checked → Proceed with implementation
+```
+
+**Skills to invoke:**
+
+- `@[skills/context-gathering-patterns]` → Read task body, domain docs, TDD
+- `@[skills/history-check-patterns]` → Search for related tasks and bugs
+- `@[skills/Flyee API]` → Create or find Flyee task
+
+> 🔴 **FALHA QUE GEROU ESTA REGRA:** Sessão de 5 fixes executada sem ler Flyee,
+> sem consultar docs, e sem sync final — porque o intelligent-routing selecionava o
+> agente mas não exigia nenhum pré-check antes da resposta.
+
+### 4. Automatic Routing Protocol
+
+## TIER 0 - Automatic Analysis (ALWAYS ACTIVE)
+
+Before responding to ANY request:
+
+```javascript
+// Pseudo-code for decision tree
+function analyzeRequest(userMessage) {
+  // 1. Classify request type
+  const requestType = classifyRequest(userMessage)
+
+  // 2. Detect domains
+  const domains = detectDomains(userMessage)
+
+  // 3. Determine complexity
+  const complexity = assessComplexity(domains)
+
+  // 4. Select agent(s)
+  if (complexity === "SIMPLE" && domains.length === 1) {
+    return selectSingleAgent(domains[0])
+  } else if (complexity === "MODERATE" && domains.length <= 2) {
+    return selectMultipleAgents(domains)
+  } else {
+    return "orchestrator" // Complex task
+  }
+}
+```
+
+## 4. Response Format
+
+**When auto-selecting an agent, inform the user concisely:**
+
+```markdown
+🤖 **Applying knowledge of `@security-auditor` + `@backend-specialist`...**
+
+[Proceed with specialized response]
+```
+
+**Benefits:**
+
+- ✅ User sees which expertise is being applied
+- ✅ Transparent decision-making
+- ✅ Still automatic (no /commands needed)
+
+## Domain Detection Rules
+
+### Single-Domain Tasks (Auto-invoke Single Agent)
+
+| Domain          | Patterns                                   | Agent                   |
+| --------------- | ------------------------------------------ | ----------------------- |
+| **Security**    | auth, login, jwt, password, hash, token    | `security-auditor`      |
+| **Frontend**    | component, react, vue, css, html, tailwind | `frontend-specialist`   |
+| **Backend**     | api, server, express, fastapi, node        | `backend-specialist`    |
+| **Mobile**      | react native, flutter, ios, android, expo  | `mobile-developer`      |
+| **Database**    | prisma, sql, mongodb, schema, migration    | `database-architect`    |
+| **Testing**     | test, jest, vitest, playwright, cypress    | `test-engineer`         |
+| **DevOps**      | docker, kubernetes, ci/cd, pm2, nginx      | `devops-engineer`       |
+| **Debug**       | error, bug, crash, not working, issue      | `debugger`              |
+| **Performance** | slow, lag, optimize, cache, performance    | `performance-optimizer` |
+| **SEO**         | seo, meta, analytics, sitemap, robots      | `seo-specialist`        |
+| **Game**        | unity, godot, phaser, game, multiplayer    | `game-developer`        |
+
+### Multi-Domain Tasks (Auto-invoke Orchestrator)
+
+If request matches **2+ domains from different categories**, automatically use `orchestrator`:
+
+```text
+Example: "Create a secure login system with dark mode UI"
+→ Detected: Security + Frontend
+→ Auto-invoke: orchestrator
+→ Orchestrator will handle: security-auditor, frontend-specialist, test-engineer
+```
+
+## Complexity Assessment
+
+### SIMPLE (Direct agent invocation)
+
+- Single file edit
+- Clear, specific task
+- One domain only
+- Example: "Fix the login button style"
+
+**Action**: Auto-invoke respective agent
+
+### MODERATE (2-3 agents)
+
+- 2-3 files affected
+- Clear requirements
+- 2 domains max
+- Example: "Add API endpoint for user profile"
+
+**Action**: Auto-invoke relevant agents sequentially
+
+### COMPLEX (Orchestrator required)
+
+- Multiple files/domains
+- Architectural decisions needed
+- Unclear requirements
+- Example: "Build a social media app"
+
+**Action**: Auto-invoke `orchestrator` → will ask Socratic questions
+
+## Implementation Rules
+
+### Rule 1: Silent Analysis
+
+#### DO NOT announce "I'm analyzing your request..."
+
+- ✅ Analyze silently
+- ✅ Inform which agent is being applied
+- ❌ Avoid verbose meta-commentary
+
+### Rule 2: Inform Agent Selection
+
+**DO inform which expertise is being applied:**
+
+```markdown
+🤖 **Applying knowledge of `@frontend-specialist`...**
+
+I will create the component with the following characteristics:
+[Continue with specialized response]
+```
+
+### Rule 3: Seamless Experience
+
+**The user should not notice a difference from talking to the right specialist directly.**
+
+### Rule 4: Override Capability
+
+**User can still explicitly mention agents:**
+
+```text
+User: "Use @backend-specialist to review this"
+→ Override auto-selection
+→ Use explicitly mentioned agent
+```
+
+## Edge Cases
+
+### Case 1: Generic Question
+
+```text
+User: "How does React work?"
+→ Type: QUESTION
+→ No agent needed
+→ Respond directly with explanation
+```
+
+### Case 2: Extremely Vague Request
+
+```text
+User: "Make it better"
+→ Complexity: UNCLEAR
+→ Action: Ask clarifying questions first
+→ Then route to appropriate agent
+```
+
+### Case 3: Contradictory Patterns
+
+```text
+User: "Add mobile support to the web app"
+→ Conflict: mobile vs web
+→ Action: Ask: "Do you want responsive web or native mobile app?"
+→ Then route accordingly
+```
+
+## Integration with Existing Workflows
+
+### With /orchestrate Command
+
+- **User types `/orchestrate`**: Explicit orchestration mode
+- **AI detects complex task**: Auto-invoke orchestrator (same result)
+
+**Difference**: User doesn't need to know the command exists.
+
+### With Socratic Gate
+
+- **Auto-routing does NOT bypass Socratic Gate**
+- If task is unclear, still ask questions first
+- Then route to appropriate agent
+
+### With GEMINI.md Rules
+
+- **Priority**: GEMINI.md rules > intelligent-routing
+- If GEMINI.md specifies explicit routing, follow it
+- Intelligent routing is the DEFAULT when no explicit rule exists
+
+## Testing the System
+
+### Test Cases
+
+#### Test 1: Simple Frontend Task
+
+```text
+User: "Create a dark mode toggle button"
+Expected: Auto-invoke frontend-specialist
+Verify: Response shows "Using @frontend-specialist"
+```
+
+#### Test 2: Security Task
+
+```text
+User: "Review the authentication flow for vulnerabilities"
+Expected: Auto-invoke security-auditor
+Verify: Security-focused analysis
+```
+
+#### Test 3: Complex Multi-Domain
+
+```text
+User: "Build a chat application with real-time notifications"
+Expected: Auto-invoke orchestrator
+Verify: Multiple agents coordinated (backend, frontend, test)
+```
+
+#### Test 4: Bug Fix
+
+```text
+User: "Login is not working, getting 401 error"
+Expected: Auto-invoke debugger
+Verify: Systematic debugging approach
+```
+
+## Performance Considerations
+
+### Token Usage
+
+- Analysis adds ~50-100 tokens per request
+- Tradeoff: Better accuracy vs slight overhead
+- Overall SAVES tokens by reducing back-and-forth
+
+### Response Time
+
+- Analysis is instant (pattern matching)
+- No additional API calls required
+- Agent selection happens before first response
+
+## User Education
+
+### Optional: First-Time Explanation
+
+If this is the first interaction in a project:
+
+```markdown
+💡 **Tip**: I am configured with automatic specialist agent selection.
+I will always choose the most suitable specialist for your task. You can
+still mention agents explicitly with `@agent-name` if you prefer.
+```
+
+## Debugging Agent Selection
+
+### Enable Debug Mode (for development)
+
+Add to GEMINI.md temporarily:
+
+```markdown
+## DEBUG: Intelligent Routing
+
+Show selection reasoning:
+
+- Detected domains: [list]
+- Selected agent: [name]
+- Reasoning: [why]
+```
+
+## Summary
+
+**intelligent-routing skill enables:**
+
+✅ Zero-command operation (no need for `/orchestrate`)  
+✅ Automatic specialist selection based on request analysis  
+✅ Transparent communication of which expertise is being applied  
+✅ Seamless integration with existing workflows  
+✅ Override capability for explicit agent mentions  
+✅ Fallback to orchestrator for complex tasks
+
+**Result**: User gets specialist-level responses without needing to know the system architecture.
+
+---
+
+**Next Steps**: Integrate this skill into GEMINI.md TIER 0 rules.

package/core/skills/lint-and-validate/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: lint-and-validate
+description: Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
+allowed-tools: Read, Glob, Grep, Bash
+---
+
+# Lint and Validate Skill
+
+> **MANDATORY:** Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.
+
+### Procedures by Ecosystem
+
+#### Node.js / TypeScript
+1. **Lint/Fix:** `npm run lint` or `npx eslint "path" --fix`
+2. **Types:** `npx tsc --noEmit`
+3. **Security:** `npm audit --audit-level=high`
+
+#### Python
+1. **Linter (Ruff):** `ruff check "path" --fix` (Fast & Modern)
+2. **Security (Bandit):** `bandit -r "path" -ll`
+3. **Types (MyPy):** `mypy "path"`
+
+## The Quality Loop
+1. **Write/Edit Code**
+2. **Run Audit:** `npm run lint && npx tsc --noEmit`
+3. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.
+4. **Fix & Repeat:** Submitting code with "FINAL AUDIT" failures is NOT allowed.
+
+## Error Handling
+- If `lint` fails: Fix the style or syntax issues immediately.
+- If `tsc` fails: Correct type mismatches before proceeding.
+- If no tool is configured: Check the project root for `.eslintrc`, `tsconfig.json`, `pyproject.toml` and suggest creating one.
+
+---
+**Strict Rule:** No code should be committed or reported as "done" without passing these checks.
+
+---
+
+## Scripts
+
+| Script | Purpose | Command |
+|--------|---------|---------|
+| `scripts/lint_runner.py` | Unified lint check | `python scripts/lint_runner.py <project_path>` |
+| `scripts/type_coverage.py` | Type coverage analysis | `python scripts/type_coverage.py <project_path>` |
+