nexus-core-v3 3.0.0

package/tasks/create-next-story.md

@@ -0,0 +1,66 @@
+---
+id: create-next-story
+agent: sm
+title: Criar a próxima story do épico
+inputs: [épico, PRD shardado, docs de arquitetura]
+outputs: ['docs/stories/{epicNum}.{storyNum}.story.md em status Draft']
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Criar a próxima story do épico
+
+**Objetivo:** transformar a próxima fatia de um épico numa story que o @dev implementa sem adivinhação
+— ACs testáveis e contexto técnico colado dentro do arquivo — rastreando tudo ao PRD/épico/arquitetura.
+
+**Pré-condições:**
+- Existe um épico de origem e o PRD shardado. Sem essa âncora, **pare**: qualquer story aqui seria
+  invenção (viola No Invention — Art. IV). Sinalize a lacuna para o @pm.
+- Os docs de arquitetura relevantes estão acessíveis (stack, contratos, padrões). Se faltarem para a
+  área da story, marque a lacuna explicitamente — não preencha com opinião.
+
+## Passos
+
+1. **Identifique a próxima story.** Leia o épico e o índice de stories em `docs/stories/`. Determine o
+   próximo `{storyNum}` na sequência do épico. Se a story anterior não estiver concluída e for
+   dependência, registre a dependência — não fure a ordem "por eficiência".
+2. **Ancore no contexto.** Leia o épico de origem, a seção correspondente do PRD shardado e os docs de
+   arquitetura relevantes. Extraia os FR/NFR/CON que a story deve atender. Tudo que entrar na story
+   precisa rastrear a uma dessas fontes.
+3. **Crie o arquivo** `docs/stories/{epicNum}.{storyNum}.story.md` a partir do template de story
+   (`templates/`). Preencha título, status `Draft` e a referência ao épico de origem.
+4. **Escreva critérios de aceite testáveis.** Cada AC no formato "dado X, quando Y, então Z" e
+   rastreável a um FR/NFR. Nada de "funciona bem". Se um requisito do épico não couber nesta story,
+   deixe-o para a próxima — não infle o escopo.
+5. **Cole o contexto técnico dentro da story.** Arquivos a tocar, contratos/interfaces, dependências de
+   stories anteriores, padrões do projeto a seguir, e a seção de Testing. O @dev não deveria precisar
+   abrir cinco documentos para implementar.
+6. **Preencha a qualidade preditiva.** Pelo tipo da story, anote a seção de integração de revisão de
+   código e quais gates/agentes especializados ela provavelmente exigirá (@qa sempre; @data-engineer se
+   toca schema; @ux-design-expert se toca UI). Planejar o gate na criação é mais barato que no review.
+7. **Releia pela lente do dev.** "Dá pra implementar isso sem me perguntar nada?" Cada ponto de
+   adivinhação vira contexto adicionado — ou uma lacuna explícita marcada para o @pm resolver.
+8. **Rode o story-draft-checklist** (via `execute-checklist`). Se passa, a story permanece em `Draft`
+   pronta para validação do @po. Se há lacuna de PRD/arquitetura, **sinalize** — não tape o buraco.
+9. **Entregue o gate.** Story pronta → @po valida (10-point). Não valide você mesma e não implemente:
+   seu entregável é o artefato story, não o commit.
+
+## Critério de pronto (DoD)
+
+- [ ] Arquivo `docs/stories/{epicNum}.{storyNum}.story.md` criado em status `Draft`
+- [ ] Cada AC é testável ("dado/quando/então") e rastreia a um FR/NFR/CON
+- [ ] Contexto técnico colado: arquivos, contratos, dependências e seção de Testing
+- [ ] Seção de revisão de código + gates previstos preenchida pelo tipo da story
+- [ ] story-draft-checklist executado com aprovação (ou lacunas sinalizadas ao @pm)
+- [ ] Story roteada ao @po para validação — sem implementação e sem `git push`
+
+## Falha / recuperação
+
+- **PRD/épico não cobre o que a story precisa** → registro a lacuna e escalo ao @pm. Não invento o
+  requisito que falta (No Invention — Art. IV).
+- **Arquitetura ambígua para a área da story** → marco a lacuna explícita na story e sinalizo ao
+  @architect; não chuto stack nem contrato.
+- **story-draft-checklist reprova** → corrijo os itens que são meus (contexto, ACs, formato) e refaço.
+  Se a reprovação é por lacuna de produto, devolvo ao @pm em vez de forçar a aprovação.
+- **Pedido de correção de escopo no meio** → escalo para a @nexus-master (correct-course). Não corrijo
+  escopo de produto por conta própria.

package/tasks/create-prd.md

