flyee 0.1.0

package/core/workflows/discovery.md

@@ -0,0 +1,267 @@
+---
+description: Workflow completo de descoberta a produção. Brainstorm → TDD → Design System → Validação → Tarefas no Flyee. Fluxo automatizado e contínuo. Suporta busca dinâmica de database.
+skills: project-tracking-patterns, ui-ux-discovery, content-strategy
+---
+
+# /discovery - Da Ideia à Execução (Automático)
+
+$ARGUMENTS
+
+**Arguments:**
+
+| Flag | Descrição | Exemplo |
+|------|-----------|---------|
+| `--from-demand` | Importa dados de proposta aprovada no Flyee | `--from-demand "Nome da Proposta"` |
+| `--from-project` | Analisa projeto existente para gerar TDD | `--from-project "c:\path\to\project"` |
+| `--from-figma` | Importa Design System do Figma existente | `--from-figma "https://figma.com/file/..."` |
+| `--no-design` | Pula geração de Design System | `--no-design` |
+| `--no-tracker` | Pula criação de tasks no Tracker | `--no-tracker` |
+| `--no-infra` | Pula definição de infraestrutura | `--no-infra` |
+| `--flyee-project` | Especifica database do Tracker | `--flyee-project "Tasks Database"` |
+
+---
+
+## 🎯 PROPÓSITO
+
+Workflow **unificado e automatizado** que transforma uma ideia em tarefas executáveis no Flyee.
+Totalmente dinâmico e adaptável ao contexto do projeto.
+
+---
+
+## 🔀 QUANDO USAR `/discovery` vs `/new-project`?
+
+> [!TIP]
+> **Escolha o workflow certo:**
+
+| Situação | Use | Por quê? |
+|----------|-----|----------|
+| Ideia clara, preciso de **documentação formal** (PRD + TDD) | `/new-project` | Fluxo completo com aprovações |
+| Ideia clara, quero ir **rápido** sem PRD | `/discovery` ou `/new-project --quick` | Direto para TDD + Flyee |
+| Tenho **proposta comercial** aprovada | `/discovery --from-demand` | Importa contexto da proposta |
+| Tenho **código legado** para documentar | `/discovery --from-project` | Engenharia reversa |
+| Tenho **Figma** pronto | `/discovery --from-figma` | Importa Design System |
+
+> [!NOTE]
+> `/discovery` é equivalente a `/new-project --quick` com integração nativa ao Flyee.
+> Se você precisa apenas de TDD + Tasks rapidamente, use `/discovery`.
+
+---
+
+## 🔴 FLUXO AUTOMATIZADO
+
+### Fase 0: INTEGRAÇÃO COM /demand (Se --from-demand)
+... (Fases 0 a 4.6 permanecem inalteradas, focando na integração Flyee) ...
+
+---
+
+### Fase 0.1: REVERSE ENGINEERING (Se --from-project)
+
+> [!TIP]
+> **Para fluxo completo de projeto legado**, use `/legacy-project [path]`.
+> Esta fase é executada automaticamente como parte daquele workflow.
+
+**Trigger:** `/discovery --from-project "path/to/project"`
+
+**Agentes Envolvidos:**
+- `explorer-agent` - Análise de estrutura e mapeamento
+- `backend-specialist` / `frontend-specialist` / `mobile-developer` - Análise técnica conforme stack
+
+**Ações:**
+
+1. **Detectar Stack Tecnológica:**
+   | Arquivo | Stack |
+   |---------|-------|
+   | `package.json` | Node.js/React/Next.js |
+   | `requirements.txt` / `pyproject.toml` | Python |
+   | `pubspec.yaml` | Flutter |
+   | `Gemfile` | Ruby |
+   | `go.mod` | Go |
+   | `Cargo.toml` | Rust |
+
+2. **Mapear Estrutura de Diretórios:**
+   ```
+   projeto/
+   ├── src/           → Código fonte
+   ├── tests/         → Testes existentes
+   ├── docs/          → Documentação existente
+   ├── config/        → Configurações
+   └── ...
+   ```
+
+3. **Identificar Entry Points:**
+   - Main files (index.js, main.py, App.tsx)
+   - Rotas/Controllers
+   - Componentes principais
+
+4. **Listar Dependências:**
+   - Frameworks utilizados
+   - Bibliotecas principais
+   - Serviços externos (APIs, DBs)
+
+5. **Gerar Outline do Projeto:**
+   ```markdown
+   # CODEBASE-{projeto}.md
+   
+   ## Stack
+   - Frontend: {framework}
+   - Backend: {framework}
+   - Database: {tipo}
+   
+   ## Estrutura
+   {tree simplificado}
+   
+   ## Componentes Principais
+   - {componente 1}: {descrição}
+   - {componente 2}: {descrição}
+   
+   ## Fluxos Identificados
+   - [ ] {fluxo 1}
+   - [ ] {fluxo 2}
+   ```
+
+**Output:**
+- `docs/CODEBASE-{projeto}.md` - Visão geral do projeto
+- Lista de fluxos para documentar com `/document`
+
+**Gate de Saída:**
+```
+[ ] Stack identificada
+[ ] Estrutura mapeada
+[ ] Fluxos principais listados
+```
+
+**Próximo Passo:** Para cada fluxo identificado → `/document [fluxo]`
+
+---
+
+### Fase 4: DESIGN SYSTEM (Exceto --no-design)
+
+> [!NOTE]
+> **Pulado se:** Flag `--no-design` ou projeto é API/Backend puro.
+
+> [!IMPORTANT]
+> **SKILL OBRIGATÓRIA:** Seguir `ui-ux-discovery` para perguntas granulares.
+> **WORKFLOW:** Executar `/ui-ux-pro-max` para obter recomendações profissionais.
+
+**Objetivo:** Definir UI/UX e Design System com base em decisões do usuário.
+
+**Trigger:**
+```
+TDD aprovado (ou Fase 3 concluída)
+```
+
+**Agentes Envolvidos:**
+- `frontend-specialist` - Para projetos web
+- `mobile-developer` - Para projetos mobile
+
+---
+
+#### Processo Completo (Skill: ui-ux-discovery)
+
+> [!CAUTION]
+> **OBRIGATÓRIO:** Seguir TODOS os 5 passos definidos na skill `ui-ux-discovery`.
+> **NÃO** gerar Design System final sem respostas do usuário.
+
+| Passo | Ação | Detalhes |
+|-------|------|----------|
+| 1 | Executar `/ui-ux-pro-max` | Obter recomendações modernas |
+| 2 | **Perguntas Granulares ⭐** | Por aspecto: cores, tipografia, layout, efeitos, logo |
+| 3 | Aguardar Respostas | **BLOQUEADOR** - Não prosseguir sem resposta |
+| 4 | Consolidar Decisões | Combinar escolhas do usuário + recomendações |
+| 5 | Validar e Aprovar | Aguardar aprovação humana |
+
+**Gate de Saída:**
+```
+[ ] /ui-ux-pro-max executado
+[ ] Perguntas granulares respondidas pelo usuário
+[ ] Design System persistido
+[ ] Design System aprovado pelo humano
+```
+
+> [!CAUTION]
+> **BLOQUEADOR:** Não prosseguir para Flyee sem Design System aprovado (exceto --no-design).
+
+---
+
+### Fase 4.5: CONTENT STRATEGY (Exceto --no-content)
+
+> [!NOTE]
+> **Pulado se:** Flag `--no-content` ou projeto é API/Backend puro.
+
+> [!IMPORTANT]
+> **SKILL:** Seguir `content-strategy` para definição de copy e conteúdo.
+> **Documento:** `docs/content/CONTENT-STRATEGY-{nome}.md`
+
+| Passo | Ação | Detalhes |
+|-------|------|----------|
+| 1 | Identificar Páginas | Listar todas as páginas que precisam de conteúdo |
+| 2 | **Perguntas ao Usuário ⭐** | Tom de voz, público, USP, pricing |
+| 3 | Gerar Documento | Hero, Features, FAQ, SEO metadata |
+| 4 | Validar e Aprovar | Aguardar aprovação humana |
+
+**Gate de Saída:**
+```
+[ ] CONTENT-STRATEGY-{nome}.md gerado
+[ ] Copy da LP definido
+[ ] Conteúdo aprovado pelo humano
+```
+
+> [!CAUTION]
+> **BLOQUEADOR:** Não prosseguir para Flyee sem Content Strategy aprovado (exceto --no-content).
+
+---
+
+### Fase 5: TASK INTEGRATION (Automático após aprovação)
+
+> [!CAUTION]
+> **GATE PRÉ-INTEGRAÇÃO: ESCOLHA DE TRACKING**
+> 
+> Antes de criar tarefas, verifique a configuração `Tracker de Tasks`.
+> Se não estiver definida, pergunte ao usuário:
+> *“Como deseja registrar as tarefas?”* (1. Flyee vs 2. Local `docs/TASKS.md`)
+> 
+> **Se Tracker = Local:** Pule a repetição Flyee e grave as tasks diretamente em `docs/TASKS.md`.
+> **Se Tracker = Flyee:** Prossiga com a Criação via Bridge abaixo.
+
+#### Fase 5.1: TASK CREATION (Execution)
+
+**Trigger:** Usuário aprova User Stories
+
+**Ações (Para CADA User Story):**
+1. Ler documento `USER-STORIES-{nome}.md`
+2. **Executar Bridge CLI:**
+
+```bash
+python3 .agent/flyee-bridge/bridge.py --create-task \
+  --name "{Título da Task}" \
+  --type implement_feature \
+  --description "User Story: As a {user}, I want {action}, so that {benefit}. ACs: 1. Criteria 1" \
+  --priority high
+```
+
+> [!CAUTION]
+> A estimativa de complexidade ou horas deve constar na description se necessário, ou usar as flags adequadas do script.
+
+#### 🔔 FLYEE BRIDGE EMIT (Condicional)
+
+> Se `flyee.json` existe E `enabled: true`:
+
+```bash
+python .agent/flyee-bridge/bridge.py emit "dev.workflow_completed" '{"workflow": "discovery", "project": "{nome}"}'
+
+# Registrar decisões de Design System (se Fase 4 executada):
+python3 .agent/flyee-bridge/bridge.py --create-decision \
+  --decision "Design System definido: {resumo — ex: dark theme, Inter font, shadcn/ui}" \
+  --category design_system \
+  --reason "Decisões tomadas na Fase 4 do Discovery" \
+  --impact "Todos os componentes UI do projeto"
+
+# Registrar decisão de stack/arquitetura (se Fase 0.1 ou TDD executado):
+python3 .agent/flyee-bridge/bridge.py --create-decision \
+  --decision "Stack definida: {resumo — ex: Next.js 14, FastAPI, PostgreSQL}" \
+  --category architecture \
+  --reason "Decisão do TDD/SDD aprovado pelo usuário" \
+  --impact "Estrutura base de todo o projeto"
+```
+
+> Se bridge não configurado → Pular silenciosamente.

