jarvis-ai-framework 5.0.0 → 5.2.0

package/agents/product/prod.discovery-interviewer.md

@@ -1,105 +1,40 @@
 ---
 name: prod.discovery-interviewer
-description: Entrevistador de produto que conduz o discovery de uma ideia: entende o problema, os requisitos iniciais e a viabilidade sem chutar, e registra tudo em um rascunho estruturado.
+description: Entrevistador de produto que conduz o discovery de uma ideia: mostra primeiro o que entendeu, faz poucas perguntas de alto impacto com recomendação e registra um rascunho com scorecard e veredito, sem chutar.
 tools: Read, Write, Edit, Glob, Grep, LS, Bash
 model: sonnet
 ---
 
 # @prod.discovery-interviewer
 
-Entrevistador de produto do Jarvis. Conduz o `/prod.spec.discovery`: transforma uma ideia ainda crua em um rascunho estruturado, com o que se sabe, o que é hipótese e o que ainda é lacuna, e indica o próximo passo.
+Entrevistador de produto do Jarvis no `/prod.spec.discovery`. **O fluxo, o orçamento de perguntas e a regra "não chute" estão no workflow `workflows/product/prod.spec.discovery.md`: siga-o.** Este arquivo define só a postura.
 
-As regras de escrita de especificação ficam em `rules/product/` (`prod.spec-rules.md`). O fluxo do comando (criação e retomada do arquivo, veredito, limites) está no workflow `workflows/product/prod.spec.discovery.md`; este arquivo define a **postura**.
+## Postura
 
-## Persona
+Você é um product manager experiente: **testa a ideia, não a julga**, e economiza o tempo de quem responde.
 
-Você é um product manager experiente e curioso, e faz o papel de entrevistador: a qualidade do discovery depende das perguntas certas, não de preencher um formulário.
-
-- **Faz perguntas abertas** e escuta a resposta antes de formular a próxima
-- **Aprofunda respostas rasas**: "por quê?", "para quem?", "com que frequência?", "me dá um exemplo real", "o que acontece hoje?"
-- **Pede evidência** quando ouve uma afirmação sem base ("todo mundo quer") e registra se ela é dado, observação ou suposição
-- **Aponta contradições**, entre respostas ou entre o que o usuário disse e o que está no projeto, e pede que o usuário resolva
-- **Levanta o que o usuário provavelmente não considerou**: quem mais é impactado, custo de manutenção, o que acontece se der errado, a alternativa mais simples
-- **Adapta o roteiro às respostas**: não segue uma lista fixa e não repete temas já esgotados
-- Tom direto e respeitoso; não julga a ideia, testa a ideia
-
-## Objetivo
-
-Ajudar o usuário a fazer o melhor discovery possível de uma ideia, cobrindo quatro eixos:
-
-1. **Ideia**: o que é e para quem
-2. **Problema**: qual dor, que evidência existe, quem sofre, como se resolve hoje
-3. **Requisitos iniciais**: o que precisaria ser verdade, em alto nível, como hipóteses
-4. **Viabilidade**: sinal indicativo de valor, usabilidade, técnica e negócio, com riscos e dependências
-
-O resultado é um arquivo no formato do template `$PROD_TEMPLATES/prod-discovery-template.md` (`templates/product/prod-discovery-template.md`), terminando com um veredito (`proceed`, `investigate_more` ou `do_not_proceed`) e um próximo passo sugerido.
-
-## Quando Usar
-
-- O usuário tem uma ideia e ainda não sabe se o problema é real, quais são os requisitos ou se é viável
-- O usuário roda `/prod.spec.discovery`, com uma ideia ou apontando um discovery existente para retomar
-- O `/prod.spec` identifica que só existe uma ideia inicial
-
-Não use quando já existe uma spec (use `/prod.spec.clarify`) ou quando o escopo já está claro e o usuário quer documentá-lo (use `/prod.spec.prd`, `/prod.spec.frd` ou `/prod.spec.issue`).
-
-## Entrada
-
-- A ideia em texto livre (`$ARGUMENTS`), ou o caminho ou nome de um discovery existente para retomar
-- O contexto do projeto: `ENV.md`, documentos em `$PROD_DOCS` e o código, lidos antes de perguntar
-
-## Saída
-
-- O arquivo `$PROD_DOCS/discoveries/discovery-{id}-{nome}.md`, preenchido pelo template e atualizado a cada tema
-- Uma seção de **Próximo passo sugerido**, sempre presente e sempre só uma sugestão
-
-## Como conduzir a entrevista
-
-1. **Comece explicando** em poucas linhas que vai entrevistar, quais temas cobrirá (ideia, problema, requisitos, viabilidade) e que o usuário pode responder "não sei" a qualquer momento
-2. **Consulte o projeto antes de perguntar**: documentos existentes (para não duplicar um PRD) e o código (para embasar a viabilidade)
-3. **Uma pergunta por vez.** Use o `AskUserQuestion` quando estiver disponível; caso contrário, o formato de tabela do `prod-rules.md`. Espere a resposta antes de seguir
-4. **Se o usuário não responde ou diz "não sei"**, não repita a pergunta: registre "não informado" e siga
-5. **Ao cobrir um tema**, resuma em poucas linhas o que entendeu e peça confirmação antes de passar ao próximo
-6. **Priorize as perguntas de maior impacto** na decisão de seguir ou não, em vez de esgotar todas as possíveis
-7. **Quando achar que já tem informação suficiente**, proponha encerrar e pergunte se o usuário quer acrescentar algo antes de fechar o documento
-
-## Não chute (regra inviolável)
-
-- Quando você não tem uma informação (público, volume, custo, prazo, restrição técnica, comportamento de usuários, estado atual do código), **não presuma nem complete com "o que costuma ser"**: pergunte, busque no projeto ou registre como lacuna
-- Todo fato citado indica a origem: resposta do usuário, arquivo do projeto ou documentação consultada. O que não tem origem entra no documento como **suposição a validar**
-- Se o usuário pedir "preencha o que faltar" ou "assuma o padrão", registre o item como **suposição explícita**, nunca como fato, e não a use para sustentar o veredito
-- Uma **lacuna crítica nunca** resulta em `proceed`: o veredito é `investigate_more`
-- Quando a viabilidade técnica depende de bibliotecas, APIs ou serviços, consulte a documentação atual (por exemplo via Context7) em vez de responder de memória
+- **Entende antes de perguntar:** lê o que já existe e devolve o que entendeu, separando o que foi dito, o que é suposição e o que falta
+- **Pergunta pouco e certo:** só o que muda o veredito, da pergunta mais impactante para a menos, sempre com o porquê e uma recomendação
+- **Não pergunta o óbvio:** um padrão razoável vira suposição registrada, não pergunta
+- **Pede evidência e aponta contradição** só quando isso muda a decisão
+- **Lembra do que o usuário não considerou:** quem mais é impactado, custo de manutenção, o que acontece se der errado, a alternativa mais simples
+- **Fecha com clareza:** abordagens com recomendação, scorecard honesto (`desconhecido` é uma resposta válida) e um próximo passo pronto para usar
+- Tom direto e respeitoso
 
 ## Skills Disponíveis
 
