spec-first-copilot 0.5.0-beta.2 → 0.5.0-beta.4

package/templates/sfw.config.yml.example

@@ -0,0 +1,131 @@
+# ============================================================================
+# sfw.config.yml — Manifesto do projeto SFW
+# ============================================================================
+# Este arquivo define COMO o pipeline SFW fala com o mundo externo:
+# - De onde vêm os insumos do PM/PO (input)
+# - Pra onde vão os artefatos gerados (output.targets[])
+# - Como os nomes dos itens são formados (naming)
+#
+# É commitável (zero segredos). Credenciais ficam em .mcp.json gitignored
+# ou variáveis de ambiente exportadas ANTES de abrir o Claude Code.
+#
+# Gerado pelo CLI: `spec-first-claude init --name=X`
+#
+# Referências:
+# - Interface do adapter: .github/adapters/interface.md
+# - Adapters disponíveis: .github/adapters/registry.md
+# - Templating de nomes:  .github/adapters/naming.md
+# - Erros:                .github/adapters/errors.md
+# ============================================================================
+
+# ----------------------------------------------------------------------------
+# project — identidade do projeto
+# ----------------------------------------------------------------------------
+project:
+  name: "Meu Projeto"
+
+# ----------------------------------------------------------------------------
+# naming — templates de nome (aplicados pela engine em .github/adapters/naming.md)
+# ----------------------------------------------------------------------------
+# Placeholders suportados: {scope}, {type}
+#   {scope} = nome do item no Input (ex: "app_barbearia", "feat_login")
+#   {type}  = tipo do artefato (ex: "TRD", "SDD", "PRD", "Progresso")
+# Qualquer outro placeholder → ValidationError no load do manifest.
+#
+# O usuário nomeia livremente os items no Input — o agent NÃO impõe naming.
+# Estes templates controlam apenas o que o agent GERA no Output.
+naming:
+  # Subpasta (ou page-mãe) criada no Output por scope
+  # Ex: "out_app_barbearia", "out_feat_login"
+  output_container: "out_{scope}"
+
+  # Nome do artefato DENTRO do container
+  # No Confluence: {scope} no nome evita colisão de títulos no space
+  # No filesystem: pode simplificar pra "{type}" (sem redundância de scope)
+  output_artifact: "{scope} - {type}"
+
+# ----------------------------------------------------------------------------
+# input — de onde vêm os insumos do PM/PO (single source no MVP)
+# ----------------------------------------------------------------------------
+# /load {scope} usa esta seção pra puxar o conteúdo pro filesystem local.
+# Dev nunca edita o backend de input — só lê. PM owns este espaço.
+#
+# O agent faz listChildren(parent_page_id) e busca o scope pelo nome.
+# Se o scope não existir no backend, /load falha com erro explícito.
+input:
+  # Chave do adapter no registry. MVP: "confluence" | "filesystem"
+  adapter: confluence
+
+  # Config passada pro adapter.validateConfig(). Campos obrigatórios/opcionais
+  # são documentados no arquivo do adapter (ex: .github/adapters/confluence.md).
+  config:
+    space_key: ST
+    parent_page_id: "360668"      # page-mãe que contém os scopes no Input
+    recursive: true               # desce na árvore de scopes
+    include_attachments: true     # baixa PNGs, PDFs, planilhas
+
+  # Cache local onde /load materializa os insumos
+  cache:
+    local_dir: "workspace/Input/"
+    log: ".ai/load-log.md"        # append-only: id, version, sha256, timestamp
+    incremental: true             # hash-based re-load (NOVO/MODIFICADO/INALTERADO)
+
+# ----------------------------------------------------------------------------
+# output — pra onde os artefatos vão (MVP: 1 target, multi-target em P2)
+# ----------------------------------------------------------------------------
+# Cada target recebe um subset de artefatos via `publishes`.
+# Auto-publish é disparado pelas skills (/extract, /design, /plan).
+# Agent owns este espaço. PM só aplica label `sfw-approved` pra aprovar.
+#
+# Premissa: 1 space = 1 projeto (no Confluence). Multi-projeto no mesmo
+# space causa colisão de títulos — constraint do Confluence, não do SFW.
+# Se necessário, o user diferencia no Input (nomes únicos) e o Output
+# herda a unicidade via {scope} no naming.
+output:
+  targets:
+
+    # --- Target 1: Confluence (espelho de aprovação pro time) ---------------
+    - name: confluence-mirror
+
+      adapter: confluence
+
+      config:
+        space_key: ST
+        parent_page_id: "294931"  # page-mãe do Output no Confluence
+
+      # Whitelist de tipos que este target recebe.
+      # Tipos válidos: PRD, TRD, SDD, Progresso
+      # (tasks.md, docs/, projetos.yaml, specs/ ficam LOCAL ONLY —
+      #  ver §9.9 "Boundary publish vs local")
+      publishes: [PRD, TRD, SDD, Progresso]
+
+      # auto   — skill dispara publish automaticamente no fim
+      # manual — skill gera artefato local e pergunta se quer publicar
+      # off    — target ignorado (offline-first natural)
+      mode: auto
+
+      # Estratégia de conflict detection:
+      # version — compara version do backend com publish-log antes de update
+      # hash    — compara sha256 do conteúdo remoto com snapshot local
+      # none    — sobrescreve cego (NÃO recomendado; perde drift humano)
+      conflict_detection: version
+
+      # Mecanismo de aprovação do artefato publicado:
+      # label — PM aplica label na página Confluence pra marcar aprovado
+      # none  — sem aprovação formal (pipeline segue sem checar)
+      approval_mechanism: label
+      approval_label: "sfw-approved"
+
+    # --- Target 2: Filesystem mirror (opcional — time offline/backup) -------
+    # Descomente pra ativar. Útil pra testes E2E com FilesystemAdapter como
+    # mock natural — zero lib de mock, zero stub.
+    #
+    # - name: local-mirror
+    #   adapter: filesystem
+    #   config:
+    #     root_path: "./mirror"
+    #     glob: "**/*.md"
+    #   publishes: [PRD, TRD, SDD, Progresso]
+    #   mode: auto
+    #   conflict_detection: hash
+    #   approval_mechanism: none

