ai-dev-workflow-cli 0.0.0-stage → 0.5.0

package/payload/central/CLAUDE.md

@@ -0,0 +1,7 @@
+@./AGENTS.md
+@./.ai-dev-workflow/docs/WORKFLOW.md
+@./.ai-dev-workflow/rules/general.md
+@./.ai-dev-workflow/rules/security.md
+@./.ai-dev-workflow/rules/git-workflow.md
+@./.ai-dev-workflow/rules/cost-control.md
+@./.ai-dev-workflow/rules/database.md

package/payload/central/GEMINI.md

@@ -0,0 +1,7 @@
+@./AGENTS.md
+@./.ai-dev-workflow/docs/WORKFLOW.md
+@./.ai-dev-workflow/rules/general.md
+@./.ai-dev-workflow/rules/security.md
+@./.ai-dev-workflow/rules/git-workflow.md
+@./.ai-dev-workflow/rules/cost-control.md
+@./.ai-dev-workflow/rules/database.md

package/payload/central-v0.2/.ai-dev-workflow/agents/architect.md

@@ -0,0 +1,5 @@
+# Papel: Architect / Planner
+
+Novo projeto: requisitos, trade-offs, ADR, componentes e esquema inicial. Legado: planejar mudança preservando contratos. Sempre listar critérios de aceitação, riscos, estimativa qualitativa, dependências, migração, testes e rollback. Não criar implementação sem G4.
+
+Em projeto novo, planejar bootstrap em P04 sobre baseline de pré-implementação aprovada em G3; não antecipar scaffold. Registrar modo do banco herdado/escolhido, DB_CHANGE e DB_EXEC separados de G4. Em MANUAL_SQL planejar entrega de SQL e roteiro conforme DATABASE_CHANGE, sem execução. Usar a matriz de regras e IDs canônicos de DECISIONS.

package/payload/central-v0.2/.ai-dev-workflow/agents/developer.md

@@ -0,0 +1,5 @@
+# Papel: Developer
+
+Entrada: task com G4, branch dedicada e baseline. Implementar escopo mínimo, preservar estilo/versões, validar inputs e autorizacão, evitar segredos. Não atualizar dependências por conveniência. Escrever testes proporcionais. Verificar diff e relatar mudanças; nunca push/merge/deploy sozinho.
+
+Novo projeto: a primeira task pode criar somente o bootstrap aprovado em G4 sobre baseline de pré-implementação G3. Seguir a matriz de regras. Banco: MANUAL_SQL por padrão; preparar arquivos e roteiro de DATABASE_CHANGE sem executar escrita. Outros modos exigem escolha humana, G2, DB_CHANGE e DB_EXEC específicos; produção exige G6. G4 nunca substitui autorização de banco.

package/payload/central-v0.2/.ai-dev-workflow/agents/discovery.md

@@ -0,0 +1,5 @@
+# Papel: Discovery
+
+**Entrada:** repositório existente autorizado. **Permissão:** leitura. Inspecionar `composer.json` + lock, `package.json` + lock, migrations, rotas, Docker, CI, READMEs e configuração sem exibir segredos. Diferenciar versões declaradas vs instaladas. Mapear pontos de entrada, dependências, autenticação, dados e riscos. **Saída:** `.ai-dev-workflow/templates/DISCOVERY.md` preenchido; solicitar G1. Proibido instalar/executar migrations.
+
+Carregar a matriz de regras. Confirmar isolamento Git antes de qualquer alteração futura; identificar motor/versão de banco somente por evidências autorizadas e sem segredos. Não executar escrita. Registrar MANUAL_SQL como padrão pendente de escolha explícita; Discovery/G1 não autoriza operações de banco.

package/payload/central-v0.2/.ai-dev-workflow/agents/documentation.md

@@ -0,0 +1,5 @@
+# Papel: Documentation / Delivery
+
+Atualize CHANGELOG quando aplicável, task report, CURRENT_STATE, evidências de testes e passos de rollback. Preparar descrição do PR; identificar alterações e validação pendente. Nunca publicar segredos ou dados de produção. Merge e deploy são ações humanas autorizadas.
+
+Referenciar IDs do registro canônico DECISIONS e preservar histórico, sem inventar aprovações. Registrar modo efetivo de banco, revisões dos SQL, executor e autorizações DB_CHANGE/DB_EXEC quando aplicáveis. Em MANUAL_SQL entregar instruções de phpMyAdmin e evidências fornecidas pelo humano; marcar execução não realizada pelo agente. Seguir a matriz de regras.

package/payload/central-v0.2/.ai-dev-workflow/agents/environment.md

@@ -0,0 +1,3 @@
+# Papel: Environment
+
+**Entrada:** Discovery aprovado (existente) ou REQUIREMENTS/ARCHITECTURE aprovados (novo), com G1. Criar plano de ambiente reproduzível local (Docker opcional se apropriado), fixar versões compatíveis, portas, variáveis de exemplo, volumes e armazenamento. Confirmar sistema operacional e arquitetura CPU. Não conectar à produção. Mostrar comandos antes de executar; G2 aprova somente o ambiente. Não criar scaffold antes da task de bootstrap com G4. Banco começa em MANUAL_SQL; inicialização, seed ou migrations exigem os controles separados de `.ai-dev-workflow/rules/database.md`. Saída `ENVIRONMENT.md`.

package/payload/central-v0.2/.ai-dev-workflow/agents/reviewer.md

@@ -0,0 +1,5 @@
+# Papel: Reviewer / QA
+
+Revise diff, riscos, permissões, tratamento de dados, cobertura de casos de borda e integridade do banco. Execute somente testes permitidos no ambiente correto. Registre comandos, saídas resumidas e falhas. Diferencie não testado de aprovado. Recomende ou bloqueie G5. Para sistemas de votação, revisar concorrência, unicidade e logs sem dados pessoais.
+
+Em P03 de projeto novo sem aplicação, registrar baseline de pré-implementação, lacunas e verificações possíveis; não exigir scaffold anterior a G4. Em P06 do bootstrap, registrar baseline executável preservando a anterior. Conferir matriz, IDs e revisões de aprovações. Revisão de SQL em MANUAL_SQL é documental; não executar escrita para validar. Testes que alterem banco seguem modo e DB_EXEC de `.ai-dev-workflow/rules/database.md`; G5 não concede execução.

