@orchestrator-claude/definitions 3.37.0 → 3.37.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orchestrator-claude/definitions",
-  "version": "3.37.0",
+  "version": "3.37.1",
   "description": "Built-in definitions (agents, skills, hooks, workflows, KB seeds) for the Orchestrator ecosystem",
   "type": "module",
   "main": "dist/index.js",
@@ -29,8 +29,9 @@
     "hooks-settings-template.json"
   ],
   "scripts": {
-    "build": "tsc && npm run bundle-hooks && npm run generate-manifest",
+    "build": "tsc && npm run bundle-hooks && npm run generate-hooks-matcher && npm run generate-manifest",
     "bundle-hooks": "npx tsx src/scripts/bundle-hooks.ts",
+    "generate-hooks-matcher": "npx tsx src/scripts/generate-hooks-matcher.ts",
     "generate-manifest": "npx tsx src/scripts/generate-manifest.ts",
     "test": "vitest run",
     "test:watch": "vitest",
@@ -40,6 +41,7 @@
   },
   "dependencies": {
     "@orchestrator-claude/mcp-server": "^3.32.2",
+    "@orchestrator-claude/project-root-resolver": "*",
     "commander": "^14.0.0",
     "chalk": "^5.4.0"
   },

package/skills/checkpoint-protocol/SKILL.md

@@ -6,10 +6,16 @@ description: When and how to create workflow checkpoints. Use after completing t
 ## Checkpoint Creation Protocol
 
 ### Who follows this (TD-171)
-This protocol applies to the `implementer` **and all engineer-type committing agents** — any agent whose tool list holds `mcp__orchestrator-tools__createCheckpoint`: as of S290 that is `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`. Engineer-types commit critical artifacts **outside `src/`** (IaC, pipelines, ETL, decks), so they need per-change git revertability too — "only `src/` commits matter" is wrong.
+This protocol applies to the `implementer` **and all engineer-type committing agents** — any agent whose tool list holds `mcp__orchestrator-tools__createCheckpoint`: as of S290 that is `implementer`, `azure-devops-engineer`, `presentation-engineer`, `operational-artifact-builder`, `cicd-platform-engineer`, `python-data-engineer`, `frontend-engineer`. Engineer-types commit critical artifacts **outside `src/`** (IaC, pipelines, ETL, decks), so they need per-change git revertability too — "only `src/` commits matter" is wrong. **That revertability comes from their own local commits, not from `createCheckpoint`** (see "Checkpoint vs git" below — corrected S444).
 
 ### Checkpoint vs git (read first)
-- `createCheckpoint` is a **PostgreSQL state snapshot** (RFC-012), **INDEPENDENT of git** — you do NOT need to commit before calling it.
+
+> **CORRECTED S444 (TD-257).** This section previously read *"`createCheckpoint` is a PostgreSQL state snapshot (RFC-012), **INDEPENDENT of git**"*. **That was false, and it was measured false**, not argued: this repo carries **6 tags `orchestrator/*`**, each pointing at a real commit whose subject is `[orchestrator] <phase>: <the description a sub-agent typed>`. Calling the tool writes to git.
+
+- `createCheckpoint` **does touch git**: `CheckpointManager.create()` → `GitOperations.createCheckpointCommit()` makes a **real commit**, and `createCheckpointTag()` makes a **real tag** `orchestrator/<phase>/<ISO-timestamp>`. The commit message is `[orchestrator] <phase>: <your description>` — **the text you pass becomes a permanent git commit message**. Write it as if a human will read it in `git log` in a year, because they will.
+- You still do **not** need to commit before calling it — it commits what is already staged (it is not passed a file list, so it does not stage anything itself).
+- **It cannot restore anything, and nothing else can either.** Measured S444: `CheckpointManager.restore()` has no production caller, no REST route (`rg "restore" src/presentation/api/` → 0), reads a `commitHash` that the repository writes hardcoded as `''` (`RepositoryFactory.ts:165`), and ends in `throw new Error('Checkpoint revert not implemented for PostgreSQL')`. Four independent breaks. Treat a checkpoint as an **audit marker**, never as a safety net you can fall back on.
+- **Your real revertability is ordinary git** — the local commits described below, on the feature branch the orchestrator prepared. Not the checkpoint.
 - **Local commit YES, push NO (TD-171):** you MAY make local git commits for granular revertability, on the **feature branch the orchestrator prepared before dispatching you** (branch-before-dispatch, `/orchestrator` §2c.0). You MUST NEVER `git push` / `git merge` / `gh pr merge` — push/merge is orchestrator-owned (enforced by `agent-git-guard`, TD-169). Return your work in your report; the orchestrator pushes after its independent assert.
 
 ### When to Create