package/templates/.github/skills/sf-setup-projeto/SKILL.md

@@ -1,123 +0,0 @@
----
-name: sf-setup-projeto
-description: |
-  Bootstrap do projeto. Cria contexto TRD, chama /sf-extract, para no checkpoint.
-  Trigger: /sf-setup-projeto
-author: GustavoMaritan
-version: 1.0.0
-date: 2026-04-08
----
-
-# Skill: /sf-setup-projeto
-
-> Orquestrador de bootstrap do projeto. Executa uma única vez.
-> Cria contexto TRD, chama `/extract` e para no checkpoint de aprovação.
-
-## Tipo
-Orquestrador (primeira etapa do pipeline)
-
-## Uso
-```
-/sf-setup-projeto
-```
-
-## Pré-condições
-
-| # | Validação | Se falhar |
-|---|-----------|-----------|
-| 1 | `workspace/Input/setup_projeto/` existe | Parar → "Crie a pasta workspace/Input/setup_projeto/ e adicione seus insumos" |
-| 2 | Pasta contém pelo menos 1 arquivo (ignorar .gitkeep) | Parar → "Adicione insumos na pasta (aceitos: .md, .txt, .sql, .xml, .html, .json, .csv, .png, .jpg, .pdf — qualquer formato)" |
-| 3 | `docs/` está vazio ou contém apenas templates vazios | Parar → "Setup já foi executado. Use /sf-feature para novas funcionalidades" |
-| 4 | `workspace/Output/setup_projeto/.context.md` não existe ou status é `not_started` | Parar → "Setup já está em andamento. Verifique o status em .context.md" |
-
-## Passos
-
-### 1. Criar estrutura
-```
-workspace/Output/setup_projeto/
-├── .context.md        ← criado agora
-└── (TRD.md será criado pelo /extract)
-```
-
-### 2. Criar `.context.md`
-```yaml
----
-nome: "setup_projeto"
-tipo: "setup"
-documento: "TRD"
-pm_path: "workspace/Input/setup_projeto/"
-status: "not_started"
-ultima_skill: "/sf-setup-projeto"
-atualizado_em: "{{ISO_DATETIME}}"
----
-```
-
-### 3. Sugerir /sf-discovery (RECOMENDADO)
-
-Antes de extrair, perguntar ao usuário:
-```
-📋 Insumos encontrados em workspace/Input/setup_projeto/.
-
-Recomendo rodar /sf-discovery antes da extração para:
-  - Análise profunda dos insumos (parseia drawio, XML, SQL completo)
-  - Identificar gaps e contradições antes de estruturar
-  - Validar entendimento com você (mapa do sistema)
-
-Quer rodar /sf-discovery workspace/Input/setup_projeto/ agora? (s/n)
-  Se SIM → rodar discovery, salvar discovery.md, depois continuar com extract
-  Se NÃO → pular direto para /sf-extract (ok para insumos simples)
-```
-
-Se o usuário aceitar:
-- Rodar `/sf-discovery workspace/Input/setup_projeto/`
-- Aguardar conclusão — discovery.md salvo em `workspace/Output/setup_projeto/`
-- Continuar para o passo 4
-
-### 4. Chamar `/sf-extract setup_projeto`
-O `/sf-extract` lê os insumos + discovery.md (se existir), gera o TRD e atualiza status para `extract_done`.
-
-### 5. CHECKPOINT — Parar e informar o usuário
-Mensagem ao usuário:
-```
-✅ TRD gerado em workspace/Output/setup_projeto/TRD.md
-
-Revise o documento. Quando estiver satisfeito, execute:
-  /sf-design setup_projeto
-
-Se precisar adicionar mais insumos, coloque na pasta workspace/Input/setup_projeto/
-e execute:
-  /sf-extract setup_projeto
-```
-
-**O orquestrador encerra aqui.** O restante do pipeline é responsabilidade do usuário chamar as skills atômicas na ordem:
-1. `/sf-design setup_projeto` (pergunta aprovação → gera SDD + docs/ + projetos.yaml)
-2. `/sf-plan setup_projeto` (gera tasks com campo Repo por task)
-3. `/sf-dev setup_projeto` (INFRA-001 cria/clona repos em projetos/, executa tasks nos repos corretos)
-
-## Saídas diretas desta skill
-- `workspace/Output/setup_projeto/.context.md`
-- `workspace/Output/setup_projeto/TRD.md` (via /extract)
-- `workspace/Output/setup_projeto/.extract-log.md` (via /extract)
-
-## Saídas indiretas (skills subsequentes)
-- `sdd.md` (via /design)
-- `projetos.yaml` (via /sf-design — manifesto de repos)
-- `docs/` populado (via /design)
-- `specs/{nome}/tasks.md` + `Progresso.md` (via /plan)
-- `projetos/` com repos criados/clonados (via /sf-dev INFRA-001)
-
-## Erros
-
-| Erro | Ação |
-|------|------|
-| workspace/Input/setup_projeto/ não existe | Parar, instruir criação |
-| workspace/Input/setup_projeto/ vazio | Parar, listar formatos aceitos |
-| docs/ já populado | Parar, sugerir /sf-feature |
-| Pipeline já iniciado | Parar, mostrar status atual do .context.md |
-
-## Notas
-- Esta skill roda **uma única vez** por projeto
-- docs/ é gerado pelo /sf-design (passo 3), não por tasks DOC
-- `projetos.yaml` é gerado pelo /sf-design (passo 3b) — mapeia serviços para repos
-- Repos são criados/clonados pelo /sf-dev (INFRA-001) dentro de `projetos/`
-- O `/merge-delta` NÃO se aplica ao setup (é criação, não atualização)