package/payload/central-v0.2/.ai-dev-workflow/docs/WORKFLOW.md

@@ -0,0 +1,58 @@
+# Workflow e critérios de transição
+
+## Trilhas
+**Existente:** P01 Discovery → G1 → P02 Environment → G2 → P03 Baseline → G3 → P04 Planning → G4 → P05 Development → P06 Validation → G5 → P07 Delivery → G6 (produção quando aplicável).
+
+**Novo:** P00 Requirements & Architecture → G1 → P02 Environment → G2 → P03 Baseline de pré-implementação → G3 → P04 Planning → G4 → P05 Development → P06 Validation → G5 → P07 Delivery → G6.
+
+O G0 (autorização de compartilhamento de código/dados com terceiros) vem **antes** de qualquer integração externa. Pode-se trabalhar inteiramente local sem compartilhar dados.
+
+| Fase | Responsável (papel) | Saída verificável | Próximo passo requer |
+| --- | --- | --- | --- |
+| P00 Requirements (novo) | architect | escopo, requisitos, decisões | G1 |
+| P01 Discovery (existente) | discovery | DISCOVERY preenchido; stack confirmada | G1 |
+| P02 Environment | environment | ENVIRONMENT + instruções reproduzíveis | G2 |
+| P03 Baseline | reviewer | BASELINE com smoke/testes e lacunas; pré-implementação se novo sem aplicação | G3 |
+| P04 Planning | architect | task + critérios de aceitação/rollback | G4 |
+| P05 Development | developer | diff mínimo, sem deploy | P06 |
+| P06 Validation | reviewer | relatório de testes e revisão independente | G5 |
+| P07 Delivery | documentation | docs, PR e release checklist | G6 se houver deploy |
+
+## Bootstrap de projeto novo
+P00 produz REQUIREMENTS e ARCHITECTURE com stack aprovada em G1. P02 aceita esses documentos no lugar de Discovery e prepara o ambiente; G2 aprova sua configuração, sem autorizar banco.
+
+Em P03, antes de existir aplicação, o reviewer registra baseline de pré-implementação: inventário real, ferramentas verificadas, verificações possíveis sem aplicação e testes indisponíveis. G3 aprova esse ponto de partida e suas lacunas, sem declarar funcionalidades aprovadas.
+
+Em P04, o architect cria uma task de bootstrap com arquivos, comandos, versões, critérios e testes. Somente após G4 o developer cria o esqueleto em P05. P06 verifica o bootstrap, registra resultados e acrescenta baseline executável preservando a referência anterior. Depois de G5, tasks funcionais usam essa baseline. Nenhum scaffold ou instalação que o gere pode antecipar G4; instalação de ferramentas em P02 deve estar no escopo aprovado de G1. Banco segue os controles próprios abaixo.
+
+## Como registrar aprovação humana
+`docs/project/DECISIONS.md` é a fonte canônica. Tasks, relatórios e CURRENT_STATE referenciam seus IDs; não duplicam decisões como fontes independentes. Antes da primeira task, registrar no mesmo arquivo as decisões do projeto. Evidência de autorização explícita na conversa pode ser transcrita de forma sanitizada; o agente registra, mas não se autoaprova.
+
+Cada registro contém ID, portão/tipo (G0–G6, DB_MODE, DB_CHANGE, DB_EXEC), estado, data, responsável humano, referência da manifestação, ação, escopo, ambiente/alvo, executor e artefato/revisão aprovada (commit, hash ou revisão documental identificável), restrições e validade.
+
+Estados: **pendente**, **aprovado**, **rejeitado**, **revogado**, **revalidação pendente**. Ausência de resposta não autoriza nada. Rejeição bloqueia a ação; revogação suspende autorização futura. Mudança relevante em escopo, alvo, modo, comandos, riscos ou artefato aprovado exige revalidação humana antes de prosseguir; alterações após G5 retornam à revisão quando afetarem o conteúdo validado. Preservar o histórico acrescentando registros que referenciem o ID anterior. Nova aprovação após rejeição/revogação não apaga o histórico.
+
+## Controle de execução de banco
+`.ai-dev-workflow/rules/database.md` é obrigatório sempre que houver banco, inclusive bootstrap, testes, seeds e scripts indiretos. Modo padrão por projeto e task: **MANUAL_SQL**; alternativas **AUTOMATIC_LOCAL** e **PRODUCTION_CONTROLLED** dependem de escolha humana registrada. G2 aprova ambiente; DB_CHANGE aprova a mudança; DB_EXEC autoriza a execução concreta. G4 não autoriza escrita. Produção exige ainda G6, backup validado, plano de execução, validação e rollback. Em MANUAL_SQL entregar SQL e roteiro de phpMyAdmin conforme `.ai-dev-workflow/templates/DATABASE_CHANGE.md`, sem executar alterações.
+
+## Matriz de leitura obrigatória
+Antes de atuar, carregar AGENTS, este workflow, papel da fase, contexto e task existentes. Não presumir carregamento automático por citar caminhos. Todas as fases leem `.ai-dev-workflow/rules/general.md`, `.ai-dev-workflow/rules/security.md`, `.ai-dev-workflow/rules/git-workflow.md` e `.ai-dev-workflow/rules/cost-control.md`.
+
+| Fase | Papel | Regras adicionais obrigatórias | Artefatos de referência |
+| --- | --- | --- | --- |
+| P00 | architect | database se houver dados persistidos | REQUIREMENTS, ARCHITECTURE, DECISIONS |
+| P01 | discovery | database se houver banco | DISCOVERY, DECISIONS |
+| P02 | environment | testing; database se houver banco | ENVIRONMENT, DECISIONS |
+| P03 | reviewer | testing; database se houver banco | BASELINE, DECISIONS |
+| P04 | architect | testing; database se houver banco | TASK, DATABASE_CHANGE quando aplicável |
+| P05 | developer | testing; database se houver banco | TASK, TASK_REPORT |
+| P06 | reviewer | testing; database se houver banco | TASK, TASK_REPORT, BASELINE |
+| P07 | documentation | testing; database se houver banco | TASK_REPORT, PR_CHECKLIST, CURRENT_STATE |
+
+Os nomes de regras adicionais correspondem a `.ai-dev-workflow/rules/<nome>.md`; os artefatos são modelos de `.ai-dev-workflow/templates/`. Aplicar `.ai-dev-workflow/stacks/*.md` somente após confirmar stack. Se a presença de banco for desconhecida, carregar database preventivamente. A matriz obriga leitura, não concede execução.
+
+## Regras de paradas
+Interrompa se identificar: credenciais expostas, produção confundida com local, dados reais em testes, incompatibilidade crítica, falha de integridade, comportamento inesperado no baseline, instruções contraditórias, custo não autorizado ou necessidade de ação destrutiva.
+
+## Saída mínima por fase
+Evidências observadas, comandos executados, falhas, riscos, decisão pendente e o que *não* foi verificado. Nunca afirmar que algo está funcional só por haver arquivos.

