@polymorphism-tech/morph-spec 8.38.0 → 8.41.0

package/framework/skills/core/morph-implement/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a execução de cada tarefa de implementação com standard e
 version: core
 when-to-invoke: ao iniciar cada task de implementação listada em tasks.json
 user-invokable: false
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-implement
@@ -54,12 +54,14 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 
    > **Relação com `morph-spec dag`:** a decisão do DAG (na `morph-apply` §2) governa o **paralelismo ENTRE tasks** — quantos sub-agents rodam ao mesmo tempo. Os gatilhos acima governam o **dispatch INDIVIDUAL desta task**. São ortogonais e coexistem: `DAG: sequencial` NÃO significa "tudo inline" — significa "uma task por vez, na ordem". Exemplo: cadeia única backend de 12 tasks (DAG: sequencial); T7 tem effort L → despache T7 sozinha para `morph-dotnet-senior` e aguarde o retorno antes de seguir; T8 (S, mesmo domínio) roda inline.
 
-   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (cláusulas do relatório em forma curta — racional completo em `MORPH.md` §6):
+   **Se for despachar — use `subagent_type: "morph-{id}"` do agente identificado no passo 3.** Os subagents são gerados de `agents.json` na instalação (`.claude/agents/morph-{id}.md`) e a persona é o **system prompt** deles — não a cole no prompt. **Fallback:** se `morph-{id}` não estiver na sua lista de subagent types (stack não instalado), use `general-purpose` colando o campo `persona` no prompt e registre nas `notes` da task: `dispatch-fallback: general-purpose ({id} não registrado)`. Template do prompt (cláusulas do relatório em forma curta — racional completo em `MORPH.md` §6). **Cole-o literal**: só os campos entre colchetes mudam; não parafraseie cláusula nem omita os parágrafos de leitura, ferramentas e comentário — foi assim que regras chegaram tortas ao sub-agent em campo:
    ```
    Implementar [ID]: [title da task]
 
    Spec: [description completa do tasks.json]
-   Standard: [path do .md do standard identificado no passo 2]
+   Standards: [por standard: `id` + o digest do `standards --find` + as 3-8 regras
+     do .md que ESTA task aplica, coladas. O path vai junto só para consulta
+     pontual — o sub-agente não relê standards inteiros]
    Arquivos relevantes: [os `target` de task.reuse + o que o scout/grafo apontou
      — este campo não é decorativo: é por ele que o código já existente chega
      ao sub-agente, que trabalha em contexto fresco e não conhece o projeto.
@@ -74,9 +76,25 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    a ausência de grafo nunca bloqueia. Se algo cobre o caso, reuse ou estenda;
    se criar mesmo assim, diga por que em uma linha no relatório.
 
-   Leitura: não releia o que este prompt já traz. Em arquivo grande, `Grep`
-   acha a linha e `Read` com `offset`/`limit` lê só o trecho; leituras que não
-   dependem uma da outra vão no mesmo turno, em paralelo.
+   Leitura e turnos: cada turno custa ~10 s antes de a tool rodar, e o teto de
+   turnos corta sem aviso. Chamadas que não dependem uma da outra vão no MESMO
+   turno: leia de uma vez todos os arquivos que este prompt lista, dispare os
+   Grep juntos. Use Read/Grep/Glob — nunca `grep`, `sed -n`, `cat`, `find`,
+   `ls` via Bash. Não releia o que este prompt já traz. Em arquivo grande, `Grep`
+   acha a linha e `Read` com `offset`/`limit` lê só o trecho; log de build/teste
+   se lê pelo `Grep` do erro, não inteiro.
+
+   Ferramentas: antes de supor a API de uma biblioteca (MAF, EF Core, Next,
+   shadcn, SDK de provedor), consulte o MCP `context7` (`resolve-library-id` →
+   `query-docs`). Impacto e vizinhança de símbolo vêm do grafo
+   (`morph-spec graph`), não de varredura por grep. Tool `mcp__…` que não esteja
+   carregada se carrega com `ToolSearch` (`select:<nome>`); MCP ausente nunca
+   bloqueia — siga com o fallback.
+
+   Comentário: o padrão é nenhum. Nome, tipo e teste explicam o código; sem
+   `///`/JSDoc em membro de aplicação, cabeçalho, banner de seção ou história
+   da task. Só o porquê que o código não mostra, em uma linha
+   (`architecture-code-comments`).
 
    Contrato do relatório final:
    1. GRAVE `.morph/features/{feature}/3-implement/reports/[ID].md` ANTES de
@@ -84,25 +102,28 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       cortesia best-effort e pode não chegar inteira). NÃO chame SendMessage.
    2. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão
       — todo estado é gravado exclusivamente pelo orquestrador.
-   3. Verificação condicional ao isolamento: em batch paralelo SEM isolamento,
-      NÃO rode build/test da suíte compartilhada — a verificação
-      (`morph-spec verify`) é do orquestrador, pós-batch. Em batch COM
-      `isolation: "worktree"`, rode build/test no seu worktree, commite na
-      branch do worktree como último ato antes do relatório — nunca faça merge.
-      Worktree não commitado NÃO é removido pelo hook e vira pendência do
-      `doctor`; o commit é o que torna o seu trabalho integrável.
-      Ao rodar teste: compile uma vez e rode sem recompilar (`dotnet test
-      --no-build`); só os testes que a mudança toca (`--filter`) e, depois de
-      uma falha, só os que falharam. Grave a saída em arquivo uma vez
-      (`… > .morph/logs/test-last.log 2>&1`, sem nada depois) e leia o arquivo:
-      rodar de novo com outro `| tail`/`| grep` repete o teste para ver outras
-      linhas, e com pipe ou `; echo` o exit é o do último comando, não o do teste.
+   3. TESTE — a prova é do orquestrador (`morph-spec verify {feature} {task}`,
+      logo depois do seu retorno), não sua. Escreva os testes pelo orçamento:
+      um por pós-condição, um de regressão por bug, variantes numa tabela
+      (`[Theory]`/`it.each`). NÃO rode teste a cada marco nem faça ciclo
+      red→green: escreva código e testes, compile, e rode SÓ o filtro dos seus
+      testes UMA vez, antes do relatório; se falhar, corrija e rode só os que
+      falharam. Em batch paralelo SEM isolamento, só compile — o teste roda no
+      verify pós-batch. Em batch COM `isolation: "worktree"`, o mesmo vale no
+      seu worktree, e o último ato antes do relatório é o commit na branch do
+      worktree — nunca faça merge; worktree não commitado NÃO é removido pelo
+      hook e vira pendência do `doctor`. Ao rodar: compile uma vez e rode sem
+      recompilar (`dotnet test --no-build`), com `--filter`. Grave a saída em
+      arquivo uma vez (`… > .morph/logs/test-last.log 2>&1`, sem nada depois)
+      e leia o arquivo: rodar de novo com outro `| tail`/`| grep` repete o teste
+      para ver outras linhas, e com pipe ou `; echo` o exit é o do último
+      comando, não o do teste.
 
    4. ESCOPO: no máximo 3 tasks e ~4 arquivos por dispatch. Escopo maior falha e
       volta — fatie antes, não depois.
    5. SOBREVIVÊNCIA: o limite de turnos (`maxTurns`, no seu system prompt)