@@ -0,0 +1,53 @@
+---
+id: create-prd
+agent: pm
+title: Criar o PRD greenfield
+inputs: [pedido de produto, pesquisa de mercado (opcional)]
+outputs: [docs/prd/prd.md com FR/NFR, métricas de sucesso e recorte MVP]
+elicit: true
+modes: [interactive]
+---
+
+# Criar o PRD greenfield
+
+**Objetivo:** transformar um pedido de produto novo num PRD-contrato — cada feature rastreada a uma dor
+real do usuário, com critério de aceite verificável, métrica de sucesso e um MVP recortado ao osso.
+
+**Pré-condições:**
+- Existe um pedido de produto (visão, ideia, oportunidade). Sem isso, **pare** e elicite o escopo.
+- O "por quê" é conhecível: há uma dor de usuário ou achado de pesquisa por trás. Se não há, **pare** e
+  delegue a pesquisa ao @analyst antes de escrever uma linha (No invention, Art. IV).
+
+## Passos
+
+1. **Cave o "por quê" até a raiz.** Para cada feature pedida, pergunte: quem é o usuário, qual a dor,
+   qual métrica isso move. Registre o rastro. Feature sem "por quê" rastreável vira pergunta, não FR.
+2. **Liste tudo que pediram e jogue na matriz** (MoSCoW ou RICE). Classifique sem dó: só o "Must" entra
+   no primeiro recorte. "Should"/"Could" viram roadmap, não escopo do MVP.
+3. **[ELICITAÇÃO] Confirme o recorte MVP com o stakeholder.** Apresente o corte (o que entra, o que vira
+   roadmap) e o "por quê" de cada inclusão. Pare e espere o GO real do usuário — não presuma o aceite.
+4. **Escreva o PRD** a partir de `templates/prd-tmpl.md`: contexto/problema, usuários, objetivos e
+   métricas de sucesso, FRs e NFRs. Cada FR/NFR com **critério de aceite verificável** e rastro ao
+   "por quê". Texto que @dev/@sm precisariam te perguntar = documento falhou.
+5. **Preveja qualidade no plano.** Anote NFRs (performance, segurança, acessibilidade) e marque onde o
+   @qa entra. Qualidade é design, não remendo.
+6. **Salve em `docs/prd/prd.md`** e registre as decisões de escopo (o que cortou e por quê).
+7. **Roteie o que não é meu.** Arquitetura/tecnologia → @architect. Quebra em epics → task `create-epic`
+   (depois eu delego stories ao @sm). Subir/versionar no remoto → @devops.
+
+## Critério de pronto (DoD)
+
+- [ ] Todo FR/NFR tem critério de aceite verificável e métrica de sucesso
+- [ ] Todo item rastreia a uma dor de usuário ou achado de pesquisa (sem invenção)
+- [ ] Recorte MVP explícito e **confirmado pelo stakeholder** (elicitação cumprida)
+- [ ] O que ficou de fora está registrado como roadmap, não perdido
+- [ ] PRD salvo em `docs/prd/prd.md`; nada de `git push` (delegado ao @devops)
+
+## Falha / recuperação
+
+- **Não consigo rastrear o "por quê" de uma feature** → não escrevo o FR; delego pesquisa ao @analyst ou
+  devolvo a pergunta ao stakeholder.
+- **Stakeholder não fecha o recorte na elicitação** → registro as opções e seguro o PRD; não invento o
+  escopo que ele não aprovou.
+- **Pedido exige decisão de arquitetura** → trago o "o quê"/"por quê" e delego o "como" ao @architect.
+- **Escopo incha sem prova** → empurro o excedente pro roadmap; o MVP não negocia sem justificativa.

package/tasks/create-project-brief.md

@@ -0,0 +1,47 @@
+---
+id: create-project-brief
+agent: analyst
+title: Criar o brief de projeto
+inputs: [insumos de descoberta (brainstorm, pesquisa de mercado, notas do usuário)]
+outputs: [docs/project-brief.md]
+elicit: true
+modes: [interactive]
+---
+
+# Criar o brief de projeto
+
+**Objetivo:** sintetizar a descoberta num brief de projeto enxuto e rastreável que dê ao @pm a munição para escrever o PRD — sem inventar escopo nem decidir produto.
+
+**Pré-condições:**
+- Existe pelo menos um insumo de descoberta (brainstorm, pesquisa de mercado, análise competitiva, ou notas do usuário). Se não houver **nada**, **pare** e elícito o contexto base — brief não nasce do vácuo.
+- Há um template de brief em `templates/`. Se existir, preencho-o; se não, uso a estrutura canônica de seções abaixo.
+
+## Passos
+
+1. **Reúno os insumos** disponíveis (brainstorms, pesquisas, notas) e listo as fontes. Cada afirmação no brief vai rastrear a uma delas.
+2. **Aperto o problema com o usuário.** Confirmo: qual é o problema, para quem, e por que agora. **(ponto de elicitação — exige resposta real do usuário)**
+3. **Preencho as seções do brief**, uma a uma, cada uma rastreando a um insumo:
+   - Problema (o que dói e para quem)
+   - Objetivo / resultado desejado (mensurável quando possível)
+   - Usuários-alvo / personas
+   - Escopo proposto (o que está dentro) e não-escopo (o que está fora)
+   - Restrições e premissas conhecidas (CON-*)
+   - Riscos e questões em aberto
+   - Métricas de sucesso
+4. **Marco hipóteses explicitamente.** Tudo que não rastreia a uma fonte verificável vira uma hipótese rotulada — nunca apresento suposição como fato.
+5. **Fecho com o "portanto".** Indico o próximo passo (handoff ao @pm para o PRD) e o que ainda precisa de validação.
+6. **Salvo** em `docs/project-brief.md` e roteio ao @pm.
+
+## Critério de pronto (DoD)
+
+- [ ] Problema, objetivo e usuários-alvo confirmados com o usuário (elicitação cumprida)
+- [ ] Todas as seções do brief preenchidas, cada afirmação rastreando a uma fonte/insumo
+- [ ] Hipóteses marcadas explicitamente, distintas dos fatos
+- [ ] Escopo e não-escopo declarados
+- [ ] Brief salvo em `docs/project-brief.md` e roteado ao @pm
+
+## Falha / recuperação
+
+- **Insumos insuficientes para uma seção** → marco a seção como "a validar" com a pergunta aberta; não invento o conteúdo.
+- **Usuário pede que eu escreva o PRD** → recuso e delego: PRD é do @pm. Eu entrego o brief, ele decide o produto.
+- **Achados conflitantes entre insumos** → registro o conflito explicitamente em "questões em aberto" em vez de escolher arbitrariamente uma versão.

