@desplega.ai/agent-swarm 1.173.0 → 2.0.0

package/templates/skills/email-domain-health/content.md

@@ -0,0 +1,131 @@
+# Email Domain Health
+
+Build a monitor that tells a person, every working day, whether mail from their
+domains authenticates, lands, and stays off blocklists. It has four parts: one
+saved script (checks + test send), a Swarm App with run history, one or two
+schedules, and an alert that fires only when something gets worse.
+
+This skill decides **what** to build. The mechanics live in other skills; read
+them, do not re-derive them:
+
+- [[swarm-scripts]]: authoring, `script-upsert`, scope, connections, secrets.
+- [[apps]]: models, named queries, pages, row writes.
+- [[scheduling]]: `targetType: "script"` schedules, cron and timezone.
+- [[composio-gmail]] (or the user's own mail integration): the test send and
+  the bounce search.
+
+Full design notes and pitfalls: the "Email domain health" playbook on the docs
+site.
+
+## 1. Ask for requirements first
+
+Ask before building (one batched question, see [[ask-user]]). Do not guess any
+of these; a wrong selector or From address makes every later check wrong.
+
+| Ask | Why it matters |
+|---|---|
+| Domains to monitor, and which one is the envelope/bounce domain | One check set per domain; SPF is judged on the envelope domain. |
+| Sending providers per domain (Google Workspace, Microsoft 365, an ESP such as Resend, SES, Postmark) and each DKIM selector | DKIM is looked up at `<selector>._domainkey.<domain>`; there is no way to list selectors. |
+| The From address for the test send, and the integration that sends it (Composio Gmail, SMTP, ESP API) | The test must leave through the real path, alias included. |
+| Test inbox: mail-tester (free tier has a small daily cap) or an inbox the user owns | Decides how the score is captured. |
+| Schedule and timezone | Default: weekdays, morning, user's timezone. |
+| Alert channel and thresholds (score floor, bounce rate) | Defaults: score < 6/10, bounces >= 5% on >= 10 sends. |
+| History retention | Default 90 days of runs. |
+
+Read the answers back in one short message before you write code.
+
+## 2. Build the checks script
+
+One saved script with modes `send`, `check`, and optionally `backfill`. Keep
+domains, selectors, thresholds and ids in a config block at the top or in
+`args`, never scattered through the code.
+
+**DNS over HTTPS, two resolvers.** Query every record on two public DoH
+resolvers (for example dns.google and Cloudflare's JSON endpoint).
+NOERROR and NXDOMAIN are answers; SERVFAIL, REFUSED and timeouts are not.
+Same verdict on both: use it. Different verdicts: `warn` ("resolvers
+disagree", often propagation). One failed: use the other, note it. Both
+failed: `unknown`.
+
+**Checks per domain:**
+
+- SPF: exactly one `v=spf1` record, includes each provider, total DNS lookups
+  <= 10 (recurse `include:`/`redirect=`; warn at 9), ends `~all` or `-all`.
+- DKIM: TXT at each selector (follow a CNAME), non-empty `p=` (empty means
+  revoked), key length.
+- DMARC: exactly one `v=DMARC1` at `_dmarc.<domain>`, a `p=` tag, `rua=` (warn
+  without it).
+- MX: present and pointing at the expected provider.
+- Provider records the ESP documents (bounce subdomain SPF and MX, DKIM
+  CNAMEs).
+- Blocklists: domain lists such as Spamhaus DBL, SURBL, URIBL (details below).
+- Test-send result: score plus the SPF, DKIM and DMARC verdicts from the
+  receiver's headers.
+- Bounce rate: sent vs bounced in the last 24h from the sending mailbox,
+  excluding test sends.
+
+**Verdicts:** `ok`, `warn`, `red`, `unknown`. Overall = worst. `unknown` means
+"could not read", and it is **never** reported as clean.
+
+**Controls, not hope.** Every negative result needs a positive control in the
+same run:
+
+- Blocklists: before trusting a list, query its documented test entry
+  (`dbltest.com` on `dbl.spamhaus.org`, `test.surbl.org` on `multi.surbl.org`,
+  `test.uribl.com` on `multi.uribl.com`) on each resolver. Use the list only on
+  a resolver where the test entry answers "listed". Refusal codes
+  (`127.255.255.x` from Spamhaus, `127.0.0.1` from SURBL and URIBL) mean the
+  resolver is blocked: `unknown`.
+- Bounce rate: a whole-mailbox 24h count of 0 means the search failed:
+  `unknown`, not "0 bounces".
+- Test result page without a score yet: `unknown` for the first hour after the
+  send, then `red`.
+
+Return a `controls.ok` flag with the result so a run that read nothing cannot
+pass as green.
+
+**Send mode.** Send one realistic message (the same template and links real
+mail uses) to a fresh test address, through the user's integration. Read the
+sent message back and confirm the From header kept the address the user asked
+for. Store the pending test id in KV with a per-day key so a retry never
+sends twice.
+
+## 3. Build the app
+
+Use [[apps]]. Minimum models:
+
+- `run`: one row per run (time, overall, red/warn/unknown counts, score,
+  bounces, sent).
+- `check`: one row per check per run (history).
+- `current`: one row per `domain|check`, updated in place, with `since` = when
+  the status last changed.
+
+Optional per-domain views (`domainRun`, `domainCheck`) make tabs per domain
+cheap to render. Page: one tab per domain (problems first, raw record on
+hover), a score trend, and a collapsed "How it works". The script writes rows
+through the row endpoints; prune `run` and `check` rows older than the
+retention window.
+
+## 4. Schedule it
+
+Use [[scheduling]] with `targetType: "script"`, not an agent task that says
+"run the script". Two schedules: `send`, then `check` 10 to 15 minutes later
+in the user's timezone, so the test inbox has the message before the check
+reads it.
+
+## 5. Alert only on change
+
+Compare with the previous `current` rows. Alert when a check **turns** red, or
+the score drops below the floor after being above it. Never alert on a
+steady-state warn or an unknown. The message lists each new red with its raw
+detail and links the app. If the script's identity cannot post to the chosen
+channel, have it hand the message to an agent that can.
+
+## Done when
+
+- A manual `check` run returns every check, `controls.ok: true`, and writes
+  rows the app renders.
+- Every blocklist shows either a passing control or `unknown`, never a bare
+  "not listed".
+- One full scheduled send + check cycle has run and the score landed in `run`.
+- You reported the app link, script name and scope, and schedule ids.

package/templates/skills/kv-storage/content.md

@@ -287,8 +287,8 @@ value so you can detect a clobber.
 ## See also
 
 - The **`pages`** skill — companion skill for authed pages and `swarmSdk.kv`.
-- The **`artifacts`** skill — for anything too big or too binary for KV.
+- The **`agent-fs`** skill — for anything too big or too binary for KV.
 - `src/be/migrations/061_kv_store.sql` — schema (`kv_entries`)
 - `src/http/kv.ts` — REST handler + namespace resolution
 - `src/tools/kv/*` — MCP tool registrars
-- `src/artifact-sdk/browser-sdk.ts` — `swarmSdk.kv` for pages
+- `src/pages/browser-sdk.ts` — `swarmSdk.kv` for pages

package/templates/skills/pages/content.md

@@ -1,8 +1,8 @@
 # Pages — DB-backed Static Artifacts
 
 DB-backed static content (HTML or JSON) served by the API directly. Cheap,
-versioned, share-able by URL. The lighter-weight cousin of `artifacts` —
-no PM2, no tunnels, no port allocation, no `services` registry row.
+versioned, share-able by URL. No server process, no tunnel, no port
+allocation.
 
 A page should be a clean human-facing artifact, not a raw dump with a URL. This
 skill covers both halves: **how to publish** a page, and **the taste baseline**
@@ -13,7 +13,7 @@ every page should meet.
 > (e.g. `CAPABILITIES=core,task-pool,pages`). If the tool is missing from
 > your MCP list, this is why.
 
-## When to use Pages vs Artifacts
+## When to use Pages vs Apps
 
 | You need… | Use |
 |---|---|
@@ -21,12 +21,11 @@ every page should meet.
 | A JSON status payload + a few buttons that call swarm APIs | **Pages** (`contentType: 'application/json'`) |
 | To share an output via a URL with no server logic | **Pages** |
 | Analysis that should be linkable and bookmarkable | **Pages** |
-| Custom routes, websockets, server-side logic | The **`artifacts`** skill |
-| File uploads or per-request computation | The **`artifacts`** skill |
+| Persistent records, queries, and server-side actions | The **`apps`** skill |
+| Large or binary files (PNG, MP4, exports) | The **`agent-fs`** skill |
 
 Rule of thumb: if the content is a snapshot (you can write the full HTML/JSON
-in a single call), use pages. If the content is a *running program*, use
-artifacts.
+in a single call), use pages. If it needs stored data and actions, use apps.
 
 Do **not** use pages for:
 
@@ -533,9 +532,8 @@ human-facing summary.
 
 ## See Also
 
-- The **`artifacts`** skill — durable storage (agent-fs, shared workspace) plus
-  full custom Hono apps with PM2 + a tunneled subdomain. Use it for interactive
-  servers, not static content.
+- The **`apps`** skill — schema-backed records, named queries, and actions.
+- The **`agent-fs`** skill — durable file storage and share links.
 - The **`kv-storage`** skill — page-scoped state via `swarmSdk.kv`.
 - `runbooks/secret-scrubbing.md` — egress scrubbing details.
 - SPA listing: `${APP_URL}/pages` — the same `APP_URL` used for share links above.

package/templates/skills/swarm-extensions/content.md

@@ -47,10 +47,12 @@ curl -s "$MCP_BASE_URL/api/extensions/type-defs" \
 | `pre.task.create` | before any task is stored (REST, MCP, Slack, schedule, workflow, webhook, follow-up) | `block(reason)`, `modify({ priority, agentId, tags, description, ... })`, or nothing |
 | `pre.task.followUp` | before the lead follow-up task for a finished worker task | `block`, `modify({ description, priority, agentId })`, or nothing |
 | `pre.slack.route` | before a Slack message becomes a task | `modify({ target: { kind: "agent", agentId } })`, `{ kind: "lead" }`, `{ kind: "broadcast" }` |
+| `pre.chat.route` | before buffered Chat SDK messages (Telegram, Slack, Discord, Teams) become a task | `block(reason)`, or `modify({ target: { kind: "agent", agentId } })`, `{ kind: "lead" }`, `{ kind: "broadcast" }`, `{ kind: "workflow", workflowId }` |
 | `pre.heartbeat.remediate` | after the heartbeat sweep finds a stalled task | `modify({ proposedAction: "record" | "fail" | "supersede-resume" })` |
 | `pre.tool.call` | before an agent MCP tool call runs | `block(reason)` or `modify({ args })` |
 | `post.task.created`, `post.task.completed`, `post.task.failed`, `post.task.cancelled`, `post.task.superseded`, `post.task.progress` | after the change is committed | none |
 | `post.slack.message`, `post.tool.call` | after the message or tool call finished | none |
+| `post.chat.message` | after a Chat SDK message is received (before buffering) or sent; `direction` is `inbound` or `outbound` | none |
 | `post.approval.resolved` | after a person answers an approval request, workflow or standalone (not on timeout or cancel) | none |
 | `post.task.budgetRefused` | after a task is refused by a daily spend budget | none |
 | `post.email.received`, `post.kapso.message` | after an inbound AgentMail or Kapso message is received | none |

package/templates/skills/swarm-scripts/SKILL.md

@@ -76,7 +76,7 @@ export default async function (args: z.infer<typeof argsSchema>, ctx: ScriptCont
 
 - `ctx.swarm.*`: the swarm SDK. `task_get`, `task_send`, `task_storeProgress`, `task_action`, `task_list`, `slack_reply`, `memory_search`, `memory_store`, `kv_get`, `kv_getOrNull`, `kv_set`, `kv_delete`, `kv_incr`, `kv_list`, `swarm_get`, `agent_info`, `db_query`, and more. `kv_getOrNull` returns the entry, `null` on a missing key, and throws on other errors.
 - `ctx.swarm.task_send` requires `routingReason` and `routingNote` whenever `agentId` is present. The note must explain the worker choice in at least 10 characters after trimming whitespace (maximum 200 characters). Use `human_pinned` for an explicit/configured choice, `skill` for a role or specialization match, `continuity` for the same worker/session, `reroute_fault` for a fault handoff, or `overflow` for capacity/pool escalation. Omit both `agentId` and routing fields for the pool.
-- `ctx.swarm.config`: `apiKey`, `agentId`, `mcpBaseUrl`, and `ctx.swarm.config.get("KEY")` for user config values. All are `Redacted` wrappers that stringify to `<redacted>`. Never unwrap one into a return value, a log line, or a request body you build by hand.
+- `ctx.swarm.config`: `apiKey`, `agentId`, `mcpBaseUrl`, and `ctx.swarm.config.get("KEY")` for swarm config values, resolved for the agent running the script (agent scope over global, the same rows `get-config` returns for that agent). A key that is not set returns `undefined`, so `config.get("KEY") ?? fallback` works. All are `Redacted` wrappers that stringify to `<redacted>`. Never unwrap one into a return value, a log line, or a request body you build by hand.
 - `ctx.api.<slug>` and `ctx.mcp.<slug>`: typed clients for registered connections. They exist only for registered connections. Introspect with `Object.keys(ctx.api ?? {})` and `Object.keys(ctx.mcp ?? {})`.
 - `ctx.stdlib`: `fetch`, `fetchJson` (retries, 30 s timeout), `grep`, `glob`, `table`, `Redacted`.
 - `ctx.logger`: `log`, `warn`, `error`. Keep logs short.
@@ -107,11 +107,13 @@ export default async function main(args: { status?: string; limit?: number } | u
 
 ## Secrets
 
+A config row reaches your shell env only when its `exportToEnv` flag is on. If `$KEY` is empty in your shell but `get-config` or `list-config` shows the row marked `not in agent env`, the row stays server-side on purpose: do not copy the value into a file, an env var, or a command. Use it from a script instead, through one of the paths below. Harness, git, and agent-fs credentials stay exported. Keys only the API server reads (Slack app token and signing secret, GitHub App private key, webhook and OAuth client secrets) can never be exported. If a recipe genuinely needs the variable in a shell, ask the lead to turn `exportToEnv` on for that row (`set-config` with `exportToEnv: true`); it applies to your next task.
+
 Order of preference:
 
 1. A registered connection: `ctx.api.<slug>.<operationId>({ path, query, header, body })` (OpenAPI), `ctx.api.<slug>.graphql(query, variables)` (GraphQL), `ctx.mcp.<slug>.<toolName>(args)` (MCP, proxied server-side, returns the raw MCP envelope: read `res.structuredContent ?? res.content?.[0]?.text`). Credentials attach at egress. The script never sees them. OAuth tokens refresh on their own.
 2. A credential binding placeholder in a hand-written request: `Authorization: Bearer [REDACTED:GITHUB_TOKEN]`. The runtime substitutes the value at egress, only for the binding's allowed hosts.
-3. `ctx.swarm.config.get("KEY")` for a config value you pass to `ctx.stdlib.fetch` as a header value. Still `Redacted`; never log it.
+3. `ctx.swarm.config.get("KEY")` for a config value you pass to `ctx.stdlib.fetch` as a header value. Unwrap it with `ctx.stdlib.Redacted.value(...)` inside the header itself (a wrapped value sends the literal `<redacted>`), and never log it. Secret values are scrubbed from run output.
 
 A raw secret, or the output of `get-config` with `includeSecrets: true`, must not appear in script source, script `args`, a schedule's `taskTemplate` or `scriptArgs`, or a task description. Those are stored as plain text and replayed on every run.
 

package/templates/skills/swarm-scripts/config.json

@@ -5,7 +5,7 @@
   "slug": "swarm-scripts",
   "title": "Swarm Scripts",
   "description": "Bulk, repeat, fan-out, or data-heavy work: write and run swarm scripts (inline `script-run`, named `script-upsert`, durable `launch-script-run`). Covers the script-vs-tool rubric, the authoring contract (`args` first, `ctx` second), the seed catalog, connections and secrets, `db_query`, and exposing a script as an API.",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "category": "skills",
   "placeholders": [],
   "runAllSeedersCandidate": true,

package/templates/skills/swarm-scripts/content.md

@@ -71,7 +71,7 @@ export default async function (args: z.infer<typeof argsSchema>, ctx: ScriptCont
 
 - `ctx.swarm.*`: the swarm SDK. `task_get`, `task_send`, `task_storeProgress`, `task_action`, `task_list`, `slack_reply`, `memory_search`, `memory_store`, `kv_get`, `kv_getOrNull`, `kv_set`, `kv_delete`, `kv_incr`, `kv_list`, `swarm_get`, `agent_info`, `db_query`, and more. `kv_getOrNull` returns the entry, `null` on a missing key, and throws on other errors.
 - `ctx.swarm.task_send` requires `routingReason` and `routingNote` whenever `agentId` is present. The note must explain the worker choice in at least 10 characters after trimming whitespace (maximum 200 characters). Use `human_pinned` for an explicit/configured choice, `skill` for a role or specialization match, `continuity` for the same worker/session, `reroute_fault` for a fault handoff, or `overflow` for capacity/pool escalation. Omit both `agentId` and routing fields for the pool.
-- `ctx.swarm.config`: `apiKey`, `agentId`, `mcpBaseUrl`, and `ctx.swarm.config.get("KEY")` for user config values. All are `Redacted` wrappers that stringify to `<redacted>`. Never unwrap one into a return value, a log line, or a request body you build by hand.
+- `ctx.swarm.config`: `apiKey`, `agentId`, `mcpBaseUrl`, and `ctx.swarm.config.get("KEY")` for swarm config values, resolved for the agent running the script (agent scope over global, the same rows `get-config` returns for that agent). A key that is not set returns `undefined`, so `config.get("KEY") ?? fallback` works. All are `Redacted` wrappers that stringify to `<redacted>`. Never unwrap one into a return value, a log line, or a request body you build by hand.
 - `ctx.api.<slug>` and `ctx.mcp.<slug>`: typed clients for registered connections. They exist only for registered connections. Introspect with `Object.keys(ctx.api ?? {})` and `Object.keys(ctx.mcp ?? {})`.
 - `ctx.stdlib`: `fetch`, `fetchJson` (retries, 30 s timeout), `grep`, `glob`, `table`, `Redacted`.
 - `ctx.logger`: `log`, `warn`, `error`. Keep logs short.
@@ -102,11 +102,13 @@ export default async function main(args: { status?: string; limit?: number } | u
 
 ## Secrets
 
+A config row reaches your shell env only when its `exportToEnv` flag is on. If `$KEY` is empty in your shell but `get-config` or `list-config` shows the row marked `not in agent env`, the row stays server-side on purpose: do not copy the value into a file, an env var, or a command. Use it from a script instead, through one of the paths below. Harness, git, and agent-fs credentials stay exported. Keys only the API server reads (Slack app token and signing secret, GitHub App private key, webhook and OAuth client secrets) can never be exported. If a recipe genuinely needs the variable in a shell, ask the lead to turn `exportToEnv` on for that row (`set-config` with `exportToEnv: true`); it applies to your next task.
+
 Order of preference:
 
 1. A registered connection: `ctx.api.<slug>.<operationId>({ path, query, header, body })` (OpenAPI), `ctx.api.<slug>.graphql(query, variables)` (GraphQL), `ctx.mcp.<slug>.<toolName>(args)` (MCP, proxied server-side, returns the raw MCP envelope: read `res.structuredContent ?? res.content?.[0]?.text`). Credentials attach at egress. The script never sees them. OAuth tokens refresh on their own.
 2. A credential binding placeholder in a hand-written request: `Authorization: Bearer [REDACTED:GITHUB_TOKEN]`. The runtime substitutes the value at egress, only for the binding's allowed hosts.
-3. `ctx.swarm.config.get("KEY")` for a config value you pass to `ctx.stdlib.fetch` as a header value. Still `Redacted`; never log it.
+3. `ctx.swarm.config.get("KEY")` for a config value you pass to `ctx.stdlib.fetch` as a header value. Unwrap it with `ctx.stdlib.Redacted.value(...)` inside the header itself (a wrapped value sends the literal `<redacted>`), and never log it. Secret values are scrubbed from run output.
 
 A raw secret, or the output of `get-config` with `includeSecrets: true`, must not appear in script source, script `args`, a schedule's `taskTemplate` or `scriptArgs`, or a task description. Those are stored as plain text and replayed on every run.
 

package/templates/skills/workflow-iterate/content.md

@@ -173,6 +173,44 @@ Afterwards, a `warnings` entry on `create-workflow` or a patch tool means the ke
 - Do not set `retry` or `validation.retry` on a `system-one-decision` node. It retries connection errors, 408, 429, and 5xx itself (`config.maxRetries`, 0 to 3, default 2) inside `config.timeoutMs` (default 30000). A 401, a 422, or an answer that fails validation ends after one attempt.
 - The node reads its provider's key (`TYPESAFE_API_KEY`, `OPENROUTER_API_KEY`, `LAYA_API_KEY`, `OPENAI_DECISIONS_API_KEY`, or `CLOUDFLARE_API_TOKEN`, plus `LAYA_URL` for `laya` and `CLOUDFLARE_ACCOUNT_ID` for `cloudflare`) server-side. The key never appears in the definition, the step output, or an error. A run whose key or `LAYA_URL` is missing fails before any node executes, and a 401 or 403 fails the step as `<KEY> was rejected`. An unresolved `{{token}}` fails the step before any request.
 
+#### Jev images (direct TypeSafe API)
+
+`system-one-decision` cannot send images today: its strict config has no `assets` field, its wire sends only `state`, `model`, and `questions`, and it does not send the image opt-in header. A URL or base64 string in `state` stays text. Use a `swarm-script` calling `POST https://api.typesafe.ai/v1/systemone` with the credential kept server-side until the node supports assets.
+
+- Send `TypeSafe-Danger-Zone-Images: true`. Both `jev-1.13.0` and `jev-1.14.0` accept images; Box questions require 1.14. Pin the model you tested.
+- Upload PNG or JPEG bytes, not a URL. Prefer multipart: first part `request` is the JSON with content type `application/json`; an asset such as `assets[uuid] = { type: "image", part: "photo-file" }` names its file part. For JSON-only calls, use the base64 shape below: standard padded base64, no whitespace or `data:` prefix.
+- Each image must be still, at most 16 MiB decoded, 256–1568 pixels on each side, and 78,400–2,458,624 pixels total (256×256 is too small). Request body, all processed images together, and the expanded request each have a 32 MiB limit. Limits reject the whole request; the API does not resize. Rotate pixels upright before sending because EXIF orientation is not applied.
+- Generate a fresh UUID reference per image. References are replaced wherever they occur in string values in `state`, `instructions`, or `criteria`; object keys are not replaced. Every asset must be referenced. Repeating the same reference inserts and bills another image copy.
+
+```json
+{
+  "model": "jev-1.13.0",
+  "state": { "photo": "d1369c6a-538e-4ab3-91cd-f76f2f67b651" },
+  "assets": {
+    "d1369c6a-538e-4ab3-91cd-f76f2f67b651": {
+      "type": "image", "format": "png", "data_base64": "<encoded PNG bytes>"
+    }
+  },
+  "questions": {
+    "ready": { "type": "noul", "instructions": "Is the product in `photo` fully assembled?" }
+  }
+}
+```
+
+Measured 2026-10-15 on `jev-1.13.0`, using an 850×850 RGB PNG with a red square on white. Cost is the complete request's `usage.input_tokens × $0.042 / 1,000,000`; output is free:
+
+| Placement | Questions | Input tokens | Request cost (USD) |
+|---|---:|---:|---:|
+| Once in `state` | 1 | 2,273 | $0.000095466 |
+| Once in `state`, questions use the `photo` path | 2 | 2,289 | $0.000096138 |
+| Twice in `state` | 1 | 4,237 | $0.000177954 |
+| Once in each question's `instructions` | 2 | 4,203 | $0.000176526 |
+| Once in `state`, resized to 425×425 | 1 | 863 | $0.000036246 |
+
+The roughly $0.0001 claim (about 10,000 one-image requests per dollar) holds for this example; the exact cost depends on image size and prompt. **Question count alone does not multiply a shared state image's tokens.** Put shared images in `state` once and have questions use its field path, not the asset UUID. Image duplication scales with repeated references, including one copy per question when embedded in each question's instructions. If several judgments form one classification, a single `choice` can avoid repeating question-local images. Downscale when the detail permits: halving both dimensions reduced this request's billed tokens from 2,273 to 863; recheck accuracy on your images.
+
+Contract and current pricing: [TypeSafe images](https://docs.typesafe.ai/images), [models](https://docs.typesafe.ai/models). Re-measure before budgeting a different model, resolution, or prompt.
+
 ### `human-in-the-loop` (how approvals render)
 
 The same rules apply to a standalone `request-human-input` call.