-As skills são apoio, nunca a fonte da decisão. A busca em `$PROD_DOCS` não é uma skill: é feita sempre, antes de perguntar.
-
 ### jarvis-docs-central
-Para conhecer o que já foi implementado no produto (funcionalidades do Central docs), quando `CENTRAL_DOCS_STORAGE` estiver configurado:
-- Arquivo: `$IDE/skills/jarvis-docs-central/SKILL.md`
-- Confiança: sempre
-
-### jarvis-context-detect
-Para calibrar a profundidade da entrevista:
-- Arquivo: `$IDE/skills/jarvis-context-detect/SKILL.md`
-- Confiança: sempre
+O que já foi implementado, quando `CENTRAL_DOCS_STORAGE` estiver configurado. Confiança: sempre.
 
 ### eng-backend-arch-c4
-Para consultar a arquitetura atual:
-- Arquivo: `$IDE/skills/eng-backend-arch-c4/SKILL.md`
-- Confiança: só com a confirmação do usuário (skill de engenharia: pergunte antes de consultá-la; o que ela retornar entra no discovery como **suposição a validar**, não como fato)
+Arquitetura atual. Confiança: só com a confirmação do usuário; o retorno é **suposição a validar**.
 
 ### eng-platform
-Para quando a ideia envolve infraestrutura, dados pessoais ou fluxo financeiro com risco de segurança/privacidade:
-- Arquivo: `$IDE/skills/eng-platform/SKILL.md` (temas 9 e 13)
-- Confiança: só com a confirmação do usuário (skill de engenharia: pergunte antes de consultá-la; o que ela retornar entra no discovery como **suposição a validar**, não como fato)
+Infraestrutura, dados pessoais ou risco de segurança (temas 9 e 13). Confiança: só com a confirmação do usuário; o retorno é **suposição a validar**.
 
 ## Restrições
 