-      corta sem aviso: commite `wip({taskId})` a cada marco (arquivo que
-      compila, teste que passa), não só ao fim da task — e só os seus arquivos
+      corta sem aviso: commite `wip({taskId})` a cada marco (um arquivo ou
+      uma fatia coerente escrita — sem rodar teste para isso), não só ao fim da task — e só os seus arquivos
       (`git add <paths>`, nunca `-A`). Sem commit, a retomada recomeça do zero.
       A ~70% do limite, grave o relatório parcial no arquivo canônico: `PARCIAL`
       na 1ª linha, o feito e o que falta, sem auto-score. Depois siga ou pare,
@@ -112,6 +133,9 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
       sessões). Encerre dev server pelo PID que você mesmo subiu.
    7. RETORNO: o relatório no arquivo canônico é o retorno. `SendMessage` não é
       substituto do relatório e não deve ser chamado.
+   8. MUTAÇÃO: nunca altere, reverta, mova ou apague código de produção para ver
+      um teste falhar (`sed`, `mv`, `git show HEAD:… >`, `git stash`, `git
+      checkout --`). A prova de que o teste morde é do avaliador no Gate 3.
 
    Seu relatório (no arquivo, e na mensagem final quando ela chega) deve conter
    APENAS: (1) o que foi feito em 2-3 frases, (2) arquivos modificados,
@@ -151,8 +175,8 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
 5. Implemente a tarefa seguindo o standard e a persona identificados.
    Se encontrar ambiguidade de escopo não coberta pelo mandate, registre no decisions.md
    e resolva da forma mais conservadora — não pause para perguntar, a menos que seja bloqueante.
-   Testes rodados durante a implementação inline seguem o mesmo loop da cláusula 3 do template
-   do passo 4 (compilar uma vez, `--filter`, saída em arquivo).
+   Testes rodados durante a implementação inline seguem a cláusula 3 do template do passo 4
+   (sem red→green, uma rodada do filtro no fim, saída em arquivo) e a 8 (sem mutação).
 
    **Task com `3-implement/evidencias/{ID}.md` em `outputs`** (critério sobre saída de LLM —
    `morph-plan` §5): rode o eval ANTES de marcar `done` — e só o eval. Com nó `runner: "evals"`
@@ -241,7 +265,7 @@ Ao iniciar cada task de `tasks.json` — antes de escrever qualquer código. Nor
    > tasks.json + recap.md + `taskScores` do feature.json. **NÃO escreva o trace
    > manualmente** — a escrita manual foi removida da cerimônia por task.
 
-9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). **Única exceção:** a execução de evidência do passo 5 — só o nó `evals`, filtrado, com `--skip-e2e`, nunca persistida (`--no-persist`); ela não é a verificação da task e não substitui a do orquestrador. **A divisão:** no loop por task o recorte é **automático** — o `group` da task escolhe as suítes e os arquivos de teste dos `outputs` (passo 8) estreitam o comando dentro de cada uma (o relógio de uma task não paga a suíte inteira); `--filter {ids}` só força a escolha de suítes (um nó não casado aparece como `skip` nomeando o filtro, e um filtro que não casa nada é erro de uso, exit 2) e `--full` desliga o recorte. A suíte **inteira** roda no Gate 3 e no CI, sem filtro — `verify {feature}` nunca recorta. A suíte completa de um projeto grande não cabe numa invocação de Bash do harness — rode em background ou por partes, nunca "suba o limite" (não há constante de timeout global no CLI). Detalhe e forma de `project.tests[]`: `.morph/framework/CLI.md`, seção "Suítes de teste". Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
+9. Quando invocada por `morph-apply`, retornar o controle à skill orquestradora — ela decide qual task vem em seguida via `getReadyTasks(data)`. Não rode a suíte de testes inteira do projeto por conta própria ao fim da task quando invocada pela `morph-apply` — a verificação determinística (`morph-spec verify {feature} {task}`) é do orquestrador, logo após seu retorno (ver morph-apply §3a). **Única exceção:** a execução de evidência do passo 5 — só o nó `evals`, filtrado, com `--skip-e2e`, nunca persistida (`--no-persist`); ela não é a verificação da task e não substitui a do orquestrador. **A divisão:** no loop por task o recorte é **automático** — o `group` da task escolhe as suítes e os arquivos de teste dos `outputs` (passo 8) estreitam o comando dentro de cada uma (o relógio de uma task não paga a suíte inteira); `--filter {ids}` só força a escolha de suítes (um nó não casado aparece como `skip` nomeando o filtro, e um filtro que não casa nada é erro de uso, exit 2) e `--full` desliga o recorte. O sub-agent despachado roda só o filtro dos próprios testes, uma vez (cláusula 3), e nunca o `verify`. A suíte **inteira** roda no Gate 3 e no CI, sem filtro — `verify {feature}` nunca recorta. A suíte completa de um projeto grande não cabe numa invocação de Bash do harness — rode em background ou por partes, nunca "suba o limite" (não há constante de timeout global no CLI). Detalhe e forma de `project.tests[]`: `.morph/framework/CLI.md`, seção "Suítes de teste". Quando invocada manualmente, verificar se há próxima task ready e iniciá-la imediatamente aplicando esta skill desde o passo 1 (auto-advance). Pause apenas se encontrar ambiguidade bloqueante não coberta pelo mandate.
 
 ## Output esperado
 - Código implementado conforme o standard consultado (direto ou via sub-agent)