package/tasks/create-rls-policies.md

@@ -0,0 +1,59 @@
+---
+id: create-rls-policies
+agent: data-engineer
+title: Projetar políticas RLS para o schema
+inputs: [schema, modelo de domínio (regras de propriedade do dado)]
+outputs: [DDL de políticas RLS, docs/data/RLS.md, casos de teste positivos e negativos]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Projetar políticas RLS para o schema
+
+**Objetivo:** garantir que cada tabela pública aplique Row Level Security — quem pode ler/escrever
+qual linha é decidido pelo banco, não pela confiança no código da aplicação.
+
+**Pré-condições:**
+- O schema existe (saída de `create-schema`). Sem tabelas, não há o que proteger.
+- As regras de propriedade do dado estão no modelo de domínio (quem é dono de qual linha:
+  usuário, tenant, papel). Se faltam, **pare** e volte ao modelo — RLS sem regra de propriedade é chute.
+- A camada de auth está definida. Se não há auth, **aviso explicitamente** que `auth.uid()` retorna
+  `NULL` e as políticas baseadas em identidade não vão filtrar nada.
+
+## Passos
+
+1. **Habilite RLS em toda tabela pública:** `ALTER TABLE ... ENABLE ROW LEVEL SECURITY` e
+   `FORCE ROW LEVEL SECURITY` onde o dono também não deve bypassar. Tabela pública sem RLS é vazamento.
+2. **Para cada tabela, derive as políticas das regras de propriedade** do modelo: `SELECT`,
+   `INSERT`, `UPDATE`, `DELETE` separadamente. Cada política expressa "qual linha este papel enxerga
+   ou altera" — tipicamente via `auth.uid()`, coluna de tenant ou papel.
+3. **Escreva `USING` (leitura/escrita do que já existe) e `WITH CHECK` (o que pode ser inserido/
+   atualizado) corretamente.** Esquecer `WITH CHECK` deixa o usuário gravar linha que ele nem
+   conseguiria ler — buraco clássico.
+4. **Decida o modo:** KISS (uma política ampla por tabela) quando o acesso é simples; granular
+   (política por operação/papel) quando o domínio exige. Documente a escolha.
+5. **Trate o service role com cuidado extremo:** ele bypassa RLS. Liste onde ele é usado e por quê —
+   service role sem justificativa é risco.
+6. **Escreva os casos de teste — positivos E negativos.** Para cada política: um caso que DEVE passar
+   (o dono acessa sua linha) e um que DEVE falhar (outro usuário NÃO acessa). RLS só validada com o
+   teste negativo verde; sem ele, eu não declaro a política segura.
+7. **Documente em `docs/data/RLS.md`** as políticas, o modo escolhido, o tratamento de service role e
+   os casos de teste. A aplicação real (`db-policy-apply`) e a emulação de usuário (`test-as-user`)
+   acontecem em tasks dedicadas.
+
+## Critério de pronto (DoD)
+
+- [ ] RLS habilitada em toda tabela pública
+- [ ] Política por operação derivada das regras de propriedade do modelo de domínio
+- [ ] `USING` e `WITH CHECK` corretos em cada política aplicável
+- [ ] Uso de service role listado e justificado
+- [ ] Cada política tem caso de teste positivo E negativo definido
+- [ ] `docs/data/RLS.md` escrito; aviso emitido se não há camada de auth
+
+## Falha / recuperação
+
+- **Falta regra de propriedade do dado** → volto ao `db-domain-modeling`; não invento quem é dono.
+- **Não há auth configurada** → não declaro RLS segura; registro o aviso de `auth.uid()` NULL e
+  escalo para o @architect/@devops resolverem a camada de identidade.
+- **Política some no teste negativo** (vazamento detectado) → bloqueio o avanço; política que falha o
+  teste negativo não vai para produção.

package/tasks/create-schema.md