package/payload/central-v0.2/.ai-dev-workflow/integrations/codex/README.md

@@ -0,0 +1,14 @@
+# Codex
+
+O arquivo `AGENTS.md` na raiz é a entrada das regras do agente. Referencie explicitamente as demais regras, templates e arquivos de contexto nos pedidos; verifique o comportamento da sua instalação do Codex. Abra uma fase por vez. Sugestão de primeiro pedido:
+
+> Leia AGENTS.md, .ai-dev-workflow/docs/WORKFLOW.md e docs/project/CURRENT_STATE.md (se existir). Estamos na fase P01 Discovery de projeto existente. Trabalhe somente leitura, gere diagnóstico no modelo .ai-dev-workflow/templates/DISCOVERY.md, sem executar comandos que mudam estado. Apresente evidências e solicite aprovação G1.
+
+Mantenha operações destrutivas, Git push/merge e deploy sob confirmação humana e controle de permissões.
+
+Antes de atuar, carregue a matriz em `.ai-dev-workflow/docs/WORKFLOW.md` e confira isolamento conforme `.ai-dev-workflow/rules/git-workflow.md`. Registre aprovações somente em DECISIONS, referenciando IDs. Para banco, aplique `.ai-dev-workflow/rules/database.md`: MANUAL_SQL padrão; G4 não autoriza execução. Não executar migrations/seeders/escrita sem modo permitido e DB_EXEC específico. Essas regras não substituem permissões técnicas.
+
+## Produção e SQL
+Produção permanece bloqueada por padrão. Operações de produção exigem as autorizações humanas específicas do workflow, incluindo G6 para a ação e o ambiente concretos. Operações de banco exigem também G2, DB_CHANGE e DB_EXEC aplicáveis, com executor, alvo e revisão dos scripts identificados; produção exige backup validado, plano de execução, validação e rollback. G4, G5 ou G6 não implicam autorização automática para executar SQL.
+
+MANUAL_SQL permanece como modo padrão: o agente apenas prepara os arquivos SQL e as instruções; a execução é responsabilidade humana, sujeita às autorizações aplicáveis. Nenhuma ferramenta deve executar comandos de escrita no banco sem autorização explícita para a operação e o ambiente. Para execução pelo agente, exigir também modo permitido escolhido pelo humano conforme `.ai-dev-workflow/rules/database.md`; DB_EXEC humano não autoriza execução pelo agente. Essas instruções não substituem permissões técnicas.

package/payload/central-v0.2/.ai-dev-workflow/integrations/continue/README.md

@@ -0,0 +1,19 @@
+# Continue
+
+A pasta `.continue/rules/` contém regras e `.continue/prompts/` contém comandos reutilizáveis. A sintaxe e interface podem mudar entre versões; valide que o Continue reconhece cada arquivo antes de depender dele. O modelo precisa oferecer suporte às funcionalidades desejadas (ferramentas/edit/agent).
+
+1. Abra o projeto no VS Code.
+2. Confira se os prompts aparecem ao digitar `/`.
+3. Em projetos sensíveis prefira Chat e forneça apenas contexto autorizado.
+4. Não presumir que o Continue herda todas as instruções do Codex ou vice-versa: se necessário, inclua `AGENTS.md` como contexto autorizado.
+5. OpenRouter e outros provedores online recebem conteúdo enviado para inferência; obtenha G0 e jamais transmita `.env`, segredos, dados reais ou código corporativo sem aprovação.
+6. Verifique custo, limite da API Key e funções de autocomplete automático antes de habilitá-las.
+
+A regra global da extensão pode exigir instalação ou configuração adicional; o exemplo aqui é local ao workspace do projeto.
+
+Antes de atuar, carregue a matriz em `.ai-dev-workflow/docs/WORKFLOW.md` e confira isolamento conforme `.ai-dev-workflow/rules/git-workflow.md`. Registre aprovações somente em DECISIONS, referenciando IDs. Para banco, aplique `.ai-dev-workflow/rules/database.md`: MANUAL_SQL padrão; G4 não autoriza execução. Não executar migrations/seeders/escrita sem modo permitido e DB_EXEC específico. Essas regras não substituem permissões técnicas.
+
+## Produção e SQL
+Produção permanece bloqueada por padrão. Operações de produção exigem as autorizações humanas específicas do workflow, incluindo G6 para a ação e o ambiente concretos. Operações de banco exigem também G2, DB_CHANGE e DB_EXEC aplicáveis, com executor, alvo e revisão dos scripts identificados; produção exige backup validado, plano de execução, validação e rollback. G4, G5 ou G6 não implicam autorização automática para executar SQL.
+
+MANUAL_SQL permanece como modo padrão: o agente apenas prepara os arquivos SQL e as instruções; a execução é responsabilidade humana, sujeita às autorizações aplicáveis. Nenhuma ferramenta deve executar comandos de escrita no banco sem autorização explícita para a operação e o ambiente. Para execução pelo agente, exigir também modo permitido escolhido pelo humano conforme `.ai-dev-workflow/rules/database.md`; DB_EXEC humano não autoriza execução pelo agente. Essas instruções não substituem permissões técnicas.

package/payload/central-v0.2/.ai-dev-workflow/rules/cost-control.md

@@ -0,0 +1,6 @@
+# Controle de custo da IA
+- Dar tarefa curta, com caminhos e critérios explícitos; evitar anexar repositório inteiro.
+- Reusar CURRENT_STATE e task para não repetir análise.
+- Escolher modelos baratos/gratuitos para perguntas genéricas; modelo principal para mudanças críticas.
+- Cotas `:free` têm limites e podem mudar; modelos online podem processar contexto por terceiros.
+- Desligar ferramentas/autocomplete automático quando não necessários; verificar consumo do provedor.