package/framework/skills/core/morph-media/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a AUTORIA de mídia gerada por IA — escolher o modelo pelo
 version: core
 when-to-invoke: quando a tarefa é PRODUZIR imagem ou vídeo por IA (catálogo, marketing, asset de LP) e alguém precisa decidir modelo, prompt e aprovação
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 stacks:
   - dotnet
   - nextjs
@@ -212,4 +212,4 @@ trabalho de design". Tratar a saída como entregável vetorial é o erro clássi
 
 - Os cinco standards da tabela do topo — a fonte de API, custo, prazo e conformidade.
 - Proveniência do conhecimento absorvido: `.morph/framework/standards/PROVENANCE.json`
-  (`gemini-image`, `cinematic-lp`, `brand-design`).
+  (`morph-image`, `cinematic-lp`, `brand-design`).

package/framework/skills/core/morph-plan/SKILL.md

@@ -4,7 +4,7 @@ description: Guia a produção dos artefatos de planejamento de uma feature (use
 version: core
 when-to-invoke: ao iniciar a fase plan de uma feature, após o Gate 1 (proposal aprovado)
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-plan
@@ -220,8 +220,9 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
      proibidos: o orçamento por task do passo 5 (um teste por pós-condição + um de regressão por
      bug, justificativa acima disso, tabela antes de cópia, nenhum teste que só fixa texto);
      fixture compartilhada antes de helper novo; TDD onde paga (bug: regressão primeiro; lógica
-     pura), teste depois aceito em UI e integração; comentário só com o porquê que o código não
-     mostra, nunca história de task/UC/ADR. Nos standards obrigatórios, liste
+     pura), teste depois aceito em UI e integração; comentário: o padrão é nenhum (nome, tipo e teste
+     explicam), só o porquê que o código não mostra, nunca `///`/JSDoc que repete a assinatura
+     nem história de task/UC/ADR. Nos standards obrigatórios, liste
      `architecture-code-comments` e o standard de teste do stack (seção *Test budget*).
    - **Baseline é um COMANDO, nunca um número.** O mandate congela no Gate 2 e é lido por
      implementadores durante dias — todo número cravado nele (`Suíte: 2366 passando`, cobertura,
@@ -307,6 +308,12 @@ Ao iniciar a fase plan — após o `proposal.md` ser aprovado e antes de qualque
 
    **Preencha `outputs` (paths planejados) em cada task** — o `morph-spec dag` usa os outputs para detectar colisão de arquivos entre fluxos paralelos e recomendar `isolation: "worktree"`. Task sem `outputs` entra como footprint desconhecido (não força isolamento, mas o dag não consegue protegê-la de colisão).
 
+   **Tamanho da task: no máximo 8 `outputs`** (testes incluídos). Uma task inteira cabe num
+   dispatch; acima disso o sub-agente bate no teto de turnos e a retomada recomeça fria. Fatie por
+   pós-condição (uma task por pós-condição ou par delas, com a dependência explícita). Antes do
+   Gate 2, o `morph-spec dag` recusa (exit 1) e o `gate-check plan` pausa com `oversizedTasks`;
+   depois do Gate 2 é só aviso.
+
    **Critério sobre saída de LLM vira eval de runtime — nunca "suíte estrutural".** Duas etapas,
    como na `morph-review`: (1) **filtro mecânico** — o `mandate.md` cita ao menos um standard
    `ai-agents`; senão, a regra não se aplica. (2) **determinação sua, por task** — o

package/framework/skills/core/morph-proposal/SKILL.md

@@ -4,7 +4,7 @@ description: Orquestra a fase de proposta+plano de uma feature morph-spec. Encad
 version: core
 when-to-invoke: ao receber instrução "use /morph-proposal" do usuário, ou ao iniciar uma nova feature
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-proposal

package/framework/skills/core/morph-review/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a fase de revisão e produz o review-report.md para o Gate 3
 version: core
 when-to-invoke: ao iniciar a fase review, após todas as tasks de tasks.json estarem com status `done`
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-review

package/framework/skills/core/morph-stack-scan/SKILL.md

@@ -4,7 +4,7 @@ description: Varre o codebase existente, detecta stack atual, compara com o stac
 version: core
 when-to-invoke: ao iniciar uma feature em projeto brownfield (codebase já existente)
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-stack-scan

package/framework/skills/core/morph-standards/SKILL.md

@@ -4,7 +4,7 @@ description: Localiza um standard específico via busca server-side (morph-spec
 version: core
 when-to-invoke: quando precisar consultar um standard específico durante a implementação
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-standards

package/framework/skills/core/morph-uiux/SKILL.md

@@ -4,7 +4,7 @@ description: Conduz a fase opcional de UI/UX — design system, mockups, compone
 version: core
 when-to-invoke: ao tomar o ramo uiux (morph-spec advance --design), depois do Gate 1 e antes do morph-plan
 user-invokable: true
-cliVersion: "8.38.0"
+cliVersion: "8.41.0"
 ---
 
 # morph-uiux
@@ -32,11 +32,11 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
    - **Sistemas, não telas isoladas** — mesmo critério da persona `ui-designer`: componentes reutilizáveis antes de composições de uso único.
    - **Toda tela sai com o checklist de tela preenchido** (template no passo 3) — a superfície, o volume esperado de dados, paginação, ordenação, filtro, os três estados (vazio, carregando, erro), o comportamento no mobile e abas × página longa. "Não se aplica" vale, **desde que escrito**. É o checklist que faz a lista de 2 000 linhas paginar: o que o design não decide não vira `doneCriteria` (`morph-plan` §5d), e o que não é critério ninguém entrega. Tela de dados segue os standards de `admin-app` (lista/tabela, formulário, feedback, estrutura de página), que a persona cita na superfície `admin-app`.
 
-3. **Despache `morph-ui-designer`** para o trabalho visual — dispatch é o default aqui (domínio diferente do Orchestrator, MORPH.md §6). `morph-ui-designer` tem `Read/Write/Edit/Glob/Grep` + MCPs `stitch`/`gemini-image`/`playwright`/`context7`, mas **não tem Bash** — não peça build, testes nem `morph-spec` a ele; isso é do orquestrador.
+3. **Despache `morph-ui-designer`** para o trabalho visual — dispatch é o default aqui (domínio diferente do Orchestrator, MORPH.md §6). `morph-ui-designer` tem o escopo das implementadoras (com Bash) + `Skill` + MCPs `stitch`/`playwright`/`context7`/`graphify` + o MCP de mídia morph-assets (imagem e vídeo). Bash serve para `morph-spec standards --find`, `npx`, screenshot e leitura de `git`; build/test da suíte, `verify` e aprovação de gate continuam do orquestrador (cláusula 3, como nas outras personas).
 
    **Persona universal** (`ui-designer.stack = ["*"]` em `agents.json`, mesmo mecanismo de `evaluator`/`scout`): UI/UX importa sempre que há superfície de UI, então o subagent está registrado em **todo** projeto — .NET/Blazor incluído, não só Next.js. **Fallback** (caso raro: instalação anterior a essa mudança, `.claude/agents/morph-ui-designer.md` ainda não regenerado): `general-purpose` colando o campo `persona` (Read em `.morph/framework/agents.json`) no prompt, registrando o fallback no relatório — resolvido rodando `morph-spec setup-infra --reinstall`.
 
-   Template do prompt (contrato do relatório em forma curta — copia o padrão de `morph-implement` §4, sem a cláusula de build/isolamento, que não se aplica a um agente sem Bash):
+   Template do prompt (contrato do relatório em forma curta — copia o padrão de `morph-implement` §4; a cláusula de build/isolamento vira "sem build/test da suíte", porque o design não entrega código a verificar):
    ```
    Produzir os artefatos de UI/UX de [feature] em `.morph/features/{feature}/1-design/`.
 
@@ -46,7 +46,7 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
    Produza, NESTA ORDEM — design-system.md primeiro, os demais só como aplicável ao escopo:
    1. `design-system.md` — tokens (cor, tipografia, espaço, motion) consistentes com o projeto
    2. `mockups.md` — descrição estruturada de cada tela nova/alterada (+ imagem via MCP
-      gemini-image/stitch quando disponível; fallback: descrição textual detalhada).
+      stitch ou o MCP de mídia (imagem/vídeo) quando disponível; fallback: descrição textual detalhada).
       Cada tela é um `## Tela: <nome>` e traz, dentro dela, o checklist abaixo, com cada `…`
       trocado pela decisão — "não se aplica" vale se escrito; `…`, vazio ou "a definir" não.
       O que cada item decide: Superfície (admin-app | marketing-site — ela escolhe que
@@ -82,8 +82,9 @@ Ao tomar o ramo opcional uiux: feature/bug cuja mudança cria ou altera superfí
       `1-design/reports/[artefato]-report.md` (ex.: `1-design/reports/design-system-report.md`)
       ANTES de encerrar — é o retorno autoritativo, não a sua mensagem final (cortesia
       best-effort, pode não chegar inteira). NÃO chame SendMessage.
-   2. Você não tem Bash — não rode `morph-spec`, build nem testes; a aprovação do Gate uiux
-      e qualquer comando CLI são do orquestrador.
+   2. Bash só para consulta (`morph-spec standards --find`, `npx`, screenshot, `git log/diff`):
+      NÃO rode build, testes nem `morph-spec verify`/`approve`/`advance` — a verificação e a
+      aprovação do Gate uiux são do orquestrador.
    3. NÃO toque em tasks.json, feature.json, state.json nem no board de sessão.
 
    Cada relatório contém: (1) o que foi feito em 2-3 frases, (2) o artefato produzido,

package/framework/standards/PROVENANCE.json

@@ -38,13 +38,13 @@
       "skills": []
     },
     {
-      "id": "gemini-image",
+      "id": "morph-image",
       "repo": "morph-HUB",
-      "path": "skills/gemini-image",
+      "path": "skills/morph-image",
       "envVar": "MORPH_HUB",
       "defaultCheckout": "R:/Polymorphism Tech/repos/morph-HUB",
-      "sourceTree": "ec0abd827badfd5cd6d4c5f8b1843f81a3d183fe",
-      "sourceCommit": "b6bbfff",
+      "sourceTree": "e55dcf307278583120601c3c5d55118302335f7b",
+      "sourceCommit": "c4c9164",
       "distilledOn": "2026-09-09",
       "distilledFrom": [
         "SKILL.md"

package/framework/standards/STANDARDS.json

@@ -1551,7 +1551,7 @@
         "errorbody": "#rule-2--error-path-tests-assert-the-response-body-not-just-the-status-code",
         "test-budget": "#test-budget"
       },
-      "digest": "Inject TimeProvider (never DateTime.UtcNow / DateOnly.FromDateTime(DateTime.UtcNow) directly in a handler or validator) and fake it with FakeTimeProvider (Microsoft.Extensions.TimeProvider.Testing) in integration tests — deterministic, no midnight-UTC flake, boundary dates (today vs. yesterday) become facts about the fake clock instead of when the suite happens to run. xUnit + WebApplicationFactory error-path tests (400/404/409) must assert the ProblemDetails response BODY (title/detail/violated field or error code), never just the HTTP status code — a status-only assertion lets the wrong validation rule or the wrong error branch pass silently as long as the status matches. Test budget per task: one test per postcondition plus one regression test per bug, more only with a one-line justification in the task; scenarios of the same behavior (edge cases included) are rows of one [Theory], never copied [Fact]s; no test whose only assertion is a copy, config or prose string (that is an analyzer or a publish-time validation, outside the suite count); shared fixtures before new helpers; TDD for bugs (regression first) and pure logic; a surviving mutant is killed by tightening an assertion or adding a row, not by a new test.",
+      "digest": "Inject TimeProvider (never DateTime.UtcNow / DateOnly.FromDateTime(DateTime.UtcNow) directly in a handler or validator) and fake it with FakeTimeProvider (Microsoft.Extensions.TimeProvider.Testing) in integration tests — deterministic, no midnight-UTC flake, boundary dates (today vs. yesterday) become facts about the fake clock instead of when the suite happens to run. xUnit + WebApplicationFactory error-path tests (400/404/409) must assert the ProblemDetails response BODY (title/detail/violated field or error code), never just the HTTP status code — a status-only assertion lets the wrong validation rule or the wrong error branch pass silently as long as the status matches. Test budget per task: one test per postcondition plus one regression test per bug, more only with a one-line justification in the task; scenarios of the same behavior (edge cases included) are rows of one [Theory], never copied [Fact]s; no test whose only assertion is a copy, config or prose string (that is an analyzer or a publish-time validation, outside the suite count); shared fixtures before new helpers; bugs and pure logic get tests in any order — the implementer runs its own filter once, never red-green cycles nor production mutation (the Gate 3 mutation proof shows the test bites); a surviving mutant is killed by tightening an assertion or adding a row, not by a new test.",
       "verifiedAgainst": ".NET 10 + xUnit 2 + `Microsoft.Extensions.TimeProvider.Testing`.",
       "provedBy": []
     },
@@ -1850,8 +1850,8 @@
         "favicon-og": "#the-two-assets-everyone-forgets",
         "variations": "#variations-and-cost"
       },
-      "digest": "Guidelines for generating project images with the Gemini Image MCP: when to use AI versus stock versus SVG, prompt patterns, aspect ratios, iterative editing and assets.md format. Core principle is brand fidelity over invention: always pass the client's real assets as referenceImages via edit_image rather than generating in a vacuum, never AI-recreate a property developer's architectural render or a physical product (animate or reference the real one), and chain derivatives from an approved hero so the whole set shares light, palette and identity. Frame anything destined to become video WITHOUT a face, because video moderation is stricter (E005), and generate scrub frames at the video's exact ratio with the subject opposite the copy. Always produce the two forgotten assets: a favicon derived from the real logo (never a new one) and a 1200x630 OG share image. Offer two to three genuinely different variations per image, varying angle, light or composition rather than the seed, and never advance with a weak image because every derivative inherits it.",
-      "verifiedAgainst": "Gemini Image MCP + Next.js 15 `next/image`.",
+      "digest": "Guidelines for generating project images with the morph-assets MCP (OpenRouter; default openai/gpt-image-2.5-flare, drafts on mai-image-2.6-flash, gemini-3.1-flash-image for 2K/4K or 6-14 refs; models: [...] compares): when to use AI versus stock versus SVG, prompt patterns, aspect ratios, iterative editing and assets.md format. Core principle is brand fidelity over invention: always pass the client's real assets as references (or @brand with a project) via edit_image rather than generating in a vacuum, never AI-recreate a property developer's architectural render or a physical product (animate or reference the real one), and chain derivatives from an approved hero so the whole set shares light, palette and identity. Frame anything destined to become video WITHOUT a face, because video moderation is stricter (E005), and generate scrub frames at the video's exact ratio with the subject opposite the copy. Always produce the two forgotten assets: a favicon derived from the real logo (never a new one) and a 1200x630 OG share image. Offer two to three genuinely different variations per image (variants returns a contact sheet), varying angle, light or composition since seed is not supported by the GPT Image/Gemini models, and never advance with a weak image because every derivative inherits it. Copy to render goes between double quotes; CONFIRMATION_REQUIRED needs human approval and a confirmToken.",
+      "verifiedAgainst": "morph-assets MCP (OpenRouter; default model `openai/gpt-image-2.5-flare`) + Next.js 15 `next/image`.",
       "provedBy": []
     },
     {
@@ -1889,8 +1889,8 @@
         "cost-ladder": "#section-4-the-cost-ladder",
         "prompt-skeleton": "#section-5-prompt-skeleton"
       },