@@ -0,0 +1,57 @@
+---
+id: create-schema
+agent: data-engineer
+title: Desenhar o schema do banco
+inputs: [modelo de domínio, story]
+outputs: [DDL do schema, docs/data/SCHEMA.md]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Desenhar o schema do banco
+
+**Objetivo:** transformar o modelo de domínio em DDL concreto — tabelas com baseline, foreign keys
+explícitas e constraints que fazem o banco cumprir as regras, mesmo se o código da aplicação falhar.
+
+**Pré-condições:**
+- O modelo de domínio existe (saída de `db-domain-modeling`): entidades, relações e padrões de
+  acesso. Se não existe, **pare** e rode `db-domain-modeling` primeiro — schema sem domínio é palpite.
+- A tecnologia de banco está definida (PostgreSQL/Supabase por padrão). Se indefinida, escalo ao
+  @architect — escolha de tecnologia não é minha.
+
+## Passos
+
+1. **Releia o modelo de domínio.** Cada tabela do DDL tem que rastrear a uma entidade do modelo. Sem
+   entidade no modelo, sem tabela no schema (Constituição Art. IV).
+2. **Crie cada tabela com o baseline obrigatório:** `id` (PK), `created_at`, `updated_at`. Adicione
+   `deleted_at` (soft delete) onde a story pede trilha de auditoria. Tabela sem baseline não está
+   pronta.
+3. **Declare as foreign keys explicitamente**, com `ON DELETE`/`ON UPDATE` coerentes com a relação do
+   modelo (cascade, restrict, set null). O lado dono da FK vem do modelo de domínio.
+4. **Aplique defesa em profundidade no DDL:** `NOT NULL` onde o domínio exige, `CHECK` para valores
+   válidos, `UNIQUE` para identidade de negócio. A aplicação é a última linha, não a única.
+5. **Escolha tipos corretos:** `uuid`/`bigint` para PKs, `timestamptz` para datas, `numeric` para
+   dinheiro (nunca `float`), `text` em vez de `varchar(n)` arbitrário. Tipo certo é integridade barata.
+6. **Escreva DDL idempotente:** `CREATE TABLE IF NOT EXISTS`, `CREATE TYPE`/enum guardados. Rodar duas
+   vezes não pode quebrar — esse DDL vai virar migration depois.
+7. **Verifique a ordem de dependência:** tabelas referenciadas antes das que as referenciam. Esse
+   ordenamento é o que `db-verify-order` vai cobrar na migration.
+8. **Documente o schema** em `docs/data/SCHEMA.md`: cada tabela, suas colunas, FKs e constraints, com
+   rastro à entidade do domínio. Sinalize que RLS e índices virão em tasks dedicadas
+   (`create-rls-policies`, `design-indexes`) — não entrego tabela pública sem RLS.
+
+## Critério de pronto (DoD)
+
+- [ ] Toda tabela rastreia a uma entidade do modelo de domínio
+- [ ] Toda tabela tem o baseline (`id`/`created_at`/`updated_at`) + `deleted_at` onde aplicável
+- [ ] FKs explícitas com política de `ON DELETE`/`ON UPDATE` coerente
+- [ ] Constraints de integridade (`NOT NULL`/`CHECK`/`UNIQUE`) aplicadas
+- [ ] DDL idempotente e em ordem de dependência correta
+- [ ] `docs/data/SCHEMA.md` escrito; RLS e índices sinalizados como próximos passos
+
+## Falha / recuperação
+
+- **Modelo de domínio incompleto** → paro e volto a `db-domain-modeling`; não preencho a lacuna
+  inventando estrutura.
+- **DDL exige decisão de arquitetura de sistema** (sharding, escolha de engine) → escalo ao @architect.
+- **A story pede código de aplicação/DAL** → delego ao @dev; eu sou dona do banco, não do código acima.

package/tasks/create-service.md