-- **O discovery é um rascunho.** Você **não** gera PRD, FRD, épico, issue, tarefas, histórias, critérios de aceitação nem estimativas (horas ou pontos). Se o usuário pedir, explique que é outra etapa e indique o comando certo
-- **Não escreve código** e não implementa nada
-- **Não grava credenciais, tokens nem dados pessoais de clientes** no arquivo: o discovery é versionado
-- **Não entrevista terceiros**: a entrevista é sempre com o usuário que executou o comando
-- **Não executa o próximo passo**: só sugere. O usuário pode escolher outro caminho ou parar ali
-- Um rascunho de abordagem técnica pode aparecer na viabilidade, sempre como hipótese a validar; a decisão de arquitetura pertence ao fluxo de engenharia
-- Siga as regras de `$PROD_RULES` (`prod-rules.md`): validação do `ENV.md`, idioma (pt-BR por padrão, ou o idioma da interação do usuário) e confirmação antes de salvar arquivos
+- Não gera PRD, FRD, épico, issue, histórias, critérios de aceitação nem estimativas; indique o comando certo
+- Não escreve código nem decide arquitetura (um rascunho técnico é sempre suposição)
+- Não entrevista terceiros e não executa o próximo passo: só sugere
+- Não grava credenciais, tokens nem dados pessoais de clientes

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jarvis-ai-framework",
-  "version": "5.0.0",
+  "version": "5.2.0",
   "description": "Jarvis framework",
   "type": "module",
   "bin": {

package/rules/AGENTS.md

@@ -32,8 +32,9 @@ rules-on-demand/              # Lidas pelo workflow que as usa (não carregadas
 │   ├── eng.pr-rules.md       # Regras para /eng.pr
 │   ├── eng.tech-spec-rules.md # Regras para tech specs
 │   └── eng.breakdown-subtasks-rules.md # Regras para o breakdown de subtarefas
-└── product/
-    └── prod.guided-rules.md  # Modo Developer-Guided (lida só com PROD_MODE=developer-guided)
+├── product/
+│   └── prod.guided-rules.md  # Modo Developer-Guided (lida só com PROD_MODE=developer-guided)
+└── warm-up-consume-rules.md  # Consumo do /warm-up (lida pelo eng.start e pelos prod.spec* só quando há aquecimento)
 ```
 
 ### `rules/` x `rules-on-demand/`

package/rules/product/prod.spec-rules.md

@@ -162,12 +162,12 @@ A terminologia inconsistente cria confusão. "Cliente" vs "Usuário" vs "Cliente
 **Como usar o discovery**:
 - Leia o discovery como **contexto, não como resposta**: é um rascunho e pode estar defasado.
 - **Questione e repasse tudo com o usuário**, seção por seção: mostre o que está registrado e pergunte se ainda vale ou se mudou.
-- Hipóteses e perguntas em aberto do discovery são perguntadas como tais; o que o comando exige e o discovery não cobre é perguntado normalmente.
+- Suposições e lacunas do discovery (seção Entendimento; em discoveries antigos, Hipóteses e Perguntas em aberto) são perguntadas como tais; o que o comando exige e o discovery não cobre é perguntado normalmente.
 - Nada do discovery entra no documento novo como fato sem o usuário ter passado por aquilo. O que ficar sem validação continua marcado como suposição.
 
 **Avisos conforme a situação do discovery**:
 - `verdict: do_not_proceed` (ou `status: cancelled`): avise que a recomendação foi não seguir, mostre o motivo registrado e só continue com confirmação explícita do usuário.
-- `verdict: investigate_more`, `verdict` vazio ou `status: in_review` (discovery ainda em entrevista): avise que há lacunas críticas, liste as perguntas em aberto e pergunte se o usuário quer retomar o discovery antes ou seguir assumindo o risco.
+- `verdict: investigate_more`, `verdict` vazio ou `status: in_review` (discovery ainda em entrevista): avise que há lacunas críticas, liste as lacunas e pergunte se o usuário quer retomar o discovery antes ou seguir assumindo o risco.
 - `verdict: proceed`: siga normalmente.
 
 **O documento novo é o oficial**:

package/rules-on-demand/engineering/eng.pr-rules.md

@@ -323,6 +323,7 @@ Antes de considerar o PR completo:
 - [ ] Comentários de code review processados
 - [ ] `pull-request.md` aprovado na sessão (e publicado, se o usuário respondeu Sim)
 - [ ] Lembrete do `/eng.spec-consolidate` na mensagem final
+- [ ] `daily.md` gerado ou atualizado e aprovado (só com PR aberto), com a linha de timesheet na mensagem final
 
 ---
 
@@ -331,3 +332,17 @@ Antes de considerar o PR completo:
 - O texto do PR fica em **`$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/pull-request.md`**, aprovado pelo usuário.
 - **Publicar (push + MR/PR) só com o Sim** do `AskUserQuestion` "Publicar o PR agora?". Com Não, o arquivo fica na sessão e nada é enviado.
 - **A sessão nunca é apagada por este comando:** o `/eng.spec-consolidate`, que roda em seguida, precisa do `architecture.md`, do `plan.md`, do `gate-checklist.md` e do `pull-request.md`. A pessoa apaga à mão quando quiser.
+
+## daily.md (registro do esforço)
+
+- Gerado na Conclusão do `eng.pr`, em `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/daily.md`, **só com PR aberto**: o criado nesta execução ou o PR da branch já existente e aberto. Sem PR aberto, não gerar.
+- **Sempre perguntar a data** (hoje ou retroativa) com `AskUserQuestion`.
+- **Período de mais de um dia:** antes de contar os dias trabalhados, perguntar sobre sábado/domingo trabalhados, feriados e outros dias não trabalhados (o usuário informa as datas).
+- ***Post mortem*:** automático com `tipo: bugfix|hotfix` no `context.md` ou com mais de 1 dia trabalhado; nos outros casos, perguntar Sim/Não.
+- **Nova execução** (`daily.md` já existe): perguntar a origem da mudança.
+  - **Ajuste do próprio usuário:** focar no que foi entregue, sem citar troca de escopo nem retrabalho.
+  - **Pedido da liderança:** documentar o que mudou, quem pediu e o impacto.
+- **Formato fixo** (`templates/engineering/daily-template.md`): uma seção `## AAAA-MM-DD` com "Descrição detalhada" e "Timesheet" (uma linha).
+- **Revisão conjunta:** mostrar a descrição e a linha de timesheet juntas, com `[Aprovar]`/`[Ajustar]`; ajustar as duas juntas até aprovar.
+- **Nunca publicar** o `daily.md` e nunca incluir e-mails, tokens nem valores de variáveis.
+

package/rules-on-demand/warm-up-consume-rules.md

@@ -0,0 +1,30 @@
+> **Applies to:** HUB: all | POSITION: all | AREA: all | SQUAD: all
+
+# Consumo do warm-up
+
+## Objetivo
+
+Levar um aquecimento do `/warm-up` (`$SESSIONS_DIR/warm-ups/{apelido}/warm-up.md`) para a sessão da tarefa. Lida pelo `/eng.start` e pelos `/prod.spec*` só quando a pasta `warm-ups/` tiver aquecimentos.
+
+## Regras
+
+### Obrigatório
+
+1. **Listar** `$SESSIONS_DIR/warm-ups/*/warm-up.md`. Nenhum: siga o comando sem perguntar nada.
+2. **Perguntar** com `AskUserQuestion`: **"Usar um aquecimento do warm-up?"**, uma opção por apelido (até 3, os mais recentes, com repositórios e data), mais **Não usar**.
+3. **Gravar** o conteúdo do escolhido, num bloco `## Warm-up ({apelido})`, no `context.md` da sessão:
+   - engenharia: `$SESSIONS_DIR/eng/{TASK_MANAGER_KEY}/context.md`, depois do `/jarvis-context-detect` (acrescente; não substitua o `CONTEXT_PROFILE`);
+   - produto: `$SESSIONS_DIR/prod/{id do documento}/context.md` (ex.: `prd-001`, `discovery-002`), ou `$SESSIONS_DIR/prod/{TASK_MANAGER_KEY}/` se a chave foi informada. Grave quando o comando já tiver definido o id.
+4. **Apagar** a pasta `$SESSIONS_DIR/warm-ups/{apelido}/` depois de gravar.
+5. **Usar** o bloco como contexto da tarefa: repositórios e áreas ativas (carregue só as especialidades dessas áreas), recorte do Central docs, entregas recentes e versões das ferramentas. Não refaça o que o aquecimento já trouxe.
+
+### Proibido
+
+- Usar um aquecimento sem a escolha do usuário
+- Apagar a pasta antes de gravar o bloco no `context.md`
+- Copiar para o `context.md` tokens, e-mails ou valores do `ENV.md`
+
+## Referências
+
+- `workflows/warm-up.md`: quem gera o aquecimento
+- `templates/warm-up-template.md`: formato do aquecimento

package/skills/AGENTS.md

@@ -222,7 +222,7 @@ Skills são invocados de formas diferentes dependendo da IDE:
 | Comando / Trigger | Skill |
 |-------------------|-------|
 | `/jarvis-init` | `jarvis-init` |
-| `/warm-up` | `jarvis-docs-central` (sync) |
+| `/warm-up` | `jarvis-docs-central` (só o recorte escolhido), `context7` (se o MCP estiver disponível) |
 | `eng.start` | `jarvis-docs-central` (buscar PRD/ARD) |
 | `/eng.docs` | `eng-global-docs-write`, `jarvis-docs-index` |
 | `/eng.pre-pr` | `eng-qa-planner`, `eng-global-docs-write`, `jarvis-docs-central` (detectar docs) |

package/skills/jarvis-init/SKILL.md

@@ -675,6 +675,9 @@ grep -qxF '.jarvis/' .gitignore 2>/dev/null || echo '.jarvis/' >> .gitignore
 #    JARVIS_DOCS=$DOCS_FOLDER/jarvis, PROD_DOCS=$JARVIS_DOCS/product, ENG_DOCS=$JARVIS_DOCS/engineering
 #    (valores do template) e docs/jarvis/ fora do versionamento (uma docs/ já existente não é tocada):
 grep -qxF 'docs/jarvis/' .gitignore 2>/dev/null || echo 'docs/jarvis/' >> .gitignore
+
+# 9. Mapa de tecnologias do workspace (CDD-MIND-MAP.md, na raiz, ao lado do AGENTS.md) fora do versionamento:
+grep -qxF 'CDD-MIND-MAP.md' .gitignore 2>/dev/null || echo 'CDD-MIND-MAP.md' >> .gitignore
 ```
 
 ### 5.2 Central docs (sempre)
@@ -972,6 +975,8 @@ Se não existir na raiz do projeto:
 2. Extrair informações do projeto
 3. Criar a partir do template com substituições
 4. Se não detectar, perguntar ao usuário
+5. Incluir (ou acrescentar, se o `AGENTS.md` já existir e não citar) a linha que identifica o mapa como contexto de workspace:
+   `> Contexto de workspace: [CDD-MIND-MAP.md](CDD-MIND-MAP.md) (tecnologias e papel de cada repositório; lido pelo /warm-up).`
 
 ### 8. Profile-Aware Rules Sync
 
@@ -1076,6 +1081,7 @@ A **detecção de stack por código e a criação de skill novo** (sub-passos 9.
 3. **Lê** o workspace (a análise **só lê**: não altera arquivos do projeto nem as listas), identifica as stacks de backend e de frontend, inclusive de vários projetos, e **mostra o que encontrou antes de sugerir** (só essas 2 áreas)
 4. Para cada stack de backend/frontend, sugere **registrar o skill que já existe** (mesmo `area` e `stack`) ou **criar um novo** com `/jarvis-create-specialization {área} {stack}`; a pessoa escolhe, e o que não aceita não muda
 5. Mostra um resumo das 6 listas e do que foi registrado ou criado
+6. **Monta o `CDD-MIND-MAP.md`** (o mapa de tecnologias do workspace, lido pelo `/warm-up`): com a mesma leitura do sub-passo 3, agora para **todas as áreas**, preenche uma linha por repositório (papel, linguagem, framework, área, até 5 ferramentas principais) pelo `$IDE/templates/cdd-mind-map-template.md`, mostra a tabela e pede a validação com `AskUserQuestion` (**Confirmar** | **Corrigir** | **Incluir informação**). Grava na raiz do workspace (já no `.gitignore`, Passo 5). Se o mapa já existe, só acrescenta os repositórios que faltam. Pular é permitido: o primeiro `/warm-up` cria o mapa.
 
 O tempo de ~10 minutos é referência, não limite. Nunca leia `.env*`, chaves ou credenciais.
 

package/templates/AGENTS.md

@@ -14,6 +14,8 @@ A pasta `templates/` contem **modelos de documentos** usados pelo framework para
 
 ```
 templates/
+├── cdd-mind-map-template.md        # Mapa de tecnologias do workspace (CDD-MIND-MAP.md; /warm-up e /jarvis-init)
+├── warm-up-template.md             # Aquecimento por apelido ($SESSIONS_DIR/warm-ups/{apelido}/)
 ├── engineering/                    # Templates tecnicos
 │   ├── architecture-template.md    # Template de arquitetura
 │   ├── advisor-template.md         # Prompts e auditoria do Advisor

package/templates/ENV-template.md

@@ -30,7 +30,7 @@ USER=
 # Limite de autonomia da IA neste workspace (60–100). 80 = a IA executa até 80%.
 MAX_AI_EXECUTION_PERCENTAGE=80
 
-# Context-Driven Development — deixe true. O warm-up calibra o comportamento.
+# Context-Driven Development — deixe true. Os comandos eng.* calibram o comportamento pelo CDD.
 ENABLE_CDD=true
 
 

package/templates/cdd-mind-map-template.md

@@ -0,0 +1,26 @@
+---
+# Data da última atualização do mapa (YYYY-MM-DD).
+updated_at: {YYYY-MM-DD}
+
+# Nome do workspace (WORKSPACE do ENV.md; vazio = nome da pasta que contém $IDE/).
+workspace: {nome}
+---
+
+# CDD-MIND-MAP — {workspace}
+
+> **Contexto de workspace:** o mapa de tecnologias e o papel de cada repositório deste workspace. Fica na raiz, ao lado do `AGENTS.md`, **fora do versionamento** (`.gitignore`), e é lido sob demanda pelo `/warm-up`. É definido uma vez e reaproveitado; não guarda decisões nem contexto de tarefa (isso vai para o `context.md` da sessão).
+
+| Repositório | Papel | Linguagem | Framework | Área | Ferramentas principais | Observações |
+|-------------|-------|-----------|-----------|------|------------------------|-------------|
+| {pasta} | {api, gateway, front, worker, lib…} | {php, golang, node…} | {laravel, nestjs, react, quasar…} | {backend, frontend, qa, data, automation, platform} | {até 5: framework, linguagem, ORM, testes} | {o que o usuário acrescentou} |
+
+<!--
+Como preencher (o /warm-up e o /jarvis-init seguem estas instruções):
+- Uma linha por repositório com .git do workspace (respeitando WORKSPACE_REPOS, se preenchida); em projeto único, uma linha para a raiz.
+- Linguagem e framework: pela tabela skills/jarvis-init/assets/sinais-de-stack.md (manifesto → linguagem → dependência → framework). Área: a da linha da tabela; sem sinal, pergunte.
+- Papel: inferido da estrutura e do nome (ex.: rotas sem regra de negócio → gateway); é sempre hipótese até o usuário confirmar.
+- Ferramentas principais: as dependências diretas mais relevantes do manifesto, com a versão declarada; no máximo 5.
+- Leia só manifestos e a estrutura de pastas. Nunca leia .env*, chaves, certificados nem credenciais.
+- Antes de gravar, mostre a tabela ao usuário e peça a validação (confirmar, corrigir, incluir informação).
+- Mapa existente: acrescente só os repositórios que faltam; não reprocesse as linhas já validadas.
+-->

package/templates/engineering/daily-template.md

@@ -0,0 +1,55 @@
+---
+# Modelo de IA recomendado para trabalhar neste documento. Se a sessão estiver em outro,
+# o comando avisa e segue (você decide se troca). Opções: opus | sonnet | haiku
+recommended_model: opus
+
+# Card ou número de controle da tarefa (TASK_MANAGER do ENV.md; freelance = número de controle).
+task_key: {TASK-123}
+
+# URL do card no task manager (padrão da eng.integrations-rules.md). Vazio no modo freelance.
+card_url: {URL}
+
+# Pull/Merge Request aberto: número e URL. O daily.md só existe com PR aberto.
+pr: {#n URL}
+
+# Branch de trabalho e branch base (Branch base: do architecture.md).
+branch: {branch}
+base: {main | dev | outra}
+
+# Dias efetivamente trabalhados no período eng.start → registro (descontados fim de semana não
+# trabalhado, feriados e outros dias não trabalhados informados). Ex.: "3 (2026-10-13, 2026-10-14, 2026-10-15)"
+worked_days: {n (datas)}
+
+# A descrição usa o formato post mortem? Opções: yes | no
+# yes = bugfix/hotfix, mais de 1 dia trabalhado, ou investigação longa confirmada pelo usuário
+post_mortem: {yes | no}
+
+# Data da última atualização deste arquivo (YYYY-MM-DD).
+updated_at: {YYYY-MM-DD}
+---
+
+# Daily — {TASK_KEY}
+
+> Registro pessoal do esforço: narrativa auditável e linha pronta para o timesheet. Fica só na sessão, nunca é publicado. Uma seção por data (`## AAAA-MM-DD`), no formato abaixo, para um comando futuro juntar os registros de um dia.
+
+## {AAAA-MM-DD}
+
+### Descrição detalhada
+
+{Um parágrafo narrativo: o contexto técnico, o que foi feito e as decisões. Detalhe suficiente para servir de embasamento em questionamentos futuros, auditorias ou consultas técnicas.}
+
+**Post mortem** _(só quando `post_mortem: yes`)_
+- **Problema e causa raiz:** {o problema identificado e a causa raiz, se aplicável}
+- **Investigação:** {o raciocínio e o processo de investigação adotado}
+- **Solução / direcionamento:** {a solução ou o direcionamento técnico final}
+
+**Mudança de escopo** _(só quando pedida pela liderança: gerente, PM, tech lead)_
+- **O que mudou:** {…}
+- **Quem pediu:** {papel/nome, como o usuário informou}
+- **Impacto:** {no prazo, no esforço, no resultado}
+
+**Referências:** card [{TASK_KEY}]({URL}) · PR/MR [#{n}]({URL}) · commits `{hash}`, `{hash}`
+
+### Timesheet
+
+`{TASK_KEY} — {resumo da atividade em uma única linha}`

package/templates/product/prod-discovery-template.md

@@ -10,112 +10,80 @@ id: {discovery-001}
 name: {nome dessa ideia}
 
 # Situação do rascunho. O discovery tem ciclo próprio (rules/product/prod-rules.md).
-# Opções: in_review | cancelled
-# in_review = rascunho em andamento ou concluído | cancelled = o veredito foi do_not_proceed
+# Opções: in_review (rascunho em andamento ou concluído) | cancelled (o veredito foi do_not_proceed)
 status: {in_review | cancelled}
 
 # Recomendação do discovery: vale seguir com essa ideia? Fica vazio durante a entrevista.
-# Opções: proceed | investigate_more | do_not_proceed
-# proceed = vale especificar | investigate_more = há lacuna crítica | do_not_proceed = não seguir (status passa a cancelled)
+# Opções: proceed (vale especificar) | investigate_more (há lacuna crítica) | do_not_proceed (não seguir; status passa a cancelled)
 verdict: {vazio durante a entrevista | proceed | investigate_more | do_not_proceed}
 
-# Data de criação (YYYY-MM-DD).
-created_at: {YYYY-MM-DD}
+# Tamanho da ideia; define quantas perguntas a entrevista faz.
+# Opções: small (trabalho já claro, até 2) | bounded (funcionalidade num produto existente, até 5) | broad (várias entregas, até 8)
+size: {small | bounded | broad}
 
-# Data da última alteração (YYYY-MM-DD).
+# Datas de criação e da última alteração (YYYY-MM-DD).
+created_at: {YYYY-MM-DD}
 updated_at: {YYYY-MM-DD}
 
-# Quem criou o documento.
+# Quem criou o documento e quem o editou por último (USER do ENV.md).
 created_by: {nome de quem criou esse doc}
-
-# Quem editou o documento por último.
 last_editor: {nome de quem editou por último}
 ---
 
 # {id}: {name}
 
-> **Este documento é um rascunho.** Ele registra o que se sabe, o que é hipótese e o que ainda é lacuna sobre uma ideia. Não define tarefas, histórias, critérios de aceitação, estimativas nem escopo fechado, e nada aqui é verdade absoluta. Quando um PRD, FRD, épico ou issue for criado a partir dele, o documento novo é a fonte da verdade.
->
-> Nunca registre credenciais, tokens nem dados pessoais de clientes neste arquivo: ele é versionado.
-
-## Ideia
-
-{O que é a ideia, em poucas frases, e para quem ela é. Use as palavras do usuário; não acrescente o que ele não disse.}
+> **Rascunho.** Registra o que se sabe, o que é suposição e o que ainda é lacuna sobre uma ideia. Não define tarefas, histórias, critérios de aceitação nem estimativas. Um PRD, FRD, épico ou issue criado a partir dele é a fonte da verdade. Nunca registre credenciais, tokens nem dados pessoais de clientes.
 
-## Problema
-
-{Declare o problema, não a solução. Responda, sempre que souber:}
-
-- **Qual é o problema?** {a dor, o que não funciona hoje}
-- **Quem sofre com ele?** {quem e em que situação}
-- **Qual a evidência de que ele existe?** {dado, relato ou observação; se não houver, diga "sem evidência"}
-- **Como se resolve hoje?** {a alternativa atual, mesmo que seja uma gambiarra}
-- **Por que agora?** {o que torna isto relevante neste momento}
-- **Como saberemos que funcionou?** {sinais de sucesso, sem metas fechadas}
+## Entendimento
 
-## Hipóteses
+{A ideia em uma frase, nas palavras do usuário, e para quem ela é.}
 
-{Uma tabela única com tudo o que precisaria ser verdade para a ideia funcionar: requisitos iniciais e suposições. Requisitos são hipóteses de alto nível, sem critério de aceitação. Destaque as de importância alta e certeza baixa: são as primeiras a validar e alimentam as perguntas em aberto.}
+| Dito por você | Suposição (origem) | Lacuna (quem responde) |
+|---|---|---|
+| {fato informado pelo usuário} | {o que precisa ser verdade; origem: dado, observação ou suposição} | {o que falta saber; marque **crítica** se mudar o veredito} |
 
-| Hipótese | Tipo | Importância | Certeza | Origem | Como validar |
-|---|---|---|---|---|---|
-| {o que precisaria ser verdade} | {problema, requisito, usuário, técnica ou negócio} | {alta, média ou baixa} | {alta, média ou baixa} | {dado, observação ou suposição} | {como confirmar ou descartar} |
+## Problema
 
-## Viabilidade
+- **Dor:** {o que não funciona hoje, sem falar de solução}
+- **Quem sofre:** {quem e em que situação}
+- **Evidência:** {dado, relato ou observação; se não houver, "sem evidência"}
+- **Como se resolve hoje:** {a alternativa atual, mesmo que seja uma gambiarra}
+- **Por que agora:** {o que torna isto relevante neste momento}
+- **Sinal de sucesso:** {como saberemos que funcionou, sem metas fechadas}
 
-{Um sinal indicativo por lente, com a justificativa e as lacunas que o sustentam. É uma leitura inicial, não um desenho técnico nem uma estimativa. Um rascunho de abordagem técnica pode aparecer, sempre como hipótese a validar e nunca como decisão de arquitetura.}
+## Abordagens
 
-| Lente | Sinal | Justificativa e lacunas |
+| Abordagem | Prós | Contras |
 |---|---|---|
-| **Valor:** alguém vai querer e usar? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
-| **Usabilidade:** as pessoas conseguem usar? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
-| **Técnica:** dá para construir com o que temos? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
-| **Negócio:** funciona para o negócio (custo, prazo, risco)? | {alto, médio ou baixo} | {por quê; o que ainda não se sabe} |
+| {a menor coisa que funciona} | {…} | {…} |
+| {outra opção} | {…} | {…} |
+| {não fazer / usar algo existente} | {…} | {…} |
 
-## Alternativas e riscos
+**Recomendação:** {qual abordagem e por quê, em 1–2 frases} · **Riscos e dependências:** {com quem pode confirmar}
 
-{Inclua sempre "não fazer nada" e "usar algo que já existe", além das opções levantadas.}
+## Scorecard
 
-| Alternativa | Prós | Contras |
+| Lente | Nota | Justificativa |
 |---|---|---|
-| {não fazer nada} | {prós resumidos} | {contras resumidos} |
-| {usar algo existente} | {prós resumidos} | {contras resumidos} |
-| {outra opção} | {prós resumidos} | {contras resumidos} |
-
-**Riscos e dependências:**
-
-- {risco ou dependência, com quem pode confirmar}
-
-## Perguntas em aberto
-
-{O que ainda precisa ser validado, com quem e como. Comece pelas hipóteses de importância alta e certeza baixa.}
-
-- [ ] {pergunta} — quem responde: {pessoa ou área}
+| **Valor:** alguém vai querer e usar? | {forte, adequado, fraco ou desconhecido} | {uma linha} |
+| **Usabilidade:** as pessoas conseguem usar? | {…} | {…} |
+| **Técnica:** dá para construir com o que temos? | {…} | {…} |
+| **Negócio:** custo, prazo e risco fazem sentido? | {…} | {…} |
 
 ## Veredito
 
-{Uma recomendação, não uma aprovação. Escolha uma e justifique em poucas linhas:}
-
-- **proceed** (seguir): vale especificar. O problema parece real e não há lacuna crítica aberta
-- **investigate_more** (investigar mais): há lacuna crítica; liste o que falta. Uma lacuna crítica nunca dá `proceed`
-- **do_not_proceed** (não seguir): informe o motivo; o `status` passa a `cancelled` e o arquivo fica como registro da decisão
-
 **Veredito:** {proceed | investigate_more | do_not_proceed}
 
-**Motivo:** {justificativa}
+**Motivo:** {justificativa curta. Lacuna crítica aberta ou lente crítica "desconhecido" nunca dá `proceed`. Com `do_not_proceed`, o `status` passa a `cancelled`.}
 
 ## Próximo passo sugerido
 
-{Sempre preencha, qualquer que seja o veredito. É só uma sugestão: o agente oferece usar este documento como insumo, mas nunca executa o comando sozinho, e você pode escolher outro caminho ou parar aqui.}
-
-- **Comando recomendado:** {/prod.spec.prd (e depois /prod.spec.breakdown), /prod.spec.frd, /prod.spec.issue, retomar este discovery ou arquivar a ideia}
+- **Comando** (só uma sugestão, nunca executado sozinho): {ex.: /prod.spec.issue discovery-001 · /prod.spec.frd discovery-001 · /prod.spec.prd discovery-001 (e depois /prod.spec.breakdown) · retomar este discovery · arquivar}
 - **Motivo:** {por que esse caminho}
-- **Alternativa:** {outro caminho possível, se houver}
-
-## Histórico das sessões
+- **Alternativa:** {outro caminho, se houver}
 
-{Um registro por sessão de entrevista, em ordem cronológica.}
+## Histórico
 
-| Data | O que foi coberto | Observações |
+| Data | Perguntas | O que ficou pendente |
 |---|---|---|
-| {YYYY-MM-DD} | {temas cobertos nesta sessão} | {o que ficou pendente} |
+| {YYYY-MM-DD} | {N de até M} | {lacunas abertas} |

package/templates/warm-up-template.md

@@ -0,0 +1,45 @@
+---
+# Apelido do aquecimento (o usuário escolhe no /warm-up). É o nome da pasta $SESSIONS_DIR/warm-ups/{apelido}/.
+apelido: {apelido}
+
+# Data em que o aquecimento foi gerado (YYYY-MM-DD).
+created_at: {YYYY-MM-DD}
+
+# Repositórios aquecidos nesta sessão (ACTIVE_REPOS), separados por vírgula.
+active_repos: {repo-a, repo-b}
+
+# Áreas confirmadas pelo usuário; as especialidades das outras ficaram de fora.
+areas: {backend, frontend}
+---
+
+# Warm-up — {apelido}
+
+> Contexto aquecido para **uma tarefa**. O `/eng.start` ou o `/prod.spec*` que usá-lo copia este conteúdo para o `context.md` da sessão e apaga a pasta (`rules-on-demand/warm-up-consume-rules.md`).
+
+## Escopo
+
+| Repositório | Papel | Stack | Branch alvo |
+|-------------|-------|-------|-------------|
+| {repo} | {papel, do CDD-MIND-MAP.md} | {linguagem / framework} | {main, dev…} |
+
+**Especialidades carregadas:** {área: base + especializações da lista} · **Fora do escopo:** {áreas descartadas}
+
+## Central docs
+
+{Produto e funcionalidade escolhidos. Para cada `feature-*.md` lido: o comportamento atual em 2–3 linhas e onde está no código. Entregas (`delivery-*.md`) do recorte, uma linha cada. Sem Central docs: "não configurado".}
+
+## Entregas recentes
+
+| Repositório | Merge | Título | Arquivos tocados |
+|-------------|-------|--------|------------------|
+| {repo} | {hash curto, data} | {título do PR/merge} | {principais pastas/arquivos} |
+
+{Padrões ou decisões recentes que valem para a tarefa, em até 3 linhas.}
+
+## Ferramentas (context7)
+
+| Ferramenta | Versão no projeto | Versão atual | Observação |
+|------------|-------------------|--------------|------------|
+| {nome} | {declarada no manifesto} | {do context7} | {mudança relevante, se houver} |
+
+{Sem MCP context7: "não consultado".}