-      "digest": "The decisive rule: a perfect loop has an end frame identical to its start, which is right for a self-playing ambient background and WRONG for scroll scrubbing, because start and end look the same and the page reads as frozen while the user scrolls. Scroll-driven footage needs directional movement via generate_video with an endImage (push-in/dolly is the most reliable, then reveal, pull-back, slow tilt); avoid orbits and any movement that returns to its origin. Client architectural renders are animated with img2vid, never AI-recreated. Human faces repeatedly trip moderation (E005), so crop the face out of frame (neck down, hands, product) and reserve faces for static image generation. Always climb the cost ladder: fast/480p/4s draft to judge framing and movement, 1080p only after approval, then re-extract frames with a bumped cache-bust. Prompts read like director notes with no hype words, and must reserve a calm dark region for the page copy with the subject on the opposite side. Generation is async: generate_video returns a request_id polled via get_video; list_videos reads local history and spends no credits.",
-      "verifiedAgainst": "seedance MCP (generate_video, generate_loop_video, get_video, list_videos) over Replicate.",
+      "digest": "The decisive rule: a perfect loop has an end frame identical to its start, which is right for a self-playing ambient background and WRONG for scroll scrubbing, because start and end look the same and the page reads as frozen while the user scrolls. Scroll-driven footage needs directional movement via generate_video with an endImage (push-in/dolly is the most reliable, then reveal, pull-back, slow tilt); avoid orbits and any movement that returns to its origin. Client architectural renders are animated with img2vid, never AI-recreated. Human faces repeatedly trip moderation (E005), so crop the face out of frame (neck down, hands, product) and reserve faces for static image generation. Always climb the cost ladder: seedance-1-5-pro 480p draft to judge framing and movement, then promoteFrom to seedance-2.0 1080p only after approval (same prompt, frames and seed), then re-extract frames with a bumped cache-bust. seedance-2.0-mini does NOT respect endImage and Veo 3.1 Lite/Fast are inconclusive, so scrub only on Seedance 1.5 Pro/2.0 and check the last-frame SSIM QA. Video has no ZDR on OpenRouter: nothing sensitive in the frames. Prompts read like director notes with no hype words, and must reserve a calm dark region for the page copy with the subject on the opposite side. Generation is async via the morph-assets MCP (OpenRouter): a running job is polled with get_video (several ids at once), never by resending generate_video; library reads local history and spends no credits; media_tool extracts scrub frames and posters.",
+      "verifiedAgainst": "morph-assets MCP (generate_video, generate_loop_video, get_video, library, media_tool) over OpenRouter; models `bytedance/seedance-1-5-pro` and `bytedance/seedance-2.0`.",
       "provedBy": []
     },
     {
@@ -2371,7 +2371,7 @@
         "e2e": "#test-file-co-location",
         "test-budget": "#test-budget"
       },
