From 6f147536cfb778b74400a8549a6cbb55bd751576 Mon Sep 17 00:00:00 2001 From: Sawyer Date: Fri, 18 Sep 2026 12:19:03 -0700 Subject: [PATCH] docs: drop mentions of the deleted agent-directory and agent-runtime packages (CL-8587) --- apps/web/src/query-client.ts | 8 +++--- docs/agent-definition-status-lifecycle.md | 34 ----------------------- docs/workflow-definition-projection.md | 15 +++++----- 3 files changed, 12 insertions(+), 45 deletions(-) delete mode 100644 docs/agent-definition-status-lifecycle.md diff --git a/apps/web/src/query-client.ts b/apps/web/src/query-client.ts index 029d41058..eb8077de1 100644 --- a/apps/web/src/query-client.ts +++ b/apps/web/src/query-client.ts @@ -92,10 +92,10 @@ export const tenantKeys = { routineRunHistories: (tenantId: string) => ["tenant", tenantId, "routine-run-histories"] as const, definitions: (tenantId: string) => ["tenant", tenantId, "definitions"] as const, agentDirectory: (tenantId: string) => ["tenant", tenantId, "agents", "directory"] as const, - /** The sidebar's unified list of agent-DM candidates: own + ancestor - * definitions (see `@corbits/agent-directory`'s `listVisibleAgentDefinitions`). - * Kept apart from `agentDirectory` above, which is a different surface's - * own key. */ + /** The sidebar's unified list of agent-DM candidates, backed by the + * stock `GET /workflows/definitions` listing (see `listAgentDefinitions` + * in `agents-api.ts`). Kept apart from `agentDirectory` above, which is + * a different surface's own key. */ visibleAgents: (tenantId: string) => ["tenant", tenantId, "agents", "visible"] as const, assets: (tenantId: string) => ["tenant", tenantId, "assets"] as const, artifacts: (tenantId: string) => ["tenant", tenantId, "artifacts"] as const, diff --git a/docs/agent-definition-status-lifecycle.md b/docs/agent-definition-status-lifecycle.md deleted file mode 100644 index fa7be6e14..000000000 --- a/docs/agent-definition-status-lifecycle.md +++ /dev/null @@ -1,34 +0,0 @@ -# Agent definition status lifecycle - -Notes on `@corbits/agent-directory`'s `routes.ts`, `PUT /:definitionId/status`. - -## What it does - -Archive and restore is the whole lifecycle a person controls from the agent -detail page. `stopped` drops a definition out of every launchable listing -while leaving the row, its asset, and its git history untouched — which is -what makes the same route, with `deployed`, a restore rather than a -re-create. - -## The invariant this route relies on - -Two other writers of `workflow_definition.status` exist in this build: - -1. Row creation. `ensureWorkflowDefinitionForAsset` inserts with the column - default (`deployed`) under `onConflictDoNothing` on `(assetId, - wireHash)`, so re-deploying the same definition body over an archived - row is a no-op and can never silently un-archive it. Editing an agent - through this package's own routes only repopulates the asset and never - re-projects a definition row at all. -2. `apps/hub`'s `undeployAgentDefinition`, which writes `stopped` — the - same direction as archiving, so the two can't fight. - -## A known hole - -The one way an archived agent reappears as launchable is a deploy of a -changed body over the same asset: a new `wireHash` misses the unique -constraint and inserts a second definition row, `deployed` by default, -beside the archived one. Nothing in this build takes that path for a -hand-authored agent — only `createAgentDefinitionCore` and Interchange's own -selector deploys call the ensure — but it's a real hole in the -status-as-lifecycle model, not a hypothetical one. diff --git a/docs/workflow-definition-projection.md b/docs/workflow-definition-projection.md index 375be6c53..54d14fb8d 100644 --- a/docs/workflow-definition-projection.md +++ b/docs/workflow-definition-projection.md @@ -25,10 +25,11 @@ the other's parsing. ## Why multi-step definitions are rejected -The launch target (`@corbits/agent-runtime`'s `AgentRuntimeConfig`) renders -exactly one `systemPrompt` into one mailbox-triggered turn — it has no -notion of step order. Reading past `stepOrder[0]` would silently drop every -later step's behavior rather than run it, so `MultiStepFoldUnsupportedError` -is thrown instead. Genuine multi-step launch needs a different deploy front -(Interchange's native workflow-run trigger, `@intx/workflow-host`'s DAG -supervisor) than this module provides. +The launch target (the bundled Myra-style deploy in +`apps/web/src/agent-deploy.ts`) renders exactly one `systemPrompt` into one +mailbox-triggered turn — it has no notion of step order. Reading past +`stepOrder[0]` would silently drop every later step's behavior rather than +run it, so `MultiStepFoldUnsupportedError` is thrown instead. Genuine +multi-step launch needs a different deploy front (Interchange's native +workflow-run trigger, `@intx/workflow-host`'s DAG supervisor) than this +module provides.