package/payload/central-v0.2/.ai-dev-workflow/rules/database.md

@@ -0,0 +1,46 @@
+# Banco de dados — controle obrigatório
+
+## Modo por projeto e por tarefa
+Registrar o modo do projeto em `docs/project/ENVIRONMENT.md` e a seleção efetiva em cada task. Sem escolha humana explícita, usar **MANUAL_SQL**. A task herda o modo do projeto; qualquer substituição exige escolha humana registrada em DECISIONS. Escolher um modo não autoriza executar operações.
+
+| Modo | Preparação | Execução pelo agente |
+| --- | --- | --- |
+| MANUAL_SQL | SQL versionado por task e roteiro para execução humana no phpMyAdmin | Proibida qualquer alteração de banco, mesmo local |
+| AUTOMATIC_LOCAL | Plano, scripts/migrations e verificações | Somente local ou ambiente isolado confirmado, com G2, DB_CHANGE e DB_EXEC aprovados |
+| PRODUCTION_CONTROLLED | Plano específico de produção, backup validado, validação e rollback | Somente com G2 do alvo, DB_CHANGE, DB_EXEC e G6 específicos aprovados; respeitar permissões da ferramenta |
+
+MANUAL_SQL é o padrão inclusive quando a stack oferece migrations. Não executar migrations, seeders, SQL de escrita, inicialização de bases, testes ou scripts que modifiquem banco sem autorização específica. Em MANUAL_SQL o agente apenas prepara os artefatos; para executar deve haver mudança explícita de modo e autorização separada. Testes com escrita também contam como execução de banco.
+
+## Aprovações cumulativas e independentes
+- **G2:** aprova configuração, isolamento e destino do ambiente; não autoriza escrita.
+- **G4:** aprova a implementação da task; não autoriza modificar banco.
+- **DB_CHANGE:** aprova o plano da mudança de schema/dados, scripts, riscos, backup, validação e reversão. Não autoriza executá-lo.
+- **DB_EXEC:** autoriza uma execução concreta pelo executor identificado (humano ou agente), sobre alvo e artefato/revisão identificados, com janela, comandos e limites. Para execução manual humana, registrar também DB_CHANGE e DB_EXEC antes da execução; isso não concede execução ao agente.
+- **G6:** autoriza operação de produção concreta, cumulativa com os controles de banco quando aplicáveis.
+
+Registrar os IDs e estados conforme `.ai-dev-workflow/docs/WORKFLOW.md`. Um mesmo pedido humano pode conceder várias aprovações apenas se explicitar cada ação e alvo. Nunca inferir DB_EXEC de G2, G4, G5, G6 ou da escolha de modo. Após mudança de script, alvo ou escopo, suspender execução até revalidação. DB_EXEC vale para a execução registrada; repetição ou retry exige autorização específica, salvo se já delimitado explicitamente.
+
+## Preparação e verificação do alvo
+Inspecionar schema, FKs, índices e migrations antes de propor mudança. Confirmar motor, versão real, host/ambiente, banco, privilégios e isolamento sem registrar credenciais. Não usar somente a versão declarada em dependências. Se essas evidências faltarem, solicitar metadados sanitizados e bloquear o SQL executável dependente delas. Separar conexões por ambiente; não usar produção como fixture sem anonimização aprovada. Dados reais continuam sujeitos às regras de privacidade.
+
+## Entrega MANUAL_SQL
+Usar `.ai-dev-workflow/templates/DATABASE_CHANGE.md` e `docs/tasks/TASK-XXX/sql/`:
+- `01-precheck.sql`: consultas de leitura sobre versão, schema e pré-condições, sem dados pessoais.
+- `02-change.sql`: alteração revisável, compatível com a versão real do MySQL ou MariaDB, charset/collation, engine e SQL mode confirmados.
+- `03-postcheck.sql`: consultas de leitura com resultados esperados e critérios de falha.
+- `04-rollback.sql`: somente quando tecnicamente seguro; caso contrário documentar irreversibilidade e restauração/compensação necessária.
+- `README.md`: ordem e seleção do banco no phpMyAdmin, conferência do alvo e versão, backup necessário e validação de restauração, autorizações, execução manual por etapas, resultados esperados, riscos e condições de parada. Não colar credenciais ou resultados sensíveis.
+
+Os SQL são artefatos da task; nenhum é executado automaticamente. Não prometer rollback transacional de DDL nem reversão de perda de dados; avaliar suporte e commits implícitos na versão confirmada. Registrar locks, impacto, dependências e risco de repetição. Idempotência somente quando demonstrável. Se phpMyAdmin/motor MySQL ou MariaDB não se aplicar, preservar MANUAL_SQL sem execução e acordar interface e dialeto reais antes de preparar a entrega; nunca presumir stack.
+
+## Restrições
+`DROP`, `TRUNCATE`, `DELETE` sem filtro, `migrate:fresh`, `db:wipe` e equivalentes continuam proibidos sem autorização específica da ação destrutiva. Um plano de rollback destrutivo também precisa de autorização para execução. Não executar rollback automaticamente. Migrations são uma opção de implementação versionada, nunca uma autorização implícita.
+
+Antes da entrega, verificar se os SQL revisados da task não estão ignorados pelo Git. Scripts de precheck, alteração aprovada, postcheck e reversão podem ser versionados em `docs/tasks/TASK-XXX/sql/`; backups, dumps e arquivos sensíveis devem permanecer nos locais ignorados e fora da entrega. Sinalizar qualquer exclusão inesperada, sem forçar staging ou alterar proteções implicitamente.
+
+O Git e o `.gitignore` não garantem ausência de dados sensíveis: arquivos já rastreados e SQL fora dos diretórios protegidos exigem inspeção. Todo SQL deve passar por revisão humana de conteúdo, dados, alvo e riscos antes de ser versionado. Não incluir dumps, credenciais, dados pessoais ou dados reais; scripts de dados devem usar conteúdo sintético ou parâmetros sem valores sensíveis. Poder versionar um arquivo não autoriza executar seu SQL nem fazer commit/push.
+
+## Bloqueio padrão de produção e ferramentas
+Produção permanece bloqueada por padrão. Operações de produção exigem as autorizações humanas específicas do workflow, incluindo G6 para a ação e o ambiente concretos. Operações de banco exigem também G2, DB_CHANGE e DB_EXEC aplicáveis, com executor, alvo e revisão dos scripts identificados; produção exige backup validado, plano de execução, validação e rollback. G4, G5 ou G6 não implicam autorização automática para executar SQL.
+
+MANUAL_SQL permanece como modo padrão: o agente apenas prepara os arquivos SQL e as instruções; a execução é responsabilidade humana, sujeita às autorizações aplicáveis. Nenhuma ferramenta deve executar comandos de escrita no banco sem autorização explícita para a operação e o ambiente. Para execução pelo agente, exigir também modo permitido escolhido pelo humano conforme `.ai-dev-workflow/rules/database.md`; DB_EXEC humano não autoriza execução pelo agente. Essas instruções não substituem permissões técnicas.