-      "digest": "Vitest for unit tests, React Testing Library for component tests. Mock next/navigation with vi.mock. Test Server Actions with direct function calls. Use MSW for API mocking in component tests. Playwright for E2E tests against running app. Never test implementation details — test user behavior and output. Test budget per task: one test per postcondition plus one regression test per bug, more only with a one-line justification in the task; scenarios of the same behavior are rows of one it.each, never copied it() blocks; no test whose only assertion is a copy string (lint or publish-time validation instead); shared wrappers, MSW handlers and factories before new helpers; TDD for bugs and pure logic, component tests may come after the code.",
+      "digest": "Vitest for unit tests, React Testing Library for component tests. Mock next/navigation with vi.mock. Test Server Actions with direct function calls. Use MSW for API mocking in component tests. Playwright for E2E tests against running app. Never test implementation details — test user behavior and output. Test budget per task: one test per postcondition plus one regression test per bug, more only with a one-line justification in the task; scenarios of the same behavior are rows of one it.each, never copied it() blocks; no test whose only assertion is a copy string (lint or publish-time validation instead); shared wrappers, MSW handlers and factories before new helpers; bugs and pure logic get tests in any order — the implementer runs its own filter once, never red-green cycles nor production mutation.",
       "verifiedAgainst": "Vitest 3 + React Testing Library 16 + MSW 2.",
       "provedBy": []
     },
