@sysmanager/sys-skills - npm Package Compare versions

Comparing version 1.0.15 to 1.0.16

package.json

 {
   "name": "@sysmanager/sys-skills",
-  "version": "1.0.15",
+  "version": "1.0.16",
   "description": "Agent Skills Framework - Easy setup for AI agent capabilities and integrations (Claude, Gemini, Codex, GitHub Copilot)",
@@ -5,0 +5,0 @@ "type": "module",

skills/implement/syscoe-acceptance-review-macro/SKILL.md

 ---
 id: syscoe-acceptance-review-macro
 name: SysCOE Acceptance Review Macro
-description: "Skill composta SysManager para varredura sistêmica do delta completo de uma feature antes do merge, rodando na sub-etapa E6.A (Bridge to Production) da fase Implement com janela de 1M tokens. Atende o slot I-E5 acceptance-reviewer (GAP shrink) do framework AI-SDLC. Use quando o orquestrador da fase Implement ativa a sub-etapa 6.A após UAT (Etapa 5) aprovado — o agente lê TODOS os arquivos alterados pela feature em conjunto para detectar inconsistências entre tasks que o Dual CR por PR não alcança. Emite veredito Go/No-Go/Aceitar Debit. Composta de: TLC tlc-spec-driven (validate.md) + security-threat-model com wrapper SysManager (hidden-eval Gherkin, UL diff report, anti-collusion macro, varredura 1M tokens)."
+description: "Skill composta SysManager para varredura sistêmica do delta completo de uma feature antes do merge, rodando na sub-etapa E6.A (Bridge to Production) da fase Implement com janela de 1M tokens. Atende o slot I-E5 acceptance-reviewer (GAP shrink) do framework AI-SDLC. Use quando o orquestrador da fase Implement ativa a sub-etapa 6.A após UAT (Etapa 5) aprovado — o agente lê TODOS os arquivos alterados pela feature em conjunto para detectar inconsistências entre tasks que o Dual CR por PR não alcança. Emite veredito Go/No-Go/Aceitar Debit via loop writer↔reviewer (Opus 1M ctx limpo). Composta de: TLC tlc-spec-driven (validate.md) + web-quality-audit + accessibility + seo + best-practices + security-threat-model com wrapper SysManager (Orchestrator writer↔reviewer Opus 1M, DDD-aware, hidden-eval Gherkin, UL diff report, delta-de-feature, anti-collusion macro, veredito formal)."
 argument-hint: "review | go | no-go | debit"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
-  dependencies: [harness-core]
+  dependencies: [harness-core, web-quality-audit, accessibility, seo, best-practices]
   requires: {}
-  tags: [acceptance, macro-review, feature-delta, hidden-eval, ul-diff, anti-collusion, e6a, 1m-context, syscoe]
+  tags: [acceptance, macro-review, feature-delta, hidden-eval, ul-diff, anti-collusion, writer-reviewer, e6a, 1m-context, syscoe]
 ---
@@ -26,2 +26,16 @@
 
+## Padrão Writer↔Reviewer (Opus 1M ctx limpo)
+
+Este agente opera no padrão **Orchestrator writer↔reviewer**:
+
+1. **Writer pass (Opus, janela limpa):** lê o delta completo + todos os artefatos de referência → produz rascunho do relatório de acceptance com apontamentos candidatos
+2. **Reviewer pass (Opus, janela separada):** recebe apenas o rascunho do Writer + delta — sem acesso ao contexto do Writer — e valida, corta falsos positivos e confirma achados reais
+3. **Consolidação:** o Orchestrator consolida os dois passes e emite o veredito final
+
+> **Por que duas janelas:** evitar que o revisor seja influenciado pelo raciocínio do writer (Stanford CodeX 2026 — circular evaluation). Janelas separadas garantem independência do julgamento.
+
+O loop writer↔reviewer ocorre **no máximo 1 vez** nesta skill — se houver divergência material entre Writer e Reviewer, escalar para HITL Final antes do veredito.
+
+---
+
 ## Por que este agente existe
@@ -142,4 +156,17 @@
 
-### 2.9 — Anti-Collusion Macro
+### 2.9 — Qualidade Web (features com frontend)
 
+Para features com componentes de UI, aplicar verificações dos padrões TLC:
+
+| Skill TLC | Verificações aplicadas |
+|---|---|
+| `web-quality-audit` | Performance (bundle size, lazy loading), SEO básico, acessibilidade, best practices — varredura agregada |
+| `accessibility` | WCAG 2.1: roles ARIA, labels, navegação por teclado, contrast ratio — verificar no delta de UI |
+| `seo` | Meta tags, structured data, sitemap (se rota nova foi adicionada) |
+| `best-practices` | Segurança (headers, CSP), compatibilidade, código moderno |
+
+Registrar resultado de cada dimensão no relatório. Features sem componentes de UI → marcar `qualidade-web: N/A (sem UI no delta)`.
+
+### 2.10 — Anti-Collusion Macro
+
 Verificação macro complementar à do `code-reviewer` por PR:
@@ -173,3 +200,4 @@ - Autor dos cenários Gherkin (fase Plan) ≠ autor das implementações (fase Implement)?
 | 2.8 UL diff report | ✅ / ⚠️ | Não-crítica |
-| 2.9 Anti-collusion macro | ✅ / ❌ | Crítica |
+| 2.9 Qualidade web (UI) | ✅ / ⚠️ / N/A | Não-crítica |
+| 2.10 Anti-collusion macro | ✅ / ❌ | Crítica |
 
@@ -176,0 +204,0 @@ ## Apontamentos Detalhados

skills/implement/syscoe-correctness-codex/SKILL.md

 ---
 id: syscoe-correctness-codex
 name: SysCOE Correctness Codex
-description: "Skill composta SysManager para code review de corretude na Etapa 4 do Implement (Dual Code Review), rodando por PR com foco em conformidade funcional com a Spec, anti-padrões BDD/DDD e UL diff report. Atende o slot I-E4 codex-correctness (GAP shrink) do framework AI-SDLC. Emite [VEREDITO: APPROVED/NEEDS REVISION/REJECTED] via comentário no WI ADO — nunca seta estado diretamente. Composta de: TLC coding-guidelines + the-fool com wrapper SysManager (A1 anti-collusion, A2 Gherkin imutável, A7 UL literal, UL diff report, trajectory metrics)."
+description: "Skill composta SysManager para code review de corretude na Etapa 4 do Implement (Dual Code Review), rodando por PR com foco em conformidade funcional com a Spec, anti-padrões BDD/DDD e UL diff report. Atende o slot I-E4 codex-correctness (GAP shrink) do framework AI-SDLC. Emite [VEREDITO: APPROVED/NEEDS REVISION/REJECTED] via comentário no WI ADO — nunca seta estado diretamente. Composta de: TLC coding-guidelines + the-fool + codex:rescue (modo rescue embutido) + gpt-5-prompting (prompt engineering para confronto heterogêneo Codex) com wrapper SysManager (taxonomia de bugs A1-A7, confronto vs AC do spec, veredito formal [VEREDITO] heterogêneo Codex, UL diff report, trajectory metrics)."
 argument-hint: "review | rescue | veredito"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
-  dependencies: [harness-core]
+  dependencies: [harness-core, coding-guidelines]
   requires: {}
-  tags: [code-review, dual-cr, correctness, bdd, ddd, anti-collusion, ul-diff, veredito, e4, syscoe]
+  tags: [code-review, dual-cr, correctness, bdd, ddd, anti-collusion, ul-diff, veredito, bug-taxonomy, e4, syscoe]
 ---
@@ -53,4 +53,22 @@
 
-## Passo 2 — Checklist Funcional (DoD)
+## Passo 2 — Taxonomia de Bugs (Confronto Heterogêneo Codex)
 
+Antes de aplicar os checklists, classificar cada problema encontrado na **taxonomia canônica SysManager** usando o padrão `gpt-5-prompting` para confronto cross-model:
+
+| Classe | Código | Descrição | Severidade |
+|---|---|---|---|
+| Anti-collusion | A1 | Mesmo autor em Plan (cenários) e Implement (código) | Crítica — bloqueia automaticamente |
+| Gherkin mutation | A2 | Cenário Gherkin editado entre commit RED e GREEN | Crítica — bloqueia automaticamente |
+| Logic bug | A3 | Lógica incorreta vs AC da Spec | Crítica |
+| UL drift | A7 | Identificador diverge do glossário UL | Crítica para Medium+ |
+| NFR violation | A5 | Violação de RNF (performance, segurança, acessibilidade) | Moderada |
+| Dead code | A6 | Código morto, logs de debug, TODOs esquecidos | Baixa |
+| Style violation | A8 | Desconformidade com code style do projeto | Baixa |
+
+**Confronto heterogêneo Codex:** para problemas A3 (Logic bug) e A5 (NFR), usar `gpt-5-prompting` para formular o prompt de confronto de forma que maximize a taxa de detecção — perguntar "o que está errado aqui?" antes de perguntar "está correto?". Isso evita viés de confirmação do revisor.
+
+---
+
+## Passo 3 — Checklist Funcional (DoD)
+
 - [ ] Todos os critérios de aceite do work item foram atendidos
@@ -65,3 +83,3 @@ - [ ] A funcionalidade descrita funciona conforme `spec.md`
 
-## Passo 3 — Checklist Técnico (DoR)
+## Passo 4 — Checklist Técnico (DoR)
 
@@ -78,3 +96,3 @@ - [ ] Código segue code style do projeto (lint, formatter, docstrings onde requerido)
 
-## Passo 4 — Checklist BDD/DDD (features Medium+)
+## Passo 5 — Checklist BDD/DDD (features Medium+)
 
@@ -120,3 +138,3 @@ Este checklist é **obrigatório** para features Medium+. Cada item com ❌ bloqueia automaticamente.
 
-## Passo 5 — Validações Automatizadas
+## Passo 6 — Validações Automatizadas
 
@@ -135,3 +153,3 @@ Executar **antes** de emitir veredito:
 
-## Passo 6 — UL Diff Report (obrigatório para Medium+)
+## Passo 7 — UL Diff Report (obrigatório para Medium+)
 
@@ -153,3 +171,3 @@ ```markdown
 
-## Passo 7 — Veredito Formal
+## Passo 8 — Veredito Formal
 
@@ -199,3 +217,3 @@ Emitir como comentário no WI ADO via `wit_add_work_item_comment`. Formato obrigatório:
 
-## Passo 8 — Mapeamento Veredito → Transição (executada pelo orquestrador)
+## Passo 9 — Mapeamento Veredito → Transição (executada pelo orquestrador)
 
@@ -202,0 +220,0 @@ | Veredito | Transição executada pelo orquestrador |

skills/implement/syscoe-deploy-multi-target/SKILL.md

 ---
 id: syscoe-deploy-multi-target
 name: SysCOE Deploy Multi-Target
-description: "Skill composta SysManager para bridge de deploy na Etapa 6 da fase Implement — valida pré-condições, dispara pipeline canônico (Vercel ou Cloudflare), cria Agent Deployment WIT, executa smoke test pós-deploy e coleta Eval Run com métricas primárias em t+15min. Atende o slot I-E6 deploy-bridge do framework AI-SDLC. Use quando o orquestrador da fase Implement ativa a Etapa 6 (Bridge to Production) após Gate 5 (UAT) e Acceptance Review macro (E6.A) aprovados. Modelo recomendado: Sonnet (orquestração com tooling pesado). Composta de: Vercel MCP oficial + Cloudflare MCP oficial + TLC sentry (post-deploy)."
+description: "Skill composta SysManager para bridge de deploy na Etapa 6 da fase Implement — valida pré-condições, dispara pipeline canônico (Vercel ou Cloudflare), cria Agent Deployment WIT, executa smoke test pós-deploy, coleta Eval Run com métricas primárias em t+15min e registra feedback loop FinOps. Atende o slot I-E6 deploy-bridge do framework AI-SDLC. Use quando o orquestrador da fase Implement ativa a Etapa 6 (Bridge to Production) após Gate 5 (UAT) e Acceptance Review macro (E6.A) aprovados. Composta de: Vercel MCP oficial + Cloudflare MCP oficial + TLC sentry (post-deploy) com wrapper SysManager (roteamento per-projeto Vercel/CF governado, Authorize Merge ADO, feedback loop FinOps, observabilidade OTel/Langfuse)."
 argument-hint: "deploy | vercel | cloudflare | rollback | status"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
@@ -207,4 +207,25 @@ dependencies: [harness-core]
 
-## Passo 9 — Atualização de `progress.md`
+## Passo 9 — Feedback Loop FinOps
 
+Após Eval Run t+15min estável, registrar métricas de custo para o ciclo FinOps:
+
+```markdown
+## FinOps — Deploy {data}
+
+| Métrica | Valor | Budget | Status |
+|---|---|---|---|
+| Custo LLM (tokens consumidos no deploy) | ${N} | $X/deploy | ✅ / ⚠️ |
+| Custo infra (Vercel/Cloudflare egress estimado) | ${N}/mês | $X/mês | ✅ / ⚠️ |
+| Custo por req estimado em produção | ${N} | $X/req | ✅ / ⚠️ |
+| Alertas de custo configurados (threshold) | ✅ / ❌ | — | — |
+```
+
+- Registrar no campo `Custom.EstAICost` do Agent Deployment WIT via `syscoe-board-ado-pro`
+- Se custo por req > budget definido no Pilar 7 (Operação/FinOps) → escalar para SRE antes de fechar Gate 6
+- Comparar com estimativa do `tech-decisions-log.md` (Pilar 7 FinOps) — divergência > 30% = alerta para revisão da estimativa
+
+---
+
+## Passo 10 — Atualização de `progress.md`
+
 Registrar o deploy em `progress.md`:
@@ -227,3 +248,3 @@
 
-## Passo 10 — Release Tag (Etapa 6 — Bridge to Production)
+## Passo 11 — Release Tag (Etapa 6 — Bridge to Production)
 
@@ -244,4 +265,28 @@ Ao confirmar deploy estável, criar tag semver via `git-cli-manager`:
 
-## Passo 11 — Estados ADO — WIT SDLC Implement
+## Passo 12 — Authorize Merge ADO + Observabilidade OTel/Langfuse
 
+### Authorize Merge ADO
+
+Após Eval Run t+15min estável e Gate 6 liberado, registrar autorização de merge no ADO:
+
+1. Delegar ao `syscoe-board-ado-pro`: transitar WIT SDLC Implement de `In Validate` → `Approved`
+2. Adicionar comentário no WIT: `"Deploy #{sha} autorizado — Eval Run t+15min estável. Authorize Merge confirmado por {SRE/Owner}."`
+3. Criar link PR → WIT via `wit_link_work_item_to_pull_request` (se não criado na Etapa 4)
+
+### Observabilidade OTel/Langfuse
+
+Verificar que os seguintes instrumentos estão ativos após o deploy:
+
+| Instrumento | Propósito | Verificação |
+|---|---|---|
+| OpenTelemetry (OTel) | Traces distribuídos, métricas de latência, error rate | Dashboard OTel ativo com dados do deploy |
+| Langfuse (se feature LLM) | Traces de chamadas LLM, custo por sessão, qualidade de resposta | Painel Langfuse mostrando eventos da feature |
+
+Se OTel não está instrumentado na feature → registrar como débito técnico em `progress.md` e alertar SRE.
+Se a feature usa LLM e Langfuse não está configurado → bloquear Gate 6 até instrumentação mínima.
+
+---
+
+## Passo 13 — Estados ADO — WIT SDLC Implement
+
 | Momento | Estado ADO |
@@ -248,0 +293,0 @@ |---|---|

skills/plan/syscoe-spec-enrich-adversarial/SKILL.md

 ---
 id: syscoe-spec-enrich-adversarial
 name: SysCOE Spec Enricher Adversarial
-description: "Skill composta SysManager para caça adversarial de edge cases, contradições e invariantes violadas na Spec durante a Etapa 3 da fase Plan, rodando em janela limpa paralela ao Spec Validator. Atende o slot P-E3 spec-enricher (GAP shrink) do framework AI-SDLC. Use quando o orquestrador da fase Plan ativa a Etapa 3 — o agente lê spec.md em janela limpa, caca problemas em 5 categorias e expande cenários BDD para 3 categorias mandatórias por US, gerando spec-enrichment-report.md para o Gate 2.5 (HITL micro). NÃO reescreve a spec — gera relatório de questões. Composta de: TLC tlc-spec-driven (discuss.md) + domain-analysis + tactical-ddd + coupling-analysis + the-fool."
+description: "Skill composta SysManager para caça adversarial de edge cases, contradições e invariantes violadas na Spec durante a Etapa 3 da fase Plan, rodando em janela limpa paralela ao Spec Validator. Atende o slot P-E3 spec-enricher (GAP shrink) do framework AI-SDLC. Use quando o orquestrador da fase Plan ativa a Etapa 3 — o agente lê spec.md em janela limpa, caça problemas nas 4 categorias canônicas (Funcional / NFR / Race / Contradição) + subcategoria de Invariantes DDD, expande cenários BDD para 3 categorias mandatórias por US, gerando spec-enrichment-report.md para o Gate 2.5 (HITL micro). NÃO reescreve a spec — gera relatório de questões. Composta de: TLC tlc-spec-driven (discuss.md) + domain-analysis + tactical-ddd + coupling-analysis + the-fool."
 argument-hint: "enrich | bdd | report | gate"
@@ -53,7 +53,7 @@ metadata:
 
-## Passo 2 — Caça Adversarial: 5 Categorias Obrigatórias
+## Passo 2 — Caça Adversarial: 4 Categorias Canônicas + Invariantes DDD
 
-Nenhuma categoria pode ser pulada. Cada apontamento deve referenciar seção específica da Spec ou do PRD.
+As 4 categorias canônicas do framework são: **Funcional / NFR / Race / Contradição**. A quinta (Invariantes DDD) é subcategoria especializada de Funcional para features Large+. Nenhuma categoria pode ser pulada. Cada apontamento deve referenciar seção específica da Spec ou do PRD.
 
-### Categoria 1 — Edge Cases de Input
+### Categoria 1 — Funcional: Edge Cases de Input
 
@@ -69,3 +69,3 @@ > "O que quebra quando a entrada está no limite ou está fora dele?"
 
-### Categoria 2 — Falhas de Dependências
+### Categoria 2 — NFR: Falhas de Dependências
 
@@ -82,3 +82,3 @@ > "O que acontece quando o mundo externo não coopera?"
 
-### Categoria 3 — Contradições entre PRD e Spec
+### Categoria 3 — Contradição: Divergências entre PRD e Spec
 
@@ -93,3 +93,3 @@ > "O que a Spec diz que conflita com o PRD?"
 
-### Categoria 4 — Race Conditions e Concorrência
+### Categoria 4 — Race: Condições de Corrida e Concorrência
 
@@ -105,3 +105,3 @@ > "O que pode dar errado quando dois processos atuam simultaneamente?"
 
-### Categoria 5 — Invariantes Violadas (DDD Tactical, features Large+)
+### Categoria 5 — Invariantes DDD Violadas (subcategoria de Funcional, features Large+)
 
@@ -108,0 +108,0 @@ > "Que regra de domínio o sistema deve recusar mesmo se o usuário pedir?"

skills/plan/syscoe-tech-decider-7pillars/SKILL.md

 ---
 id: syscoe-tech-decider-7pillars
-name: SysCOE Tech Decider — 6 Pilares
-description: "Skill composta SysManager para conduzir decisões tecnológicas na Etapa 1 da fase Plan via conversa estruturada HITL em 6 pilares (BD / Backend / Frontend / Segurança / DDD Strategic / Granularidade F1-F4). Atende o slot P-E1 tech-decider do framework AI-SDLC. Use quando o orquestrador da fase Plan ativa a Etapa 1 para tomar decisões de stack antes da geração da Spec. Nunca decide sozinho — apresenta 2-3 opções com trade-offs e espera arbitragem humana. Composta de: TLC create-adr + tactical-ddd + modular-design-principles + coupling-analysis com wrapper SysManager (6-criteria test de granularidade, fallback via Rules, ADR draft obrigatório por decisão significativa)."
-argument-hint: "start | pilar1 | pilar2 | pilar3 | pilar4 | pilar5 | pilar6 | finalize"
+name: SysCOE Tech Decider — 7 Pilares
+description: "Skill composta SysManager para conduzir decisões tecnológicas na Etapa 1 da fase Plan via conversa estruturada HITL em 7 pilares (BD / Backend / Frontend / Segurança / DDD Strategic / Granularidade F1-F4 / Operação-SRE-Compliance-FinOps). Atende o slot P-E1 tech-decider do framework AI-SDLC. Use quando o orquestrador da fase Plan ativa a Etapa 1 para tomar decisões de stack antes da geração da Spec. Nunca decide sozinho — apresenta 2-3 opções com trade-offs e espera arbitragem humana via matriz de aprovação multi-LLM. Composta de: TLC create-adr + create-rfc + tactical-ddd + modular-design-principles + decomposition-planning-roadmap + coupling-analysis + legacy-migration-planner com wrapper SysManager (7 pilares, 6-criteria test de granularidade, fallback via Rules, ADR draft obrigatório, matriz de aprovação multi-LLM)."
+argument-hint: "start | pilar1 | pilar2 | pilar3 | pilar4 | pilar5 | pilar6 | pilar7 | finalize"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
-  dependencies: [create-adr]
+  dependencies: [create-adr, create-rfc, decomposition-planning-roadmap, legacy-migration-planner]
   requires: {}
-  tags: [tech-decision, architecture, ddd, granularity, f1-f4, coupling, plan, e1, hitl, syscoe]
+  tags: [tech-decision, architecture, ddd, granularity, f1-f4, coupling, sre, compliance, finops, plan, e1, hitl, multi-llm, syscoe]
 ---
 
-# SysCOE Tech Decider — Plan E1
+# SysCOE Tech Decider — 7 Pilares — Plan E1
 
@@ -114,2 +114,28 @@ ## Objetivo
 
+### Pilar 7 — Operação / SRE / Compliance / FinOps
+
+> Aplicável a todas as features. Conduzir obrigatoriamente — decisões aqui afetam custo operacional, LGPD e SLOs em produção.
+
+**Operação / SRE:**
+- Qual o SLO de disponibilidade para esta feature? (99.9% / 99.5% / best-effort)
+- Quais alertas de produção são necessários? (error rate, latência P95, filas)
+- Runbook: há procedimento documentado para rollback e incidente desta feature?
+- Observabilidade: OpenTelemetry, Langfuse ou equivalente habilitado?
+
+**Compliance / AI-Act:**
+- Há processamento de dados pessoais (LGPD)? Se sim, DPIA necessário?
+- Se há componente de IA/ML: esta feature se enquadra no EU AI Act (alto risco / limitado / mínimo)?
+- Retenção de dados: qual a política de retenção para logs e dados gerados pela feature?
+- Auditoria: há requisito de trilha de auditoria para ações do usuário?
+
+**FinOps:**
+- Custo estimado por requisição / por usuário / por mês no MVP?
+- Há componentes com custo variável (LLM tokens, storage, egress)? Qual o budget máximo?
+- Alertas de custo: threshold de alerta e limite de kill-switch configurados?
+- Modelo de custo preferido para LLMs nesta feature: Haiku / Sonnet / Opus — justificado por complexidade, não por hábito.
+
+Apresentar 2-3 opções por subitem onde aplicável. Registrar decisão + justificativa.
+
+Output deste pilar: seção `Operação/Compliance/FinOps` no `tech-decisions-log.md`.
+
 ### Pilar 6 — Granularidade Arquitetural (F1-F4)
@@ -153,8 +179,24 @@
 
-## Passo 3 — Outputs Obrigatórios
+## Passo 3 — Matriz de Aprovação Multi-LLM
 
-Ao concluir os 6 pilares, gerar:
+Antes de gerar os outputs, submeter as decisões dos 7 pilares à **matriz de aprovação multi-LLM**:
 
-### 3.1 — `design-doc-enriquecido.md`
+| Categoria de Decisão | Aprovador Primário | Validador Independente | Critério de Aprovação |
+|---|---|---|---|
+| BD / Backend / Frontend | Opus 4.6 (raciocínio profundo) | Gemini Pro (validação cruzada) | Consenso ou divergência documentada |
+| Segurança / Compliance | Opus 4.6 + SecEng (HITL) | Gemini Pro | Aprovação humana obrigatória |
+| DDD Strategic (Pilar 5) | Opus 4.6 | Sonnet (verificação tática) | Consenso em invariantes |
+| Granularidade F1-F4 (Pilar 6) | Opus 4.6 | Gemini Pro | 6-criteria test idêntico nas duas LLMs |
+| Operação/SRE/Compliance/FinOps (Pilar 7) | Opus 4.6 + SRE (HITL) | Gemini Pro | Aprovação humana obrigatória para SLO e DPIA |
 
+**Protocolo de divergência:** se Opus e Gemini divergem em uma decisão → registrar ambas as posições no `tech-decisions-log.md` + escalar para HITL Tech Lead para arbitragem. Divergência silenciada é anti-padrão.
+
+---
+
+## Passo 4 — Outputs Obrigatórios
+
+Ao concluir os 7 pilares, gerar:
+
+### 4.1 — `design-doc-enriquecido.md`
+
 Design Doc da Research com **camada de Tech Decisions adicionada**. Não sobrescrever — adicionar seção nova:
@@ -175,3 +217,3 @@
 
-### 3.2 — `tech-decisions-log.md`
+### 4.2 — `tech-decisions-log.md`
 
@@ -189,3 +231,3 @@ Registro auditável de cada escolha:
 
-### 3.3 — ADR Drafts em `docs/adr/ADR-XXXX-<slug>.md`
+### 4.3 — ADR Drafts em `docs/adr/ADR-XXXX-<slug>.md`
 
@@ -212,3 +254,3 @@ **Toda decisão tecnológica significativa** (escolha que persistirá além desta feature, cria lock-in ou afeta repos vizinhos) gera um ADR draft com `Status: ⏳ Proposed`.
 
-### 3.4 — `context-map.md` (features Large+ — Pilar 5)
+### 4.4 — `context-map.md` (features Large+ — Pilar 5)
 
@@ -237,3 +279,3 @@ Mapa de relações entre Bounded Contexts:
 
-## Passo 4 — Estados ADO — WIT SDLC Plan
+## Passo 5 — Estados ADO — WIT SDLC Plan
 
@@ -240,0 +282,0 @@ | Momento | Estado ADO |

skills/research/syscoe-design-doc-suite/SKILL.md

 ---
 id: syscoe-design-doc-suite
 name: SysCOE Design Doc Suite
-description: "Skill composta SysManager para produção do Design Doc técnico na Etapa 5B da fase Research, rodando em janela de contexto separada e paralela ao PRD Writer. Atende o slot R-E5 design-doc-writer do framework AI-SDLC. Use quando o orquestrador da fase Research aciona a Etapa 5B para produzir o artefato técnico complementar ao PRD — arquitetura, APIs, modelo de dados, RNF operacionais e Domain Language técnica. Não usar para ADR (Plan E1) nem RFC (Plan E2). Composta de: TLC technical-design-doc-creator + mermaid-studio com wrapper SysManager (11 seções canônicas, Domain Language técnica §11, loop Validador-Juiz max 3 ciclos)."
+description: "Skill composta SysManager para produção do Design Doc técnico na Etapa 5B da fase Research, rodando em janela de contexto separada e paralela ao PRD Writer. Atende o slot R-E5 design-doc-writer do framework AI-SDLC. Use quando o orquestrador da fase Research aciona a Etapa 5B para produzir o artefato técnico complementar ao PRD — arquitetura, APIs, modelo de dados, RNF operacionais e Domain Language técnica. ADRs standalone e RFCs standalone pertencem ao Plan E1; este slot usa os formatos de create-adr e create-rfc para estruturar §7 (Tradeoffs) e propostas técnicas embutidas no Design Doc. Composta de: TLC technical-design-doc-creator + create-adr + create-rfc + mermaid-studio com wrapper SysManager (11 seções canônicas, header DDD com UL/Bounded Contexts, glossário automático §11, cross-ref ADO Features, loop Validador-Juiz max 3 ciclos)."
 argument-hint: "draft | iterate | finalize"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
-  dependencies: []
+  dependencies: [create-adr, create-rfc]
   requires: {}
-  tags: [design-doc, architecture, rfc, domain-language, research, e5b, validador-juiz, syscoe]
+  tags: [design-doc, architecture, rfc, adr, domain-language, research, e5b, validador-juiz, syscoe]
 ---
@@ -34,7 +34,9 @@
 Não usar para:
-- Criar ADRs → slot Plan E1 (`syscoe-tech-decider-7pillars`)
-- Criar RFCs → slot Plan E1/E2
+- Criar ADRs standalone (arquivo `docs/adr/ADR-XXXX.md`) → slot Plan E1 (`syscoe-tech-decider-7pillars`)
+- Criar RFCs standalone → slot Plan E1/E2
 - Criar diagramas Mermaid isolados → usar mermaid-studio diretamente
 - Enriquecer spec de Plan → usar `syscoe-spec-enrich-adversarial`
 
+> **Uso embutido de `create-adr` e `create-rfc`:** o formato canônico de `create-adr` é usado para estruturar cada entrada de §7 (Tradeoffs); o formato de `create-rfc` é usado para propostas técnicas que requerem aprovação antes de implementar. Os artefatos resultantes ficam **embutidos no Design Doc**, não como arquivos separados.
+
 ---
@@ -115,7 +117,10 @@
 
-### Seção 7 — Tradeoffs: toda decisão significativa documentada
+### Seção 7 — Tradeoffs: toda decisão significativa documentada (formato `create-adr`)
 
-Toda decisão arquitetural que persistirá além desta feature ou cria lock-in tecnológico deve ter justificativa. Formato:
+Toda decisão arquitetural que persistirá além desta feature ou cria lock-in tecnológico deve ter justificativa. Usar o formato canônico do `create-adr` embutido:
 
-```
+```markdown
+**ADR embutido — [Título da Decisão]**
+**Status:** ⏳ Proposed (será promovido a ADR standalone no Plan E1 se aprovado)
+**Feature ADO:** #{id} — cross-ref obrigatório
 **Decisão:** [o que foi decidido]
@@ -125,4 +130,17 @@ **Alternativas consideradas:** [opção B, opção C]
 **Trade-off aceito:** [o que se abre mão ao escolher A]
+**Consequências:** [o que muda; impacto em outros componentes]
 ```
 
+Para decisões que requerem aprovação explícita antes de implementar, usar formato `create-rfc` embutido:
+
+```markdown
+**RFC embutida — [Título da Proposta]**
+**Status:** 🔍 Draft (aguarda aprovação do Tech Lead no Gate 5)
+**Feature ADO:** #{id} — cross-ref obrigatório
+**Problema:** [por que esta proposta é necessária]
+**Proposta:** [o que se propõe fazer]
+**Alternativas:** [o que foi considerado e descartado]
+**Critério de aceite:** [como saberemos que a proposta foi implementada com sucesso]
+```
+
 Se Rules (`CLAUDE.md`/`AGENTS.md`) já cobre o padrão → referenciar e seguir, nunca reinventar.
@@ -138,5 +156,5 @@
 
-### Seção 11 — Domain Language Técnica (features Medium+)
+### Seção 11 — Domain Language Técnica (features Medium+) — Glossário Automático
 
-Espelha o glossário UL do PRD §14, mas focado nos termos técnicos canônicos. Formato obrigatório:
+Espelha o glossário UL do PRD §14, mas focado nos termos técnicos canônicos. **Geração automática:** ao produzir §11, varrer o `design-doc.md` em produção e extrair automaticamente todo substantivo de domínio que aparecerá em código, banco ou eventos — não esperar que o usuário liste os termos. Formato obrigatório:
 
@@ -146,9 +164,15 @@ ```markdown
 
-| Termo | Tipo DDD | Definição Técnica | Tag de Origem |
-|---|---|---|---|
-| `PaymentOrder` | Aggregate | Raiz de agregado para ordens de pagamento | [CONFIRMED by TL] |
-| `PaymentMethod` | Value Object | Enum imutável: CREDIT/PIX/BOLETO | [INFERRED, needs validation] |
-| `PaymentProcessed` | Domain Event | Emitido após cobrança confirmada no gateway | [CONFIRMED by Owner] |
+**Cross-ref ADO:** Feature #{id} | PRD §14
+
+| Termo | Tipo DDD | Definição Técnica | ADO Feature | Tag de Origem |
+|---|---|---|---|---|
+| `PaymentOrder` | Aggregate | Raiz de agregado para ordens de pagamento | #{id} | [CONFIRMED by TL] |
+| `PaymentMethod` | Value Object | Enum imutável: CREDIT/PIX/BOLETO | #{id} | [INFERRED, needs validation] |
+| `PaymentProcessed` | Domain Event | Emitido após cobrança confirmada no gateway | #{id} | [CONFIRMED by Owner] |
 ```
 
+**Regras do glossário automático:**
+- Todo termo que aparece ≥2 vezes no Design Doc como substantivo de domínio é candidato automático
+- Todo Aggregate, Entity, Value Object e Domain Event identificado no §1 (Arquitetura) deve estar aqui
+- A coluna **ADO Feature** registra em qual Feature ADO este termo aparece — é o cross-ref com o board
 - `[CONFIRMED by Owner/TL]` — validado com humano responsável
@@ -211,3 +235,3 @@ - `[INFERRED, needs validation]` — inferido dos artefatos; precisa confirmação
 - **Estimativa ≠ PBI** — nunca decompor em tasks aqui; isso é papel do Plan
-- **Nunca criar ADR ou RFC nesta skill** — pertencem ao Plan E1
+- **ADR e RFC embutidos, nunca standalone** — o formato `create-adr`/`create-rfc` estrutura §7 e propostas técnicas; arquivos `ADR-XXXX.md` separados pertencem ao Plan E1
 - **Idioma** — gerar no idioma da solicitação; termos técnicos canônicos permanecem em inglês quando estabelecidos no glossário UL

skills/syscoe-board-ado-pro/SKILL.md

 ---
 id: syscoe-board-ado-pro
 name: SysCOE Board ADO Pro
-description: "Skill composta SysManager para gestão mecânica do board Azure DevOps — atualização de estados, registro de métricas (tokens/custo/duração) e criação de work items hierárquicos. Atende o slot Transversal board-manager do framework AI-SDLC. Use quando o orquestrador de qualquer fase (Research/Plan/Implement) precisa transitar estados do WIT SDLC, registrar métricas de execução ou criar hierarquia Epic→Feature→WIT SDLC. Agente deliberadamente leve (Haiku) — executa apenas operações mecânicas, nunca decide autonomamente. Composta de: Microsoft azure-devops-mcp oficial com wrapper SysManager (process-target verification, 15-state flow, métricas por modelo)."
-argument-hint: "transition | metrics | create | link | status"
+description: "Skill composta SysManager para gestão mecânica do board Azure DevOps — atualização de estados, registro de métricas (tokens/custo/duração), criação de work items hierárquicos e capacity planning de 3 times. Atende o slot Transversal board-manager do framework AI-SDLC. Use quando o orquestrador de qualquer fase (Research/Plan/Implement) precisa transitar estados do WIT SDLC, registrar métricas de execução, criar hierarquia Epic→Feature→WIT SDLC ou calcular capacidade de sprint. Agente deliberadamente leve (Haiku) — executa apenas operações mecânicas, nunca decide autonomamente. Composta de: Microsoft azure-devops-mcp oficial + JoshuaRamirez state-transitions (extensão custom) com wrapper SysManager (process-target verification, 15-state flow, estados custom gov-sys-manager, links Feature↔PBI↔Task↔PR, capacity calc 3 teams, métricas por modelo)."
+argument-hint: "transition | metrics | create | link | status | capacity"
 metadata:
-  version: '2.0.0'
+  version: '2.1.0'
   category: sdlc
   dependencies: [harness-core]
   requires: {}
-  tags: [ado, board, work-items, wit-sdlc, metrics, state-transition, gov-sys-manager, haiku, syscoe]
+  tags: [ado, board, work-items, wit-sdlc, metrics, state-transition, gov-sys-manager, capacity, haiku, syscoe]
 ---
@@ -177,4 +177,25 @@
 
-### 3.5 — Consultar Status (modo `status`)
+### 3.5 — Capacity Calc 3 Teams (modo `capacity`)
 
+Calcular capacidade de sprint para até 3 times simultaneamente usando `work_get_team_capacity` e `work_get_iteration_capacities`:
+
+```markdown
+## Capacity Sprint — {sprint}
+
+| Time | Membros | Dias úteis | Férias/folgas | Capacidade (SP) | Alocado | Disponível |
+|---|---|---|---|---|---|---|
+| Time Backend | {N} | {N} | {N} dias | {N} SP | {N} SP | {N} SP |
+| Time Frontend | {N} | {N} | {N} dias | {N} SP | {N} SP | {N} SP |
+| Time Infra/SRE | {N} | {N} | {N} dias | {N} SP | {N} SP | {N} SP |
+| **Total** | | | | **{N} SP** | **{N} SP** | **{N} SP** |
+```
+
+**Regra de over-commitment:** se `Alocado > Disponível × 1.15` → alertar orquestrador antes de finalizar sprint planning. O time de `syscoe-task-decomposer-pro` usa este relatório para validar o sprint plan (Etapa 5).
+
+Delegar ajuste de capacidade individual ao `work_update_team_capacity` quando necessário.
+
+> **Nota JoshuaRamirez state-transitions:** ao transitar estados relacionados a sprint (ex: `Todo → In Planning` em massa para um sprint), usar o padrão de batch transitions da extensão `state-transitions` para evitar N chamadas individuais à API ADO — uma transição em lote é mais eficiente e reduz risco de estado inconsistente.
+
+### 3.6 — Consultar Status (modo `status`)
+
 Gerar snapshot rápido de um work item ou iteração:
@@ -181,0 +202,0 @@

New alerts

Filesystem access

Supply chain risk

Accesses the file system, and could potentially read sensitive data.

Found 1 instance in 1 package

Fixed alerts

Filesystem access

Supply chain risk

Accesses the file system, and could potentially read sensitive data.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

614805

2.08%

No dependency changes