package/payload/central-v0.2/.ai-dev-workflow/rules/general.md

@@ -0,0 +1,7 @@
+# Regras gerais
+- Confirmar trilha e fase.
+- Basear afirmações em arquivos/comandos reais e citar caminhos.
+- Alterações mínimas e reversíveis; evitar escopo ampliado.
+- Separar fatos, hipóteses e recomendações.
+- Declarar impedimentos, não esconder testes não executados.
+- Resumo final: objetivo, diff, testes, riscos, próximos passos.

package/payload/central-v0.2/.ai-dev-workflow/rules/git-workflow.md

@@ -0,0 +1,16 @@
+# Git workflow
+- Inspecionar `git status` antes de iniciar; não sobrescrever alterações preexistentes.
+- Trabalhar em `feature/TASK-xxx-descricao`, `fix/TASK-xxx-descricao`, `docs/TASK-xxx-descricao` conforme o caso.
+- Branch protegida (`main`/`master`); nunca push/merge sem autorização.
+- Commit pequeno e descritivo `feat:`, `fix:`, `docs:`, `test:`, `chore:`.
+- Revisar diff, conflitos, segredos e arquivos não rastreados; PR inclui testes, risco e rollback.
+
+## Verificação de isolamento antes de alterações
+Executar no diretório autorizado: `pwd`, `git rev-parse --show-toplevel`, `git rev-parse --absolute-git-dir`, `git rev-parse --git-common-dir`, `git status --short --branch` e `git symbolic-ref --short HEAD`. Confirmar caminhos reais, inclusive symlinks, e comparar a raiz com o projeto autorizado. Repositórios aninhados, submódulos ou worktrees com metadados externos exigem confirmação do escopo antes de qualquer escrita Git. HEAD destacado exige branch de task antes de editar.
+
+Se a raiz for um diretório pai ou outro projeto, interromper alterações. Não executar `git add`, criar branch ou inicializar repositório nesse pai; não apagar/mover seu `.git`. Pedir definição explícita do limite correto. Não sobrescrever alterações preexistentes; arquivos não rastreados também são trabalho existente.
+
+## Inicialização segura
+Inicializar somente mediante autorização explícita para o diretório concreto, após confirmar caminho real e ausência de `.git` local. Se um pai já for repositório, informar que será criado um repositório aninhado e obter autorização específica. Não modificar o repositório pai nem aplicações vizinhas.
+
+No diretório confirmado, `git init` cria apenas os metadados locais; conferir novamente a raiz e o git-dir. Criar branch dedicada com `git switch -c docs/TASK-XXX-descricao` (ou feature/fix conforme tarefa), inclusive sem commits, e verificar a branch efetiva antes de editar. Se falhar por permissões ou versão da ferramenta, parar e resolver sem alterar em main. Não usar `git add .`, commit inicial, remote ou push como parte implícita da inicialização. Branch de task não autoriza commit/push/merge.

package/payload/central-v0.2/.ai-dev-workflow/rules/security.md

@@ -0,0 +1,11 @@
+# Segurança e privacidade
+- Autorização G0 para transmitir código/dados a IA externa; respeitar contrato/política da organização.
+- Não abrir/transmitir `.env`, tokens, dumps reais, dados pessoais ou segredos; não versionar chaves de API.
+- Não executar ações destrutivas/produção sem aprovação explícita e específica; conferir alvo `APP_ENV`, host, banco e branch.
+- Proteção por permissões de ferramenta, ambiente e revisão humana; prompts não são barreiras de segurança.
+- Para acesso à nuvem, aplicar princípio do menor privilégio.
+- Redigir evidências com dados sintéticos, nunca credenciais.
+
+- Para banco, G2/G4 não autorizam escrita: aplicar modo efetivo, DB_CHANGE e DB_EXEC de `.ai-dev-workflow/rules/database.md`; produção exige G6 específico e backup validado.
+
+G4, G5 e G6 não substituem DB_EXEC. Produção permanece bloqueada por padrão; qualquer escrita por ferramentas exige autorização explícita da operação, ambiente e executor, em modo permitido. Em MANUAL_SQL a execução é humana; o agente apenas prepara os artefatos. Git e .gitignore não garantem ausência de dados sensíveis: revisar todo SQL antes de versionar e manter dumps/backups/segredos fora da entrega.

package/payload/central-v0.2/.ai-dev-workflow/rules/testing.md

@@ -0,0 +1,6 @@
+# Testes e evidências
+- Baseline antes de refatorar legado.
+- Preferir testes automatizados; smoke HTTP, autenticação, autorização, dados inválidos e regressões.
+- Registrar comando, ambiente, data, resultado e limitações.
+- Testes que alteram banco exigem base de teste isolada confirmada, G2, DB_CHANGE e DB_EXEC específicos, em AUTOMATIC_LOCAL. MANUAL_SQL permite apenas preparar o procedimento; não executar testes com escrita, mesmo com rollback. Seguir `.ai-dev-workflow/rules/database.md`.
+- Não reportar PASS sem execução.

package/payload/central-v0.2/.ai-dev-workflow/stacks/nodejs.md

@@ -0,0 +1,3 @@
+# Node.js — checklist
+- Verificar `package.json`, lockfile, Node, scripts, build, env, testes, gerenciador de pacotes, dependências e banco.
+- Instalar usando lockfile no ambiente autorizado, sem upgrades implícitos.

package/payload/central-v0.2/.ai-dev-workflow/stacks/php-laravel.md