@@ -2689,8 +2689,8 @@
         "tools": "#mcp-providers-by-phase",
         "setup": "#mcp-availability-detection"
       },
-      "digest": "MCP tools extend Claude with external data and actions. Tools are synchronous request-response with typed inputSchema. Resources provide read-only data access. Prompts are reusable templates. Register MCP servers in .claude/settings.json. Prefer @context7 for live library docs. Test tools with MCP Inspector before integrating.",
-      "verifiedAgainst": "Claude Code MCP tooling — context7, Playwright; GitHub via `gh` CLI; Neon via `neonctl`.",
+      "digest": "MCP tools extend Claude with external data and actions. Tools are synchronous request-response with typed inputSchema. Resources provide read-only data access. Prompts are reusable templates. Register MCP servers in .claude/settings.json. Prefer @context7 for live library docs. Tool names follow where the server is configured: mcp__context7__query-docs from .mcp.json, mcp__plugin_context7_context7__query-docs from the plugin; a deferred tool loads via ToolSearch. Test tools with MCP Inspector before integrating.",
+      "verifiedAgainst": "Claude Code 2.1.282 MCP tooling — context7, Playwright (as plugin and as a project MCP server); GitHub via `gh` CLI; Neon via its MCP or `neonctl`.",
       "provedBy": []
     },
     {
@@ -2848,7 +2848,7 @@
         "not-worth": "#o-que-não-merece",
         "size": "#tamanho"
       },
-      "digest": "Comment only the WHY the code cannot show: an invariant the type does not express, an order that matters, an external quirk (third-party API, library bug with its link), a public API contract. Never process history: task, UC, ADR, FR, Gate, evaluator, spec.md and mockup belong in the commit message and decisions.md. Do not restate the code (a good name replaces the comment), do not describe the world outside the file (it goes stale), and turn claims about behavior into test assertions. Ceiling ~3 lines; longer needs a reason. The verify validators node (code-budget) warns with the count of added comment lines that cite process.",
+      "digest": "Default is NO comment: code explains itself through names, types and tests. Before commenting, rename, extract a function or named constant, encode the state in the type, or write a test; comment only what none of these can express: an invariant the type does not express, an order that matters, an external quirk (third-party API, library bug with its link), or the contract of a package published for consumers outside the repo. Never process history (task, UC, ADR, FR, Gate, evaluator, spec.md, mockup: commit message and decisions.md), never restate the code, no XML doc/JSDoc on application members that repeats the signature, no file headers, section banners, #region, commented-out code or loose TODOs, no claims about behavior (make them test assertions). One line is normal, ~3 is the ceiling; more than one comment line per ten code lines means the names are not doing the work. The verify validators node (code-budget) warns on added comments that cite process and on added comment density.",
       "verifiedAgainst": "C#, TypeScript e JavaScript (convenção de linguagem, sem pacote externo).",
       "provedBy": []
     }

package/framework/standards/ai-agents/context-providers.md