@@ -0,0 +1,55 @@
+---
+id: create-service
+agent: dev
+title: Criar um serviço novo a partir de template
+inputs: [tipo de serviço (api-integration|utility|agent-tool), nome, story/spec]
+outputs: [scaffold do serviço, teste inicial, File List atualizada]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Criar um serviço novo a partir de template
+
+**Objetivo:** scaffoldar um serviço novo a partir de um template do projeto — já com estrutura,
+ponto de entrada e teste inicial — pelo menor caminho, sem inventar escopo além do que a story pede.
+
+**Pré-condições:**
+- O serviço rastreia a uma story/spec que pede explicitamente sua criação. Sem essa origem,
+  **pare** e elicito o escopo — não invento serviço (Constituição Art. IV).
+- O `tipo de serviço` é um dos templates suportados (`api-integration`, `utility`, `agent-tool`).
+  Tipo desconhecido → **pare** e confirmo com o usuário.
+- Não existe já um serviço que resolve isso. Antes de criar, checo o codebase: se existe um que
+  serve (REUSE) ou quase serve (ADAPT), uso/adapto em vez de criar.
+
+## Passos
+
+1. **Confirmo a origem** (story/spec) e o `tipo` do serviço. Identifico o template correspondente
+   em `templates/` e o leio antes de scaffoldar.
+2. **Verifico ausência de duplicata.** Procuro no codebase um serviço equivalente. Se existe, paro e
+   reporto — reuso vence criação.
+3. **Scaffoldo o serviço** a partir do template do tipo escolhido, no path do projeto (`.nexus/` para
+   artefatos de framework; o pacote/módulo do projeto para código de app). Preencho os pontos do
+   template: nome, ponto de entrada, contrato/interface conforme a story.
+4. **Sigo os padrões do projeto** (naming, imports absolutos, tratamento de erro). Não introduzo
+   dependência nova não aprovada — se o serviço exige uma, **paro** e confirmo com o usuário.
+5. **Escrevo o teste inicial** que prova que o esqueleto sobe e expõe o contrato mínimo. Serviço sem
+   teste não está pronto — está pela metade.
+6. **Rodo lint + o teste inicial** (verde obrigatório) e **atualizo a File List** com tudo que criei.
+
+## Critério de pronto (DoD)
+
+- [ ] O serviço rastreia a uma story/spec (sem invenção de escopo)
+- [ ] Nenhuma duplicata existente foi ignorada (reúso checado antes de criar)
+- [ ] Scaffold gerado a partir do template do tipo correto, seguindo os padrões do projeto
+- [ ] Teste inicial verde provando que o esqueleto sobe e expõe o contrato mínimo
+- [ ] Nenhuma dependência nova não aprovada introduzida
+- [ ] File List atualizada com os arquivos criados
+
+## Falha / recuperação
+
+- **Já existe serviço equivalente** → paro e reporto; reúso/adapto em vez de duplicar.
+- **O tipo não tem template** → HALT e confirmo com o usuário; não improviso scaffold do zero sem
+  base.
+- **O serviço exigiria dependência nova não aprovada** → HALT e confirmo antes de adicionar
+  (Constituição Art. IV).
+- **O escopo do serviço não está na story** → paro e elicito; não invento contrato.

package/tasks/create-squad.md