@@ -0,0 +1,6 @@
+# PHP / Laravel — checklist
+- Identificar versões por `composer.json` e `composer.lock`, `php -v` se ambiente autorizado.
+- Mapear `artisan`, `routes/`, `app/`, `config/`, `database/migrations`, `tests/`.
+- Verificar versão do PHP, extensões, Composer, banco, Node e compatibilidade de pacotes.
+- Evitar atualizar Laravel/PHP durante mudanças urgentes; preparar plano em separado.
+- Comandos que criem/alterem banco, seeds e migrations seguem `.ai-dev-workflow/rules/database.md`: MANUAL_SQL por padrão; G2 não autoriza execução. Exigir modo permitido, DB_CHANGE e DB_EXEC específicos. Não executar escrita em MANUAL_SQL.

package/payload/central-v0.2/.ai-dev-workflow/stacks/php-native.md

@@ -0,0 +1,3 @@
+# PHP nativo — checklist
+- Identificar versão/extensões PHP, roteador/front controller, `.htaccess`/Nginx, composer (se existir), sessões, CSRF, SQL e estrutura pública.
+- Documentar configuração local, segurança e rotas sem reescrever arquitetura na Discovery.

package/payload/central-v0.2/.ai-dev-workflow/stacks/wordpress.md

@@ -0,0 +1,4 @@
+# WordPress — checklist
+- Inventariar WordPress, PHP, plugins, tema, hooks, banco, checkout e integrações.
+- Nunca atualizar plugins ou tocar em produção antes de backup e testes de staging.
+- Isolar dados pessoais e credenciais de provedores de pagamento.

package/payload/central-v0.2/.ai-dev-workflow/templates/ARCHITECTURE.md

@@ -0,0 +1,8 @@
+# Architecture — [projeto]
+## Contexto e limites
+## Componentes, responsabilidades e integrações
+## Diagrama (texto ou Mermaid)
+## Fluxos críticos e segurança
+## Modelo de dados (sem dados reais)
+## Decisões arquiteturais e trade-offs
+## Dívida técnica e plano futuro

package/payload/central-v0.2/.ai-dev-workflow/templates/BASELINE.md

@@ -0,0 +1,16 @@
+# Baseline — [projeto]
+Status G2: [...] | Status G3: pendente
+## Comportamento esperado antes da alteração
+## Fluxos testados
+| Cenário | Ambiente | Comando/procedimento | Resultado | Evidência |
+|---|---|---|---|---|
+## Falhas já existentes
+## Lacunas de cobertura
+## Riscos de regressão
+## Decisão G3
+
+## Projeto novo sem aplicação
+Tipo: [pré-implementação / executável] | Referência preservada da baseline anterior: [...]
+Inventário e ferramentas realmente verificadas: [...]
+Testes indisponíveis sem bootstrap e motivo: [...]
+G3 aprova ponto de partida e lacunas; não aprova funcionalidades inexistentes. Bootstrap só após G4; baseline executável registrada em P06.

package/payload/central-v0.2/.ai-dev-workflow/templates/CURRENT_STATE.md

@@ -0,0 +1,15 @@
+# Estado atual — [projeto]
+Atualizado em: [AAAA-MM-DD]
+## Trilha e fase atual
+## Stack e ambiente confirmado
+## Última task concluída / ativa
+## Funcionalidades verificadas
+## Mudanças locais não commitadas
+## Bloqueios e riscos
+## Aprovações pendentes (G0–G6)
+## Próximos passos em ordem
+## Referências de documentos / PRs
+
+## Modo de banco e aprovações canônicas
+Modo do projeto: MANUAL_SQL | Task e override humano (se houver): [...]
+IDs/revisões vigentes em DECISIONS, rejeições/revogações e revalidações pendentes: [...]

package/payload/central-v0.2/.ai-dev-workflow/templates/DATABASE_CHANGE.md

@@ -0,0 +1,31 @@
+# TASK-XXX — Plano e controle de banco
+## Modo e evidências
+Modo do projeto: [MANUAL_SQL por padrão; herdar escolha humana vigente] | Modo da task: [...]
+DB_MODE (escolha/override humano): [...] | Executor: [...]
+Motor e versão real: [...] | Evidência sanitizada: [...]
+Ambiente/alvo: [...] | Schema, engine, charset/collation e SQL mode: [...]
+Se desconhecido, bloquear SQL executável dependente dessas informações. Para outro motor/interface, acordar dialeto e procedimento sem alterar o modo implicitamente.
+## Aprovações canônicas
+G2: [...] | G4: [...] | DB_CHANGE: [...] | DB_EXEC: [...] | G6 se produção: [...]
+Revisão/hash dos scripts: [...] | Janela/validade/repetições autorizadas: [...]
+G4 e escolha de modo não autorizam escrita. MANUAL_SQL permite apenas preparação pelo agente.
+## Artefatos por task
+Pasta: `docs/tasks/TASK-XXX/sql/` (sem dumps, credenciais ou dados reais).
+- `01-precheck.sql`: versão, schema, pré-condições e resultados esperados.
+- `02-change.sql`: mudança compatível com o motor/versão confirmados.
+- `03-postcheck.sql`: invariantes e resultados esperados.
+- `04-rollback.sql`: reversão segura quando possível; ausência justificada abaixo.
+- `README.md`: roteiro manual de phpMyAdmin e referências das aprovações.
+## Riscos e backup
+Locks, indisponibilidade, perda de dados, commits implícitos, repetição e dependências: [...]
+Backup necessário, responsável, referência segura e evidência de restauração validada: [...]
+## Execução manual no phpMyAdmin
+Humano autorizado confirma servidor/banco/versão, backup e aprovações; abre a aba SQL do banco correto, executa precheck e confere resultados; executa a mudança aprovada por etapas; executa postcheck e registra evidências sanitizadas. Não prosseguir se pré-condições falharem. Não repetir nem executar reversão sem conferir autorização específica.
+Adaptar a interface e etapas à instalação real. O agente não executa nem simula resultados.
+## Validação e condições de parada
+Critérios de sucesso/falha, observações e responsável: [...]
+## Reversão ou compensação
+Possibilidade técnica, limitações transacionais/DDL, perda irrecuperável e restauração: [...]
+Comandos de reversão exigem autorização própria de execução; nunca rollback automático.
+## Resultado real
+Não executado / executor / data / evidências / desvios / IDs de autorizações: [...]

package/payload/central-v0.2/.ai-dev-workflow/templates/DECISIONS.md

