jarvis-ai-framework 7.0.0 → 8.2.0

package/workflows/product/prod.spec.epic.md

@@ -123,15 +123,15 @@ Após a aprovação do usuário:
 1. Atualize a PRD com as alterações relacionadas ao épico
 2. Atualize o arquivo de breakdown (plan) com as alterações relacionadas ao épico
 
-## Busca no Central Docs (condicional)
+## Busca de contexto (`$PROD_DOCS` sempre; Central docs se configurado)
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md, antes de criar o épico:
+Antes de criar o épico (a busca em `$PROD_DOCS` é sempre feita; a consulta ao Central docs só se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md; vazio, pule só o `jarvis docs sync`):
 
-- Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
+- Se `CENTRAL_DOCS_STORAGE` estiver definido, consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
   ```bash
   jarvis docs sync --silent
   ```
-- Buscar PRD e épicos existentes em `$PROD_DOCS` e, no Central docs, as funcionalidades já implementadas relacionadas
+- Buscar PRD e épicos existentes em `$PROD_DOCS`
 - Se encontrar: carregar como contexto e informar o usuário
 - Se não encontrado: continuar com fluxo normal
 

package/workflows/product/prod.spec.frd.md

@@ -61,9 +61,9 @@ A FRD não é um épico, história ou task: ela serve como documento de detalham
 
 ---
 
-## Busca no Central Docs (condicional)
+## Busca de contexto (`$PROD_DOCS` sempre; Central docs se configurado)
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
+A busca em `$PROD_DOCS` é sempre feita. A consulta ao Central docs (o que já foi implementado) só acontece se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md; vazio, pule só o `jarvis docs sync`.
 
 1. **Buscar PRD correspondente:**
    - Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
@@ -178,7 +178,7 @@ O sistema deve validar os dados do formulário.
 ## Instruções
 
 - Se o usuário forneceu ou está atuando em um projeto existente, priorize obter informações sobre o projeto a partir de:
-  - **Central-docs** (se configurado) - busca automática do PRD correspondente
+  - **Central-docs** (se configurado) - funcionalidades já implementadas; o PRD correspondente vem de `$PROD_DOCS`
   - Documentação existente (README, docs/, PRDs, FRDs, ARDs, etc.)
   - Commits recentes para entender o que está sendo desenvolvido
   - Arquivos de AI como CLAUDE.md e AGENTS.md para obter informações estruturadas sobre o contexto do projeto/produto.

package/workflows/product/prod.spec.issue.md

@@ -47,7 +47,7 @@ Um grupo de histórias de um mesmo assunto podem formar um épico.
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Estrutura da Issue (salvar no `$TASK_MANAGER`) | CLI do vendor (`gh`/`glab issue create`, `acli jira workitem create`) | Se o usuário pedir para salvar no `$TASK_MANAGER` e `TASK_MANAGER`, `TASK_MANAGER_ACCESS` e `TASK_MANAGER_URL_BASE` estiverem no ENV.md, com a CLI logada; freelance, CLI indisponível ou `TASK_MANAGER_ACCESS=manual`: salvar só o markdown local |
+| Estrutura da Issue (salvar no `$TASK_MANAGER`) | CLI do vendor (`gh`/`glab issue create`, `acli jira workitem create`) | Se o usuário pedir para salvar no `$TASK_MANAGER` e `TASK_MANAGER`, `TASK_MANAGER_ACCESS` e `TASK_MANAGER_URL_BASE` estiverem no ENV.md, com a CLI logada, só com o Sim da pergunta (regra de ouro; a pergunta só existe quando o envio vai sair); freelance, CLI indisponível ou `TASK_MANAGER_ACCESS=manual`: salvar só o markdown local |
 
 ## Resultado Final
 - Siga a estrutura exata do template `$PROD_TEMPLATES/prod-issue-template.md`
@@ -55,8 +55,8 @@ Um grupo de histórias de um mesmo assunto podem formar um épico.
 - O idioma do arquivo deve corresponder ao idioma de interação do usuário
 - Se o usuário não tiver um título claro, crie um título baseado no conteúdo do arquivo e no contexto do épico
 - Uma História ou Task pode ou não ter subtasks. Sugira as subtasks que são as menores partes da issue para guiar o PM ou o Dev na criação dessas histórias ou tasks.
