@dynamicworks/br-openspec 2.0.1 → 2.1.0

package/dist/core/update.js

@@ -24,6 +24,7 @@ import { WORKFLOW_TO_SKILL_DIR, getCommandConfiguredTools, getConfiguredToolsFor
 import { scanInstalledWorkflows as scanInstalledWorkflowsShared, migrateIfNeeded as migrateIfNeededShared, } from './migration.js';
 const require = createRequire(import.meta.url);
 const { version: OPENSPEC_VERSION } = require('../../package.json');
+const OLD_CORE_WORKFLOWS = ['propose', 'explore', 'apply', 'archive'];
 /**
  * Scans installed workflow artifacts (skills and managed commands) across all configured tools.
  * Returns the union of detected workflow IDs that match ALL_WORKFLOWS.
@@ -96,6 +97,7 @@ export class UpdateCommand {
             // Still check for new tool directories and extra workflows
             this.detectNewTools(resolvedProjectPath, configuredTools);
             this.displayExtraWorkflowsNote(resolvedProjectPath, configuredTools, desiredWorkflows);
+            this.displayOldCoreCustomProfileNote(profile, globalConfig.workflows);
             return;
         }
         // 8. Display update plan
@@ -202,6 +204,7 @@ export class UpdateCommand {
         this.detectNewTools(resolvedProjectPath, configuredAndNewTools);
         // 14. Display note about extra workflows not in profile
         this.displayExtraWorkflowsNote(resolvedProjectPath, configuredAndNewTools, desiredWorkflows);
+        this.displayOldCoreCustomProfileNote(profile, globalConfig.workflows);
         // 15. List affected tools
         if (updatedTools.length > 0) {
             const toolDisplayNames = updatedTools;
@@ -265,6 +268,24 @@ export class UpdateCommand {
             console.log(chalk.dim(UPDATE_MESSAGES.extraWorkflowsNote(extraWorkflows.length)));
         }
     }
+    /**
+     * Sugere voltar ao perfil core quando um perfil personalizado ainda
+     * corresponde ao conjunto core antigo (anterior ao sync). Mantém os perfis
+     * personalizados sob controle do usuário; não os altera.
+     */
+    displayOldCoreCustomProfileNote(profile, workflows) {
+        if (profile !== 'custom' || !workflows) {
+            return;
+        }
+        const workflowSet = new Set(workflows);
+        const matchesOldCore = workflowSet.size === OLD_CORE_WORKFLOWS.length &&
+            OLD_CORE_WORKFLOWS.every((workflow) => workflowSet.has(workflow));
+        if (!matchesOldCore) {
+            return;
+        }
+        console.log(chalk.dim(UPDATE_MESSAGES.oldCoreProfileSyncNote));
+        console.log(chalk.dim(UPDATE_MESSAGES.oldCoreProfileSyncHint));
+    }
     /**
      * Removes skill directories for workflows when delivery changed to commands-only.
      * Returns the number of directories removed.

package/dist/core/validation/validator.js

@@ -151,7 +151,7 @@ export class Validator {
                         issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingRequirementTextAdded(block.name) });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingShallOrMustAdded(block.name) });
+                        issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingShallOrMustAdded(block.name, this.containsShallOrMust(block.name)) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {
@@ -173,7 +173,7 @@ export class Validator {
                         issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingRequirementTextModified(block.name) });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingShallOrMustModified(block.name) });
+                        issues.push({ level: 'ERROR', path: entryPath, message: VALIDATOR_MESSAGES.missingShallOrMustModified(block.name, this.containsShallOrMust(block.name)) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {

package/dist/messages/index.d.ts

@@ -3,6 +3,28 @@
  *
  * Este módulo reúne todas as mensagens exibidas ao usuário para facilitar
  * manutenção, revisão e consistência linguística.
+ *
+ * ─────────────────────────────────────────────────────────────────────────
+ * ⚠️ TERMOS RESERVADOS — NÃO TRADUZIR
+ * ─────────────────────────────────────────────────────────────────────────
+ * O BR-OpenSpec é PT-BR first, mas o FORMATO de spec é um protocolo lido pelo
+ * parser e pelo validador. Os marcadores estruturais e as palavras-chave
+ * normativas DEVEM permanecer em inglês e em CAIXA ALTA. Só o conteúdo
+ * descritivo (nomes, descrições, prosa) é escrito em português.
+ *
+ * - Palavras-chave normativas (RFC 2119): MUST, MUST NOT, REQUIRED, SHALL,
+ *   SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL.
+ * - Cabeçalhos de delta/spec: "## ADDED Requirements", "## MODIFIED Requirements",
+ *   "## REMOVED Requirements", "## RENAMED Requirements", "## Requirements",
+ *   "### Requirement:", "#### Scenario:".
+ * - Cláusulas de cenário (Gherkin): WHEN, THEN, AND, GIVEN, ELSE.
+ * - Auxiliares de RENAMED: FROM, TO.
+ *
+ * Regra geral: qualquer palavra em CAIXA ALTA que represente uma regra, uma
+ * operação de delta (ADD/REMOVE/RENAME) ou uma cláusula de cenário fica em
+ * inglês. Traduzir esses termos quebra o parsing/validação dos specs.
+ * Ver também AGENTS.md ("Termos reservados em inglês").
+ * ─────────────────────────────────────────────────────────────────────────
  */
 export declare const CLI_DESCRIPTIONS: {
     root: string;
@@ -458,6 +480,8 @@ export declare const CONFIG_MESSAGES: {
     workflowBulkArchiveDesc: string;
     workflowVerifyName: string;
     workflowVerifyDesc: string;
+    workflowCodeReviewName: string;
+    workflowCodeReviewDesc: string;
     workflowOnboardName: string;
     workflowOnboardDesc: string;
 };
@@ -719,6 +743,8 @@ export declare const UPDATE_MESSAGES: {
     it: string;
     them: string;
     extraWorkflowsNote: (count: number) => string;
+    oldCoreProfileSyncNote: string;
+    oldCoreProfileSyncHint: string;
     cleaningLegacy: string;
     legacyCleaned: string;
     forceLegacyHint: string;
@@ -752,11 +778,11 @@ export declare const VALIDATOR_MESSAGES: {
     unknownError: string;
     duplicateRequirementAdded: (name: string) => string;
     missingRequirementTextAdded: (name: string) => string;
-    missingShallOrMustAdded: (name: string) => string;
+    missingShallOrMustAdded: (name: string, keywordInHeader?: boolean) => string;
     missingScenarioAdded: (name: string) => string;
     duplicateRequirementModified: (name: string) => string;
     missingRequirementTextModified: (name: string) => string;
-    missingShallOrMustModified: (name: string) => string;
+    missingShallOrMustModified: (name: string, keywordInHeader?: boolean) => string;
     missingScenarioModified: (name: string) => string;
     duplicateRequirementRemoved: (name: string) => string;
     duplicateFromRenamed: (name: string) => string;
@@ -890,6 +916,12 @@ export declare const VERIFY_CHANGE_TEMPLATE_MESSAGES: {
     skillInstructions: string;
     opsxContent: string;
 };
+export declare const CODE_REVIEW_TEMPLATE_MESSAGES: {
+    skillDescription: string;
+    skillCompatibility: string;
+    opsxDescription: string;
+    instructions: string;
+};
 export declare const TELEMETRY_MESSAGES: {
     firstRunNotice: string;
 };

package/dist/messages/index.js

@@ -3,6 +3,28 @@
  *
  * Este módulo reúne todas as mensagens exibidas ao usuário para facilitar
  * manutenção, revisão e consistência linguística.
+ *
+ * ─────────────────────────────────────────────────────────────────────────
+ * ⚠️ TERMOS RESERVADOS — NÃO TRADUZIR
+ * ─────────────────────────────────────────────────────────────────────────
+ * O BR-OpenSpec é PT-BR first, mas o FORMATO de spec é um protocolo lido pelo
+ * parser e pelo validador. Os marcadores estruturais e as palavras-chave
+ * normativas DEVEM permanecer em inglês e em CAIXA ALTA. Só o conteúdo
+ * descritivo (nomes, descrições, prosa) é escrito em português.
+ *
+ * - Palavras-chave normativas (RFC 2119): MUST, MUST NOT, REQUIRED, SHALL,
+ *   SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL.
+ * - Cabeçalhos de delta/spec: "## ADDED Requirements", "## MODIFIED Requirements",
+ *   "## REMOVED Requirements", "## RENAMED Requirements", "## Requirements",
+ *   "### Requirement:", "#### Scenario:".
+ * - Cláusulas de cenário (Gherkin): WHEN, THEN, AND, GIVEN, ELSE.
+ * - Auxiliares de RENAMED: FROM, TO.
+ *
+ * Regra geral: qualquer palavra em CAIXA ALTA que represente uma regra, uma
+ * operação de delta (ADD/REMOVE/RENAME) ou uma cláusula de cenário fica em
+ * inglês. Traduzir esses termos quebra o parsing/validação dos specs.
+ * Ver também AGENTS.md ("Termos reservados em inglês").
+ * ─────────────────────────────────────────────────────────────────────────
  */
 // ═══════════════════════════════════════════════════════════
 // CLI — Descrições de comandos (src/cli/index.ts)
@@ -514,6 +536,8 @@ export const CONFIG_MESSAGES = {
     workflowBulkArchiveDesc: 'Arquiva múltiplas alterações concluídas juntas',
     workflowVerifyName: 'Verificar alteração',
     workflowVerifyDesc: 'Executa verificações contra uma alteração',
+    workflowCodeReviewName: 'Code review',
+    workflowCodeReviewDesc: 'Revisa diffs, branches ou arquivos com contexto do projeto',
     workflowOnboardName: 'Onboarding',
     workflowOnboardDesc: 'Fluxo de onboarding guiado para o BR-OpenSpec',
 };
@@ -799,6 +823,8 @@ export const UPDATE_MESSAGES = {
     it: 'ela',
     them: 'elas',
     extraWorkflowsNote: (count) => `Nota: ${count} fluxos de trabalho extras não estão no perfil (use \`openspec config profile\` para gerenciar)`,
+    oldCoreProfileSyncNote: 'Nota: o perfil core agora inclui o fluxo de trabalho sync. Seu perfil personalizado está mantendo o conjunto antigo de fluxos de trabalho do core.',
+    oldCoreProfileSyncHint: 'Execute `openspec config profile core` e depois `openspec update` para adicionar o sync.',
     cleaningLegacy: 'Limpando arquivos legados...',
     legacyCleaned: 'Arquivos legados limpos',
     forceLegacyHint: '⚠ Execute com --force para limpar automaticamente arquivos legados, ou execute de forma interativa.',
@@ -841,11 +867,21 @@ export const VALIDATOR_MESSAGES = {
     unknownError: 'Erro desconhecido',
     duplicateRequirementAdded: (name) => `Requisito duplicado em ADDED: "${name}"`,
     missingRequirementTextAdded: (name) => `ADDED "${name}" está sem texto de requisito`,
-    missingShallOrMustAdded: (name) => `ADDED "${name}" deve conter SHALL ou MUST`,
+    missingShallOrMustAdded: (name, keywordInHeader = false) => {
+        const base = `ADDED "${name}" deve conter SHALL ou MUST`;
+        return keywordInHeader
+            ? `${base} no corpo do requisito, não apenas no cabeçalho. Mova a declaração SHALL/MUST para a linha imediatamente após o cabeçalho "### Requirement: ...".`
+            : base;
+    },
     missingScenarioAdded: (name) => `ADDED "${name}" deve incluir pelo menos um cenário`,
     duplicateRequirementModified: (name) => `Requisito duplicado em MODIFIED: "${name}"`,
     missingRequirementTextModified: (name) => `MODIFIED "${name}" está sem texto de requisito`,
-    missingShallOrMustModified: (name) => `MODIFIED "${name}" deve conter SHALL ou MUST`,
+    missingShallOrMustModified: (name, keywordInHeader = false) => {
+        const base = `MODIFIED "${name}" deve conter SHALL ou MUST`;
+        return keywordInHeader
+            ? `${base} no corpo do requisito, não apenas no cabeçalho. Mova a declaração SHALL/MUST para a linha imediatamente após o cabeçalho "### Requirement: ...".`
+            : base;
+    },
     missingScenarioModified: (name) => `MODIFIED "${name}" deve incluir pelo menos um cenário`,
     duplicateRequirementRemoved: (name) => `Requisito duplicado em REMOVED: "${name}"`,
     duplicateFromRenamed: (name) => `FROM duplicado em RENAMED: "${name}"`,
@@ -1321,11 +1357,11 @@ Aqui está um rascunho de proposal:
 
 ---
 
-## Por Que
+## Why
 
 [1-2 frases explicando o problema/oportunidade]
 
-## O Que Muda
+## What Changes
 
 [Bullet points do que será diferente]
 
@@ -1389,21 +1425,21 @@ Aqui está o spec:
 
 ---
 
-## Requisitos ADICIONADOS
+## ADDED Requirements
 
-### Requisito: <Nome>
+### Requirement: <Nome>
 
-<Descrição do que o sistema deve fazer>
+O sistema SHALL <descrição do que o sistema deve fazer>
 
-#### Cenário: <Nome do cenário>
+#### Scenario: <Nome do cenário>
 
-- **QUANDO** <condição de gatilho>
-- **ENTÃO** <resultado esperado>
-- **E** <resultado adicional se necessário>
+- **WHEN** <condição de gatilho>
+- **THEN** <resultado esperado>
+- **AND** <resultado adicional se necessário>
 
 ---
 
-Este formato - QUANDO/ENTÃO/E - torna os requisitos testáveis. Você pode literalmente lê-los como casos de teste.
+Este formato - WHEN/THEN/AND - torna os requisitos testáveis. Você pode literalmente lê-los como casos de teste. Os marcadores estruturais (ADDED Requirements, Requirement, Scenario) e as palavras-chave (WHEN/THEN/AND, SHALL/MUST) ficam SEMPRE em inglês — é o protocolo que o parser e o validador reconhecem. Apenas o conteúdo descritivo é escrito em português.
 \`\`\`
 
 Salve em \`openspec/changes/<nome>/specs/<capability>/spec.md\`.
@@ -1984,6 +2020,140 @@ Use markdown claro com:
 - Sem sugestões vagas como "consider reviewing"`,
 };
 // ═══════════════════════════════════════════════════════════
+// Templates de Workflow — Code Review (src/core/templates/workflows/code-review.ts)
+// ═══════════════════════════════════════════════════════════
+export const CODE_REVIEW_TEMPLATE_MESSAGES = {
+    skillDescription: 'Realiza code review genérico e consciente do projeto. Use quando o usuário quiser revisar um diff, branch, PR, working tree ou conjunto de arquivos antes de mesclar ou continuar.',
+    skillCompatibility: 'Requer acesso aos arquivos do projeto. Git é recomendado para revisar diffs e branches.',
+    opsxDescription: 'Revisa diffs, branches, PRs ou arquivos usando contexto do projeto',
+    instructions: `Realize um code review rigoroso, genérico e consciente do projeto. Seu objetivo é encontrar problemas reais antes do merge — não validar superficialmente, não comentar estilo, não elogiar.
+
+**Entrada**: Opcionalmente especifique o alvo após \`/opsx:code-review\`: branch, PR, diff, working tree, staged changes, caminho de arquivo ou descrição de escopo. Se omitido, descubra o alvo com segurança.
+
+**Postura**
+
+- Você está revisando, não implementando. Não edite arquivos a menos que o usuário peça explicitamente para corrigir.
+- Aja como um revisor sênior cético: assuma que existe um bug até o código provar o contrário, e fundamente cada finding com evidência concreta no código.
+- Priorize nesta ordem: correção/regressões → segurança/privacidade → perda ou corrupção de dados → quebra de contrato/compatibilidade → concorrência → comportamento cross-platform → testes ausentes → performance → manutenibilidade.
+- Estilo e preferência pessoal só viram finding se tiverem impacto concreto (ex.: legibilidade que esconde um bug, violação de um padrão real do projeto).
+- Findings primeiro, com evidência. Resumo depois.
+- Calibre a profundidade ao tamanho do diff; em diffs grandes, revise por blocos e priorize as áreas de maior risco.
+- Sinalize incerteza explicitamente. Nunca invente número de linha, nome de símbolo ou comportamento que você não verificou.
+
+**Passos**
+
+1. **Determine o alvo da review**
+
+   Use o argumento do usuário quando existir. Caso contrário, descubra com segurança:
+   - Confirme se há Git: \`git rev-parse --is-inside-work-tree\`.
+   - Inspecione o estado local: \`git status --short\`, \`git diff\` (unstaged) e \`git diff --staged\`.
+   - Para revisar um branch contra a base: identifique a base provável (ex.: \`git merge-base HEAD origin/main\`) e use \`git diff <base>...HEAD\`.
+   - Para um PR, prefira \`gh pr diff <numero>\` quando o \`gh\` estiver disponível.
+   - Se não houver Git, peça arquivos ou escopo explícitos ao usuário.
+   - Se o alvo continuar ambíguo, pergunte ao usuário o que revisar.
+
+   Não assuma review do repositório inteiro sem confirmação. Leia o diff completo (com contexto de linha) antes de julgar.
+
+2. **Entenda a intenção antes de criticar**
+
+   Antes de procurar defeitos, articule o que a mudança tenta fazer e por quê (a partir do título do PR/branch, mensagens de commit, artifacts OpenSpec ou do próprio diff). Um bom review compara o que o código faz com o que deveria fazer; sem a intenção, você só consegue revisar sintaxe.
+
+3. **Colete contexto do projeto**
+
+   Leia apenas os arquivos relevantes, priorizando:
+   - \`README.md\`, \`README_*.md\` e docs de contribuição
+   - \`AGENTS.md\`, instruções de agentes e skills existentes do projeto
+   - \`openspec/config.yaml\` e docs de arquitetura/ADRs quando existirem
+   - specs vivas em \`openspec/specs/\` quando relacionadas ao alvo
+   - testes vizinhos ao código alterado (para entender o contrato esperado)
+   - manifests e configs de stack (\`package.json\`, lockfiles, \`tsconfig.json\`, configs de lint/test/build, CI etc.)
+
+   Aplique as instruções encontradas. Em caso de conflito, prefira a orientação mais específica do repositório.
+
+4. **Entenda a stack e os comandos de verificação**
+
+   Infira linguagem, framework, package manager e comandos úteis a partir dos arquivos locais.
+
+   Exemplos:
+   - Node/TypeScript: scripts de \`package.json\`, lockfile e \`tsconfig.json\`
+   - Python: \`pyproject.toml\`, \`requirements*.txt\`, configs de pytest/ruff/mypy
+   - Go/Rust: \`go.mod\`, \`Cargo.toml\` e scripts de CI
+
+5. **Inclua contexto OpenSpec quando existir**
+
+   Se houver uma change relacionada:
+   - Leia \`proposal.md\`, \`design.md\`, \`tasks.md\` e delta specs disponíveis.
+   - Verifique se o diff preserva a intenção dos artifacts.
+   - Não transforme esta review em \`/opsx:verify\`; use os artifacts apenas como contexto adicional para revisar o código.
+
+6. **Revise o código em profundidade**
+
+   Método para cada mudança: leia além do diff (o código ao redor, chamadores e implementações chamadas), rastreie de onde vêm os dados e para onde vão, e teste mentalmente entradas adversárias (vazio, nulo, zero, negativo, muito grande, unicode, concorrente). Não confie no nome de uma função — confirme o que ela faz.
+
+   Procure, por categoria:
+   - **Correção e lógica**: regressões, edge cases e limites (off-by-one), condições invertidas ou incompletas, \`switch\` sem \`break\`/default, retorno/await faltando, suposições falsas sobre a entrada.
+   - **Dados e estado**: mutação de estado compartilhado, ordem de operações, idempotência, transações e atomicidade, invalidação de cache, lifecycle e limpeza de recursos.
+   - **Concorrência**: race conditions, \`await\`/lock faltando, reentrância, deadlock, escrita concorrente.
+   - **Segurança e privacidade**: injeção (SQL/command/path/template), validação e sanitização de entrada não confiável, authn/authz, segredos hardcoded, dados sensíveis vazando em logs/erros, deserialização insegura, SSRF/path traversal.
+   - **Erros e resiliência**: erros engolidos, mensagens que vazam dados, ausência de rollback, retries/timeouts, recursos não liberados em caminho de erro.
+   - **Contratos e compatibilidade**: mudança em API pública, assinatura, schema ou formato persistido; migrações reversíveis; compatibilidade retroativa e versionamento.
+   - **Cross-platform**: separador de caminho, case sensitivity, line endings, shell e encoding quando filesystem/processo estiverem envolvidos.
+   - **Performance**: N+1, complexidade quadrática, I/O ou alocação dentro de loop — reporte apenas quando o impacto for plausível.
+   - **Testes**: cenários novos/quebráveis cobertos, testes negativos e de borda, testes frágeis ou que não exercitam de fato o código.
+   - **Dependências**: nova dependência justificada, versão e licença sãs, risco de supply chain.
+   - **Consistência com o projeto**: aderência a padrões, convenções e decisões reais do repositório (incluindo, quando aplicável, mensagens centralizadas/i18n em vez de texto hardcoded).
+
+7. **Valide quando for seguro**
+
+   Rode verificações focadas e proporcionais (typecheck, lint, testes do escopo afetado) quando forem seguras. Não rode comandos destrutivos, dependentes de serviços externos ou desproporcionalmente caros sem explicar/confirmar. Reporte o que rodou e o que pulou (e por quê).
+
+8. **Sugira contexto durável do projeto**
+
+   Se o projeto não tiver orientação durável suficiente para reviews (nenhum \`AGENTS.md\`, skill do projeto, docs de contribuição ou contexto em \`openspec/config.yaml\`):
+   - Sugira criar ou enriquecer uma skill/contexto do projeto para futuras reviews, indicando um local concreto (ex.: \`AGENTS.md\` ou uma skill do projeto) e os pontos que ela deveria registrar (padrões, comandos de validação, armadilhas).
+   - Explique brevemente o benefício.
+   - Peça confirmação antes de escrever qualquer arquivo.
+
+**Formato de Saída**
+
+Se houver findings, comece por eles, ordenados por severidade. Para cada finding:
+
+\`\`\`text
+Findings
+- [CRITICAL] caminho/arquivo.ext:123 — Título curto e específico
+  Evidência: o que no código causa o problema (cite o trecho/símbolo)
+  Impacto: o que quebra na prática e sob qual condição
+  Correção: ação concreta e mínima
+  Confiança: alta | média | baixa (se < alta, diga a suposição)
+\`\`\`
+
+Depois inclua, de forma breve:
+- alvo revisado
+- contexto/instruções considerados
+- validações executadas
+- validações não executadas e por quê
+- risco residual ou perguntas abertas
+
+Se não houver findings, diga claramente que nenhum problema foi encontrado e ainda informe as validações não executadas.
+
+**Regras de Severidade**
+
+- **CRITICAL**: bug provável, perda/corrupção de dados, falha de segurança, quebra de contrato, build/test claramente quebrado.
+- **WARNING**: risco real mas dependente de condição, cobertura ausente para comportamento importante, inconsistência que pode virar regressão.
+- **SUGGESTION**: melhoria útil, baixa urgência, refino de manutenção.
+
+**Guardrails**
+
+- Não altere arquivos durante uma review pura.
+- Todo finding precisa de evidência concreta; sem evidência, não reporte.
+- Não reporte o que linter/typecheck/formatter já pegam automaticamente — foque no que essas ferramentas não veem.
+- Não duplique o mesmo finding; agrupe ocorrências do mesmo problema.
+- Prefira poucos findings fortes a muitos comentários especulativos.
+- Não encha a saída com elogios genéricos.
+- Use referências no formato \`arquivo:linha\`; quando não houver linha exata, cite o menor escopo verificável.
+- Se a informação for incerta, diga o que verificou e qual suposição está fazendo — e marque a confiança.`,
+};
+// ═══════════════════════════════════════════════════════════
 // Telemetry (src/telemetry/index.ts)
 // ═══════════════════════════════════════════════════════════
 export const TELEMETRY_MESSAGES = {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dynamicworks/br-openspec",
-  "version": "2.0.1",
+  "version": "2.1.0",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",

package/schemas/spec-driven/schema.yaml

@@ -4,61 +4,61 @@ description: Fluxo de trabalho BR-OpenSpec padrão - proposta → specs → desi
 artifacts:
   - id: proposal
     generates: proposal.md
-    description: Initial proposal document outlining the change
+    description: Documento de proposta inicial que descreve a mudança
     template: proposal.md
     instruction: |
-      Create the proposal document that establishes WHY this change is needed.
+      Crie o documento de proposta que estabelece o WHY (por que) esta mudança é necessária.
 
-      Sections:
-      - **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now?
-      - **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**.
-      - **Capabilities**: Identify which specs will be created or modified:
-        - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<name>/spec.md`. Use kebab-case names (e.g., `user-auth`, `data-export`).
-        - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Check `openspec/specs/` for existing spec names. Leave empty if no requirement changes.
-      - **Impact**: Affected code, APIs, dependencies, or systems.
+      Seções:
+      - **Why**: 1-2 frases sobre o problema ou oportunidade. Qual problema isso resolve? Por que agora?
+      - **What Changes**: Lista de marcadores das mudanças. Seja específico sobre novas capabilities, modificações ou remoções. Marque mudanças incompatíveis com **BREAKING**.
+      - **Capabilities**: Identifique quais specs serão criadas ou modificadas:
+        - **New Capabilities**: Liste as capabilities sendo introduzidas. Cada uma vira um novo `specs/<name>/spec.md`. Use nomes em kebab-case (ex.: `user-auth`, `data-export`).
+        - **Modified Capabilities**: Liste as capabilities existentes cujos REQUIREMENTS estão mudando. Inclua apenas se o comportamento no nível da spec mudar (não apenas detalhes de implementação). Cada uma precisa de um arquivo de spec delta. Verifique `openspec/specs/` para os nomes de spec existentes. Deixe vazio se não houver mudança de requirement.
+      - **Impact**: Código, APIs, dependências ou sistemas afetados.
 
-      IMPORTANT: The Capabilities section is critical. It creates the contract between
-      proposal and specs phases. Research existing specs before filling this in.
-      Each capability listed here will need a corresponding spec file.
+      IMPORTANTE: A seção Capabilities é crítica. Ela cria o contrato entre
+      as fases de proposta e specs. Pesquise as specs existentes antes de preenchê-la.
+      Cada capability listada aqui precisará de um arquivo de spec correspondente.
 
-      Keep it concise (1-2 pages). Focus on the "why" not the "how" -
-      implementation details belong in design.md.
+      Mantenha conciso (1-2 páginas). Foque no "porquê", não no "como" -
+      detalhes de implementação pertencem ao design.md.
 
-      This is the foundation - specs, design, and tasks all build on this.
+      Esta é a fundação - specs, design e tarefas se baseiam nela.
     requires: []
 
   - id: specs
     generates: "specs/**/*.md"
-    description: Detailed specifications for the change
+    description: Especificações detalhadas da mudança
     template: spec.md
     instruction: |
-      Create specification files that define WHAT the system should do.
-
-      Create one spec file per capability listed in the proposal's Capabilities section.
-      - New capabilities: use the exact kebab-case name from the proposal (specs/<capability>/spec.md).
-      - Modified capabilities: use the existing spec folder name from openspec/specs/<capability>/ when creating the delta spec at specs/<capability>/spec.md.
-
-      Delta operations (use ## headers):
-      - **ADDED Requirements**: New capabilities
-      - **MODIFIED Requirements**: Changed behavior - MUST include full updated content
-      - **REMOVED Requirements**: Deprecated features - MUST include **Reason** and **Migration**
-      - **RENAMED Requirements**: Name changes only - use FROM:/TO: format
-
-      Format requirements:
-      - Each requirement: `### Requirement: <name>` followed by description
-      - Use SHALL/MUST for normative requirements (avoid should/may)
-      - Each scenario: `#### Scenario: <name>` with WHEN/THEN format
-      - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
-      - Every requirement MUST have at least one scenario.
-
-      MODIFIED requirements workflow:
-      1. Locate the existing requirement in openspec/specs/<capability>/spec.md
-      2. Copy the ENTIRE requirement block (from `### Requirement:` through all scenarios)
-      3. Paste under `## MODIFIED Requirements` and edit to reflect new behavior
-      4. Ensure header text matches exactly (whitespace-insensitive)
-
-      Common pitfall: Using MODIFIED with partial content loses detail at archive time.
-      If adding new concerns without changing existing behavior, use ADDED instead.
+      Crie arquivos de especificação que definam o WHAT (o que) o sistema deve fazer.
+
+      Crie um arquivo de spec por capability listada na seção Capabilities da proposta.
+      - Novas capabilities: use o nome exato em kebab-case da proposta (specs/<capability>/spec.md).
+      - Capabilities modificadas: use o nome da pasta de spec existente em openspec/specs/<capability>/ ao criar a spec delta em specs/<capability>/spec.md.
+
+      Operações de delta (use cabeçalhos ##):
+      - **ADDED Requirements**: Novas capabilities
+      - **MODIFIED Requirements**: Comportamento alterado - MUST incluir o conteúdo atualizado completo
+      - **REMOVED Requirements**: Recursos descontinuados - MUST incluir **Reason** e **Migration**
+      - **RENAMED Requirements**: Apenas mudanças de nome - use o formato FROM:/TO:
+
+      Requisitos de formato:
+      - Cada requirement: `### Requirement: <name>` seguido de descrição
+      - Use SHALL/MUST para requisitos normativos (evite should/may)
+      - Cada cenário: `#### Scenario: <name>` no formato WHEN/THEN
+      - **CRITICAL**: Os cenários MUST usar exatamente 4 cerquilhas (`####`). Usar 3 cerquilhas ou marcadores falha silenciosamente.
+      - Todo requirement MUST ter pelo menos um cenário.
+
+      Fluxo de trabalho de requirements MODIFIED:
+      1. Localize o requirement existente em openspec/specs/<capability>/spec.md
+      2. Copie o bloco INTEIRO do requirement (de `### Requirement:` até todos os cenários)
+      3. Cole sob `## MODIFIED Requirements` e edite para refletir o novo comportamento
+      4. Garanta que o texto do cabeçalho corresponda exatamente (ignorando espaços em branco)
+
+      Armadilha comum: Usar MODIFIED com conteúdo parcial perde detalhe no momento do arquivamento.
+      Se estiver adicionando novas preocupações sem alterar o comportamento existente, use ADDED.
 
       Example:
       ```
@@ -78,53 +78,53 @@ artifacts:
       **Migration**: Use new export endpoint at /api/v2/export
       ```
 
-      Specs should be testable - each scenario is a potential test case.
+      As specs devem ser testáveis - cada cenário é um possível caso de teste.
     requires:
       - proposal
 
   - id: design
     generates: design.md
-    description: Technical design document with implementation details
+    description: Documento de design técnico com detalhes de implementação
     template: design.md
     instruction: |
-      Create the design document that explains HOW to implement the change.
-
-      When to include design.md (create only if any apply):
-      - Cross-cutting change (multiple services/modules) or new architectural pattern
-      - New external dependency or significant data model changes
-      - Security, performance, or migration complexity
-      - Ambiguity that benefits from technical decisions before coding
-
-      Sections:
-      - **Context**: Background, current state, constraints, stakeholders
-      - **Goals / Non-Goals**: What this design achieves and explicitly excludes
-      - **Decisions**: Key technical choices with rationale (why X over Y?). Include alternatives considered for each decision.
-      - **Risks / Trade-offs**: Known limitations, things that could go wrong. Format: [Risk] → Mitigation
-      - **Migration Plan**: Steps to deploy, rollback strategy (if applicable)
-      - **Open Questions**: Outstanding decisions or unknowns to resolve
-
-      Focus on architecture and approach, not line-by-line implementation.
-      Reference the proposal for motivation and specs for requirements.
-
-      Good design docs explain the "why" behind technical decisions.
+      Crie o documento de design que explica o HOW (como) implementar a mudança.
+
+      Quando incluir design.md (crie apenas se algum se aplicar):
+      - Mudança transversal (múltiplos serviços/módulos) ou novo padrão arquitetural
+      - Nova dependência externa ou mudanças significativas no modelo de dados
+      - Complexidade de segurança, desempenho ou migração
+      - Ambiguidade que se beneficia de decisões técnicas antes de codificar
+
+      Seções:
+      - **Context**: Histórico, estado atual, restrições, partes interessadas
+      - **Goals / Non-Goals**: O que este design alcança e o que explicitamente exclui
+      - **Decisions**: Principais escolhas técnicas com justificativa (por que X em vez de Y?). Inclua as alternativas consideradas para cada decisão.
+      - **Risks / Trade-offs**: Limitações conhecidas, coisas que podem dar errado. Formato: [Risco] → Mitigação
+      - **Migration Plan**: Passos para implantar, estratégia de rollback (se aplicável)
+      - **Open Questions**: Decisões pendentes ou incógnitas a resolver
+
+      Foque na arquitetura e na abordagem, não na implementação linha a linha.
+      Referencie a proposta para a motivação e as specs para os requirements.
+
+      Bons documentos de design explicam o "porquê" por trás das decisões técnicas.
     requires:
       - proposal
 
   - id: tasks
     generates: tasks.md
-    description: Implementation checklist with trackable tasks
+    description: Checklist de implementação com tarefas rastreáveis
     template: tasks.md
     instruction: |
-      Create the task list that breaks down the implementation work.
+      Crie a lista de tarefas que detalha o trabalho de implementação.
 
-      **IMPORTANT: Follow the template below exactly.** The apply phase parses
-      checkbox format to track progress. Tasks not using `- [ ]` won't be tracked.
+      **IMPORTANTE: Siga o template abaixo exatamente.** A fase de apply faz o parse
+      do formato de checkbox para acompanhar o progresso. Tarefas que não usam `- [ ]` não serão rastreadas.
 
-      Guidelines:
-      - Group related tasks under ## numbered headings
-      - Each task MUST be a checkbox: `- [ ] X.Y Task description`
-      - Tasks should be small enough to complete in one session
-      - Order tasks by dependency (what must be done first?)
+      Diretrizes:
+      - Agrupe tarefas relacionadas sob cabeçalhos numerados ##
+      - Cada tarefa MUST ser um checkbox: `- [ ] X.Y Descrição da tarefa`
+      - As tarefas devem ser pequenas o suficiente para serem concluídas em uma sessão
+      - Ordene as tarefas por dependência (o que precisa ser feito primeiro?)
 
       Example:
       ```
@@ -139,8 +139,8 @@ artifacts:
       - [ ] 2.2 Add CSV formatting utilities
       ```
 
-      Reference specs for what needs to be built, design for how to build it.
-      Each task should be verifiable - you know when it's done.
+      Referencie as specs para o que precisa ser construído e o design para como construir.
+      Cada tarefa deve ser verificável - você sabe quando ela está concluída.
     requires:
       - specs
       - design
@@ -149,5 +149,5 @@ apply:
   requires: [tasks]
   tracks: tasks.md
   instruction: |
-    Read context files, work through pending tasks, mark complete as you go.
-    Pause if you hit blockers or need clarification.
+    Leia os arquivos de contexto, execute as tarefas pendentes e marque como concluídas conforme avança.
+    Pause se encontrar bloqueios ou precisar de esclarecimentos.