@@ -0,0 +1,9 @@
+# Registro canônico de decisões e aprovações
+Única fonte de aprovações; tasks e estado referenciam IDs. Não registrar segredos. Preservar histórico por novos registros vinculados ao anterior.
+
+| ID | Data | Tipo/portão | Estado | Responsável humano / evidência da manifestação | Ação, escopo e ambiente/alvo | Executor | Artefato e revisão/hash | Restrições / validade | ID anterior / motivo |
+|---|---|---|---|---|---|---|---|---|---|
+
+Tipos: G0–G6, DB_MODE, DB_CHANGE, DB_EXEC ou ADR.
+Estados: pendente, aprovado, rejeitado, revogado, revalidação pendente.
+Rejeição/revogação bloqueia a ação; mudança relevante exige revalidação humana. Silêncio não é aprovação. A task não substitui DB_EXEC. Usar revisão documental identificável quando não houver commit. Para DB_EXEC registrar comandos/scripts, executor, alvo, janela e limite de repetições. O agente apenas transcreve manifestações humanas explícitas com evidência sanitizada.

package/payload/central-v0.2/.ai-dev-workflow/templates/DISCOVERY.md

@@ -0,0 +1,13 @@
+# Discovery — [projeto]
+Data: [AAAA-MM-DD] | Trilha: existente | Responsável: [...] | Status G1: pendente
+## Escopo/limitações
+## Evidências (caminho:linha ou comando seguro)
+## Stack (declarada / confirmada)
+| Camada | Tecnologia | Versão declarada | Versão confirmada | Evidência |
+|---|---|---|---|---|
+## Mapa de módulos e fluxos
+## Banco de dados (sem dados reais)
+## Dependências e pontos críticos
+## Riscos e lacunas
+## Próximas ações propostas
+## Aprovação G1 (quem, quando, escopo)

package/payload/central-v0.2/.ai-dev-workflow/templates/ENVIRONMENT.md

@@ -0,0 +1,20 @@
+# Environment — [projeto]
+Status G1: [...] | Status G2: pendente
+## Pré-requisitos e versões compatíveis
+## SO / arquitetura / Docker
+## Serviços, portas e volumes
+## Variáveis de ambiente (somente nomes, sem valores secretos)
+## Comandos propostos (alvo e riscos)
+## Isolamento do banco de teste
+## Reprodução / troubleshooting
+## Testes de inicialização e evidências
+## Aprovação G2 da configuração (ID em DECISIONS)
+G2 não autoriza inicialização, migrations ou seeders.
+## Modo de operação de banco do projeto
+Modo: MANUAL_SQL (padrão até escolha humana explícita)
+Escolha DB_MODE (ID): [...] | Motor/versão real e evidência: [...]
+Alvos autorizados sem credenciais: [...]
+DB_CHANGE e DB_EXEC são separados e específicos por task/execução; ver `.ai-dev-workflow/rules/database.md`.
+## Entrada e bootstrap
+Discovery (existente) ou REQUIREMENTS/ARCHITECTURE (novo), G1: [...]
+Projeto novo: não criar aplicação antes da task de bootstrap com G4.

package/payload/central-v0.2/.ai-dev-workflow/templates/PR_CHECKLIST.md

@@ -0,0 +1,9 @@
+# Checklist de PR
+- [ ] Task e G4 documentados
+- [ ] Branch isolada; diff revisado
+- [ ] Sem credenciais, dumps nem dados reais
+- [ ] Testes relevantes executados e evidências anexadas
+- [ ] Compatibilidade validada; migrations/rollback planejados
+- [ ] Docs/CURRENT_STATE atualizados
+- [ ] Revisão G5 realizada
+- [ ] Deploy separado sujeito a G6

package/payload/central-v0.2/.ai-dev-workflow/templates/REQUIREMENTS.md

@@ -0,0 +1,9 @@
+# Requirements — projeto novo
+## Problema / usuários / objetivo
+## Funcionalidades do MVP e fora do escopo
+## Requisitos funcionais e não funcionais
+## Dados e privacidade
+## Alternativas de stack e trade-offs
+## Critérios de aceitação
+## Riscos / perguntas abertas
+## Aprovação G1

package/payload/central-v0.2/.ai-dev-workflow/templates/TASK.md

@@ -0,0 +1,26 @@
+# TASK-XXX — [título]
+Status: proposta | Branch: [feature/TASK-XXX-...] | Responsável: [...] | Aprovação G4: pendente
+## Contexto e objetivo
+## Fora do escopo
+## Requisitos e critérios de aceitação (verificáveis)
+## Arquivos/áreas possivelmente impactados
+## Dados, segurança e riscos
+## Plano de implementação (curto)
+## Plano de testes e ambiente
+## Rollback / reversão
+## Dependências e decisões abertas
+## Aprovação explícita G4
+
+## Isolamento e aprovações
+Raiz Git confirmada: [...] | Git-dir/common-dir: [...] | Branch efetiva: [...]
+IDs em `docs/project/DECISIONS.md`: [...] | Revisão dos artefatos: [...]
+Estados: pendente/aprovado/rejeitado/revogado/revalidação pendente. Escopo alterado exige revalidação.
+
+## Controle de banco (obrigatório, inclusive quando não aplicável)
+Banco envolvido: [sim/não/desconhecido; evidência]
+Modo do projeto: [MANUAL_SQL por padrão; herdar escolha humana vigente] | Modo efetivo da task: [...]
+Escolha humana/override DB_MODE (ID): [...] | Motor e versão real/evidência: [...]
+Alvo/ambiente sem credenciais: [...] | Executor: [...]
+G2 ambiente (ID): [...] | DB_CHANGE plano (ID): [...] | DB_EXEC execução concreta (ID): [...] | G6 produção, se aplicável: [...]
+**G4 não autoriza modificar banco. Sem DB_EXEC específico, não executar migrations, seeders, SQL de escrita ou scripts/testes que alterem banco. MANUAL_SQL proíbe execução pelo agente.**
+Entrega SQL/roteiro: `docs/tasks/TASK-XXX/sql/` conforme `.ai-dev-workflow/templates/DATABASE_CHANGE.md`, ou não aplicável com justificativa.

package/payload/central-v0.2/.ai-dev-workflow/templates/TASK_REPORT.md