-- Se o usuário pedir para salvar no `$TASK_MANAGER`, leia `TASK_MANAGER`, `TASK_MANAGER_ACCESS` e `TASK_MANAGER_URL_BASE` no ENV.md e abra o card pela CLI oficial do vendor, com o login dela (github: `gh issue create`; gitlab: `glab issue create`; jira: `acli jira workitem create`, conferindo os flags no `--help`), seguindo a cadeia de `rules/engineering/eng.integrations-rules.md`. Nunca peça token.
-  - Se `TASK_MANAGER` estiver vazio (freelance), a CLI não estiver disponível ou `TASK_MANAGER_ACCESS=manual`, **não invente board** — salve só o markdown local e diga onde ele está.
+- Se o usuário pedir para salvar no `$TASK_MANAGER` e o envio vai sair (leia `TASK_MANAGER`, `TASK_MANAGER_ACCESS` e `TASK_MANAGER_URL_BASE` no ENV.md: board preenchido, CLI do vendor logada e `TASK_MANAGER_ACCESS=cli` ou vazio), mostre o título e o corpo, pergunte com `AskUserQuestion` (regra de ouro, `eng.integrations-rules.md`) e, só com o Sim, abra o card pela CLI oficial do vendor, com o login dela (github: `gh issue create`; gitlab: `glab issue create`; jira: `acli jira workitem create`, conferindo os flags no `--help`), seguindo a cadeia de `rules/engineering/eng.integrations-rules.md`. Nunca peça token.
+  - Se `TASK_MANAGER` estiver vazio (freelance), a CLI não estiver disponível ou `TASK_MANAGER_ACCESS=manual`, **não invente board**; não há envio e, portanto, nenhuma pergunta: salve só o markdown local e diga onde ele está.
 
 ## Estrutura da Issue
 

package/workflows/product/prod.spec.prd.md

@@ -37,7 +37,7 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 | Passo | Skill | Condição |
 |-------|-------|----------|
-| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md (iteração de PRD existente) |
+| Busca no Central Docs (condicional) | `/jarvis-docs-central` (via `jarvis docs sync --silent`) | Se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md (PRD novo ou iteração; o PRD existente vem de `$PROD_DOCS`) |
 
 ## Princípios Fundamentais
 1. **Sempre use o template** `$PROD_TEMPLATES/prod-prd-template.md` para o output final
@@ -46,9 +46,9 @@ Utilize o `$ARGUMENTS` que o usuário passar como ponto de partida e para entend
 
 ---
 
-## Busca no Central Docs (condicional)
+## Busca de contexto (`$PROD_DOCS` sempre; Central docs se configurado)
 
-Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
+A busca em `$PROD_DOCS` é sempre feita. A consulta ao Central docs (o que já foi implementado) só acontece se `CENTRAL_DOCS_STORAGE` estiver definido no ENV.md; vazio, pule só o `jarvis docs sync`.
 
 1. **Para iteração de PRD existente:**
    - Consultar no Central docs as funcionalidades já implementadas relacionadas (o que existe hoje):
@@ -68,7 +68,7 @@ Se `CENTRAL_DOCS_STORAGE` definido no ENV.md:
      - Continuar com fluxo normal
 
 2. **Para PRD novo:**
-   - Pular busca no central-docs
+   - Pular a busca de PRD existente (a consulta ao Central docs, se configurado, continua)
    - Continuar com criação normal
 
 ## Fluxo de Trabalho
@@ -165,7 +165,7 @@ Quais métricas? A) Engajamento B) Receita C) Outro
 ## Instruções
 
 - Se o usuário forneceu ou está atuando em um projeto existente, priorize obter informações sobre o projeto a partir de:
-  - **Central-docs** (se configurado) - busca automática de PRDs existentes
+  - **Central-docs** (se configurado) - funcionalidades já implementadas; os PRDs existentes vêm de `$PROD_DOCS`
   - Documentação existente (README, docs/, PRDs, FRDs, ARDs, etc.)
   - Commits recentes para entender o que está sendo desenvolvido
   - Arquivos de AI como CLAUDE.md e AGENTS.md para obter informações estruturadas sobre o contexto do projeto/produto.

package/bin/commands/qa-signoff.js