@@ -30,8 +30,7 @@ Preciso que o agente saiba X.
 Plano por fase (instruções + **allow-list de tools** conforme o estado do funil) **não** é caso de provider. É C# puro, montado antes de criar a requisição:
 
 ```csharp
-// O CÓDIGO decide o modo; o LLM só classifica. A allow-list de tools é a parte
-// que um provider não consegue dar: AIContext.Tools ACRESCENTA tools, não remove.
+// A allow-list não cabe num provider: AIContext.Tools ACRESCENTA tools, não remove.
 public sealed record OperatorPlan(string Instructions, IReadOnlyList<AITool> Tools);
 
 public static OperatorPlan PlanFor(FunnelStage stage) => stage switch
@@ -92,10 +91,8 @@ Use um `AIContextProvider` quando o agente precisa de **contexto dinâmico compu
 
 **Método a sobrescrever:**
 
-```csharp
-// ProvideAIContextAsync  → chamado ANTES do LLM (before-run hook) — injeta contexto
-// StoreAIContextAsync    → chamado APÓS o LLM (after-run hook) — persiste estado se necessário
-```
+- `ProvideAIContextAsync` → chamado ANTES do LLM (before-run hook) — injeta contexto
+- `StoreAIContextAsync` → chamado APÓS o LLM (after-run hook) — persiste estado se necessário (opcional)
 
 ### A invariante de instância — a mesma de `ai-agents-agent-session`
 
@@ -122,32 +119,33 @@ Consequência prática: **compaction só faz sentido com histórico local**. Com
 
 ## Exemplo C# — context provider que injeta data atual e perfil do tenant
 
+O bloco tem três partes: o provider, o registro do agente com o provider no DI (`Program.cs`) e o uso
+normal. `ITenantContext` é implementado via `IHttpContextAccessor` ou `AsyncLocal` para resolver o
+tenant em runtime, nunca registrado como instância estática. O contexto volta como instrução
+adicional, não como mensagem do usuário, e `StoreAIContextAsync` fica vazio porque o provider é
+stateless. No uso, o provider é invocado a cada `RunAsync`: o agente já sabe a data, o nome do tenant
+e o idioma, sem código extra no caller.
+
 ```csharp
 using Microsoft.Agents.AI;
 using Microsoft.Extensions.AI;
 
-// ── 1. Definir o provider ──
 public sealed class TenantContextProvider : AIContextProvider
 {
     private readonly ITenantService _tenantService;
     private readonly ITenantContext _tenantContext;
 
-    // ITenantContext deve ser implementado via IHttpContextAccessor ou AsyncLocal
-    // para resolver o tenant atual em runtime — não registre como instância estática.
-    // O AIAgent é singleton, então o provider também é singleton; o tenant corrente
-    // é lido de forma ambient (IHttpContextAccessor/AsyncLocal) a cada chamada.
+    // Singleton como o AIAgent: o tenant corrente é lido ambient a cada chamada, nunca guardado.
     public TenantContextProvider(ITenantService tenantService, ITenantContext tenantContext)
     {
         _tenantService = tenantService;
         _tenantContext = tenantContext;
     }
 
-    // Sobrescreva: injetado ANTES de cada chamada ao LLM
     protected override async ValueTask<AIContext> ProvideAIContextAsync(
         InvokingContext context,
         CancellationToken cancellationToken = default)
     {
-        // Tenant resolvido via serviço injetado (ambient context, ex: IHttpContextAccessor)
         var tenantId = _tenantContext.TenantId ?? "unknown";
         var tenant = await _tenantService.GetTenantAsync(tenantId, cancellationToken);
 
@@ -159,20 +157,16 @@ public sealed class TenantContextProvider : AIContextProvider
 
         return new AIContext
         {
-            // Injeta como instrução adicional — não como mensagem do usuário
             Instructions = instructions,
         };
     }
 
-    // Sobrescreva (opcional): chamado APÓS o LLM — use para persistir estado derivado da resposta
     protected override ValueTask StoreAIContextAsync(
         InvokedContext context,
         CancellationToken cancellationToken = default)
-        => ValueTask.CompletedTask; // stateless provider — nada a persistir
+        => ValueTask.CompletedTask;
 }
 
-// ── 2. Registrar o agente com o provider no DI ──
-// Program.cs
 builder.Services.AddSingleton<AIAgent>(sp =>
 {
     var registry      = sp.GetRequiredService<ModelRegistry>();
@@ -187,19 +181,15 @@ builder.Services.AddSingleton<AIAgent>(sp =>
         });
 });
 
-// ── Alternativa: pipeline de chat (compacta/injeta SÓ o request em voo) ──
-// using Microsoft.Extensions.AI;   // a extensão vive na assembly Microsoft.Agents.AI
-// IChatClient enriched = chatClient.AsBuilder()
-//     .UseAIContextProviders(new TenantContextProvider(tenantSvc, tenantContext))
-//     .Build();
-
-// ── 3. Uso normal — provider é invocado automaticamente a cada RunAsync ──
 AgentSession session = await agent.CreateSessionAsync();
 AgentResponse response = await agent.RunAsync("Quais são meus benefícios do plano?", session);
 Console.WriteLine(response.Text);
-// O agente já sabe a data, o nome do tenant e o idioma — sem código extra no caller
 ```
 
+**Alternativa: pipeline de chat**, que compacta/injeta **só** o request em voo: registre o provider
+com `.UseAIContextProviders(...)` no `ChatClientBuilder` (`chatClient.AsBuilder()`). O `using` é
+`Microsoft.Extensions.AI`, mas a extensão vive na assembly `Microsoft.Agents.AI`.
+
 ---
 
 ## Context Provider vs Tools vs RAG

package/framework/standards/ai-agents/durable-workflows-hitl.md

@@ -22,12 +22,11 @@ If neither applies, a plain workflow (or no workflow at all — see `ai-agents-s
 
 ## Human-in-the-Loop via `RequestPort`
 
-HITL is modeled with `RequestPort` — a special node in the workflow graph that pauses execution and waits for an external (human) response instead of processing automatically.
+HITL is modeled with `RequestPort` — a special node in the workflow graph that pauses execution and waits for an external (human) response instead of processing automatically. Its two type arguments are the request type the port sends out and the response type it expects back.
 
 ```csharp
 using Microsoft.Agents.AI.Workflows;
 
-// Request type the port sends out, response type it expects back.
 RequestPort<ApprovalRequest, bool> approvalPort =
     RequestPort.Create<ApprovalRequest, bool>("RefundApproval");
 
@@ -47,8 +46,7 @@ await foreach (WorkflowEvent evt in run.WatchStreamAsync())
     switch (evt)
     {
         case RequestInfoEvent requestEvt:
-            // Surface requestEvt.Request to a human (dashboard, email, Slack, ...).
-            // This is where execution pauses until an external answer arrives.
+            // Execution pauses here until the human's answer arrives (dashboard, email, Slack, ...).
             bool approved = await GetHumanDecisionAsync(requestEvt.Request);
             await run.SendResponseAsync(requestEvt.Request.CreateResponse(approved));
             break;
@@ -77,8 +75,14 @@ O caso do agente único é o que a casa realmente tem (MORPH_OS: billing, envio
 
 ### O ciclo, medido em `Microsoft.Extensions.AI` 10.9.0
 
+Quatro passos: (1) embrulhe a tool — `ApprovalRequiredAIFunction : DelegatingAIFunction`; (2) o run
+**termina** pedindo aprovação — não bloqueia, não espera —, e `ToolApprovalRequestContent.ToolCall` é
+um `ToolCallContent` (medido; **não** é `FunctionCallContent`, que aparece em
+`ToolAutoApprovalRuleContext`); (3) responda **na mesma sessão**, com
+`CreateResponse(bool approved, string? reason)`; (4) **repita** o passo 2 até não restar pendência —
+uma volta pode pedir **outra** tool.
+
 ```csharp