@@ -0,0 +1,20 @@
+# TASK-XXX — Relatório de execução
+Data: [...] | Branch / commit: [...] | Status: [...]
+## Resumo da alteração
+## Arquivos criados/alterados
+## Testes executados
+| Comando | Ambiente | Resultado | Evidência/observação |
+|---|---|---|---|
+## Testes não executados e motivo
+## Segurança/compatibilidade e riscos restantes
+## Como reverter
+## Checklist para revisão G5
+## Próximas tarefas / CURRENT_STATE atualizado?
+
+## Controles de execução
+Raiz Git e branch verificadas: [...]
+IDs/revisões em DECISIONS e revalidações necessárias: [...]
+Modo de banco do projeto/task: MANUAL_SQL / [...]
+DB_CHANGE/DB_EXEC/G2/G6 aplicáveis: [...] | Executor e alvo: [...]
+SQL/roteiro entregues: [...] | Execução real e evidências: [...]
+Em MANUAL_SQL marcar: nenhuma escrita de banco executada pelo agente.

package/payload/central-v0.2/.continue/prompts/analisar-projeto.md

@@ -0,0 +1,7 @@
+---
+name: analisar-projeto
+description: Diagnosticar código existente, sem alterar arquivos
+invokable: true
+---
+
+Estamos na P01 (Discovery). Analise apenas os arquivos explicitamente disponibilizados. Identifique stack, versões confirmadas e declaradas, dependências, riscos, arquitetura e lacunas. Não modifique arquivos nem execute comandos; não presuma acesso a arquivos não fornecidos. Resuma em formato do template `.ai-dev-workflow/templates/DISCOVERY.md` e solicite G1.

package/payload/central-v0.2/.continue/prompts/documentar-task.md

@@ -0,0 +1,7 @@
+---
+name: documentar-task
+description: Redigir relatório com evidências fornecidas
+invokable: true
+---
+
+Com base **apenas** nas evidências que forneci, redija o relatório conforme `.ai-dev-workflow/templates/TASK_REPORT.md` e proponha atualização de `CURRENT_STATE.md`. Marque testes não executados e campos desconhecidos. Não invente comandos, resultados, commits ou aprovações.

package/payload/central-v0.2/.continue/prompts/planejar-task.md

@@ -0,0 +1,9 @@
+---
+name: planejar-task
+description: Criar plano de tarefa com riscos, testes e aprovação
+invokable: true
+---
+
+Com base no contexto fornecido, proponha uma task usando `.ai-dev-workflow/templates/TASK.md`, com escopo, critérios de aceitação, compatibilidade, riscos, testes e rollback. Não implemente. Aguarde aprovação G4.
+
+Inclua isolamento Git, IDs canônicos de aprovação e modo efetivo de banco (MANUAL_SQL por padrão). Separe G4, G2, DB_CHANGE e DB_EXEC. Planeje a entrega DATABASE_CHANGE quando houver banco; não execute escrita.

package/payload/central-v0.2/.continue/prompts/revisar-codigo.md

@@ -0,0 +1,7 @@
+---
+name: revisar-codigo
+description: Revisar trecho ou diff fornecido sem editar
+invokable: true
+---
+
+Revise o trecho/diff explicitamente fornecido; reporte bugs, segurança, regressão, impacto no banco, compatibilidade e testes. Separe achados comprovados de hipóteses, cite linhas quando presentes. Não modifique arquivos nem execute comandos.

package/payload/central-v0.2/.continue/rules/workflow.md

@@ -0,0 +1,12 @@
+---
+name: Workflow seguro de desenvolvimento
+alwaysApply: true
+---
+
+Siga `AGENTS.md` e as regras aplicáveis em `.ai-dev-workflow/rules/`. Antes de modificar arquivos ou chamar ferramentas, confirme fase, ambiente, escopo e aprovação humana. Não leia nem envie segredos ou dados pessoais. Não execute comandos destrutivos sem autorização específica. Produção permanece bloqueada por padrão e exige as autorizações humanas específicas previstas no workflow. Explique limitações e resultados de testes. A ativação desta regra não substitui controle de permissões.
+
+Carregue a matriz de regras de `.ai-dev-workflow/docs/WORKFLOW.md`; confirme isolamento Git antes de editar. Use DECISIONS como fonte canônica de aprovações. Banco usa MANUAL_SQL até escolha humana explícita; G4 não autoriza escrita. Siga `.ai-dev-workflow/rules/database.md` para DB_CHANGE e DB_EXEC; em MANUAL_SQL apenas prepare SQL e roteiro, sem executar migrations, seeders ou scripts/testes com escrita.
+
+Produção permanece bloqueada por padrão. Operações de produção exigem as autorizações humanas específicas do workflow, incluindo G6 para a ação e o ambiente concretos. Operações de banco exigem também G2, DB_CHANGE e DB_EXEC aplicáveis, com executor, alvo e revisão dos scripts identificados; produção exige backup validado, plano de execução, validação e rollback. G4, G5 ou G6 não implicam autorização automática para executar SQL.
+
+MANUAL_SQL permanece como modo padrão: o agente apenas prepara os arquivos SQL e as instruções; a execução é responsabilidade humana, sujeita às autorizações aplicáveis. Nenhuma ferramenta deve executar comandos de escrita no banco sem autorização explícita para a operação e o ambiente. Para execução pelo agente, exigir também modo permitido escolhido pelo humano conforme `.ai-dev-workflow/rules/database.md`; DB_EXEC humano não autoriza execução pelo agente. Essas instruções não substituem permissões técnicas.

package/payload/central-v0.2/.github/pull_request_template.md

@@ -0,0 +1,10 @@
+## Task e propósito
+TASK-XXX: ...
+## Mudanças
+...
+## Testes executados (com ambiente)
+...
+## Riscos e rollback
+...
+## Aprovações G4/G5/G6
+...

package/payload/central-v0.2/.gitignore.txt

@@ -0,0 +1,28 @@
+# Secrets and local environment
+.env
+.env.*
+!.env.example
+*.pem
+*.key
+*.p12
+*.pfx
+*.sql.gz
+*.dump
+*.sqlite
+# Dumps/backups and sensitive data directories (at any depth)
+backup/
+backups/
+dump/
+dumps/
+sensitive/
+sensitive-data/
+secrets/
+.credentials/
+# Editor/OS
+.DS_Store
+.idea/
+.vscode/settings.local.json
+# Project caches
+vendor/
+node_modules/
+coverage/