@@ -1,115 +0,0 @@
-import { existsSync, readdirSync, readFileSync } from "node:fs";
-import { join } from "node:path";
-import { loadEnv, resolveEnvPath } from "../lib/env-loader.js";
-import { extractFrontmatterBlock } from "../lib/utils/frontmatter.js";
-import { GREEN, RED, YELLOW, DIM, NC } from "../lib/utils/ui.js";
-import { logger } from "../lib/utils/logger.js";
-
-/**
- * Verifica se existe um sign-off QA válido para a branch atual (ou informada).
- * Retorna 0 (válido) ou 1 (inválido/ausente) — usado pelo CI.
- *
- * @param {Object} flags
- * @param {string} flags.branch     - Branch a verificar (padrão: lido do git)
- * @param {string} flags['max-age'] - Validade máxima em horas (padrão: 24)
- */
-export async function qaSignoff(flags = {}) {
-  const cwd = process.cwd();
-  const maxAgeHours = parseInt(flags["max-age"] ?? "24", 10);
-
-  // Resolver branch
-  let branch = flags.branch;
-  if (!branch) {
-    try {
-      const { execSync } = await import("node:child_process");
-      branch = execSync("git branch --show-current", { cwd, encoding: "utf-8" }).trim();
-    } catch {
-      logger.error(`${RED}❌ Não foi possível detectar a branch atual.${NC}`);
-      logger.info(`${YELLOW}Passe a branch via --branch <nome>${NC}`);
-      process.exit(1);
-    }
-  }
-
-  if (!branch) {
-    logger.error(`${RED}❌ Branch não identificada.${NC}`);
-    process.exit(1);
-  }
-
-  // Carregar ENV.md para descobrir DOCS_FOLDER
-  let docsFolder = "docs";
-  try {
-    const resolved = resolveEnvPath(cwd, flags);
-    const env = loadEnv(cwd, resolved.path);
-    if (env.DOCS_FOLDER) docsFolder = env.DOCS_FOLDER;
-  } catch {
-    // Se não encontrar ENV.md, usa default
-  }
-
-  const signoffsDir = join(cwd, docsFolder, "engineering", "qa", "signoffs");
-
-  if (!existsSync(signoffsDir)) {
-    logger.error(`${RED}❌ Nenhum sign-off QA encontrado para a branch: ${branch}${NC}`);
-    logger.info(`${YELLOW}Execute o workflow qa.release-signoff antes do deploy.${NC}`);
-    process.exit(1);
-  }
-
-  // Normalizar slug da branch para busca nos nomes de arquivo
-  const branchSlug = branch.replace(/\//g, "-").replace(/[^a-zA-Z0-9-_]/g, "-");
-
-  // Buscar arquivos de sign-off que correspondam à branch
-  const files = readdirSync(signoffsDir)
-    .filter((f) => f.endsWith(".md") && f.includes(branchSlug))
-    .sort()
-    .reverse(); // mais recente primeiro
-
-  if (files.length === 0) {
-    logger.error(`${RED}❌ Nenhum sign-off QA encontrado para a branch: ${branch}${NC}`);
-    logger.info(`${YELLOW}Execute o workflow qa.release-signoff antes do deploy.${NC}`);
-    process.exit(1);
-  }
-
-  // Ler o sign-off mais recente
-  const latestFile = files[0];
-  const filePath = join(signoffsDir, latestFile);
-  const content = readFileSync(filePath, "utf-8");
-
-  // Extrair frontmatter
-  const frontmatter = extractFrontmatterBlock(content);
-  if (frontmatter === null) {
-    logger.error(`${RED}❌ Sign-off inválido: frontmatter ausente em ${latestFile}${NC}`);
-    process.exit(1);
-  }
-  const statusMatch = frontmatter.match(/^status:\s*(.+)$/m);
-  const dateMatch = frontmatter.match(/^date:\s*(.+)$/m);
-
-  const status = statusMatch?.[1]?.trim().replace(/['"]/g, "") ?? "";
-  const dateStr = dateMatch?.[1]?.trim().replace(/['"]/g, "") ?? "";
-
-  // Verificar status
-  if (status.toUpperCase() !== "GO") {
-    logger.error(`${RED}❌ Sign-off com status ${status} — deploy bloqueado.${NC}`);
-    logger.info(`${DIM}Arquivo: ${latestFile}${NC}`);
-    process.exit(1);
-  }
-
-  // Verificar validade (max-age)
-  if (dateStr) {
-    const signoffDate = new Date(dateStr);
-    const now = new Date();
-    const ageHours = (now - signoffDate) / (1000 * 60 * 60);
-
-    if (ageHours > maxAgeHours) {
-      logger.error(
-        `${RED}❌ Sign-off expirado: criado há ${Math.round(ageHours)}h (máximo: ${maxAgeHours}h).${NC}`
-      );
-      logger.info(`${YELLOW}Execute qa.release-signoff novamente antes do deploy.${NC}`);
-      process.exit(1);
-    }
-  }
-
-  logger.info(`${GREEN}✅ Sign-off QA válido para branch: ${branch}${NC}`);
-  logger.info(
-    `${DIM}Arquivo: ${latestFile} | Status: GO | Válido por mais ${Math.round(maxAgeHours - (new Date() - new Date(dateStr)) / (1000 * 60 * 60))}h${NC}`
-  );
-  process.exit(0);
-}