@@ -0,0 +1,100 @@
+---
+id: create-squad
+agent: squad-creator
+title: Forjar um squad a partir de uma missão
+inputs: [missão, restrições, tamanho desejado]
+outputs: ['blueprint <squad>{json}</squad> validado', 'squads/{id}/ materializado pelo motor (squad.yaml + agents/ + tasks/ + knowledge/)']
+elicit: true
+modes: [interactive, yolo]
+---
+
+# Forjar um squad a partir de uma missão
+
+**Objetivo:** transformar uma missão em um squad coeso de especialistas — blueprint completo emitido
+num único bloco `<squad>{json}</squad>`, validado e materializado pelo **motor** (`nexus squad
+create`) em `squads/{id}/`.
+
+**Pré-condições:**
+- A missão rastreia a um pedido/story/spec (`traceRef`). Sem rastro, **pare** e elicite — squad de
+  escopo inventado não nasce (Art. IV).
+- O roster core (`agents/`) foi lido NESTA sessão — o mapa de cobertura (passo 2) compara contra o
+  time real, não contra memória.
+
+## Passos
+
+1. **Entenda a missão.** Em modo interativo (`elicit: true` — ponto sagrado), elicite: (a) a missão
+   em uma frase e seu rastro (story/spec/pedido); (b) o tamanho desejado do time (default: o menor
+   que cobre os gaps); (c) restrições (prazo, stack, o que está FORA do escopo). Em modo yolo,
+   derive dos inputs recebidos e **declare** cada suposição no relatório — suposição silenciosa é
+   invenção.
+2. **Mapeie os papéis contra o core.** Liste as lentes que a missão exige e cruze com o roster real
+   de `agents/`. REUSE > CREATE: o que o core cobre é **referenciado** (delegação, nunca cópia);
+   só o gap real vira membro novo. Registre o mapa papel → coberto-por/gap no manifest.
+3. **Desenhe o time.** Exatamente **um chief** de arquétipo `Orchestrator` + **2 a 7 especialistas**
+   (fora dessa faixa a composição está errada — squad de 1 agente não nasce). Cada membro: lente
+   distinta, `owns:` apontando para tasks DO squad, `delegatesTo:` apontando para o core nas
+   fronteiras (git push/PR/release/MCP → @devops, SEMPRE).
+4. **Preencha os templates** de `templates/squad/`: `squad-yaml-tmpl` (manifest), `chief-dna-tmpl`
+   (chief com roster e delegação), `agent-dna-tmpl` (cada membro), `squad-task-tmpl` (cada task do
+   squad). Todo frontmatter de agente tem que validar contra o contrato `Agent`
+   (`packages/contracts/src/agent.schema.ts`); corpo segue o formato canônico de `agents/README.md`.
+   Task core NUNCA é copiada para dentro do squad — é referenciada pelo slug.
+5. **Emita o blueprint** — EXATAMENTE UM bloco `<squad>{json}</squad>` no output (mesma convenção
+   anti-teatro do `<delegate>`: zero blocos = nada a criar; mais de um = ambíguo → recusado). O
+   JSON é um `SquadBlueprint` com este shape:
+
+   ```jsonc
+   {
+     "manifest": {
+       "id": "kebab-case único do squad",
+       "name": "nome legível",
+       "mission": "a missão em uma frase",
+       "version": "0.1.0",
+       "chief": "id do agente chief (tem que existir em agents[])",
+       "origin": "generated",
+       "traceRef": "rastro da missão (story/spec/pedido)",
+       "guards": { /* freios do squad (fanout/budget), nunca acima dos tetos do core */ },
+       "authorities": [ "squad.{id-do-squad}.{operacao}" ]
+     },
+     "agents": [ { "frontmatter": { /* contrato Agent: id, name, title, icon, archetype, lens, whenToUse, authority, model, owns, delegatesTo, knowledge */ }, "body": "markdown do DNA" } ],
+     "tasks": [ { "slug": "kebab-case da task", "content": "markdown completo (frontmatter + passos)" } ],
+     "knowledge": [ { "ref": "categoria/nome-do-pack", "content": "markdown do knowledge pack" } ]
+   }
+   ```
+
+   **Shapes que o schema EXIGE (erros mais comuns na forja):**
+   - `manifest.authorities`: array de **STRINGS** no formato namespaced `"squad.{id}.{operacao}"`
+     (kebab-case, ex.: `"squad.conteudo-ig.aprovar-pauta"`). **NUNCA objetos** `{operation, owner}` —
+     esse shape é da Constitution do CORE, não do squad. Na dúvida, use `[]` (autoridade é opcional).
+   - `knowledge[].ref`: slug kebab-case `categoria/nome-do-pack` — **sem** prefixo de caminho
+     (`squads/...`), **sem** extensão `.md`, **sem** acentos/maiúsculas (ex.: `marketing/metricas-ig`,
+     nunca `squads/x/knowledge/Métricas.md`). O ref também não pode colidir com um pack do root
+     em `knowledge/` (o motor rejeita sombra de knowledge do core).
+   - `agents[].frontmatter.archetype`: um de `Orchestrator | Builder | Sage | Guardian | Explorer | Maker`.
+   - ids/slugs em geral: kebab-case ASCII `[a-z0-9-]` (sem acentos).
+
+6. **Dispare o motor:** `nexus squad create`. O MOTOR valida o blueprint contra o schema e
+   materializa `squads/{id}/` (squad.yaml + agents/ + tasks/ + knowledge/). Blueprint com issue →
+   o squad NÃO nasce; corrija e re-emita. **Nunca** materialize na mão para "destravar".
+7. **Prove que nasceu inteiro:** rode `validate-squad` sobre o id criado e reporte o resultado REAL
+   (Lei 3). Operação do squad daí em diante é da @nexus-master — criar não é operar.
+
+## Critério de pronto (DoD)
+
+- [ ] Missão elicitada/derivada com `traceRef` rastreável e restrições registradas
+- [ ] Mapa de cobertura papel → core/gap registrado; nenhum membro duplica o time core
+- [ ] Chief é `Orchestrator`; time entre chief+2 e chief+7; lentes distintas
+- [ ] Nenhuma autoridade do squad colide com as exclusivas do core
+- [ ] EXATAMENTE UM bloco `<squad>{json}</squad>` emitido, com manifest/agents/tasks/knowledge completos
+- [ ] Motor validou e materializou `squads/{id}/` — sem materialização manual
+- [ ] `validate-squad` do squad recém-criado passou, com resultado reportado
+
+## Falha / recuperação
+
+- **O motor recusa o blueprint** → leia o issue apontado, corrija o blueprint e re-emita. Duas
+  recusas seguidas do MESMO issue = pare e reporte com o erro exato, sem contornar o motor.
+- **A missão não tem rastro** → HALT: elicite o `traceRef`; sem ele a task não prossegue.
+- **Todos os papéis já são cobertos pelo core** → não crie squad: reporte que a missão é da
+  @nexus-master orquestrar com o time existente (REUSE total é sucesso, não falha).
+- **O time não fecha na faixa (1 membro, ou >7 gaps)** → renegocie o recorte da missão com o
+  usuário: fatie a missão ou colapse lentes — não force a faixa com membro decorativo.

package/tasks/create-suite.md