package/core/workflows/document.md

@@ -0,0 +1,272 @@
+---
+description: Document existing flows and processes for testing and future implementations
+skills: document-registry
+---
+
+# /document
+
+> Documentar fluxos e processos existentes para servir como referência em testes e novas implementações.
+
+## When to Use
+
+- Documentar um processo/fluxo existente no projeto
+- Criar base para criação de testes automatizados
+- Orientar futuras implementações relacionadas
+- Onboarding de novos desenvolvedores
+
+---
+
+## 🔀 QUANDO USAR `/document` vs `/legacy-project`?
+
+> [!TIP]
+> **Escolha o workflow certo:**
+
+| Situação | Use | Por quê? |
+|----------|-----|----------|
+| Documentar **UM fluxo** específico | `/document [fluxo]` | Focado, rápido |
+| Documentar **PROJETO INTEIRO** | `/legacy-project [path]` | Análise completa + SDD Reverso |
+| Apenas **analisar estrutura** | `/discovery --from-project` | Mapeamento inicial |
+| **Modernizar** projeto legado | `/legacy-project` → tasks | Fluxo completo |
+
+> [!NOTE]
+> `/document` é chamado internamente pelo `/legacy-project` na Phase 2.
+> Use `/document` standalone quando precisar documentar apenas um fluxo isolado.
+
+---
+
+## Prerequisites
+
+- [ ] Projeto existente com código funcionando
+- [ ] Conhecimento do fluxo a ser documentado (ou acesso ao código)
+
+---
+
+## 🚫 FLUXO: DISCOVER → ANALYZE → GENERATE → CROSS-REFERENCE
+
+---
+
+### 📚 Fase 0: DISCOVERY (Contexto)
+
+**Objetivo:** Identificar documentações existentes e estrutura do projeto.
+
+**Agente Envolvido:** `explorer-agent`
+
+1. **Verificar Index:**
+   - Checar `docs/INDEX.md` para documentações existentes
+   - Identificar documentos relacionados ao fluxo
+
+2. **Analisar Codebase:**
+   - Localizar arquivos envolvidos no fluxo
+   - Mapear dependências e integrações
+
+---
+
+### 🔍 Fase 1: ANÁLISE TÉCNICA
+
+**Objetivo:** Entender profundamente o fluxo.
+
+**Agentes Envolvidos:**
+- `backend-specialist` - Para fluxos de API/serviços
+- `frontend-specialist` - Para fluxos de UI/componentes
+- `mobile-developer` - Para fluxos mobile (React Native/Flutter)
+- `debugger` - Para entender comportamento e edge cases
+
+1. **Mapear Componentes:**
+   | Tipo | O que buscar |
+   |------|--------------|
+   | API/Routes | Endpoints envolvidos |
+   | Services | Lógica de negócio |
+   | Models | Estruturas de dados |
+   | UI | Componentes visuais |
+   | Events | Eventos disparados |
+
+2. **Identificar Fluxo:**
+   - Entrada → Processamento → Saída
+   - Validações aplicadas
+   - Tratamento de erros
+
+3. **Levantar Dependências:**
+   - Serviços externos
+   - Outros fluxos que este afeta
+   - Outros fluxos que afetam este
+
+---
+
+### 📝 Fase 2: GERAÇÃO DO DOCUMENTO
+
+**Objetivo:** Criar documentação estruturada.
+
+**Agente Envolvido:** `documentation-writer` (fallback: agente da Fase 1)
+
+**Template Obrigatório:**
+
+```markdown
+# {Nome do Fluxo}
+
+> {Descrição breve do propósito do fluxo}
+
+## Visão Geral
+
+[Diagrama Mermaid do fluxo - sequência ou flowchart]
+
+## Componentes Envolvidos
+
+| Arquivo | Responsabilidade | Linha/Função Principal |
+|---------|------------------|------------------------|
+| `path/to/file.ts` | Descrição | `functionName()` |
+
+## Fluxo Detalhado
+
+### 1. {Etapa 1}
+- Descrição
+- Validações
+- Possíveis erros
+
+### 2. {Etapa 2}
+...
+
+## Regras de Negócio
+
+| Regra | Descrição | Onde Aplicada |
+|-------|-----------|---------------|
+| RN-01 | ... | `file.ts:L42` |
+
+## Casos de Teste Essenciais
+
+### Happy Path
+- [ ] {Cenário de sucesso 1}
+- [ ] {Cenário de sucesso 2}
+
+### Edge Cases
+- [ ] {Caso limite 1}
+- [ ] {Caso limite 2}
+
+### Error Cases
+- [ ] {Cenário de erro 1}
+- [ ] {Cenário de erro 2}
+
+## Dependências
+
+### Este fluxo afeta:
+- {Outro fluxo/módulo}
+
+### Este fluxo é afetado por:
+- {Outro fluxo/módulo}
+
+## Documentos Relacionados
+
+- [{Doc relacionado 1}](./outro-doc.md)
+- [{Doc relacionado 2}](../architecture/sistema.md)
+```
+
+**Salvar em:** `docs/flows/{nome-do-fluxo}.md`
+
+---
+
+### 🔒 Fase 2.5: CODE-TRUTH VALIDATION (OBRIGATÓRIO)
+
+**Objetivo:** Garantir que TODA afirmação técnica no doc corresponde ao código real.
+
+> [!CAUTION]
+> **NÃO salvar o documento sem executar esta validação.**
+> Esta fase existe para impedir que documentação descreva estado planejado como se fosse
+> estado atual (ex: documentar "gateway Pagar.me ativo" quando o código tem Cielo).
+
+**Checklist de Validação:**
+
+1. **Para cada integração/gateway/API externa mencionada:**
+   - [ ] Arquivo/classe existe no codebase? (`find_by_name` / `grep_search`)
+   - [ ] Está registrado no enum/config correspondente?
+   - [ ] Se descrito como "ativo/implementado" → código NÃO é stub/mock?
+   - [ ] Se descrito como "planejado" → marcado com `⏳ PLANEJADO` no doc?
+
+2. **Para cada arquivo/componente referenciado:**
+   - [ ] Path existe?
+   - [ ] Funções/métodos citados existem na assinatura real?
+
+3. **Para cada enum/constante/config:**
+   - [ ] Valor confirmado contra o fonte real?
+
+**Se detectar divergência entre doc e código:**
+- Separar em seções distintas: `## Estado Atual` vs `## Estado Planejado`
+- Marcar estado planejado com `> ⏳ **Ainda não implementado no código**`
+- Registrar divergência como débito técnico
+
+### 🔗 Fase 3: CROSS-REFERENCE
+
+**Objetivo:** Manter consistência entre documentações.
+
+**Agente Envolvido:** `project-planner` (para visão sistêmica)
+
+1. **Atualizar INDEX:**
+   ```markdown
+   Adicionar entrada em docs/INDEX.md:
+   
+   | Fluxo | Descrição | Última Atualização |
+   |-------|-----------|-------------------|
+   | [{nome}](./flows/{nome}.md) | {desc} | {data} |
+   ```
+
+2. **Linkar Documentos Relacionados:**
+   - Adicionar referência nos docs existentes que se relacionam
+   - Garantir links bidirecionais
+
+3. **Notificar:**
+   - Informar quais documentos foram atualizados
+
+---
+
+### 📢 Fase 4: PUBLICAÇÃO NO FLYEE
+
+**Objetivo:** Publicar documentação no Flyee para acesso sem repositório.
+
+> [!IMPORTANT]
+> **SKILL:** Seguir Flyee API → seção "DOCUMENTATION DATABASES" OBRIGATORIAMENTE.
+
+#### 4.1 — Documentação Técnica (SEMPRE)
+
+1. Buscar database "Documentação Técnica" (skill → "DATABASE 1")
+2. Verificar upsert (doc já existe?)
+3. Criar/atualizar página com template correto
+4. Preencher propriedades: Nome, Módulo, Tipo=Fluxo, Status, Arquivo Local
+
+#### 4.2 — Manual do Usuário (SE fluxo de usuário)
+
+> Executar apenas se o fluxo documentado é visível para o usuário final ou operador.
+
+1. Buscar database "Manual do Usuário" (skill → "DATABASE 2")
+2. Verificar se guia correspondente já existe
+3. Gerar versão em linguagem acessível (sem código, sem componentes)
+4. Criar/atualizar página com template de guia do usuário
+5. Preencher propriedades: Nome, Seção, Status, Público-alvo
+
+> [!TIP]
+> Se o fluxo é puramente backend (ex: cron jobs, migrations), pular 4.2.
+> Se o fluxo tem interface visível (ex: checkout, login), executar 4.2.
+
+---
+
+## Output
+
+| Artefato | Local |
+|----------|-------|
+| Documentação do fluxo | `docs/flows/{nome-do-fluxo}.md` |
+| Index atualizado | `docs/INDEX.md` |
+| Docs relacionados atualizados | Links bidirecionais |
+| Página Flyee (técnica) | Database "Documentação Técnica" |
+| Página Flyee (manual) | Database "Manual do Usuário" (se aplicável) |
+
+---
+
+## Examples
+
+```bash
+# Documentar fluxo de cadastro de produtos
+/document cadastro de produtos
+
+# Documentar fluxo de autenticação
+/document autenticação OAuth
+
+# Documentar processo de pagamento
+/document checkout e pagamento
+```