@@ -28,7 +34,16 @@ This protocol applies to the `implementer` **and all engineer-type committing ag
 - "Tasks T-001 to T-005: auth controller + tests"
 - "Pre-refactor checkpoint: before DI migration"
 
-### Recovery
-If you need to check previous checkpoints:
+### Recovery — read the limit before you rely on it
+
+`listCheckpoints` is **display only**. Measured S444: its handler does exactly `JSON.stringify(result, null, 2)` into an MCP text block (`packages/mcp-server/src/handlers/checkpoints-handlers.ts:55-66`) — zero side effects, no restore. There is **no recovery path in this system**; see "Checkpoint vs git" above.
+
+To *inspect* what was checkpointed:
 1. Call ToolSearch("select:mcp__orchestrator-tools__listCheckpoints")
 2. Call listCheckpoints with: { workflowId }
+
+Two things to expect, both measured S444 and neither yet fixed — do not read an empty list as "nothing happened":
+- `GET /api/v1/checkpoints` for this project returned `[]` (HTTP 200, with a positive control returning 200 + real data on the same token), while 6 `orchestrator/*` tags exist in git. **The git side and the database side disagree**, and the database side is the one that is empty.
+- The rows that do get written carry `commit_sha = ''` (`RepositoryFactory.ts:165`), so even a populated list would not point at a recoverable commit.
+
+**To actually recover work, use git directly** (`git log`, `git reflog`, `git show`) against your own local commits.

package/skills/ciclo-lane-dispatch/SKILL.md

@@ -41,6 +41,27 @@ system · repo-alvo · escopo (quais US) · ator-alvo. O **ator sai do PRD com l
 memória. `[M]` Na S420 cinco das seis correções ao orquestrador foram da mesma família: afirmação
 sobre artefato externo sem probe — o Invariante 6 escrito e não aplicado.
 
+**1.3.1 O `escopo` tem procedência, e ela viaja no prompt — não na tua cabeça.** `[M]` (S475) O
+insumo *quais US* não é servido pelo PRD: é servido pela **projeção** (a fase 1b da lane 1). Uma
+projeção só vale se for re-derivável, e o contrato da lane 1 exige três itens juntos no registro
+dela — commit, `sha256` da fonte e o pedido literal (`J4`, §5 do contrato). Antes de despachar:
+
+```bash
+# 1. o sha256 que a projecao DECLARA ter derivado (Anexo A.1 dela)
+grep -A1 'sha256.*fonte' <projecao>
+# 2. o sha256 do PRD hoje
+sha256sum <prd>
+```
+
+Se **não** baterem, **não despache**: mande re-derivar (é trabalho de fase 1b, não de lane 2) —
+e re-derivar, nunca editar à mão, porque editar produz documento sincronizado e destrói a chance
+de rodar o teste de derivabilidade. `[M]` Uma projeção desta casa ficou 330 linhas atrás da fonte
+e nada no despacho dizia isso; o modo de falha está medido e é o pior tipo: **não falha limpo,
+preenche** (cláusula *Marca `client` proibida sem registro*, no §2 abaixo, e S469:100).
+
+> Referência por conteúdo e não por número de linha, de propósito: esta própria inserção deslocou
+> em +21 as linhas que a versão anterior citava como `:57-59`.
+
 **1.4 Se for run de medição, retire a referência E prove que ela não cobre o alvo.** `[M]` (S420)
 Antes de escrever o prompt, `grep -c` no artefato de referência pelo escopo pretendido. Se ele já
 cobre o alvo, o run mede cópia, não transferência. Quando a referência cobre todo o espaço de
@@ -57,6 +78,9 @@ Entregue os cinco insumos e mais estas cláusulas:
 - **Marca `client` proibida sem registro.** Se tu não passar a conversa do cliente, a marca não
   existe para o agente e o fato vira lacuna. Sem isso ele marca `client` "porque faz sentido", que é
   palpite com crachá.