@@ -0,0 +1,62 @@
+---
+id: create-suite
+agent: qa
+title: Criar a suíte de testes da story
+inputs: [story]
+outputs: [arquivos de teste, mapa AC→teste em Given-When-Then, File List da suíte]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Criar a suíte de testes da story
+
+**Objetivo:** transformar os critérios de aceite de uma story em uma suíte de testes executável e
+rastreável — cada AC com pelo menos um teste em Given-When-Then — sem inventar requisito e sem tocar o
+código de produção.
+
+**Pré-condições:**
+- A story existe e tem ACs explícitos e a seção de Testing. Se faltar AC ou Testing, **pare** e
+  devolva ao @sm/@po — eu não invento o contrato que vou testar (No invention, Art. IV).
+- A story NÃO está em `Draft` (foi validada). Desenhar suíte sobre contrato não-validado é retrabalho.
+- Conheço o framework de testes do projeto (runner, convenção de pasta, comando de execução). Se não
+  estiver definido na story/arquitetura, **pare** e elicito — não escolho stack por conta própria.
+
+## Passos
+
+1. **Leio a story completa** — ACs, Dev Notes, seção de Testing. Defino o que "pronto" significa AQUI
+   antes de escrever qualquer teste.
+2. **Perfilo o risco por AC** (probabilidade × impacto). Caminho crítico e dado sensível recebem
+   cobertura profunda (caso de erro, borda, regressão); CRUD trivial recebe cobertura proporcional.
+   Profundidade segue o sinal de risco, não o meu humor.
+3. **Mapeio cada AC para cenário(s)** em Given-When-Then. AC sem cenário é um buraco — eu o nomeio,
+   não o ignoro. O mapa AC→teste é artefato de saída obrigatório.
+4. **Escrevo os testes**, seguindo a convenção do projeto (REUSE > ADAPT > CREATE: reutilizo helpers/
+   fixtures existentes antes de criar). Para cada AC:
+   a. caminho feliz que prova o AC;
+   b. ao menos um caso de erro/borda quando o risco aponta;
+   c. teste de regressão quando o AC nasce de um bug conhecido.
+5. **Rodo a suíte** no runner do projeto. Testes novos podem ficar vermelhos se o código ainda não
+   existe — registro claramente quais falham por código ausente (esperado) versus por defeito real.
+6. **Registro a File List da suíte** (arquivos de teste criados/modificados) e entrego o mapa AC→teste
+   junto. Esse é o rastro que o gate vai auditar.
+7. **Roteio.** Suíte pronta → @dev implementa contra ela (TDD) ou eu sigo para `*review`/`*gate` se o
+   código já existe. Eu **nunca** escrevo o código de produção que faz a suíte passar — isso é do @dev.
+
+## Critério de pronto (DoD)
+
+- [ ] Todo AC mapeado para pelo menos um teste em Given-When-Then (zero AC órfão)
+- [ ] Casos de erro/borda presentes onde o perfil de risco aponta
+- [ ] Suíte roda no runner do projeto; falhas classificadas (código ausente × defeito real)
+- [ ] File List da suíte e mapa AC→teste entregues
+- [ ] Reutilizei helpers/fixtures existentes antes de criar novos
+- [ ] Não toquei o código de produção nem qualquer seção da story além da minha
+
+## Falha / recuperação
+
+- **AC ambíguo ou não-testável** → paro, registro a lacuna e devolvo ao @sm/@po. Não invento a
+  interpretação que falta.
+- **Framework de testes indefinido** → paro e elicito; não escolho stack por conta própria.
+- **A suíte exige tocar schema/migration além do teste** → delego ao @data-engineer para validar/
+  otimizar; eu não invado a lane de dados.
+- **Preciso subir a suíte (push/PR)** → delego ao @devops, sempre. Eu não faço `git push` nem abro PR;
+  commit local é do @dev.

package/tasks/db-apply-migration.md

@@ -0,0 +1,56 @@
+---
+id: db-apply-migration
+agent: data-engineer
+title: Aplicar uma migration com segurança
+inputs: [migration (path), story/spec de origem]
+outputs: [migration aplicada, snapshot pré-aplicação, rollback script, registro de aplicação]
+elicit: false
+modes: [interactive, yolo]
+---
+
+# Aplicar uma migration com segurança
+
+**Objetivo:** aplicar uma migration de schema em transação, com snapshot antes e rollback pronto, de
+forma que rodar de novo seja seguro — sem nunca subir nada (push é do @devops).
+
+**Pré-condições:**
+- A migration existe no path informado e rastreia a uma story/spec. Se não rastreia, **pare** — não
+  aplico DDL órfão (Constituição Art. IV).
+- O dry-run (`db-dry-run`) já rodou verde e a ordem do DDL (`db-verify-order`) já foi verificada. Se
+  não rodaram, **pare** e rode-os antes — aplicar sem dry-run é apostar no escuro.
+- O ambiente-alvo está validado (`db-env-check` ok, `sslmode=require` em produção). Se o alvo for
+  produção, confirmo explicitamente o ambiente antes de tocar.
+
+## Passos
+
+1. **Confirme o ambiente-alvo** (dev / staging / produção) e as variáveis de conexão. Em produção,
+   exijo Pooler com `sslmode=require` e justificativa se for usar service role.
+2. **Crie o snapshot pré-aplicação** (`db-snapshot {label}`, label tipo `pre-{migration-id}`). Sem
+   snapshot, eu **não** aplico — reversibilidade é pré-condição, não opção.
+3. **Garanta o rollback script** correspondente à migration (o `down`/reverse). Se não existe, escrevo
+   ou peço antes de seguir. Se eu não sei desfazer, eu não aplico.
+4. **Aplique dentro de uma transação** (`BEGIN … COMMIT`), com DDL idempotente (`IF NOT EXISTS` /
+   `IF EXISTS`). Qualquer erro no meio → `ROLLBACK` automático, banco intacto.
+5. **Verifique a aplicação:** as estruturas existem, constraints/FKs/RLS estão ativas, e a tabela tem
+   o baseline (`id`, `created_at`, `updated_at`) quando aplicável.
+6. **Rode o smoke-test** (`db-smoke-test {version}`) para confirmar que nada quebrou pós-migração.
+7. **Registre a aplicação** (migration id, snapshot label, ambiente, timestamp) na trilha da story.
+8. **Pronto para subir → delego ao @devops.** Eu não faço `git push` nem release; deixo a migration
+   aplicada e o registro pronto e roteio a subida ao @devops (Gage).
+
+## Critério de pronto (DoD)
+
+- [ ] Snapshot pré-aplicação criado e rollback script disponível
+- [ ] Migration aplicada em transação, com DDL idempotente
+- [ ] Estruturas, constraints/FKs/RLS e baseline verificados pós-aplicação
+- [ ] Smoke-test verde
+- [ ] Aplicação registrada na trilha da story; subida delegada ao @devops
+
+## Falha / recuperação
+
+- **Erro durante a aplicação** → a transação já fez `ROLLBACK`; confirmo que o banco está no estado do
+  snapshot e reporto a causa. Não tento "consertar ao vivo".
+- **Smoke-test falha pós-aplicação** → executo `db-rollback {snapshot}` para o ponto anterior, registro
+  o que falhou e devolvo a migration para correção.
+- **Migration não rastreia a story/spec** → HALT, não aplico — escalo para alinhar escopo.
+- **Pediram que eu faça o push** → recuso e delego ao @devops; push/PR/release não são meus.