-// 1. Embrulhe a tool. ApprovalRequiredAIFunction : DelegatingAIFunction.
 AIFunction charge = AIFunctionFactory.Create(BillingTools.ChargeCustomer);
 AITool guarded = new ApprovalRequiredAIFunction(charge);
 
@@ -88,22 +92,16 @@ AIAgent agent = registry.GetChatClient("text-default")
 AgentSession session = await agent.CreateSessionAsync();
 AgentResponse response = await agent.RunAsync("Cobre o cliente 42.", session);
 
-// 2. O run TERMINA pedindo aprovação — não bloqueia, não espera.
-//    ToolApprovalRequestContent.ToolCall é um ToolCallContent (medido; NÃO é
-//    FunctionCallContent — este último aparece em ToolAutoApprovalRuleContext).
 var pending = response.Messages
     .SelectMany(m => m.Contents)
     .OfType<ToolApprovalRequestContent>()
     .ToList();
 
-// 3. Responda NA MESMA SESSÃO. CreateResponse(bool approved, string? reason).
 if (pending.Count > 0)
 {
     var approvals = pending.Select(r => (AIContent)r.CreateResponse(approved: true, reason: "aprovado por lucas@…"));
     response = await agent.RunAsync(new ChatMessage(ChatRole.User, [.. approvals]), session);
 }
-
-// 4. REPITA o passo 2 até não restar pendência. Uma volta pode pedir OUTRA tool.
 ```
 
 **Os quatro pontos que erram na primeira tentativa:**
@@ -157,10 +155,11 @@ Checkpointing is part of the **base, GA** `Microsoft.Agents.AI.Workflows` namesp
 | `CheckpointManager.CreateJson(new FileSystemJsonCheckpointStore(dir))` | Local disk, survives process restart | Single-instance VPS deployments — no Azure, no preview package |
 | Custom `ICheckpointStore` implementation | Whatever backend you implement it against | **Recommended for production** — implement against the project's own Neon Postgres table, matching the ownership model already used by `ai-agents-rag-custom-pgvector` |
 
+Local-disk durability, with no Azure dependency:
+
 ```csharp
 using Microsoft.Agents.AI.Workflows;
 
-// Local-disk durability — no Azure dependency:
 var checkpointFolder = Directory.CreateDirectory("./checkpoints");
 CheckpointManager checkpointManager = CheckpointManager.CreateJson(
     new FileSystemJsonCheckpointStore(checkpointFolder));
@@ -171,13 +170,12 @@ await foreach (WorkflowEvent evt in run.WatchStreamAsync())
     if (evt is SuperStepCompletedEvent stepEvt)
     {
         CheckpointInfo? checkpoint = stepEvt.CompletionInfo?.Checkpoint;
-        // Persist checkpoint.CheckpointId alongside the business record
-        // (e.g. the refund request row) so it can be resumed after a restart.
+        // Persist checkpoint.CheckpointId with the business record (e.g. the refund row) to resume after a restart.
     }
 }
 ```
 
-Resuming after a restart — rehydrate into a **new** run instance from the last known checkpoint:
+Resuming after a restart — rehydrate into a **new** run instance from the last known checkpoint. A pending `RequestPort` request is re-emitted as a `RequestInfoEvent`, so the paused approval survives the restart:
 
 ```csharp
 StreamingRun resumedRun = await InProcessExecution.ResumeStreamingAsync(
@@ -185,8 +183,6 @@ StreamingRun resumedRun = await InProcessExecution.ResumeStreamingAsync(
 
 await foreach (WorkflowEvent evt in resumedRun.WatchStreamAsync())
 {
-    // A pending RequestPort request is re-emitted here as a RequestInfoEvent —
-    // the paused approval survives the restart.
     if (evt is RequestInfoEvent requestEvt) { /* re-surface to the human */ }
 }
 ```
@@ -211,14 +207,12 @@ internal sealed class RefundAnalyzerExecutor() : Executor("RefundAnalyzer")
 
 ### `ICheckpointStore` — Neon/Postgres-backed (recommended production pattern)
 
-Implementing `ICheckpointStore` against the project's own Postgres database keeps checkpoint durability inside the same infrastructure the rest of the project already trusts (see `infrastructure-neon-setup`), instead of introducing a new storage dependency:
+Implementing `ICheckpointStore` against the project's own Postgres database keeps checkpoint durability inside the same infrastructure the rest of the project already trusts (see `infrastructure-neon-setup`), instead of introducing a new storage dependency. The store persists and retrieves checkpoint blobs in a `workflow_checkpoints` table (`workflow_id`, `checkpoint_id`, `payload` jsonb/bytea, `created_at`), implemented per the `ICheckpointStore` contract in the `Microsoft.Agents.AI.Workflows` docs:
 
 ```csharp
 public sealed class PostgresCheckpointStore(NpgsqlDataSource dataSource) : ICheckpointStore
 {
-    // Persist/retrieve checkpoint blobs in a workflow_checkpoints table
-    // (workflow_id, checkpoint_id, payload jsonb/bytea, created_at).
-    // Implement per the ICheckpointStore contract — see Microsoft.Agents.AI.Workflows docs.
+    // ICheckpointStore members over workflow_checkpoints — elided.
 }
 ```