@dynamicworks/br-openspec 2.0.0 → 2.1.0

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.

package/schemas/spec-driven/templates/design.md

@@ -1,19 +1,19 @@
 ## Context
 
-<!-- Background and current state -->
+<!-- Contexto e estado atual -->
 
 ## Goals / Non-Goals
 
 **Goals:**
-<!-- What this design aims to achieve -->
+<!-- O que este design pretende alcançar -->
 
 **Non-Goals:**
-<!-- What is explicitly out of scope -->
+<!-- O que está explicitamente fora de escopo -->
 
 ## Decisions
 
-<!-- Key design decisions and rationale -->
+<!-- Principais decisões de design e suas justificativas -->
 
 ## Risks / Trade-offs
 
-<!-- Known risks and trade-offs -->
+<!-- Riscos e trade-offs conhecidos -->

package/schemas/spec-driven/templates/proposal.md

@@ -1,23 +1,23 @@
 ## Why
 
-<!-- Explain the motivation for this change. What problem does this solve? Why now? -->
+<!-- Explique a motivação desta mudança. Qual problema ela resolve? Por que agora? -->
 
 ## What Changes
 
-<!-- Describe what will change. Be specific about new capabilities, modifications, or removals. -->
+<!-- Descreva o que vai mudar. Seja específico sobre novas capacidades, modificações ou remoções. -->
 
 ## Capabilities
 
 ### New Capabilities
-<!-- Capabilities being introduced. Replace <name> with kebab-case identifier (e.g., user-auth, data-export, api-rate-limiting). Each creates specs/<name>/spec.md -->
-- `<name>`: <brief description of what this capability covers>
+<!-- Capacidades sendo introduzidas. Substitua <name> por um identificador kebab-case (ex.: user-auth, data-export, api-rate-limiting). Cada uma cria specs/<name>/spec.md -->
+- `<name>`: <descrição breve do que esta capacidade abrange>
 
 ### Modified Capabilities
-<!-- Existing capabilities whose REQUIREMENTS are changing (not just implementation).
-     Only list here if spec-level behavior changes. Each needs a delta spec file.
-     Use existing spec names from openspec/specs/. Leave empty if no requirement changes. -->
-- `<existing-name>`: <what requirement is changing>
+<!-- Capacidades existentes cujos REQUIREMENTS estão mudando (não apenas a implementação).
+     Liste aqui somente se o comportamento em nível de spec mudar. Cada uma precisa de um arquivo de spec delta.
+     Use nomes de spec existentes de openspec/specs/. Deixe vazio se nenhum requisito mudar. -->
+- `<existing-name>`: <qual requisito está mudando>
 
 ## Impact
 
-<!-- Affected code, APIs, dependencies, systems -->
+<!-- Código, APIs, dependências e sistemas afetados -->

package/schemas/spec-driven/templates/spec.md

@@ -1,8 +1,8 @@
 ## ADDED Requirements
 
-### Requirement: <!-- requirement name -->
-<!-- requirement text -->
+### Requirement: <!-- nome do requisito -->
+<!-- texto do requisito -->
 
-#### Scenario: <!-- scenario name -->
-- **WHEN** <!-- condition -->
-- **THEN** <!-- expected outcome -->
+#### Scenario: <!-- nome do cenário -->
+- **WHEN** <!-- condição -->
+- **THEN** <!-- resultado esperado -->

package/schemas/spec-driven/templates/tasks.md

@@ -1,9 +1,9 @@
-## 1. <!-- Task Group Name -->
+## 1. <!-- Nome do Grupo de Tarefas -->
 
-- [ ] 1.1 <!-- Task description -->
-- [ ] 1.2 <!-- Task description -->
+- [ ] 1.1 <!-- Descrição da tarefa -->
+- [ ] 1.2 <!-- Descrição da tarefa -->
 
-## 2. <!-- Task Group Name -->
+## 2. <!-- Nome do Grupo de Tarefas -->
 
-- [ ] 2.1 <!-- Task description -->
-- [ ] 2.2 <!-- Task description -->
+- [ ] 2.1 <!-- Descrição da tarefa -->
+- [ ] 2.2 <!-- Descrição da tarefa -->

package/dist/core/templates/workflows/upstream-sync.d.ts

@@ -1,10 +0,0 @@
-/**
- * Upstream Sync Workflow Template
- *
- * Guides the process of syncing the BR-OpenSpec fork with the upstream
- * OpenSpec repository, translating new content to Brazilian Portuguese.
- */
-import type { SkillTemplate, CommandTemplate } from '../types.js';
-export declare function getUpstreamSyncSkillTemplate(): SkillTemplate;
-export declare function getOpsxUpstreamSyncCommandTemplate(): CommandTemplate;
-//# sourceMappingURL=upstream-sync.d.ts.map

package/dist/core/templates/workflows/upstream-sync.js