+- **Procedência do escopo, em três campos.** Passe o **caminho da projeção**, o **`sha256` que ela
+  declara** e o **caminho do PRD**. Sem os três o agente não tem como conferir vintage, e a Fase 0
+  dele manda parar e devolver — corretamente, porque insumo sem procedência é palpite com crachá.
 - **Segure o commit** (§14.6, publicar-antes-de-corrigir): o agente grava e **não** commita; tu
   commita depois de ler o relatório.
 - **Cláusula de escape.** `[M]` (S420) *"Se o protocolo te obrigar a abrir o arquivo vedado, não

package/skills/fase-1b-projecao/SKILL.md

@@ -0,0 +1,146 @@
+---
+name: fase-1b-projecao
+description: Use ANTES de derivar um PRD em épicos e user stories — a fase 1b da lane 1, que produz o insumo `escopo (quais US)` que a lane 2A consome. Triggers on "derivar o PRD em épicos", "quebrar o PRD em user stories", "re-derivar a projeção", "o par PRD/projeção está dessincronizado", "fechar J4". Carrega o procedimento de re-derivação, o pedido literal canônico, o isolamento que torna o teste de derivabilidade possível, e — o essencial — o que esta fase NÃO pode prometer. Do NOT use para escrever o PRD (isso é autoria, não tem procedimento) nem para despachar a lane 2A (use ciclo-lane-dispatch).
+---
+
+# Fase 1b — a projeção do PRD em épicos e user stories
+
+A lane 1 entrega um **par**: o PRD constitucional e a **projeção** dele. Esta skill cobre a
+segunda peça. `[U]` Ela é **fase da lane 1**, não lane nova — o contrato de saída já a contratou
+em `J1` (decomposição rastreável, cada item com referente citado) e `J2` (critério de aceite por
+item), cita o documento, mede os itens e carrega o `sha256` dele.
+
+Marcas: `[M]` medido · `[S]` síntese nossa · `[U]` decidido pelo usuário · `[L]` lacuna aberta.
+
+---
+
+## 1 · O que esta fase NÃO promete — leia antes de tudo
+
+`[M]` **Granularidade não é propriedade do PRD.** Medido na S475 com réplica exata — mesma fonte,
+mesmo pedido, mesma árvore, **zero variáveis**: 55 stories numa execução e **78** na outra, +42%.
+Quatro derivações do mesmo PRD deram **33 · 66 · 55 · 78** stories e **8 · 12 · 11 · 15** épicos.
+
+Consequências operacionais, e nenhuma se conserta melhorando o prompt:
+
+1. **Não prometa um número.** Se alguém a jusante precisa de granularidade fixa, ela vem de um
+   **corte humano**, não de re-derivar até sair o número desejado — re-derivar até gostar do
+   resultado é escolher a amostra depois de ver os dados.
+2. **Divergência de contagem entre duas projeções não é sinal de nada.** Está dentro do ruído.
+3. **O que É estável** (medido em 3 de 3 braços independentes): o **ator** sai como posição do
+   fluxo e nunca como cargo · a **espinha** cai das capacidades que o próprio PRD enumera · a
+   **cobertura** por referente `§x.y`.
+
+---
+
+## 2 · O procedimento — quatro passos, e o passo 4 é o que quase ninguém roda
+
+1. **Fixe a fonte antes de derivar.** `git rev-parse HEAD` e `sha256sum` do PRD; registre os dois.
+   Fonte não fixada torna a comparação seguinte impossível de interpretar.
+2. **Derive, guardando o pedido literal.** Escreva o pedido **antes** do despacho e congele-o.
+   `[M]` É assim que o item se perde: quem deriva primeiro e pensa em guardar depois não guarda.
+3. **Compare com a versão anterior.** Divergência é **sinal, não estado**.
+4. **Decida de que lado o documento cai.** Se a derivação não for reproduzível a partir da mesma
+   fonte, ele não é projeção — é fonte autoral, e passa a exigir **backup** como defesa em vez de
+   reconstrução.
+
+> `[M]` **O passo 4 é executável mais vezes do que parece.** Se a versão anterior declara o
+> `sha256` da fonte de que derivou, **a fonte velha está em git**: `git show <commit>:<PRD>` a
+> devolve byte a byte. Não presuma que só resta a fonte de hoje — o controle do experimento
+> costuma já existir.
+
+---
+
+## 3 · O pedido literal — e o que **não** pode entrar nele
+
+O pedido é curto de propósito. Fixe **forma**, nunca **conteúdo**:
+
+```
+Transforme o PRD em épicos e user stories.
+
+Fonte única: <PRD>. Não consulte nenhum outro documento deste repositório e não procure
+decomposições anteriores; se encontrar uma, não a abra.
+
+Escreva a saída em <SAIDA>, markdown único, com esta estrutura:
+
+- épico: heading `## EP-NN — <título>`
+- story: heading `### US-NN.N — <título>`, aninhada no épico a que pertence
+- cada story traz: a formulação "como … / quero … / para …", o critério de aceite, e o
+  referente `§x.y` da seção do PRD de onde ela cai
+
+Quantos épicos e quantas stories saem é resultado, não meta.
+```
+
+`[S]` **O que fica de fora, e é a decisão que faz o teste valer.** Regras de conteúdo que a
+projeção anterior declarava — *ator é posição e não cargo*, *nenhuma story nomeia mecanismo*,
+*nada por inferência* — **não entram**, mesmo citando o PRD. Se estão mesmo na fonte, o derivador
+chega nelas sozinho, e chegar **é** a evidência de derivabilidade. Colocá-las no pedido faz o
+passo 4 medir obediência ao pedido em vez de derivabilidade da fonte: verde por vacuidade.
+
+`[M]` Funciona: com o pedido acima, três braços independentes produziram **zero** cargos e
+nomearam a espinha correta sem instrução.
+
+`[L]` **Contaminação residual, declarada:** fixar os headings `## EP-NN` / `### US-NN.N` já
+entrega parte da forma escolhida pela versão anterior. Mantida porque é o que os comandos do
+contrato medem; não há como remover sem perder a comparabilidade.
+
+---
+
+## 4 · Executor e isolamento
+
+**Executor: `general-purpose`.** `[S]` Não use `specifier` nem `task-generator` — os dois têm
+formato de saída próprio no corpo (spec, tasks atômicas) que empurra a derivação para um molde
+que não é do PRD, contaminando o eixo que se quer medir. Agente **sem** corpo calibrado é a
+escolha certa aqui, e é a razão de esta fase ser skill e não agente.
+
+**Isolamento por construção, não por instrução.** `[M]` Instruir "não olhe a projeção anterior"
+depende do agente obedecer. Derivar numa **worktree de um commit anterior à promoção** dela não
+depende de nada: o arquivo não existe lá.
+
+```bash
+git worktree add --detach <tmp>/wt b4b1eba4          # commit anterior a promocao
+git show HEAD:<PRD> > <tmp>/wt/<PRD>                 # so a fonte e trocada
+git grep -l 'EP-0[1-9]\|US-0[1-9]\.' b4b1eba4 -- ':!*agent-memory*'   # esperado: vazio
+```
+
+O último comando é o que transforma "isolado" em **medido**. Rode-o e cole a saída.
+
+---
+
+## 5 · O que medir na volta — e o instrumento certo
+
+Use os comandos que o contrato registra, nunca os inventados na hora:
+
+```bash
+grep -cE '^## EP-'  <projecao>      # epicos
+grep -cE '^### US-' <projecao>      # stories
+grep -oE '§[0-9]+(\.[0-9]+)*' <projecao> | sort -u   # cobertura por referente
+```
+
+> `[M]` **Para medir se o delta da fonte atravessou, olhe o ITEM que a emenda tocou — nunca o
+> agregado.** Medido S475: contagem e sobreposição de referentes não distinguem troca de fonte de
+> ruído (réplica pura dá 95%/88%; trocar a fonte dá 85–91% — dentro do ruído). O mesmo delta
+> aparece **limpo e reprodutível** no item específico: a seção emendada saiu como *item aberto* na
+> fonte velha e como *requisito* nas **duas** réplicas da fonte nova. O agregado afoga o sinal.
+
+---
+
+## 6 · Fechar `J4` — três itens, juntos
+
+> Uma projeção só é projeção se vier com o que a torna re-derivável: **commit** da fonte,
+> **`sha256`** da fonte, e o **pedido literal**. Faltando qualquer um, o artefato não é projeção —
+> é **segunda fonte**, e passa a exigir backup porque não há de onde reconstruir.
+
+`[M]` O item que se perde é sempre o terceiro. Escreva o pedido antes do despacho e o dispatch
+**vira** o registro; guardá-lo depois depende de lembrar, e a primeira execução desta fase nesta
+casa não lembrou.
+
+---
+
+## 7 · Erro de classe a evitar
+
+`[M]` **Quando um insumo "falta", meça no artefato que deveria servi-lo, não no que está à mão.**
+O insumo *quais US* nunca seria servido pelo PRD — é servido pela projeção. `grep 'US-'` na fonte
+dá zero, e o zero é real enquanto a conclusão é falsa.
+
+`[M]` **Re-derivar, nunca editar à mão.** Editar as peças dessincronizadas produz um documento
+sincronizado e **destrói a única chance de rodar o passo 4**.

