Mechanical rename produced by scripts/msd-rename.cjs: gsd/Gsd/GSD -> msd/Msd/MSD across contents and paths, upstream package/repo coordinates -> @golem15/msd-core and golem15com/msd-core. Deep links into upstream history, sibling upstream packages, the GSD-2 import feature, CHANGELOG.md and .changeset/ are kept as-is. Hand edits on top: MSD block-letter banner and logos, LICENSE copyright line, package/plugin identity, regenerated lockfile, install-tree fixtures, derived registries and benchmark baseline; migration checksum baseline re-locked (MSD keeps its own install state, so no install had applied the old sums); sort-order and regex-escaped expectations in tests adjusted.
2.3 KiB
2.3 KiB
Referência de Agentes do MSD
Este documento descreve os papéis dos agentes especializados no ecossistema MSD.
Para a listagem completa com regras detalhadas, consulte AGENTS.md em inglês.
Visão geral
O MSD usa um orquestrador leve para coordenar subagentes especializados por etapa:
- pesquisa
- planejamento
- execução
- validação
- depuração
Cada agente tem responsabilidade clara, entradas/saídas definidas e contexto de trabalho limitado.
Famílias de agentes
Pesquisa
- Project/Phase researchers: investigam stack, arquitetura, padrões e riscos
- Research synthesizer: consolida descobertas em artefatos utilizáveis
Planejamento
- Planner: transforma requisitos em planos atômicos
- Plan checker: valida consistência, escopo, verificabilidade e dependências
Execução
- Executor: implementa tarefas do plano com contexto fresco
- Integration checker: verifica se as partes integram corretamente
Verificação
- Verifier: compara entrega contra objetivos da fase
- UAT support: auxilia no processo de validação manual guiada
Diagnóstico
- Debugger: identifica causa-raiz quando há falhas (
--diagnosepara modo somente diagnóstico, v1.32) - Forensics: investiga inconsistências de estado/artefatos/histórico
- Security auditor: verificação de segurança por threat model (v1.31)
- Doc writer / Doc verifier: geração e validação de documentação (v1.31)
Padrões operacionais
- Contexto isolado por tarefa: evita poluição acumulada
- Commits atômicos: um commit por unidade de trabalho
- Execução em ondas: paralelo quando possível, sequencial quando necessário
- Loop de revisão: planejamento e validação iteram até critérios mínimos
Boas práticas
- Prefira tarefas pequenas e verificáveis
- Trave decisões de implementação no
CONTEXT.md - Use
assumptions modequando já houver padrão consolidado no código - Ajuste perfil de modelo conforme custo x qualidade
Note
Esta versão em Português é uma referência operacional. Se você estiver contribuindo com o núcleo do framework ou alterando comportamento de agentes, consulte sempre o documento em inglês para detalhes normativos.