flyee 0.1.0

package/core/workflows/new-task.md

@@ -0,0 +1,404 @@
+---
+description: Add or update features with mandatory Analysis, Splitting, and Tracker sync (Flyee or Local). Supports dynamic database discovery.
+skills: checkpointing-patterns, history-check-patterns, context-gathering-patterns, project-tracking-patterns, ui-ux-discovery, local-verification, integration-completeness, design-system-enforcement, document-registry
+
+---
+
+# /new-task - Structured Improvement Workflow
+
+$ARGUMENTS
+
+**Flags:**
+
+| Flag | Descrição |
+|------|-----------|
+| `--tdd` | Modo **TDD obrigatório** (testes antes do código) |
+| `--resume` | **Retomar** de onde parou |
+| `--backlog` | **Apenas registro**: Cria a task no Flyee e encerra (não inicia implementação) |
+| `--skip-history` | Pular consulta de histórico (não recomendado) |
+
+**Status lifecycle da task:**
+```
+backlog → running → testing → completed
+```
+- `backlog` — Task registrada, plano em elaboração (iterações)
+- `running` — Plano aprovado, implementação em curso
+- `testing` — Implementação concluída, aguardando validação QA
+- `completed` — QA aprovado, task encerrada via `/task-complete`
+
+---
+
+## 🛑🛑🛑 MANDATORY EXECUTION PROTOCOL (READ FIRST) 🛑🛑🛑
+
+> [!CAUTION]
+> **HALT.** Você DEVE completar TODAS as etapas abaixo **ANTES** de escrever qualquer linha de código.
+> Pular qualquer etapa = **VIOLAÇÃO GRAVE**. O workflow inteiro será considerado inválido.
+> **NENHUMA EXCEÇÃO.** Nem urgência, nem simplicidade, nem pedido do usuário justifica pular.
+
+### 📋 CHECKLIST OBRIGATÓRIO (Executar em ordem, mostrar evidência)
+
+**O agente DEVE executar cada comando e mostrar o output ao usuário:**
+
+```
+🛑 /new-task GOVERNANCE GATE
+
+[ ] 0. FASE 0 — TASK CRIADA ANTES DO PLANO:
+       → Executei `bridge.py --create-task --status backlog`?
+       → task_id obtido: ___________
+       → task_id gravado no frontmatter do implementation_plan.md?
+       → Se falhou: RETRY 1x → Se falhou novamente: INFORMAR usuário e parar
+
+[ ] 1. FLYEE DETECTION: Executei `cat flyee.json` e verifiquei se existe?
+       → Se não existe: INFORMAR usuário e perguntar se deseja configurar
+       → Se existe mas enabled:false: INFORMAR que tracking está desativado
+
+[ ] 2. HISTORY CHECK: Consultei tasks anteriores no Flyee relacionadas à demanda?
+       → Tasks encontradas: ___ (ou "Nenhuma")
+       → Lições aplicáveis: ___ (ou "Nenhuma")
+
+[ ] 3. CONTEXT CHECK: Verifiquei docs/INDEX.md e docs/flows/ para contexto?
+       → Documentação encontrada: ___ (ou "Nenhuma → perguntar ao usuário")
+
+[ ] 4. PERSIST-PLAN ITERATIVO ATIVO:
+       → A cada atualização do implementation_plan.md, executei `--persist-plan`?
+       → task_id presente no frontmatter do .md? (se não → ERRO, não continuar)
+
+❌ QUALQUER ITEM DESMARCADO → NÃO INICIAR IMPLEMENTAÇÃO
+✅ TODOS MARCADOS → Prosseguir para código
+```
+
+> [!CAUTION]
+> **ANTI-SKIP RULES:**
+> - ❌ "É uma task simples" → NÃO é motivo para pular. Tasks simples TAMBÉM devem ser rastreadas.
+> - ❌ "O usuário pediu para ir direto" → NÃO é motivo. Informar o usuário que o gate é obrigatório.
+> - ❌ "Já sei o que fazer" → NÃO é motivo. O registro no Flyee serve para rastreabilidade, não para planejamento.
+> - ❌ "Vou registrar depois" → PROIBIDO. A task DEVE ser criada ANTES da implementação.
+
+### ⚡ ORDEM DE EXECUÇÃO OBRIGATÓRIA
+
+```
+0. bridge.py --create-task --status backlog    → Criar task ANTES do plano
+   ↳ Gravar task_id no frontmatter do implementation_plan.md
+1. cat flyee.json                              → Detectar Flyee
+2. Flyee API: search tasks relacionadas        → History check
+3. Verificar docs/INDEX.md + docs/flows/       → Context check
+4. Escrever implementation_plan.md             → Planejamento
+   ↳ bridge.py --persist-plan <path> --task-id <id>  → Persiste v1
+   ↳ A cada iteração do plano → --persist-plan novamente (SHA256 dedup)
+5. Usuário aprova plano:
+   ↳ bridge.py --update-task <id> --status running
+   ↳ bridge.py --update-task <id> --description "<escopo final aprovado>"
+6. ════════════════════════════════════════════
+   ↓↓↓ SOMENTE APÓS 0-5 COMPLETOS ↓↓↓
+7. Implementar código
+8. bridge.py --update-task <id> --status testing  → Aguarda QA
+9. /task-complete                               → Fechar task
+```
+
+> [!CAUTION]
+> **ANTI-BYPASS:** Se `implementation_plan.md` não tiver `task_id` no frontmatter ao executar `--persist-plan`, o bridge retorna **exit(1)** com mensagem de erro. O agente **DEVE** parar e resolver — não ignorar silenciosamente.
+
+> [!CAUTION]
+> **SE O AGENTE CHEGAR AO PASSO 6 SEM TER EXECUTADO 1-4:**
+> O agente DEVE parar IMEDIATAMENTE, voltar, e executar os passos faltantes.
+> Código escrito sem task rastreada = trabalho perdido.
+
+---
+
+## 🎯 PROPÓSITO
+
+Workflow para melhorias e correções que exige **Análise Prévia** e **Registro no Tracker** (Flyee ou Local).
+Totalmente dinâmico: adapta-se ao projeto atual buscando o contexto correto.
+
+> [!IMPORTANT]
+> **Tracker-aware:** Lê `PROJECT-PROGRESS.md` → `Tracker de Tasks` para determinar
+> se cria tasks via Flyee API ou em `docs/TASKS.md`.
+
+---
+
+## 💾 SISTEMA DE CHECKPOINTING
+
+> **Skill:** `project-tracking-patterns`
+>
+> O workflow mantém estado em dois lugares:
+> - Arquivo local: `docs/NEW-TASK-PROGRESS.md`
+> - Tracker remoto: Flyee Task
+>
+> **Retomada:** Ao executar `/new-task --resume`, o agente carrega o arquivo de progresso, busca a task no Flyee e continua da fase pendente.
+
+---
+
+## 🚫 FLUXO: PRE-CHECK → HISTORY → DISCOVER → ANALYSE → TRACK → EXECUTE → VERIFY
+
+> [!CAUTION]
+> **REGRA DE OURO:** NUNCA use IDs fixos. Sempre busque o contexto do projeto atual.
+> **Cada transição de fase exige que a fase anterior tenha sido COMPLETADA com evidência.**
+
+---
+
+### 🚨 Fase -2: PRE-START CHECK (Gate de Finalização)
+
+> [!CAUTION]
+> **REGRA BLOQUEANTE:** Esta é a PRIMEIRA ação ao iniciar o workflow.
+> Verificar se há tasks "Em andamento" antes de criar/iniciar nova.
+
+**Ações OBRIGATÓRIAS (executar e mostrar output):**
+
+1. **Detectar Flyee:**
+   ```bash
+   cat flyee.json 2>/dev/null || echo "⚠️ flyee.json não encontrado"
+   ```
+   → Se não existe: **PARAR** e perguntar ao usuário se deseja configurar.
+
+2. **Verificar tasks abertas:**
+   ```bash
+   python3 .agent/flyee-bridge/bridge.py --search-context "status em andamento"
+   ```
+   → Se houver tasks em andamento: Perguntar se deseja finalizar primeiro.
+   → Se usuário quiser finalizar: Executar `/task-complete` antes de prosseguir.
+
+**Gate de Saída Fase -2:**
+```
+[ ] flyee.json verificado (mostrar output)
+[ ] Tasks em andamento verificadas
+❌ Se desmarcado → NÃO prosseguir para Fase -1
+```
+
+---
+
+### 🕵️ Fase -1: HISTORY CHECK (Aprender com o passado)
+
+> **Skill:** `history-check-patterns`
+>
+> **Objetivo:** Consultar histórico de tarefas relacionadas à demanda para evitar repetir erros e adotar padrões já definidos.
+> **Ação:** Executar a busca de histórico descrita no skill.
+
+**Gate de Saída Fase -1:**
+```
+[ ] History check executado (mostrar output ou "Nenhum histórico")
+[ ] Lições identificadas e anotadas
+❌ Se desmarcado → NÃO prosseguir para Fase 0
+```
+
+---
+
+   - Atualizar doc na "Documentação Técnica" (se existir)
+   - Atualizar guia no "Manual do Usuário" (se existir)
+
+---
+
+### 🧠 Fase 1: ANÁLISE TÉCNICA (Offline/Mental)
+
+**Trigger:** Database identificado e validado.
+
+**1. Análise de Complexidade:**
+   - O pedido toca em múltiplos contextos?
+   - Tempo estimado > 2h?
+
+**2. Estratégia de Particionamento (Split):**
+   - **SIMPLES:** 1 Task.
+   - **COMPLEXA:** Múltiplas sub-tasks.
+
+**3. Estimativa:**
+   - Defina a estimativa para cada task (P/M/G ou Pontos).
+
+**Gate de Saída Fase 1:**
+```
+[ ] Complexidade avaliada
+[ ] Estratégia de split definida
+[ ] Estimativa definida
+❌ Se desmarcado → NÃO prosseguir para Fase 2
+```
+
+---
+
+### 🌱 Fase 0: TASK REGISTRATION (Antes do Plano)
+
+> [!CAUTION]
+> **BLOQUEADOR ABSOLUTO:** Task DEVE ser criada no Flyee ANTES de escrever qualquer linha do plano.
+
+```bash
+# Criar task em status backlog (intenção registrada, plano ainda não aprovado)
+python3 .agent/flyee-bridge/bridge.py \
+  --create-task \
+  --name "{nome da demanda}" \
+  --type implement_feature \
+  --status backlog \
+  --description "Intent placeholder — plano em elaboração" \
+  --priority normal
+# → Salva o task_id retornado no frontmatter do implementation_plan.md
+```
+
+**Frontmatter obrigatório em `implementation_plan.md`:**
+```yaml
+---
+task_id: <uuid retornado acima>
+task_name: <nome>
+flyee_status: backlog
+iteration: 0
+---
+```
+
+> [!IMPORTANT]
+> **STOP GATE (`--backlog` flag):** Se `--backlog` foi utilizado, **ENCERRA AQUI**. Informe o link da task ao usuário. Task permanece em `backlog`.
+
+**Gate de Saída Fase 0:**
+```
+[ ] Task criada com --status backlog (ID obtido)
+[ ] task_id gravado no frontmatter do implementation_plan.md
+[ ] Se --backlog: encerrou aqui
+❌ task_id ausente → NÃO escrever plano
+```
+
+---
+
+### 📝 Fase 2: PLANNING + PERSIST ITERATIVO
+
+> [!CAUTION]
+> **REGRA:** `--persist-plan` roda a **cada iteração** do plano — não só na aprovação.
+> SHA256 dedup garante que versões idênticas não geram duplicatas.
+
+```bash
+# A cada atualização do implementation_plan.md:
+python3 .agent/flyee-bridge/bridge.py \
+  --persist-plan "implementation_plan.md" \
+  --task-id <id do frontmatter>
+# → bridge lê task_id do frontmatter automaticamente se não informado via flag
+# → se task_id AUSENTE no frontmatter → exit(1) com erro explícito
+# → se conteúdo idêntico ao anterior (mesmo SHA256) → skipped (não cria nova versão)
+# → se conteúdo diferente → cria nova versão, incrementa iteration no frontmatter
+
+# Ao APROVAR o plano (usuário confirma):
+python3 .agent/flyee-bridge/bridge.py --update-task <id> --status running
+python3 .agent/flyee-bridge/bridge.py --update-task <id> --description "<escopo real aprovado>"
+
+# Ao ABANDONAR (usuário rejeita definitivamente):
+# Task permanece em backlog — registro de intenção explorada. Usuário arquiva manualmente.
+```
+
+**🧩 UI Component Classification Gate (se plano contém componentes UI):**
+
+> [!CAUTION]
+> **ANTES de aprovar o plano**, o agente DEVE classificar CADA componente UI listado como `[NEW]`.
+> Skill de referência: `design-system-enforcement` § Component Classification.
+> Skill complementar: `plan-writing` § Principle 6.
+
+Para cada `[NEW]` componente UI no plano, preencher:
+
+```markdown
+⚠️ UI COMPONENT CLASSIFICATION — Plano: {task_name}
+
+| Componente | Conceito Visual Genérico? | Reutilizável em 2+ features? | Destino |
+|------------|--------------------------|------------------------------|---------|
+| {nome}     | Sim/Não                   | Sim/Não                       | components/ui/ OU features/{x}/components/ |
+
+[ ] Primitivos genéricos extraídos para components/ui/ (se aplicável)
+[ ] Feature components consomem os primitivos genéricos (não recriam o visual)
+❌ Componente genérico dentro de features/ → CORRIGIR PLANO antes de aprovar
+```
+
+> **Anti-pattern:** Plano aprovado com `[NEW] features/progress/components/SprintTimeline.tsx`
+> contendo sua própria `.module.css` que constrói uma timeline visual do zero.
+> O conceito "Timeline" é genérico e deveria estar em `components/ui/Timeline/`.
+
+**Gate de Saída Fase 2:**
+```
+[ ] Plano escrito com task_id no frontmatter
+[ ] --persist-plan executado ao menos 1x (versão v1 criada no Flyee)
+[ ] UI Component Classification preenchido (se plano tem componentes UI)
+[ ] Plano aprovado → --update-task --status running executado
+❌ task_id ausente → PARAR, executar Fase 0 primeiro
+❌ Componente genérico preso em features/ → CORRIGIR PLANO
+```
+
+---
+
+### 💻 Fase 3: EXECUTION (Code)
+
+> **Skills ativas:** `tdd-workflow`, `design-system-enforcement`, `ui-validation`
+
+> [!CAUTION]
+> **🛑 CHECKPOINT:** Verifique que as Fases -2 a 2 foram CONCLUÍDAS. 
+> É terminantemente proibido codar sem uma Task ID do Flyee em mãos.
+
+**Ação:** Implementar as mudanças delegando responsabilidades aos skills especialistas:
+
+| Sub-fase | Skill | O que |
+|----------|-------|-------|
+| 🔴 **3.0 Context Gather** | `context-gathering-patterns` | (Opcional) Re-ler requisitos detalhados listados na Fase 0 |
+| **3.1 Lógica/Backend** | `tdd-workflow` | Implementar TDD: RED → GREEN → REFACTOR. Seguir regras Anti-Mock. |
+| **3.2 UI Components** | `design-system-enforcement` | Se houver UI, extrair tokens do `docs/design/DESIGN-SYSTEM.md` e garantir Premium Styling e Responsividade. |
+| **3.3 UI Check** | `ui-validation` | Se alterou UI, rodar validação automatizada de antipatterns Visuais. |
+
+**Gate de Saída Fase 3:**
+```
+[ ] Lógica implementada (Testada se --tdd)
+[ ] UI aderente ao Design System (se aplicável)
+❌ Se pendente → NÃO prosseguir
+```
+
+---
+
+### ✅ Fase 4: VERIFICATION & COMPLETION (Workflow Delegation)
+
+> **Workflow:** `/task-complete`
+> **Skill:** `project-tracking-patterns`
+
+**Ação Final:**
+
+1.  **Document Refresh:** Busque documentações antigas impactadas e atualize (local e no Flyee).
+2.  **Coverage:** Se `--tdd`, garanta mínimo de 80% coverage localmente.
+3.  **Completion:** Execute `/task-complete`. ESTA É A ÚNICA FORMA AUTORIZADA DE FECHAR TASKS.
+
+> [!CAUTION]
+> 🚫 **ANTI-PATTERN PROIBIDO:** `API-patch-page` solto para fechar a Task sem comentários ou detalhes.
+> ✅ **OBRIGATÓRIO:** Workflow `/task-complete` fará os 8 steps de encerramento, incluindo o Log de Execução e o tempo gasto.
+
+**Gate Final:**
+```
+[ ] `/task-complete` excutado
+[ ] Documentação técnica ou guias atualizados
+```
+
+### ⚠️ Checklist de Finalização (OBRIGATÓRIO)
+
+**Antes de ENCERRAR a conversa ou resposta, o agente DEVE verificar:**
+
+- [ ] **Fase 2 executada?** Task criada no Flyee com ID registrado?
+- [ ] **Fase 3 concluída?** Todas as alterações implementadas?
+- [ ] **Doc Refresh executado?** Docs impactados verificados e atualizados (local + Flyee)?
+- [ ] **Fase 4 executada?** 
+  - [ ] Workflow `/task-complete` invocado para finalizar a task no sistema?
+
+### 🔄 Se a Execução for Longa/Interrompida
+
+Se o agente precisar pausar ou a conversa for longa:
+
+1. **ANTES de parar:** Atualizar Tracker com progresso parcial
+2. **Informar usuário:** "Task {ID} em progresso - X de Y itens concluídos"
+3. **Ao retomar:** Verificar status atual no Flyee antes de continuar
+
+### ❌ O Que NUNCA Fazer
+
+1. ❌ **Encerrar conversa** sem atualizar tracker
+2. ❌ **Marcar como Concluído** sem verificar se TODOS os itens foram resolvidos
+3. ❌ **Esquecer de registrar** a task inicialmente (Fase 2)
+4. ❌ **Pular o resumo final** com descrição das alterações
+
+### ✅ Verificação de Conclusão Correta
+
+Quando o usuário perguntar "verificar task" ou "checar Flyee":
+
+1. **Buscar task:** `API-post-search` com o nome/ID
+2. **Ler status atual:** Verificar Status e comentários
+3. **Comparar com trabalho feito:** 
+   - Listar arquivos modificados na sessão
+   - Verificar se correspondem ao escopo da task
+4. **Se incompleto:** Perguntar ao usuário antes de marcar como Concluído
+   ```
+   ⚠️ A task "{nome}" tem os seguintes itens pendentes:
+   - [ ] {item 1}
+   - [ ] {item 2}
+   
+   Deseja marcar como Concluído mesmo assim?
+   ```

