@dynamicworks/br-openspec 1.3.1

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

@@ -0,0 +1,272 @@
+export function getSyncSpecsSkillTemplate() {
+    return {
+        name: 'openspec-sync-specs',
+        description: 'Sincroniza delta specs de uma change para os specs principais. Use quando o usuário quiser atualizar os specs principais com alterações de um delta spec, sem arquivar a change.',
+        instructions: `Sincroniza delta specs de uma change para os specs principais.
+
+Esta é uma operação **dirigida por agente** — você lerá os delta specs e editará diretamente os specs principais para aplicar as alterações. Isso permite mesclagem inteligente (por exemplo, adicionar um cenário sem copiar o requisito inteiro).
+
+**Entrada**: Opcionalmente especifique um nome de change. Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
+
+**Passos**
+
+1. **Se nenhum nome de change for fornecido, solicite a seleção**
+
+   Execute \`openspec list --json\` para obter as changes disponíveis. Use a ferramenta **AskUserQuestion** para permitir que o usuário selecione.
+
+   Mostre as changes que possuem delta specs (no diretório \`specs/\`).
+
+   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
+
+2. **Encontre os delta specs**
+
+   Procure arquivos de delta spec em \`openspec/changes/<nome>/specs/*/spec.md\`.
+
+   Cada arquivo de delta spec contém seções como:
+   - \`## ADDED Requirements\` — Novos requisitos a adicionar
+   - \`## MODIFIED Requirements\` — Alterações em requisitos existentes
+   - \`## REMOVED Requirements\` — Requisitos a remover
+   - \`## RENAMED Requirements\` — Requisitos a renomear (formato FROM:/TO:)
+
+   Se nenhum delta spec for encontrado, informe o usuário e pare.
+
+3. **Para cada delta spec, aplique as alterações nos specs principais**
+
+   Para cada capability com um delta spec em \`openspec/changes/<nome>/specs/<capability>/spec.md\`:
+
+   a. **Leia o delta spec** para entender as alterações pretendidas
+
+   b. **Leia o spec principal** em \`openspec/specs/<capability>/spec.md\` (pode ainda não existir)
+
+   c. **Aplique as alterações de forma inteligente**:
+
+      **ADDED Requirements:**
+      - Se o requisito não existir no spec principal → adicione-o
+      - Se o requisito já existir → atualize-o para corresponder (trate como MODIFIED implícito)
+
+      **MODIFIED Requirements:**
+      - Encontre o requisito no spec principal
+      - Aplique as alterações — isso pode ser:
+        - Adicionar novos cenários (não é necessário copiar os existentes)
+        - Modificar cenários existentes
+        - Alterar a descrição do requisito
+      - Preserve cenários/conteúdo não mencionados no delta
+
+      **REMOVED Requirements:**
+      - Remova o bloco inteiro do requisito do spec principal
+
+      **RENAMED Requirements:**
+      - Encontre o requisito FROM, renomeie para TO
+
+   d. **Crie um novo spec principal** se a capability ainda não existir:
+      - Crie \`openspec/specs/<capability>/spec.md\`
+      - Adicione a seção Purpose (pode ser breve, marque como TBD)
+      - Adicione a seção Requirements com os requisitos ADDED
+
+4. **Exiba o resumo**
+
+   Após aplicar todas as alterações, resuma:
+   - Quais capabilities foram atualizadas
+   - Quais alterações foram feitas (requisitos adicionados/modificados/removidos/renomeados)
+
+**Referência de Formato de Delta Spec**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+O sistema DEVERÁ fazer algo novo.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**Princípio-Chave: Mesclagem Inteligente**
+
+Ao contrário da mesclagem programática, você pode aplicar **atualizações parciais**:
+- Para adicionar um cenário, basta incluí-lo sob MODIFIED — não copie os cenários existentes
+- O delta representa *intenção*, não uma substituição total
+- Use seu julgamento para mesclar as alterações de forma sensata
+
+**Saída em Sucesso**
+
+\`\`\`
+## Specs Sincronizados: <nome-change>
+
+Specs principais atualizados:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Os specs principais foram atualizados. A change permanece ativa — arquive quando a implementação estiver completa.
+\`\`\`
+
+**Guardrails**
+- Leia tanto os delta specs quanto os specs principais antes de fazer alterações
+- Preserve o conteúdo existente não mencionado no delta
+- Se algo não estiver claro, peça esclarecimento
+- Mostre o que está alterando à medida que avança
+- A operação deve ser idempotente — executar duas vezes deve dar o mesmo resultado`,
+        license: 'MIT',
+        compatibility: 'Requer openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxSyncCommandTemplate() {
+    return {
+        name: 'OPSX: Sync',
+        description: 'Sincroniza delta specs de uma change para os specs principais',
+        category: 'Workflow',
+        tags: ['workflow', 'specs', 'experimental'],
+        content: `Sincroniza delta specs de uma change para os specs principais.
+
+Esta é uma operação **dirigida por agente** — você lerá os delta specs e editará diretamente os specs principais para aplicar as alterações. Isso permite mesclagem inteligente (por exemplo, adicionar um cenário sem copiar o requisito inteiro).
+
+**Entrada**: Opcionalmente especifique um nome de change após \`/opsx:sync\` (por exemplo, \`/opsx:sync add-auth\`). Se omitido, verifique se pode ser inferido do contexto da conversa. Se vago ou ambíguo, você DEVE solicitar as changes disponíveis.
+
+**Passos**
+
+1. **Se nenhum nome de change for fornecido, solicite a seleção**
+
+   Execute \`openspec list --json\` para obter as changes disponíveis. Use a ferramenta **AskUserQuestion** para permitir que o usuário selecione.
+
+   Mostre as changes que possuem delta specs (no diretório \`specs/\`).
+
+   **IMPORTANTE**: NÃO adivinhe ou selecione automaticamente uma change. Sempre deixe o usuário escolher.
+
+2. **Encontre os delta specs**
+
+   Procure arquivos de delta spec em \`openspec/changes/<nome>/specs/*/spec.md\`.
+
+   Cada arquivo de delta spec contém seções como:
+   - \`## ADDED Requirements\` — Novos requisitos a adicionar
+   - \`## MODIFIED Requirements\` — Alterações em requisitos existentes
+   - \`## REMOVED Requirements\` — Requisitos a remover
+   - \`## RENAMED Requirements\` — Requisitos a renomear (formato FROM:/TO:)
+
+   Se nenhum delta spec for encontrado, informe o usuário e pare.
+
+3. **Para cada delta spec, aplique as alterações nos specs principais**
+
+   Para cada capability com um delta spec em \`openspec/changes/<nome>/specs/<capability>/spec.md\`:
+
+   a. **Leia o delta spec** para entender as alterações pretendidas
+
+   b. **Leia o spec principal** em \`openspec/specs/<capability>/spec.md\` (pode ainda não existir)
+
+   c. **Aplique as alterações de forma inteligente**:
+
+      **ADDED Requirements:**
+      - Se o requisito não existir no spec principal → adicione-o
+      - Se o requisito já existir → atualize-o para corresponder (trate como MODIFIED implícito)
+
+      **MODIFIED Requirements:**
+      - Encontre o requisito no spec principal
+      - Aplique as alterações — isso pode ser:
+        - Adicionar novos cenários (não é necessário copiar os existentes)
+        - Modificar cenários existentes
+        - Alterar a descrição do requisito
+      - Preserve cenários/conteúdo não mencionados no delta
+
+      **REMOVED Requirements:**
+      - Remova o bloco inteiro do requisito do spec principal
+
+      **RENAMED Requirements:**
+      - Encontre o requisito FROM, renomeie para TO
+
+   d. **Crie um novo spec principal** se a capability ainda não existir:
+      - Crie \`openspec/specs/<capability>/spec.md\`
+      - Adicione a seção Purpose (pode ser breve, marque como TBD)
+      - Adicione a seção Requirements com os requisitos ADDED
+
+4. **Exiba o resumo**
+
+   Após aplicar todas as alterações, resuma:
+   - Quais capabilities foram atualizadas
+   - Quais alterações foram feitas (requisitos adicionados/modificados/removidos/renomeados)
+
+**Referência de Formato de Delta Spec**
+
+\`\`\`markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+O sistema DEVERÁ fazer algo novo.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: \`### Requirement: Old Name\`
+- TO: \`### Requirement: New Name\`
+\`\`\`
+
+**Princípio-Chave: Mesclagem Inteligente**
+
+Ao contrário da mesclagem programática, você pode aplicar **atualizações parciais**:
+- Para adicionar um cenário, basta incluí-lo sob MODIFIED — não copie os cenários existentes
+- O delta representa *intenção*, não uma substituição total
+- Use seu julgamento para mesclar as alterações de forma sensata
+
+**Saída em Sucesso**
+
+\`\`\`
+## Specs Sincronizados: <nome-change>
+
+Specs principais atualizados:
+
+**<capability-1>**:
+- Added requirement: "New Feature"
+- Modified requirement: "Existing Feature" (added 1 scenario)
+
+**<capability-2>**:
+- Created new spec file
+- Added requirement: "Another Feature"
+
+Os specs principais foram atualizados. A change permanece ativa — arquive quando a implementação estiver completa.
+\`\`\`
+
+**Guardrails**
+- Leia tanto os delta specs quanto os specs principais antes de fazer alterações
+- Preserve o conteúdo existente não mencionado no delta
+- Se algo não estiver claro, peça esclarecimento
+- Mostre o que está alterando à medida que avança
+- A operação deve ser idempotente — executar duas vezes deve dar o mesmo resultado`
+    };
+}
+//# sourceMappingURL=sync-specs.js.map

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

@@ -0,0 +1,10 @@
+/**
+ * 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

@@ -0,0 +1,116 @@
+/**
+ * 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

package/dist/core/templates/workflows/verify-change.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getVerifyChangeSkillTemplate(): SkillTemplate;
+export declare function getOpsxVerifyCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=verify-change.d.ts.map

package/dist/core/templates/workflows/verify-change.js

@@ -0,0 +1,21 @@
+import { VERIFY_CHANGE_TEMPLATE_MESSAGES } from '../../../messages/index.js';
+export function getVerifyChangeSkillTemplate() {
+    return {
+        name: 'openspec-verify-change',
+        description: VERIFY_CHANGE_TEMPLATE_MESSAGES.skillDescription,
+        instructions: VERIFY_CHANGE_TEMPLATE_MESSAGES.skillInstructions,
+        license: 'MIT',
+        compatibility: VERIFY_CHANGE_TEMPLATE_MESSAGES.skillCompatibility,
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxVerifyCommandTemplate() {
+    return {
+        name: 'OPSX: Verify',
+        description: VERIFY_CHANGE_TEMPLATE_MESSAGES.opsxDescription,
+        category: 'Workflow',
+        tags: ['workflow', 'verify', 'experimental'],
+        content: VERIFY_CHANGE_TEMPLATE_MESSAGES.opsxContent,
+    };
+}
+//# sourceMappingURL=verify-change.js.map

package/dist/core/tools-manager.d.ts

@@ -0,0 +1,56 @@
+/**
+ * Tools Manager
+ *
+ * Encapsulates adding and removing IDE/Code Agent OpenSpec configuration files.
+ * Shared by `openspec init` (via InitCommand) and `openspec tools`.
+ */
+import { type AIToolOption } from './config.js';
+/**
+ * Removes all OpenSpec-owned skill directories under the given `skillsDir`.
+ * Only directories whose names match known workflow skill dir names are removed.
+ * Other files and directories are left intact.
+ *
+ * @returns Number of directories removed
+ */
+export declare function removeOpenSpecSkillDirs(skillsDir: string): Promise<number>;
+/**
+ * Removes all OpenSpec-owned command files for the given tool.
+ * Only files whose paths are produced by the tool's adapter `getFilePath()` are removed.
+ * The tool's configuration directory is left intact.
+ *
+ * @returns Number of files removed
+ */
+export declare function removeOpenSpecCommandFiles(projectPath: string, toolId: string): Promise<number>;
+/**
+ * Adds OpenSpec skill and command files for the given tool.
+ * Creates the tool's configuration directory if it does not exist.
+ * Respects the active global config (profile and delivery settings).
+ */
+export declare function addTool(projectPath: string, tool: AIToolOption): Promise<void>;
+/**
+ * Removes OpenSpec-owned skill and command files for the given tool.
+ * The tool's configuration directory itself is left intact; only files and
+ * directories created by OpenSpec are removed.
+ *
+ * @returns Counts of removed skill dirs and command files
+ */
+export declare function removeTool(projectPath: string, tool: AIToolOption): Promise<{
+    removedSkillCount: number;
+    removedCommandCount: number;
+}>;
+/**
+ * Returns the IDs of all tools that are currently configured in the project.
+ */
+export declare function getCurrentToolIds(projectPath: string): Set<string>;
+/**
+ * Returns all tools eligible for skill generation (those with a skillsDir).
+ */
+export declare function getEligibleTools(): AIToolOption[];
+/**
+ * Resolves a comma-separated tool list string to an array of valid tool IDs.
+ *
+ * Accepts the special values "all" and "none".
+ * Throws a descriptive error for invalid or ambiguous inputs.
+ */
+export declare function resolveToolsArg(raw: string): string[];
+//# sourceMappingURL=tools-manager.d.ts.map