trackfw 2.10.0 → 2.11.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "trackfw",
-  "version": "2.10.0",
+  "version": "2.11.0",
   "description": "CLI de governança para entrega de software: ADR → REQ → ROADMAP → kanban. Suporte nativo a agentes de IA (Claude Code, Gemini CLI, Cursor).",
   "keywords": [
     "cli",

package/src/generators/init.js

@@ -336,30 +336,14 @@ function trackfwRulesBlock() {
 This project uses **trackfw** for AI-native delivery governance.
 Chain: \`ADR → REQ → ROADMAP\` · States: \`backlog / analyzing / wip / blocked / done / abandoned\`
 
-\`\`\`
-backlog     → roadmaps aguardando execução
-analyzing   → roadmap em análise/validação pré-wip
-wip         → roadmap em execução ativa (máximo 1)
-blocked     → impedido por dependência ou decisão
-done        → concluído e validado
-abandoned   → descontinuado ou superado
-\`\`\`
-
 ### Agent Protocol
 1. **Before starting:** run \`trackfw context\` · read \`docs/agents-working-context.md\`
 2. **After finishing:** update \`docs/agents-working-context.md\` with what changed
 3. **Before PR:** \`trackfw validate\` must pass
-4. **Ciclo de vida do ML — obrigatório:**
-   - Ao **iniciar** um ML: edite o roadmap alterando \`**Status:** ⬜ Pendente\` → \`**Status:** 🔄 Em andamento\` e faça commit do roadmap.
-   - Ao **concluir** um ML: edite o roadmap alterando \`**Status:** 🔄 Em andamento\` → \`**Status:** ✅ Concluído\` e inclua essa mudança no commit do ML.
-   - Ao **analisar** um roadmap antes de iniciar: mova o arquivo de \`backlog/\` para \`analyzing/\`; só mova para \`wip/\` ao começar a codificar de fato.
-
-### Key Commands
-- \`trackfw context\` — current governance state (always run first)
-- \`trackfw status\` — all artifacts and states
-- \`trackfw validate\` — governance consistency check
-- \`trackfw roadmap move <name> <state>\` — transition roadmap state (\`backlog\`, \`analyzing\`, \`wip\`, \`blocked\`, \`done\`, \`abandoned\`)
-- \`trackfw serve\` — live Kanban board at http://localhost:4080
+4. **ML lifecycle — mandatory:**
+   - Starting a ML: edit roadmap \`**Status:** ⬜ Pendente\` → \`**Status:** 🔄 Em andamento\` + commit.
+   - Completing a ML: edit roadmap → \`**Status:** ✅ Concluído\` + include in ML commit.
+   - Analyzing a roadmap: move from \`backlog/\` to \`analyzing/\`; to \`wip/\` only when coding starts.
 
 ### Attention Signal (when you need user input during a task)
 Write \`docs/roadmaps/.trackfw-attention.json\`:
@@ -369,14 +353,10 @@ Write \`docs/roadmaps/.trackfw-attention.json\`:
 Delete the file when resolved. Visible as a live banner in \`trackfw serve\`.
 ` +
 '\n### Architecture Directives (mandatory)\n' +
-'- **3-layer separation:** frontend / backend / database — never mix concerns\n' +
-'- **No in-memory data:** always database + ORM (never arrays/globals for persistence)\n' +
-'- **Auth from day 1:** never defer — refactoring auth later is very costly\n' +
-'- **Docker + .env from day 1:** containerize early; all config via env vars\n' +
-'- **2-layer validation:** frontend (UX) + backend (security) — never only one\n' +
-'- **API-first:** define OpenAPI contract before coding frontend/backend integration\n' +
-'- **Security wave:** include a red-team review wave in every feature roadmap\n' +
-'- **Test coverage:** TDD for critical logic; min 60% (prototype) / 80% (production)\n' +
+'- **3-layer arch + no in-memory data:** frontend / backend / database; always DB + ORM — never arrays/globals\n' +
+'- **Auth + Docker + .env from day 1:** never defer auth; containerize early; all config via env vars\n' +
+'- **2-layer validation + API-first:** frontend (UX) + backend (security); define OpenAPI contract first\n' +
+'- **Security wave + test coverage:** red-team review in every roadmap; TDD for critical; min 60%/80%\n' +
 '- Use `/trackfw:architect` to define stack before the first REQ\n' +
 RULES_END
 }
@@ -893,14 +873,7 @@ Explique a arquitetura com uma metáfora de negócio:
 - **Backend** = a cozinha: onde as regras de negócio acontecem, nunca exposta diretamente
 - **Banco de dados** = a despensa: onde os dados ficam guardados, acessada só pela cozinha"
 
-Reforce as regras obrigatórias:
-- **Nunca dados em memória** (arrays, variáveis globais): sempre banco + ORM
-- **Docker + .env desde o dia 1**: facilita deploys e evita problemas de ambiente
-- **Auth desde o início**: nunca deixe para depois — refatorar auth é muito custoso
-- **Validação em 2 camadas**: frontend (UX) + backend (segurança)
-- **API-first**: defina o contrato OpenAPI antes de codar frontend e backend juntos
-- **Red team wave**: reserve 1 wave de segurança no roadmap para revisar vulnerabilidades
-- **Cobertura mínima de testes**: 60% (protótipo) / 80% (produção)
+Reforce as **Architecture Directives** já injetadas no CLAUDE.md deste projeto: separação em 3 camadas sem dados em memória (sempre DB + ORM), auth + Docker + .env desde o dia 1, validação em 2 camadas, contrato OpenAPI antes de codar, wave de segurança em todo roadmap e cobertura mínima de testes (60% protótipo / 80% produção).
 
 ---
 
@@ -1016,7 +989,7 @@ function generateClaudeCommandsForce(rootDir) {
     'validate.md': `Execute o seguinte comando bash: \`trackfw validate\`\n\nSe o comando falhar com \`trackfw: command not found\` ou similar, informe ao usuário:\n\n\`\`\`\ntrackfw não está instalado. Instale com uma das opções:\n\n  curl -sSfL https://github.com/kgsaran/trackfw/releases/latest/download/install.sh | sh\n  npm install -g trackfw\n  pip install trackfw\n\`\`\``,
     'status.md': `Execute o seguinte comando bash: \`trackfw status\`\n\nSe o comando falhar com \`trackfw: command not found\` ou similar, informe ao usuário:\n\n\`\`\`\ntrackfw não está instalado. Instale com uma das opções:\n\n  curl -sSfL https://github.com/kgsaran/trackfw/releases/latest/download/install.sh | sh\n  npm install -g trackfw\n  pip install trackfw\n\`\`\``,
     'move.md': `Execute o seguinte comando bash: \`trackfw roadmap move $ARGUMENTS\`\n\nO formato esperado é: \`<nome-do-roadmap> <estado>\`\nEstados válidos: \`backlog\`, \`analyzing\`, \`wip\`, \`blocked\`, \`done\`, \`abandoned\`\n\nSe o comando falhar, instale trackfw com:\n  curl -sSfL https://github.com/kgsaran/trackfw/releases/latest/download/install.sh | sh`,
-    'architect.md': `Você é o guia de arquitetura do trackfw. Ajude o usuário a escolher a stack correta e arquitetar a aplicação em linguagem simples, acessível para times não técnicos.\n\n## Passo 1 — Descoberta de Negócio\n\nFaça ao usuário as seguintes perguntas em linguagem simples, uma por vez:\n\n1. "O que sua aplicação vai fazer? Descreva em 2-3 frases como se fosse explicar para alguém de fora da TI."\n2. "Quantas pessoas vão usar esse sistema simultaneamente? (< 10 pessoas / 10-100 pessoas / > 100 pessoas)"\n3. "Esse sistema vai para produção de verdade ou é um protótipo para validar uma ideia?"\n4. "Você precisa de login/autenticação de usuários? (Sim / Não / Não sei)"\n5. "Tem alguma restrição de tecnologia ou preferência da empresa? (ex: só Java, só Microsoft, etc.)"\n\n---\n\n## Passo 2 — Recomendação de Stack\n\nCom base nas respostas, escolha **UM** dos combos pré-validados:\n\n### Combo A — Protótipo Rápido\n**Quando usar:** prototipagem, validação de ideia, até ~10 usuários, sem pressão de produção.\n- **Frontend:** React + Vite\n- **Backend:** FastAPI (Python) ou Express (Node.js)\n- **Banco:** SQLite + SQLAlchemy / Prisma\n- **Auth:** JWT simples quando necessário\n- **Docker:** Dockerfile básico para o backend\n\n### Combo B — Sistema Pequeno/Médio em Produção\n**Quando usar:** sistema real, 10-100 usuários, robustez e manutenibilidade.\n- **Frontend:** Next.js (SSR + rotas prontas)\n- **Backend:** FastAPI (Python) ou NestJS (Node.js)\n- **Banco:** PostgreSQL + ORM (SQLAlchemy / Prisma / TypeORM)\n- **Auth:** OAuth2 com JWT (Supabase Auth ou Auth0)\n- **Docker:** docker-compose com frontend + backend + banco\n\n### Combo C — Enterprise / Java\n**Quando usar:** integração com sistemas corporativos, > 100 usuários, exigência de Java.\n- **Frontend:** Angular\n- **Backend:** Spring Boot\n- **Banco:** PostgreSQL + Hibernate\n- **Auth:** Spring Security + OAuth2 (Keycloak ou Azure AD)\n- **Docker:** docker-compose com todos os serviços\n\nApresente o combo recomendado com explicação simples do motivo.\n\n---\n\n## Passo 3 — Arquitetura em Camadas (explicação simples)\n\nExplique a arquitetura com uma metáfora de negócio:\n\n"Pense na aplicação como um restaurante:\n- **Frontend** = o salão: o que o cliente vê e interage\n- **Backend** = a cozinha: onde as regras de negócio acontecem, nunca exposta diretamente\n- **Banco de dados** = a despensa: onde os dados ficam guardados, acessada só pela cozinha"\n\nReforce as regras obrigatórias:\n- **Nunca dados em memória** (arrays, variáveis globais): sempre banco + ORM\n- **Docker + .env desde o dia 1**: facilita deploys e evita problemas de ambiente\n- **Auth desde o início**: nunca deixe para depois — refatorar auth é muito custoso\n- **Validação em 2 camadas**: frontend (UX) + backend (segurança)\n- **API-first**: defina o contrato OpenAPI antes de codar frontend e backend juntos\n- **Red team wave**: reserve 1 wave de segurança no roadmap para revisar vulnerabilidades\n- **Cobertura mínima de testes**: 60% (protótipo) / 80% (produção)\n\n---\n\n## Passo 4 — Gerar o ADR de Stack\n\nExecute \`/trackfw:adr\` com o título: \`"Stack e arquitetura em camadas — [nome do projeto]"\`\n\nO ADR deve registrar a stack escolhida (combo e componentes), motivação baseada nas respostas, alternativas descartadas e princípios de arquitetura adotados.\n\n---\n\n## Passo 5 — Próximos Passos\n\nOriente o usuário:\n\n\`\`\`\n✅ Stack definida. Próximos passos:\n\n1. Crie a REQ da primeira feature com /trackfw:req\n2. Gere o roadmap em microlotes com /trackfw:roadmap\n3. Inicie a implementação com /trackfw:implement\n\`\`\``,
+    'architect.md': `Você é o guia de arquitetura do trackfw. Ajude o usuário a escolher a stack correta e arquitetar a aplicação em linguagem simples, acessível para times não técnicos.\n\n## Passo 1 — Descoberta de Negócio\n\nFaça ao usuário as seguintes perguntas em linguagem simples, uma por vez:\n\n1. "O que sua aplicação vai fazer? Descreva em 2-3 frases como se fosse explicar para alguém de fora da TI."\n2. "Quantas pessoas vão usar esse sistema simultaneamente? (< 10 pessoas / 10-100 pessoas / > 100 pessoas)"\n3. "Esse sistema vai para produção de verdade ou é um protótipo para validar uma ideia?"\n4. "Você precisa de login/autenticação de usuários? (Sim / Não / Não sei)"\n5. "Tem alguma restrição de tecnologia ou preferência da empresa? (ex: só Java, só Microsoft, etc.)"\n\n---\n\n## Passo 2 — Recomendação de Stack\n\nCom base nas respostas, escolha **UM** dos combos pré-validados:\n\n### Combo A — Protótipo Rápido\n**Quando usar:** prototipagem, validação de ideia, até ~10 usuários, sem pressão de produção.\n- **Frontend:** React + Vite\n- **Backend:** FastAPI (Python) ou Express (Node.js)\n- **Banco:** SQLite + SQLAlchemy / Prisma\n- **Auth:** JWT simples quando necessário\n- **Docker:** Dockerfile básico para o backend\n\n### Combo B — Sistema Pequeno/Médio em Produção\n**Quando usar:** sistema real, 10-100 usuários, robustez e manutenibilidade.\n- **Frontend:** Next.js (SSR + rotas prontas)\n- **Backend:** FastAPI (Python) ou NestJS (Node.js)\n- **Banco:** PostgreSQL + ORM (SQLAlchemy / Prisma / TypeORM)\n- **Auth:** OAuth2 com JWT (Supabase Auth ou Auth0)\n- **Docker:** docker-compose com frontend + backend + banco\n\n### Combo C — Enterprise / Java\n**Quando usar:** integração com sistemas corporativos, > 100 usuários, exigência de Java.\n- **Frontend:** Angular\n- **Backend:** Spring Boot\n- **Banco:** PostgreSQL + Hibernate\n- **Auth:** Spring Security + OAuth2 (Keycloak ou Azure AD)\n- **Docker:** docker-compose com todos os serviços\n\nApresente o combo recomendado com explicação simples do motivo.\n\n---\n\n## Passo 3 — Arquitetura em Camadas (explicação simples)\n\nExplique a arquitetura com uma metáfora de negócio:\n\n"Pense na aplicação como um restaurante:\n- **Frontend** = o salão: o que o cliente vê e interage\n- **Backend** = a cozinha: onde as regras de negócio acontecem, nunca exposta diretamente\n- **Banco de dados** = a despensa: onde os dados ficam guardados, acessada só pela cozinha"\n\nReforce as **Architecture Directives** já injetadas no CLAUDE.md deste projeto: separação em 3 camadas sem dados em memória (sempre DB + ORM), auth + Docker + .env desde o dia 1, validação em 2 camadas, contrato OpenAPI antes de codar, wave de segurança em todo roadmap e cobertura mínima de testes (60% protótipo / 80% produção).\n\n---\n\n## Passo 4 — Gerar o ADR de Stack\n\nExecute \`/trackfw:adr\` com o título: \`"Stack e arquitetura em camadas — [nome do projeto]"\`\n\nO ADR deve registrar a stack escolhida (combo e componentes), motivação baseada nas respostas, alternativas descartadas e princípios de arquitetura adotados.\n\n---\n\n## Passo 5 — Próximos Passos\n\nOriente o usuário:\n\n\`\`\`\n✅ Stack definida. Próximos passos:\n\n1. Crie a REQ da primeira feature com /trackfw:req\n2. Gere o roadmap em microlotes com /trackfw:roadmap\n3. Inicie a implementação com /trackfw:implement\n\`\`\``,
   }
 
   for (const [filename, content] of Object.entries(commands)) {