package/core/workflows/orchestrate.md

@@ -0,0 +1,237 @@
+---
+description: Coordinate multiple agents for complex tasks. Use for multi-perspective analysis, comprehensive reviews, or tasks requiring different domain expertise.
+---
+
+# Multi-Agent Orchestration
+
+You are now in **ORCHESTRATION MODE**. Your task: coordinate specialized agents to solve this complex problem.
+
+## Task to Orchestrate
+$ARGUMENTS
+
+---
+
+## 🔴 CRITICAL: Minimum Agent Requirement
+
+> ⚠️ **ORCHESTRATION = MINIMUM 3 DIFFERENT AGENTS**
+> 
+> If you use fewer than 3 agents, you are NOT orchestrating - you're just delegating.
+> 
+> **Validation before completion:**
+> - Count invoked agents
+> - If `agent_count < 3` → STOP and invoke more agents
+> - Single agent = FAILURE of orchestration
+
+### Agent Selection Matrix
+
+| Task Type | REQUIRED Agents (minimum) |
+|-----------|---------------------------|
+| **Web App** | frontend-specialist, backend-specialist, test-engineer |
+| **API** | backend-specialist, security-auditor, test-engineer |
+| **UI/Design** | frontend-specialist, seo-specialist, performance-optimizer |
+| **Database** | database-architect, backend-specialist, security-auditor |
+| **Full Stack** | project-planner, frontend-specialist, backend-specialist, devops-engineer |
+| **Debug** | debugger, explorer-agent, test-engineer |
+| **Security** | security-auditor, penetration-tester, devops-engineer |
+
+---
+
+## Pre-Flight: Mode Check
+
+| Current Mode | Task Type | Action |
+|--------------|-----------|--------|
+| **plan** | Any | ✅ Proceed with planning-first approach |
+| **edit** | Simple execution | ✅ Proceed directly |
+| **edit** | Complex/multi-file | ⚠️ Ask: "This task requires planning. Switch to plan mode?" |
+| **ask** | Any | ⚠️ Ask: "Ready to orchestrate. Switch to edit or plan mode?" |
+
+---
+
+## 🔴 STRICT 2-PHASE ORCHESTRATION
+
+### PHASE 1: PLANNING (Sequential - NO parallel agents)
+
+| Step | Agent | Action |
+|------|-------|--------|
+| 1 | `project-planner` | Create docs/PLAN.md |
+| 2 | (optional) `explorer-agent` | Codebase discovery if needed |
+
+> 🔴 **NO OTHER AGENTS during planning!** Only project-planner and explorer-agent.
+
+### ⏸️ CHECKPOINT: User Approval
+
+```
+After PLAN.md is complete, ASK:
+
+"✅ Plan oluşturuldu: docs/PLAN.md
+
+Onaylıyor musunuz? (Y/N)
+- Y: Implementation başlatılır
+- N: Planı düzeltirim"
+```
+
+> 🔴 **DO NOT proceed to Phase 2 without explicit user approval!**
+
+### PHASE 2: IMPLEMENTATION (Parallel agents after approval)
+
+| Parallel Group | Agents |
+|----------------|--------|
+| Foundation | `database-architect`, `security-auditor` |
+| Core | `backend-specialist`, `frontend-specialist` |
+| Polish | `test-engineer`, `devops-engineer` |
+
+> ✅ After user approval, invoke multiple agents in PARALLEL.
+
+## Available Agents (17 total)
+
+| Agent | Domain | Use When |
+|-------|--------|----------|
+| `project-planner` | Planning | Task breakdown, PLAN.md |
+| `explorer-agent` | Discovery | Codebase mapping |
+| `frontend-specialist` | UI/UX | React, Vue, CSS, HTML |
+| `backend-specialist` | Server | API, Node.js, Python |
+| `database-architect` | Data | SQL, NoSQL, Schema |
+| `security-auditor` | Security | Vulnerabilities, Auth |
+| `penetration-tester` | Security | Active testing |
+| `test-engineer` | Testing | Unit, E2E, Coverage |
+| `devops-engineer` | Ops | CI/CD, Docker, Deploy |
+| `mobile-developer` | Mobile | React Native, Flutter |
+| `performance-optimizer` | Speed | Lighthouse, Profiling |
+| `seo-specialist` | SEO | Meta, Schema, Rankings |
+| `documentation-writer` | Docs | README, API docs |
+| `debugger` | Debug | Error analysis |
+| `game-developer` | Games | Unity, Godot |
+| `orchestrator` | Meta | Coordination |
+
+---
+
+## Orchestration Protocol
+
+### Step 1: Analyze Task Domains
+Identify ALL domains this task touches:
+```
+□ Security     → security-auditor, penetration-tester
+□ Backend/API  → backend-specialist
+□ Frontend/UI  → frontend-specialist
+□ Database     → database-architect
+□ Testing      → test-engineer
+□ DevOps       → devops-engineer
+□ Mobile       → mobile-developer
+□ Performance  → performance-optimizer
+□ SEO          → seo-specialist
+□ Planning     → project-planner
+```
+
+### Step 2: Phase Detection
+
+| If Plan Exists | Action |
+|----------------|--------|
+| NO `docs/PLAN.md` | → Go to PHASE 1 (planning only) |
+| YES `docs/PLAN.md` + user approved | → Go to PHASE 2 (implementation) |
+
+### Step 3: Execute Based on Phase
+
+**PHASE 1 (Planning):**
+```
+Use the project-planner agent to create PLAN.md
+→ STOP after plan is created
+→ ASK user for approval
+```
+
+**PHASE 2 (Implementation - after approval):**
+```
+Invoke agents in PARALLEL:
+Use the frontend-specialist agent to [task]
+Use the backend-specialist agent to [task]
+Use the test-engineer agent to [task]
+```
+
+**🔴 CRITICAL: Context Passing (MANDATORY)**
+
+When invoking ANY subagent, you MUST include:
+
+1. **Original User Request:** Full text of what user asked
+2. **Decisions Made:** All user answers to Socratic questions
+3. **Previous Agent Work:** Summary of what previous agents did
+4. **Current Plan State:** If plan files exist in workspace, include them
+
+**Example with FULL context:**
+```
+Use the project-planner agent to create PLAN.md:
+
+**CONTEXT:**
+- User Request: "Öğrenciler için sosyal platform, mock data ile"
+- Decisions: Tech=Vue 3, Layout=Grid Widget, Auth=Mock, Design=Genç Dinamik
+- Previous Work: Orchestrator asked 6 questions, user chose all options
+- Current Plan: playful-roaming-dream.md exists in workspace with initial structure
+
+**TASK:** Create detailed PLAN.md based on ABOVE decisions. Do NOT infer from folder name.
+```
+
+> ⚠️ **VIOLATION:** Invoking subagent without full context = subagent will make wrong assumptions!
+
+
+### Step 4: Verification (MANDATORY)
+The LAST agent must run appropriate verification scripts:
+```bash
+python .agent/skills/vulnerability-scanner/scripts/security_scan.py .
+python .agent/skills/lint-and-validate/scripts/lint_runner.py .
+```
+
+### Step 5: Synthesize Results
+Combine all agent outputs into unified report.
+
+---
+
+## Output Format
+
+```markdown
+## 🎼 Orchestration Report
+
+### Task
+[Original task summary]
+
+### Mode
+[Current Antigravity Agent mode: plan/edit/ask]
+
+### Agents Invoked (MINIMUM 3)
+| # | Agent | Focus Area | Status |
+|---|-------|------------|--------|
+| 1 | project-planner | Task breakdown | ✅ |
+| 2 | frontend-specialist | UI implementation | ✅ |
+| 3 | test-engineer | Verification scripts | ✅ |
+
+### Verification Scripts Executed
+- [x] security_scan.py → Pass/Fail
+- [x] lint_runner.py → Pass/Fail
+
+### Key Findings
+1. **[Agent 1]**: Finding
+2. **[Agent 2]**: Finding
+3. **[Agent 3]**: Finding
+
+### Deliverables
+- [ ] PLAN.md created
+- [ ] Code implemented
+- [ ] Tests passing
+- [ ] Scripts verified
+
+### Summary
+[One paragraph synthesis of all agent work]
+```
+
+---
+
+## 🔴 EXIT GATE
+
+Before completing orchestration, verify:
+
+1. ✅ **Agent Count:** `invoked_agents >= 3`
+2. ✅ **Scripts Executed:** At least `security_scan.py` ran
+3. ✅ **Report Generated:** Orchestration Report with all agents listed
+
+> **If any check fails → DO NOT mark orchestration complete. Invoke more agents or run scripts.**
+
+---
+
+**Begin orchestration now. Select 3+ agents, execute sequentially, run verification scripts, synthesize results.**