@@ -1,116 +0,0 @@
-/**
- * Upstream Sync Workflow Template
- *
- * Guides the process of syncing the BR-OpenSpec fork with the upstream
- * OpenSpec repository, translating new content to Brazilian Portuguese.
- */
-export function getUpstreamSyncSkillTemplate() {
-    return {
-        name: 'openspec-upstream-sync',
-        description: 'Sincroniza o BR-OpenSpec com o upstream, traduz novas mensagens e atualiza a documentação em português brasileiro. Use quando houver atualizações no repositório original que precisem ser incorporadas ao fork.',
-        instructions: `Sincronize o BR-OpenSpec com o repositório upstream e traduza o conteúdo novo para português brasileiro.
-
-**Entrada**: O usuário indica que há atualizações no upstream ou pede para sincronizar.
-
-**Pré-requisitos**
-- O remote upstream deve estar configurado: 
-  \`git remote add upstream https://github.com/<upstream-owner>/<upstream-repo>.git\` (se ainda não estiver)
-
-**Passos**
-
-1. **Verifique o estado atual**
-   \`\`\`bash
-   git fetch upstream
-   git log --oneline HEAD..upstream/main --no-merges | head -20
-   \`\`\`
-   Isso mostra os commits que serão incorporados.
-
-2. **Crie uma branch para o sync**
-   \`\`\`bash
-   git checkout -b sync/upstream-$(date +%Y%m%d)
-   \`\`\`
-
-3. **Faça o merge do upstream**
-   \`\`\`bash
-   git merge upstream/main --no-edit
-   \`\`\`
-   - Se houver conflitos em \`src/messages/index.ts\`, resolva mantendo as mensagens em português brasileiro e incorporando as novas chaves em inglês.
-   - Para outros arquivos, resolva normalmente preservando as adaptações do BR-OpenSpec.
-
-4. **Identifique novas strings de usuário**
-   Após o merge, encontre strings hardcoded em inglês que ainda não estão no catálogo:
-   \`\`\`bash
-   git diff upstream/main..HEAD --name-only | grep "^src/"
-   \`\`\`
-   Busque por novas ocorrências de \`console.log\`, \`console.error\`, \`console.warn\`, \`.description(\`, \`message:\` em arquivos modificados.
-
-5. **Atualize o catálogo de mensagens**
-   - Adicione novas chaves em \`src/messages/index.ts\` na seção apropriada
-   - Traduza os valores para português brasileiro
-   - Mantenha a organização por domínio (CLI_DESCRIPTIONS, CLI_MESSAGES, CHANGE_MESSAGES, etc.)
-   - Se uma seção nova for necessária, crie-a com o padrão existente
-
-6. **Substitua strings hardcoded nos arquivos fonte**
-   - Substitua cada string em inglês recém-adicionada pela referência ao catálogo
-   - Adicione o import necessário de \`../messages/index.js\` (ou caminho relativo apropriado)
-   - NÃO traduza: nomes de variáveis, comentários de código, identificadores técnicos, nomes de comandos CLI
-
-7. **Atualize menções ao nome do projeto**
-   - Novos textos podem referenciar "OpenSpec" em vez de "BR-OpenSpec"
-   - Substitua referências ao nome do projeto em mensagens de usuário: \`s/\\bOpenSpec\\b/BR-OpenSpec/g\`
-   - NÃO altere: \`openspec\` (comando), \`openspec-\` (prefixos), \`OPENSPEC_\` (constantes), URLs
-
-8. **Sincronize a documentação traduzida**
-   Compare os arquivos de documentação em inglês com seus correspondentes em pt-BR:
-   - \`README.md\` ↔ \`README.pt-BR.md\`
-   - \`docs/*.md\` ↔ \`docs/pt-BR/*.md\`
-   
-   Para cada arquivo modificado pelo upstream:
-   - Aplique as mesmas mudanças estruturais nos correspondentes pt-BR
-   - Traduza novos trechos adicionados pelo upstream
-   - **PRESERVE adições pontuais do fork** (ex: justificativa da criação do fork, referências específicas ao BR-OpenSpec, links para recursos em pt-BR)
-   - Substitua "OpenSpec" por "BR-OpenSpec" quando o texto se referir ao projeto que o usuário está usando
-   - Mantenha nomes técnicos inalterados: \`openspec\`, \`.openspec.yaml\`, \`openspec/\`, skills \`openspec-*\`
-
-9. **Atualize os testes**
-   - Rode \`pnpm test\` para identificar testes que quebraram devido às traduções
-   - Atualize as expectativas de strings de \`test/\` para refletir as mensagens em português
-   - NÃO altere a lógica dos testes — apenas as strings de comparação
-
-10. **Valide o build**
-    \`\`\`bash
-    pnpm run build
-    pnpm exec tsc --noEmit
-    pnpm lint
-    \`\`\`
-
-11. **Resumo do sync**
-    Informe ao usuário:
-    - Quais commits foram incorporados
-    - Quais arquivos foram modificados
-    - Quantas novas mensagens foram traduzidas
-    - Quais arquivos de documentação foram sincronizados
-    - Se há testes ainda falhando (e por quê)
-
-**IMPORTANTE**: NUNCA traduza código técnico (nomes de variáveis, funções, constantes) ou comentários de documentação de API. Apenas mensagens exibidas ao usuário final.
-`,
-    };
-}
-export function getOpsxUpstreamSyncCommandTemplate() {
-    return {
-        name: 'upstream-sync',
-        description: 'Sincroniza com upstream e traduz novidades',
-        category: 'maintenance',
-        tags: ['sync', 'upstream', 'i18n'],
-        content: `Sincronize o BR-OpenSpec com o upstream.
-
-1. Verifique atualizações: \`git fetch upstream && git log --oneline HEAD..upstream/main | head -10\`
-2. Se houver commits, crie branch e faça merge
-3. Identifique e traduza novas strings de usuário
-4. Atualize o catálogo em \`src/messages/index.ts\`
-5. Sincronize a documentação em pt-BR preservando adições do fork
-6. Valide: \`pnpm run build && pnpm test\`
-7. Resuma as mudanças para o usuário`,
-    };
-}
-//# sourceMappingURL=upstream-sync.js.map