package/skills/orchestrator/SKILL.md

@@ -114,7 +114,8 @@ To prevent recurrence, append the following **commit policy block** to every dis
 
 ```
 [Commit Policy]
-- createCheckpoint (mcp__orchestrator-tools__createCheckpoint) is a PostgreSQL state snapshot per RFC-012. It is INDEPENDENT of git. You do NOT need to commit before calling it. Calling createCheckpoint with no uncommitted changes is the normal path. createCheckpoint may also trigger an auto-commit hook on the orchestrator side — that hook's commit message is NOT authoritative for phase attribution (hard rule (s) S194/S195: hook reads currentPhase post-advance, drifts one phase ahead). Trust explicit authored commits (`feat|fix|refactor|docs(sN): subject`) for phase attribution in audit/blame archaeology.
+- createCheckpoint (mcp__orchestrator-tools__createCheckpoint) WRITES TO GIT. Corrected S444 (TD-257) — this line used to say it was "INDEPENDENT of git", and that was measured false: calling it runs CheckpointManager.create() -> GitOperations.createCheckpointCommit() (a real commit, message `[orchestrator] <phase>: <your description>`) plus createCheckpointTag() (a real tag `orchestrator/<phase>/<ISO-timestamp>`). Evidence: 6 such tags exist in this repo, each on a commit carrying the description a sub-agent typed. CONSEQUENCE FOR YOU: the description you pass becomes a permanent public git commit message — write it accordingly. You still do NOT need to commit before calling it (it commits what is already staged and stages nothing itself), so calling it with a clean tree is the normal path. It CANNOT restore anything: restore() has no production caller, no REST route, and the stored commit_sha is hardcoded to '' — a checkpoint is an audit marker, never a safety net.
+- SEPARATE MECHANISM, do not confuse: an unattended auto-commit hook (subagent-stop -> createCheckpointIfNeeded) has historically committed on its own, NOT triggered by your createCheckpoint call. Its commit message is NOT authoritative for phase attribution (hard rule (s) S194/S195: it reads currentPhase post-advance and drifts one phase ahead). Measured S444 under TD-257: 212 such commits, 68% capturing only machine noise, one (`01c28adf`) deleting 1627 lines of production code under the message "Auto-checkpoint after tasks phase". Trust explicit authored commits (`feat|fix|refactor|docs(sN): subject`) for phase attribution in audit/blame archaeology — never the auto-checkpoint label.
 - Commit policy for this dispatch: <one of>
     a) "DO NOT commit — orchestrator owns the closure commit at review gate."
     b) "Local commit per-phase is OK (granular revertability) using prefix `<feat|fix|refactor>(s<N>): <subject>` — confirm prefix before commit. You are on a dedicated feature branch (the orchestrator branched before dispatching you, §2c.0); commit LOCALLY only." (use when implement/framework/operational/deliver phase exceeds 80k tokens or spans multiple sub-fases)
@@ -124,7 +125,7 @@ To prevent recurrence, append the following **commit policy block** to every dis
 
 Substitute `<CURRENT_SESSION>` with the active session number (e.g., `s195`) and pick **exactly one** of (a) or (b) — never leave both options visible. The block goes **after** `[Task]` and **before** the artifactStore instruction.
 
-If the orchestrator (main) wants to own all commits, prefer option (a) + call `createCheckpoint` itself after the phase completes — do NOT delegate that call to the dispatched agent.
+If the orchestrator (main) wants to own all commits, prefer option (a) + call `createCheckpoint` itself after the phase completes — do NOT delegate that call to the dispatched agent. **Know what that call does before making it (corrected S444):** `createCheckpoint` is not a passive record — it creates a real commit *and* a real tag. "Owning all commits" therefore means owning this one too; if the working tree holds unrelated dirt, that dirt is what gets captured under your description. Check `git status` first.
 
 #### 2c.2 Verify-Before-Assert dispatch addenda (TD-S192-003)
 
@@ -154,7 +155,12 @@ The block goes **after** `[Task]` and **before** `[Commit Policy]`. It applies t
 
 ### 2d. Gate Check
 
-After each sub-agent completes, present the artifact summary and ask for approval:
+Two things travel together here and they are **not** the same (identity MUST 2 and 3, split in S478):
+
+- **the guarantee (MUST 2)** — no phase advances without a decision **recorded and attributed**. Never auto-approve.
+- **the instrument (MUST 3)** — `AskUserQuestion` by default; a project MAY declare another decision channel in its Charter. Swapping the instrument does not relax the guarantee.
+
+Default instrument — after each sub-agent completes, present the artifact summary and ask for approval:
 
 ```
 AskUserQuestion({
@@ -163,6 +169,8 @@ AskUserQuestion({
 })
 ```
 
+If this project declares a **delegated** channel instead (see `project-guidelines/technical/GATE-DELEGAVEL-PROPOSTA-S477.md` — proposed, not implemented), then the approver may be an **agent** acting for an **absent** human, and the record MUST say so: who approved, under which delegation, when. Read the answer from a **file**, never from the channel's screen (S476). Never let a timeout fall through to "proceed alone" — that is auto-approval wearing a delegation.
+
 - **Approve** → call `advancePhase`, dispatch next phase agent.
 - **Request changes** → re-dispatch same sub-agent with the user's feedback.
 - **Abort** → call `completeWorkflow` with `cancelled` status.

package/skills/workflow-coordination/SKILL.md

@@ -25,7 +25,7 @@ Note: ToolSearch results are cached — you only need to fetch each tool once pe
 The **main conversation is the orchestrator**. There is no orchestrator sub-agent.
 
 - Phase sub-agents (specifier, planner, implementer, etc.) are dispatched via `Agent(subagent_type: "...")` directly from the main conversation
-- Gates between phases use `AskUserQuestion` — never auto-approve
+- Gates between phases: the **guarantee** is a recorded decision by an authorized party, never auto-approve; the **instrument** is `AskUserQuestion` unless the project Charter declares another decision channel (identity MUST 2 and 3, split in S478)
 - The `/orchestrator` skill is the universal entry point
 
 ### Deterministic Hooks (ADR-013)
@@ -41,7 +41,7 @@ Orchestration governance is enforced by hooks, not by prompt instructions:
 | `prompt-orchestrator` | On user prompt Submit | Injects workflow hints |
 
 ### Phase Advancement
-1. Present artifact summary to user via AskUserQuestion
+1. Present the artifact summary and obtain a decision — via `AskUserQuestion`, or via the project's declared channel if it has one. Either way the decision must be **recorded and attributed** before advancing (identity MUST 2)
 2. If user approves: call advancePhase
 3. If user requests changes: re-dispatch the same sub-agent with feedback
 4. The gate-guardian hook provides an additional safety check
@@ -61,7 +61,7 @@ Orchestration governance is enforced by hooks, not by prompt instructions:
 - SPECIFY: spec.md exists in MinIO, has required sections
 - PLAN: plan.md exists, references spec, has architecture section
 - TASKS: tasks.md exists, tasks are atomic, has acceptance criteria
-- IMPLEMENT: requires human approval via AskUserQuestion
+- IMPLEMENT: requires an approval recorded by an authorized party — via `AskUserQuestion` by default. If the project delegates the gate, the record must name the approver and the delegation in force; a delegated approval is **not** a human approval and must not be written as one (identity MUST 2)
 
 ### Observability
 Hooks automatically track agent invocations via SubagentStart/SubagentStop events.