@polymorphism-tech/morph-spec 7.3.0 → 7.4.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CLAUDE.md +1 -1
- package/README.md +2 -2
- package/bin/morph-spec.js +4 -2
- package/claude-plugin.json +1 -1
- package/docs/CHEATSHEET.md +1 -1
- package/docs/QUICKSTART.md +1 -1
- package/framework/CLAUDE.md +1 -1
- package/framework/MORPH.md +29 -12
- package/framework/agents.json +132 -132
- package/framework/evals/rubrics/README.md +9 -8
- package/framework/hooks/README.md +2 -0
- package/framework/hooks/claude-code/core/gate-guard.js +160 -0
- package/framework/hooks/claude-code/core/state-sync.js +15 -3
- package/framework/hooks/claude-code/core/validate-completion.js +105 -0
- package/framework/hooks/shared/state-reader.js +236 -221
- package/framework/skills/README.md +1 -1
- package/framework/skills/core/morph-apply/SKILL.md +63 -21
- package/framework/skills/core/morph-brainstorming/SKILL.md +5 -1
- package/framework/skills/core/morph-eval/SKILL.md +4 -5
- package/framework/skills/core/morph-implement/SKILL.md +47 -19
- package/framework/skills/core/morph-plan/SKILL.md +8 -2
- package/framework/skills/core/morph-proposal/SKILL.md +1 -1
- package/framework/skills/core/morph-review/SKILL.md +13 -6
- package/framework/skills/core/morph-stack-scan/SKILL.md +1 -1
- package/framework/skills/core/morph-standards/SKILL.md +1 -1
- package/framework/standards/ai-agents/setup.md +258 -244
- package/package.json +1 -1
- package/src/commands/project/init.js +517 -515
- package/src/commands/state/approve.js +251 -213
- package/src/commands/validation/validate-feature.js +64 -23
- package/src/core/state/state-manager.js +19 -9
- package/src/lib/risk-detector.js +2 -2
- package/src/utils/hooks-installer.js +527 -516
package/CLAUDE.md
CHANGED
|
@@ -52,7 +52,7 @@ No build step — pure ESM JavaScript, runs directly via Node.js 18+.
|
|
|
52
52
|
- `agents.json` (v5.0.0) — 7 domain personas, no tiers
|
|
53
53
|
- `phases.json` — 5 phases (proposal, uiux, plan, implement, review)
|
|
54
54
|
- `standards/STANDARDS.json` — index of available standards
|
|
55
|
-
- `hooks/claude-code/core/` —
|
|
55
|
+
- `hooks/claude-code/core/` — 7 fail-open guardrail hooks
|
|
56
56
|
- `skills/core/` — 7 core NLH skills (single source of truth)
|
|
57
57
|
- `templates/` — Handlebars templates for code generation
|
|
58
58
|
- `mcp/registry.json` — MCP server registry
|
package/README.md
CHANGED
|
@@ -3,7 +3,7 @@
|
|
|
3
3
|
> Spec-driven development framework for multi-stack projects. Turns feature requests into implementation-ready code through structured, AI-orchestrated phases.
|
|
4
4
|
|
|
5
5
|
**Package:** `@polymorphism-tech/morph-spec`
|
|
6
|
-
**Version:** 7.
|
|
6
|
+
**Version:** 7.4.0
|
|
7
7
|
**Requires:** Node.js 22+, Claude Code
|
|
8
8
|
|
|
9
9
|
---
|
|
@@ -365,4 +365,4 @@ Code generated by morph-spec (contracts, templates, implementation output) belon
|
|
|
365
365
|
|
|
366
366
|
---
|
|
367
367
|
|
|
368
|
-
*morph-spec v7.
|
|
368
|
+
*morph-spec v7.4.0 by [Polymorphism Tech](https://polymorphism.tech)*
|
package/bin/morph-spec.js
CHANGED
|
@@ -112,7 +112,8 @@ program
|
|
|
112
112
|
program
|
|
113
113
|
.command('approve <feature> <gate>')
|
|
114
114
|
.description('Approve a phase gate (proposal, plan, review)')
|
|
115
|
-
.option('--approver <name>', 'Name of approver (default: current user)')
|
|
115
|
+
.option('--approver <name>', 'Name of approver (default: current user when interactive, "auto" otherwise)')
|
|
116
|
+
.option('--mode <mode>', 'Approval mode: "user" or "auto" (default: detected from TTY)')
|
|
116
117
|
.option('--notes <notes>', 'Approval notes')
|
|
117
118
|
.action((feature, gate, options) => approveCommand(feature, gate, options));
|
|
118
119
|
|
|
@@ -125,7 +126,8 @@ program
|
|
|
125
126
|
program
|
|
126
127
|
.command('unapprove <feature> <gate>')
|
|
127
128
|
.description('Revoke a phase gate approval (recovery only)')
|
|
128
|
-
.option('--revoker <name>', 'Name of person revoking')
|
|
129
|
+
.option('--revoker <name>', 'Name of person revoking (default: current user when interactive, "auto" otherwise)')
|
|
130
|
+
.option('--mode <mode>', 'Revocation mode: "user" or "auto" (default: detected from TTY)')
|
|
129
131
|
.option('--reason <reason>', 'Reason for revocation')
|
|
130
132
|
.action((feature, gate, options) => unapproveCommand(feature, gate, options));
|
|
131
133
|
|
package/claude-plugin.json
CHANGED
package/docs/CHEATSHEET.md
CHANGED
package/docs/QUICKSTART.md
CHANGED
package/framework/CLAUDE.md
CHANGED
|
@@ -24,7 +24,7 @@ Se não houver feature ativa, pergunte ao usuário qual feature trabalhar.
|
|
|
24
24
|
- Atualizar o progresso em `tasks.json` via `writeTasksJson` ao concluir cada task — apenas os campos `status`, `outputs` e `notes` mudam; o contrato do plano permanece congelado.
|
|
25
25
|
- Apresentar gates com o template fixo definido em MORPH.md / morph-plan.
|
|
26
26
|
- Registrar decisões não triviais em `decisions.md`.
|
|
27
|
-
- Aplicar `morph-eval` após cada tarefa; silêncio em score ≥
|
|
27
|
+
- Aplicar `morph-eval` após cada tarefa; silêncio em score ≥ 9 é o sinal correto. Score < 9 dispara o loop de correção autônomo (re-implementa, sem pausa), não escala ao humano entre tarefas.
|
|
28
28
|
|
|
29
29
|
## Slash commands
|
|
30
30
|
|
package/framework/MORPH.md
CHANGED
|
@@ -21,9 +21,9 @@ Entre gates, você opera com autonomia total. O dev valida. Você executa.
|
|
|
21
21
|
| Sub-agent com auto-score ≥ 7 | Integrar ao recap.md e continuar |
|
|
22
22
|
| Sub-agent com auto-score < 7 | Aplicar morph-eval antes de aceitar |
|
|
23
23
|
| Build/typecheck quebra | Corrigir antes de marcar tarefa como done |
|
|
24
|
-
| Score morph-eval ≥
|
|
25
|
-
| Score morph-eval
|
|
26
|
-
| Score morph-eval <
|
|
24
|
+
| Score morph-eval ≥ 9 | Silêncio (aprovação implícita), próxima tarefa |
|
|
25
|
+
| Score morph-eval < 9 numa task | Loop de correção autônomo: re-implementar com o feedback priorizado, até 3 tentativas, sem pausa humana |
|
|
26
|
+
| Score morph-eval < 9 após 3 tentativas | Escalar ao usuário (aceitar / continuar tentando / pular) — único ponto de pausa do loop de implement |
|
|
27
27
|
|
|
28
28
|
**Regra de ouro:** Dúvida que não bloqueia o progresso → resolver e registrar. Dúvida que bloqueia → uma pergunta, máximo.
|
|
29
29
|
|
|
@@ -68,7 +68,7 @@ Responsabilidades: executar tarefas do tasks.json em ordem, consultar standards
|
|
|
68
68
|
Anti-padrão: o Specialist não cria novas tarefas. Descobertas de escopo durante a implementação vão para o decisions.md com flag "escopo expandido" — o Orchestrator avalia se o tasks.json precisa ser atualizado.
|
|
69
69
|
|
|
70
70
|
**Evaluator** — ativo após uma tarefa ou fase ser concluída.
|
|
71
|
-
Responsabilidades: aplicar as rubricas em `framework/evals/rubrics/`, produzir score 0-10, emitir feedback priorizado quando score <
|
|
71
|
+
Responsabilidades: aplicar as rubricas em `framework/evals/rubrics/`, produzir score 0-10, emitir feedback priorizado quando score < 9 (que alimenta o loop de correção autônomo do morph-apply), escalar para revisão humana apenas quando o loop de correção se esgotar (3 tentativas sem atingir 9).
|
|
72
72
|
Anti-padrão: o Evaluator não reescreve o código que avaliou. Se o score está abaixo de 6, o relatório vai para o humano — não para uma segunda rodada de tentativa automática.
|
|
73
73
|
|
|
74
74
|
Os papéis não são exclusivos — numa sessão longa você transita entre Orchestrator e Specialist conforme as tarefas avançam. A transição deve ser explícita: antes de mudar de papel, conclua o que estava fazendo ou registre o estado corrente no recap.md.
|
|
@@ -167,7 +167,7 @@ Gates são pontos de **pausa potencial**. Em `trust: "auto"` (default), gates **
|
|
|
167
167
|
|-------|-----------|---------------|
|
|
168
168
|
| `designSystemDivergence` | true | Brainstorming detecta fontes conflitantes (spec antigo vs bundle local) |
|
|
169
169
|
| `standardsViolations` | array.length > 0 | Mandate ou implementation viola padrões proibidos |
|
|
170
|
-
| `evalScore` | <
|
|
170
|
+
| `evalScore` | < 9 | morph-review produz score composto da feature abaixo do mínimo (o loop de correção intra-task já buscou 9 por task antes daqui) |
|
|
171
171
|
| `taskCount` | > 20 | Escopo grande — provavelmente vale revisar antes de implementar |
|
|
172
172
|
|
|
173
173
|
**Gate 1 — Proposta**
|
|
@@ -186,19 +186,32 @@ Para alterar o modo: editar `.morph/config/config.json → trust` (`"auto"` ou `
|
|
|
186
186
|
|
|
187
187
|
**Comportamento padrão fora de gate:** trabalhe com autonomia total. Gates só existem nestes três pontos. Não pause para confirmação no meio de implementação a menos que encontre uma ambiguidade de escopo que o mandate não cobre — nesse caso, registre a ambiguidade no decisions.md, resolva da forma mais conservadora possível, e sinalize na entrega da task.
|
|
188
188
|
|
|
189
|
-
**O hook state-sync.js** detecta as respostas dos Gates automaticamente: quando uma `AskUserQuestion` é respondida com label começando em "aprovado", marca o gate correspondente em `.morph/state.json
|
|
189
|
+
**O hook state-sync.js** detecta as respostas dos Gates automaticamente: quando uma `AskUserQuestion` é respondida com label começando em "aprovado", marca o gate correspondente em `.morph/state.json` com `approvedBy: "manual"` (um humano aprovou no loop). Em modo auto sem AskUserQuestion, a skill atualiza state.json diretamente (allowlist permite Edit em `.morph/state.json`).
|
|
190
|
+
|
|
191
|
+
**Registre quem aprovou cada gate (`approvedBy`):** o gate é um objeto `{ approved, timestamp, approvedBy }`.
|
|
192
|
+
- `approvedBy: "auto"` — gate avançado por política `trust: auto` sem decisão humana.
|
|
193
|
+
- `approvedBy: "manual"` — um humano aprovou explicitamente (via `AskUserQuestion`, ou, quando `AskUserQuestion` está indisponível em contexto headless, via mensagem em texto do usuário começando em "aprovado"). Em `trust: manual`, todo gate é `"manual"` — nunca grave `"auto"` num gate que um humano aprovou em conversa.
|
|
194
|
+
|
|
195
|
+
Isso mantém o audit trail honesto justamente nos contextos headless (CI, `claude -p`) onde ele mais importa.
|
|
196
|
+
|
|
197
|
+
**O hook gate-guard.js** confere, sem bloquear, se a ação tomada num gate (pausar via `AskUserQuestion` vs auto-aprovar) bateu com a decisão de trust que a skill computou via `shouldPauseGate`. Para isso, a skill **persiste** a decisão em `state.json` antes de agir: `features[feature].gateDecisions[gate] = { pause, reason, signals, trust, decidedAt }`. Se a ação observada divergir do registro (pausou um gate auto-aprovável, ou auto-aprovou um gate que exigia pausa), o guard injeta um aviso no contexto — a LLM corrige. É um guardrail silencioso, nunca um orquestrador: coerente, sem registro, ou erro → silêncio.
|
|
190
198
|
|
|
191
199
|
---
|
|
192
200
|
|
|
193
201
|
## 6. Sub-agents
|
|
194
202
|
|
|
195
|
-
|
|
203
|
+
A thread principal é o **Orchestrator**. Trabalho de implementação pesado ou fora do domínio corrente **deve** ser delegado a um sub-agent com persona e standard escopados — não absorvido inline na thread principal. Delegar não é uma permissão excepcional; é o modo padrão de operação para o caso pesado/multi-domínio. Implementar tudo inline porque "eu já sei o padrão" contamina o contexto principal e desperdiça o sistema de personas — é exatamente o anti-padrão que esta seção existe para evitar.
|
|
204
|
+
|
|
205
|
+
**Despache um sub-agent por padrão quando a tarefa atende a pelo menos um destes gatilhos:**
|
|
196
206
|
|
|
197
|
-
-
|
|
198
|
-
-
|
|
199
|
-
-
|
|
200
|
-
-
|
|
201
|
-
-
|
|
207
|
+
- **Domínio diferente do contexto corrente** — a task pertence a um domínio (ver `agents.json → domains`) distinto do que você está trabalhando agora (ex: você está no backend e a próxima task é frontend/UI/dados). Cruzar de domínio é o gatilho mais importante: cada domínio tem sua persona e seus standards, e o sub-agent escopado os carrega sem inchar seu contexto.
|
|
208
|
+
- **Esforço L ou XL** (duração estimada > 5 minutos).
|
|
209
|
+
- Mais de 3 tentativas de correção falharam no mesmo problema.
|
|
210
|
+
- Análise de arquivo com mais de 500 linhas.
|
|
211
|
+
- Tarefa repetitiva com mais de 3 instâncias do mesmo padrão.
|
|
212
|
+
- Risco de "contaminar" o contexto principal com detalhes de baixo nível irrelevantes para o fluxo.
|
|
213
|
+
|
|
214
|
+
Inline (sem dispatch) é aceitável para tasks curtas (effort S/M) **dentro do domínio que você já tem carregado em contexto**. Se optar por inline numa task que dispara um gatilho acima, **registre a justificativa em uma linha no decisions.md** ("inline porque o contexto X já está carregado e o overhead de dispatch não compensa") — uma escolha de inline silenciosa numa task pesada/multi-domínio é o anti-padrão.
|
|
202
215
|
|
|
203
216
|
**O que passar ao sub-agent:**
|
|
204
217
|
- Especificação da tarefa (do tasks.json)
|
|
@@ -226,6 +239,10 @@ O sub-agent deve ser autossuficiente com o que você passou. Se precisar de mais
|
|
|
226
239
|
|
|
227
240
|
**Após receber o retorno do sub-agent:** leia o auto-score. Se for < 7, aplique a skill morph-eval no resultado antes de aceitar. Se for >= 7 e sem itens bloqueantes, integre o resultado ao recap.md e siga para a próxima tarefa.
|
|
228
241
|
|
|
242
|
+
> **Anti-padrão a evitar:** implementar múltiplas tasks de domínios diferentes inline, em sequência, na thread principal — "eu já sei o padrão de cada uma". Isso é exatamente o sinal de que o sistema de delegação foi ignorado. Quando uma feature cruza ≥2 domínios, o caminho default é o Orchestrator despachando especialistas, não o Orchestrator virando faz-tudo.
|
|
243
|
+
|
|
244
|
+
**Dispatch em paralelo (multi-agent):** quando há fluxos de trabalho **genuinamente independentes** (ex: a cadeia de backend e a cadeia de frontend de uma mesma feature, que só convergem no fim), despache múltiplos sub-agents **ao mesmo tempo** — um por fluxo — em vez de processá-los em série. O orquestrador analisa o DAG de `tasks.json`, identifica os fluxos independentes (por `dependencies` e por `group`), e dispara o batch paralelo. As regras concretas de decisão sequencial vs. paralelo e o cap de agentes simultâneos vivem na skill `morph-apply` (seção "Análise de DAG"). A thread principal coordena; os especialistas executam — inclusive em paralelo.
|
|
245
|
+
|
|
229
246
|
O padrão de dispatch e o template de prompt para sub-agents estão detalhados em `framework/skills/core/morph-implement/SKILL.md`.
|
|
230
247
|
|
|
231
248
|
---
|
package/framework/agents.json
CHANGED
|
@@ -1,132 +1,132 @@
|
|
|
1
|
-
{
|
|
2
|
-
"version": "5.0.0",
|
|
3
|
-
"schema": "domain-personas",
|
|
4
|
-
"total_agents": 7,
|
|
5
|
-
"description": "Domain personas dispatched per task by the morph-implement skill. The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md — these are domain personas the Specialist consults when working in a specific area.",
|
|
6
|
-
"agents": {
|
|
7
|
-
"dotnet-senior": {
|
|
8
|
-
"title": ".NET Senior Engineer",
|
|
9
|
-
"icon": "🔷",
|
|
10
|
-
"color": "blue",
|
|
11
|
-
"domains": ["backend", "backend-api", "architecture"],
|
|
12
|
-
"keywords": [
|
|
13
|
-
"backend", "api", "dotnet", ".net", "csharp", "c#",
|
|
14
|
-
"minimal api", "vertical slice", "vsa", "result pattern",
|
|
15
|
-
"feature slice", "endpoint", "handler", "validator"
|
|
16
|
-
],
|
|
17
|
-
"stack": ["dotnet"],
|
|
18
|
-
"standards": [
|
|
19
|
-
"architecture-vertical-slice-vertical-slice",
|
|
20
|
-
"backend-dotnet-result-pattern",
|
|
21
|
-
"backend-dotnet-vsa-handler-patterns",
|
|
22
|
-
"backend-dotnet-fluent-validation-vsa"
|
|
23
|
-
],
|
|
24
|
-
"persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados híbrido: IRepository<T> + IUnitOfWork para CRUD, DbContext direto no slice para queries específicas; nunca uma camada de Service/Manager. Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
|
|
25
|
-
},
|
|
26
|
-
"ef-modeler": {
|
|
27
|
-
"title": "EF Core / Database Modeler",
|
|
28
|
-
"icon": "🗄️",
|
|
29
|
-
"color": "cyan",
|
|
30
|
-
"domains": ["database", "data-modeling", "migrations"],
|
|
31
|
-
"keywords": [
|
|
32
|
-
"ef core", "entity framework", "neon", "postgres", "postgresql",
|
|
33
|
-
"migration", "dbcontext", "navigation property", "configuration"
|
|
34
|
-
],
|
|
35
|
-
"stack": ["dotnet"],
|
|
36
|
-
"standards": [
|
|
37
|
-
"backend-database-postgresql-database",
|
|
38
|
-
"infrastructure-neon-setup",
|
|
39
|
-
"infrastructure-neon-pgvector"
|
|
40
|
-
],
|
|
41
|
-
"persona": "Você é um especialista em EF Core sobre Neon (Postgres). Pensa em migrations explícitas, configurações fluentes, navigation properties bem nomeadas, índices intencionais. Sempre Guid.CreateVersion7() para PKs. Sealed entities. Nunca leak de DbContext fora do handler."
|
|
42
|
-
},
|
|
43
|
-
"maf-expert": {
|
|
44
|
-
"title": "Microsoft Agent Framework Expert",
|
|
45
|
-
"icon": "🤖",
|
|
46
|
-
"color": "purple",
|
|
47
|
-
"domains": ["ai-agents", "ai-orchestration"],
|
|
48
|
-
"keywords": [
|
|
49
|
-
"agent", "ai agent", "maf", "microsoft agent framework",
|
|
50
|
-
"tool", "tool calling", "rag", "vector search", "llm",
|
|
51
|
-
"orchestration", "multi-agent"
|
|
52
|
-
],
|
|
53
|
-
"stack": ["dotnet"],
|
|
54
|
-
"standards": [
|
|
55
|
-
"ai-agents-setup",
|
|
56
|
-
"ai-agents-sweet-spot",
|
|
57
|
-
"ai-agents-providers-model-registry",
|
|
58
|
-
"ai-agents-structured-output",
|
|
59
|
-
"ai-agents-prompts-in-db",
|
|
60
|
-
"ai-agents-rag-custom-pgvector",
|
|
61
|
-
"ai-agents-middleware-patterns",
|
|
62
|
-
"ai-agents-multi-agent-patterns"
|
|
63
|
-
],
|
|
64
|
-
"persona": "Você é especialista no Microsoft Agent Framework (MAF 1.0 GA). Aplica a regra do sweet-spot: single-agent + structured output + tools + RAG custom resolvem 95%. Refere alias do Model Registry, nunca model hardcoded. Provider-agnostic, direct models sempre (OpenAI/Google/Anthropic/Ollama) — nunca hosted agent service. Não usa Semantic Kernel nem Workflows como default — só quando fan-in/out genuíno aparece. Telemetria via AgentOpenTelemetryConsts.DefaultSourceName."
|
|
65
|
-
},
|
|
66
|
-
"nextjs-expert": {
|
|
67
|
-
"title": "Next.js / React Expert",
|
|
68
|
-
"icon": "⚛️",
|
|
69
|
-
"color": "green",
|
|
70
|
-
"domains": ["frontend", "ui", "react", "nextjs"],
|
|
71
|
-
"keywords": [
|
|
72
|
-
"nextjs", "next.js", "react", "app router", "server component",
|
|
73
|
-
"client component", "tailwind", "framer motion", "shadcn"
|
|
74
|
-
],
|
|
75
|
-
"stack": ["nextjs"],
|
|
76
|
-
"standards": [
|
|
77
|
-
"frontend-nextjs-app-router",
|
|
78
|
-
"frontend-nextjs-components",
|
|
79
|
-
"frontend-nextjs-data-fetching",
|
|
80
|
-
"frontend-nextjs-naming-conventions",
|
|
81
|
-
"frontend-nextjs-state-management"
|
|
82
|
-
],
|
|
83
|
-
"persona": "Você escreve Next.js App Router idiomático. Server Components por padrão, Client Components apenas quando há interatividade real. Tailwind + Shadcn + Framer Motion. Tipos via Zod. Nada de getServerSideProps. RSC streaming quando faz sentido."
|
|
84
|
-
},
|
|
85
|
-
"ui-designer": {
|
|
86
|
-
"title": "UI/UX Designer",
|
|
87
|
-
"icon": "🎨",
|
|
88
|
-
"color": "magenta",
|
|
89
|
-
"domains": ["ui", "ux", "design-system", "accessibility"],
|
|
90
|
-
"keywords": [
|
|
91
|
-
"design", "ui", "ux", "design system", "tokens", "wcag",
|
|
92
|
-
"accessibility", "mockup", "flow", "shadcn", "tailwind"
|
|
93
|
-
],
|
|
94
|
-
"stack": ["nextjs"],
|
|
95
|
-
"standards": [
|
|
96
|
-
"frontend-design-system-naming",
|
|
97
|
-
"frontend-design-system-animations",
|
|
98
|
-
"frontend-nextjs-motion-patterns"
|
|
99
|
-
],
|
|
100
|
-
"persona": "Você desenha sistemas, não telas isoladas. Pensa em tokens (cor, espaço, tipografia), componentes reutilizáveis, estados (default/hover/focus/disabled/loading/error), acessibilidade WCAG AA. Mockups em Tailwind direto, sem Figma intermediário."
|
|
101
|
-
},
|
|
102
|
-
"infra-engineer": {
|
|
103
|
-
"title": "Infrastructure / Jobs Engineer",
|
|
104
|
-
"icon": "⚙️",
|
|
105
|
-
"color": "yellow",
|
|
106
|
-
"domains": ["infrastructure", "jobs", "deployment", "observability"],
|
|
107
|
-
"keywords": [
|
|
108
|
-
"hangfire", "background job", "queue", "deployment",
|
|
109
|
-
"docker", "ci/cd", "telemetry", "logging", "monitoring"
|
|
110
|
-
],
|
|
111
|
-
"stack": ["dotnet"],
|
|
112
|
-
"standards": [
|
|
113
|
-
"backend-integrations-hangfire-hangfire-jobs",
|
|
114
|
-
"infrastructure-docker-easypanel-deploy",
|
|
115
|
-
"backend-dotnet-scrutor"
|
|
116
|
-
],
|
|
117
|
-
"persona": "Você cuida de infra: jobs assíncronos com Hangfire (apenas quando há razão real), deployment, observabilidade. Pensa em retry, idempotência, dead-letter, métricas. Não inventa infra — usa o que o stack já oferece."
|
|
118
|
-
},
|
|
119
|
-
"evaluator": {
|
|
120
|
-
"title": "Code & Architecture Evaluator",
|
|
121
|
-
"icon": "🔍",
|
|
122
|
-
"color": "red",
|
|
123
|
-
"domains": ["evaluation", "review", "quality"],
|
|
124
|
-
"keywords": [
|
|
125
|
-
"review", "eval", "score", "rubric", "audit", "quality"
|
|
126
|
-
],
|
|
127
|
-
"stack": ["*"],
|
|
128
|
-
"standards": [],
|
|
129
|
-
"persona": "Você aplica as rubricas em framework/evals/rubrics/. Não reescreve código — produz scores 0-10 por dimensão (architecture, contracts, code-quality, test-coverage), feedback priorizado, e ação clara (aprovado/feedback
|
|
130
|
-
}
|
|
131
|
-
}
|
|
132
|
-
}
|
|
1
|
+
{
|
|
2
|
+
"version": "5.0.0",
|
|
3
|
+
"schema": "domain-personas",
|
|
4
|
+
"total_agents": 7,
|
|
5
|
+
"description": "Domain personas dispatched per task by the morph-implement skill. The 3 roles (Orchestrator/Specialist/Evaluator) are assumed by Claude itself per MORPH.md — these are domain personas the Specialist consults when working in a specific area.",
|
|
6
|
+
"agents": {
|
|
7
|
+
"dotnet-senior": {
|
|
8
|
+
"title": ".NET Senior Engineer",
|
|
9
|
+
"icon": "🔷",
|
|
10
|
+
"color": "blue",
|
|
11
|
+
"domains": ["backend", "backend-api", "architecture"],
|
|
12
|
+
"keywords": [
|
|
13
|
+
"backend", "api", "dotnet", ".net", "csharp", "c#",
|
|
14
|
+
"minimal api", "vertical slice", "vsa", "result pattern",
|
|
15
|
+
"feature slice", "endpoint", "handler", "validator"
|
|
16
|
+
],
|
|
17
|
+
"stack": ["dotnet"],
|
|
18
|
+
"standards": [
|
|
19
|
+
"architecture-vertical-slice-vertical-slice",
|
|
20
|
+
"backend-dotnet-result-pattern",
|
|
21
|
+
"backend-dotnet-vsa-handler-patterns",
|
|
22
|
+
"backend-dotnet-fluent-validation-vsa"
|
|
23
|
+
],
|
|
24
|
+
"persona": "Você é um engenheiro .NET sênior. Pensa em VSA com handlers diretos, result pattern, sealed classes, Guid.CreateVersion7(). Acesso a dados híbrido: IRepository<T> + IUnitOfWork para CRUD, DbContext direto no slice para queries específicas; nunca uma camada de Service/Manager. Não usa exceptions como fluxo. Consulta o standard antes de escrever cada slice. Nomeia tudo em PascalCase para tipos, camelCase para parâmetros."
|
|
25
|
+
},
|
|
26
|
+
"ef-modeler": {
|
|
27
|
+
"title": "EF Core / Database Modeler",
|
|
28
|
+
"icon": "🗄️",
|
|
29
|
+
"color": "cyan",
|
|
30
|
+
"domains": ["database", "data-modeling", "migrations"],
|
|
31
|
+
"keywords": [
|
|
32
|
+
"ef core", "entity framework", "neon", "postgres", "postgresql",
|
|
33
|
+
"migration", "dbcontext", "navigation property", "configuration"
|
|
34
|
+
],
|
|
35
|
+
"stack": ["dotnet"],
|
|
36
|
+
"standards": [
|
|
37
|
+
"backend-database-postgresql-database",
|
|
38
|
+
"infrastructure-neon-setup",
|
|
39
|
+
"infrastructure-neon-pgvector"
|
|
40
|
+
],
|
|
41
|
+
"persona": "Você é um especialista em EF Core sobre Neon (Postgres). Pensa em migrations explícitas, configurações fluentes, navigation properties bem nomeadas, índices intencionais. Sempre Guid.CreateVersion7() para PKs. Sealed entities. Nunca leak de DbContext fora do handler."
|
|
42
|
+
},
|
|
43
|
+
"maf-expert": {
|
|
44
|
+
"title": "Microsoft Agent Framework Expert",
|
|
45
|
+
"icon": "🤖",
|
|
46
|
+
"color": "purple",
|
|
47
|
+
"domains": ["ai-agents", "ai-orchestration"],
|
|
48
|
+
"keywords": [
|
|
49
|
+
"agent", "ai agent", "maf", "microsoft agent framework",
|
|
50
|
+
"tool", "tool calling", "rag", "vector search", "llm",
|
|
51
|
+
"orchestration", "multi-agent"
|
|
52
|
+
],
|
|
53
|
+
"stack": ["dotnet"],
|
|
54
|
+
"standards": [
|
|
55
|
+
"ai-agents-setup",
|
|
56
|
+
"ai-agents-sweet-spot",
|
|
57
|
+
"ai-agents-providers-model-registry",
|
|
58
|
+
"ai-agents-structured-output",
|
|
59
|
+
"ai-agents-prompts-in-db",
|
|
60
|
+
"ai-agents-rag-custom-pgvector",
|
|
61
|
+
"ai-agents-middleware-patterns",
|
|
62
|
+
"ai-agents-multi-agent-patterns"
|
|
63
|
+
],
|
|
64
|
+
"persona": "Você é especialista no Microsoft Agent Framework (MAF 1.0 GA). Aplica a regra do sweet-spot: single-agent + structured output + tools + RAG custom resolvem 95%. Refere alias do Model Registry, nunca model hardcoded. Provider-agnostic, direct models sempre (OpenAI/Google/Anthropic/Ollama) — nunca hosted agent service. Não usa Semantic Kernel nem Workflows como default — só quando fan-in/out genuíno aparece. Telemetria via AgentOpenTelemetryConsts.DefaultSourceName."
|
|
65
|
+
},
|
|
66
|
+
"nextjs-expert": {
|
|
67
|
+
"title": "Next.js / React Expert",
|
|
68
|
+
"icon": "⚛️",
|
|
69
|
+
"color": "green",
|
|
70
|
+
"domains": ["frontend", "ui", "react", "nextjs"],
|
|
71
|
+
"keywords": [
|
|
72
|
+
"nextjs", "next.js", "react", "app router", "server component",
|
|
73
|
+
"client component", "tailwind", "framer motion", "shadcn"
|
|
74
|
+
],
|
|
75
|
+
"stack": ["nextjs"],
|
|
76
|
+
"standards": [
|
|
77
|
+
"frontend-nextjs-app-router",
|
|
78
|
+
"frontend-nextjs-components",
|
|
79
|
+
"frontend-nextjs-data-fetching",
|
|
80
|
+
"frontend-nextjs-naming-conventions",
|
|
81
|
+
"frontend-nextjs-state-management"
|
|
82
|
+
],
|
|
83
|
+
"persona": "Você escreve Next.js App Router idiomático. Server Components por padrão, Client Components apenas quando há interatividade real. Tailwind + Shadcn + Framer Motion. Tipos via Zod. Nada de getServerSideProps. RSC streaming quando faz sentido."
|
|
84
|
+
},
|
|
85
|
+
"ui-designer": {
|
|
86
|
+
"title": "UI/UX Designer",
|
|
87
|
+
"icon": "🎨",
|
|
88
|
+
"color": "magenta",
|
|
89
|
+
"domains": ["ui", "ux", "design-system", "accessibility"],
|
|
90
|
+
"keywords": [
|
|
91
|
+
"design", "ui", "ux", "design system", "tokens", "wcag",
|
|
92
|
+
"accessibility", "mockup", "flow", "shadcn", "tailwind"
|
|
93
|
+
],
|
|
94
|
+
"stack": ["nextjs"],
|
|
95
|
+
"standards": [
|
|
96
|
+
"frontend-design-system-naming",
|
|
97
|
+
"frontend-design-system-animations",
|
|
98
|
+
"frontend-nextjs-motion-patterns"
|
|
99
|
+
],
|
|
100
|
+
"persona": "Você desenha sistemas, não telas isoladas. Pensa em tokens (cor, espaço, tipografia), componentes reutilizáveis, estados (default/hover/focus/disabled/loading/error), acessibilidade WCAG AA. Mockups em Tailwind direto, sem Figma intermediário."
|
|
101
|
+
},
|
|
102
|
+
"infra-engineer": {
|
|
103
|
+
"title": "Infrastructure / Jobs Engineer",
|
|
104
|
+
"icon": "⚙️",
|
|
105
|
+
"color": "yellow",
|
|
106
|
+
"domains": ["infrastructure", "jobs", "deployment", "observability"],
|
|
107
|
+
"keywords": [
|
|
108
|
+
"hangfire", "background job", "queue", "deployment",
|
|
109
|
+
"docker", "ci/cd", "telemetry", "logging", "monitoring"
|
|
110
|
+
],
|
|
111
|
+
"stack": ["dotnet"],
|
|
112
|
+
"standards": [
|
|
113
|
+
"backend-integrations-hangfire-hangfire-jobs",
|
|
114
|
+
"infrastructure-docker-easypanel-deploy",
|
|
115
|
+
"backend-dotnet-scrutor"
|
|
116
|
+
],
|
|
117
|
+
"persona": "Você cuida de infra: jobs assíncronos com Hangfire (apenas quando há razão real), deployment, observabilidade. Pensa em retry, idempotência, dead-letter, métricas. Não inventa infra — usa o que o stack já oferece."
|
|
118
|
+
},
|
|
119
|
+
"evaluator": {
|
|
120
|
+
"title": "Code & Architecture Evaluator",
|
|
121
|
+
"icon": "🔍",
|
|
122
|
+
"color": "red",
|
|
123
|
+
"domains": ["evaluation", "review", "quality"],
|
|
124
|
+
"keywords": [
|
|
125
|
+
"review", "eval", "score", "rubric", "audit", "quality"
|
|
126
|
+
],
|
|
127
|
+
"stack": ["*"],
|
|
128
|
+
"standards": [],
|
|
129
|
+
"persona": "Você aplica as rubricas em framework/evals/rubrics/. Não reescreve código — produz scores 0-10 por dimensão (architecture, contracts, code-quality, test-coverage), feedback priorizado acionável, e ação clara (aprovado em >=9 / feedback para o loop de correção em <9). Silêncio em scores ≥ 9 é o sinal correto."
|
|
130
|
+
}
|
|
131
|
+
}
|
|
132
|
+
}
|
|
@@ -14,11 +14,12 @@ Cada dimensão tem uma rubrica própria. O score final é ponderado.
|
|
|
14
14
|
|
|
15
15
|
## Escala de scores
|
|
16
16
|
|
|
17
|
-
| Score | Ação
|
|
18
|
-
|
|
19
|
-
|
|
|
20
|
-
|
|
|
21
|
-
|
|
17
|
+
| Score | Ação |
|
|
18
|
+
|-------|--------------------------------------------------------------------------------------------|
|
|
19
|
+
| 9-10 | Aprovado — sem output no contexto, siga para próxima tarefa |
|
|
20
|
+
| < 9 | Feedback priorizado — alimenta o loop de correção autônomo do morph-apply (re-implementa, sem pausa humana, até 3 tentativas) |
|
|
21
|
+
|
|
22
|
+
A barra de aprovação por tarefa é **9**. Abaixo disso o modelo corrige sozinho — não escala ao humano entre tarefas. A escalada humana só acontece quando o loop de correção esgota 3 tentativas sem atingir 9 (ver morph-apply/SKILL.md §3a e MORPH.md §0).
|
|
22
23
|
|
|
23
24
|
## Como calcular o score composto
|
|
24
25
|
|
|
@@ -28,7 +29,7 @@ score = (arquitetura × 0.30) + (contratos × 0.25) + (qualidade × 0.25) + (tes
|
|
|
28
29
|
|
|
29
30
|
Arredonde para uma casa decimal.
|
|
30
31
|
|
|
31
|
-
## Formato de output quando score <
|
|
32
|
+
## Formato de output quando score < 9
|
|
32
33
|
|
|
33
34
|
Produza exatamente este bloco (não mais, não menos):
|
|
34
35
|
|
|
@@ -38,7 +39,7 @@ Score: [X.X/10]
|
|
|
38
39
|
Issues (ordenados por impacto):
|
|
39
40
|
- [descrição do problema mais impactante]
|
|
40
41
|
- [próximo problema]
|
|
41
|
-
Ação: [feedback priorizado —
|
|
42
|
+
Ação: [feedback priorizado — alimenta o loop de correção | escalar (só após 3 tentativas)]
|
|
42
43
|
```
|
|
43
44
|
|
|
44
|
-
Quando score ≥
|
|
45
|
+
Quando score ≥ 9: nenhum output. O silêncio é o sinal de aprovação.
|
|
@@ -47,6 +47,8 @@ framework/hooks/
|
|
|
47
47
|
| **PreToolUse** (Write\|Edit) | protect-spec-files.js | Block | Blocks edits to spec files after approval |
|
|
48
48
|
| **PreToolUse** (Write\|Edit) | enforce-phase-writes.js | Block | Ensures writes go to current phase directory |
|
|
49
49
|
| **PreToolUse** (Bash) | _(prompt-type inline guard)_ | Block | Blocks `rm -rf .morph/` and direct state edits via Claude's reasoning |
|
|
50
|
+
| **PostToolUse** (Write\|Edit\|AskUserQuestion) | state-sync.js | State sync | Autonomous state.json updates (feature register, output tracking, gate approval) |
|
|
51
|
+
| **PostToolUse** (Write\|Edit\|AskUserQuestion) | gate-guard.js | Advisory | Warns (never blocks) when a gate action disagrees with the persisted gateDecisions (trust-mode enforcement, issue #63) |
|
|
50
52
|
| **PostToolUse** (Bash) | dispatch.js | Dispatch | Triggers checkpoints on task completion |
|
|
51
53
|
| **PostToolUseFailure** | handle-tool-failure.js | Logging | Appends structured JSON to .morph/logs/tool-failures.log |
|
|
52
54
|
| **Stop** | validate-completion.js | Advisory | Warns about incomplete tasks/missing outputs/pending gates |
|