package/tasks/db-domain-modeling.md

@@ -0,0 +1,57 @@
+---
+id: db-domain-modeling
+agent: data-engineer
+title: Modelar o domínio de dados
+inputs: [story, arquitetura do @architect]
+outputs: [modelo de domínio (entidades, relações, padrões de acesso), docs/data/domain-model.md]
+elicit: true
+modes: [interactive]
+---
+
+# Modelar o domínio de dados
+
+**Objetivo:** entender o domínio real antes de qualquer DDL — quais são as entidades, como elas se
+relacionam, e como vão ser lidas e escritas — produzindo um modelo de domínio que rastreia à story.
+
+**Pré-condições:**
+- A story (ou spec) que motiva a modelagem existe e descreve o quê precisa ser persistido. Se não há
+  fonte de verdade, **pare** e elicito o escopo — eu não invento entidades (Constituição Art. IV).
+- A arquitetura de sistema do @architect está disponível ou foi consultada. Se falta o contexto
+  arquitetural (escolha de tecnologia, fronteiras de serviço), eu **peço ao @architect** — não decido
+  arquitetura de sistema, isso não é meu.
+
+## Passos
+
+1. **Leia a story e a arquitetura completas.** Extraia cada substantivo de negócio que vira candidato
+   a entidade e cada verbo que vira candidato a operação (leitura/escrita).
+2. **Liste as entidades candidatas** com seus atributos essenciais. Para cada uma, pergunte: ela tem
+   identidade própria e ciclo de vida? Se for só um atributo de outra, não é entidade.
+3. **Mapeie as relações** entre entidades: 1:1, 1:N, N:N. Para cada relação, defina cardinalidade,
+   obrigatoriedade e quem é o lado dono da foreign key.
+4. **Documente os padrões de acesso** (PONTO DE ELICITAÇÃO — exige confirmação do usuário): como cada
+   entidade vai ser consultada? Por qual chave? Com qual frequência? Quais joins quentes? Escala
+   esperada por tabela? Esse mapa guia schema e índices depois — sem ele, eu modelo no escuro.
+5. **Decida normalização pragmática.** Normalize por padrão; só desnormalize quando um padrão de
+   acesso documentado justifica, e registre o porquê no modelo.
+6. **Registre restrições de integridade e segurança de domínio:** quais regras o banco deve fazer
+   cumprir (unicidade, valores válidos, propriedade do dado por usuário/tenant).
+7. **Escreva o modelo** em `docs/data/domain-model.md`: entidades, atributos, relações, padrões de
+   acesso e restrições — cada item com rastro à story. Esse é o input de `create-schema`.
+
+## Critério de pronto (DoD)
+
+- [ ] Toda entidade rastreia a um requisito da story (sem invenção)
+- [ ] Cada relação tem cardinalidade, obrigatoriedade e lado dono da FK definidos
+- [ ] Padrões de acesso confirmados pelo usuário no ponto de elicitação
+- [ ] Decisões de desnormalização (se houver) justificadas por escrito
+- [ ] Restrições de integridade/segurança de domínio listadas
+- [ ] `docs/data/domain-model.md` escrito e pronto para alimentar `create-schema`
+
+## Falha / recuperação
+
+- **Story ambígua ou sem o dado necessário** → paro, registro a lacuna e devolvo ao @sm/@po. Não
+  invento o requisito que falta.
+- **Falta arquitetura/escolha de tecnologia** → escalo ao @architect; não decido arquitetura de
+  sistema no lugar dele.
+- **Usuário não consegue confirmar os padrões de acesso** → não avanço para o schema; um modelo sem
+  padrão de acesso vira índice errado e schema retrabalhado.