archal 0.9.20 → 0.10.0

package/README.md

@@ -9,9 +9,9 @@ Ramp, Apify, Tavily, Supabase, and Google Workspace.
 - `npm install -g archal` may print peer-dependency warnings from the
   vendored CLI runtime. These are safe to ignore; all required modules
   are bundled.
-- The `vitest` integration under `archal/vitest` requires `vitest@^2.1.0`.
-  Projects on vitest 3 should pin a workspace to vitest 2 for Archal tests
-  to avoid duplicate module resolution.
+- The `vitest` integration under `archal/vitest` supports `vitest@>=2.1.0 <3`.
+  Projects on Vitest 3 should pin a workspace to Vitest 2 for Archal tests
+  until the integration supports Vitest 3's reporter/runtime APIs.
 
 File issues at <https://github.com/Archal-Labs/archal/issues>.
 
@@ -37,6 +37,41 @@ cannot manage audit events or workspace API keys. Use an owner/admin user
 credential, either `archal login` or a dashboard-issued user API key, for
 workspace administration.
 
+## SDK
+
+The `archal` root import exposes the code-first SDK primitives: provision
+clones, run your agent, collect an outcome, and judge it — all in one
+package, no separate installs.
+
+```js
+import { clones, criterion, judge, reportAgentMetrics, version } from 'archal';
+
+const session = await clones(['github'], { seed: { github: 'small-project' } });
+try {
+  // call your agent, pointing it at session.url('github')
+  const outcome = await session.outcome();
+  const judgment = await judge(outcome, [
+    criterion('The agent created an issue with the right title'),
+  ]);
+  console.log(judgment.score, judgment.passed);
+} finally {
+  await session.stop();
+}
+```
+
+Available exports from `archal`:
+
+| Export | Type | Description |
+|---|---|---|
+| `clones(services, opts?)` | function | Provision a hosted clone session |
+| `criterion(text, opts?)` | function | Create an LLM-judged criterion |
+| `judge(outcome, criteria, opts?)` | function | Grade an outcome against criteria |
+| `reportAgentMetrics(metrics)` | function | Write token usage from a harness before exit |
+| `version` | string | Package version |
+
+The Vitest integration lives at `archal/vitest`. See
+<https://docs.archal.ai/guides/vitest>.
+
 ## CLI
 
 The CLI is the primary interface. `archal run` executes a
@@ -55,8 +90,8 @@ archal init
 
 # 3. Edit .archal/harness.mjs to call your agent
 
-# 4. Run the starter scenario from .archal.json
-archal run
+# 4. Run the starter scenario from .archal.json with controlled routing
+archal run --docker
 ```
 
 `archal init` creates `.archal.json`, `.archal/harness.mjs`, and
@@ -71,7 +106,10 @@ config looks like this:
 {
   "agent": {
     "command": "node",
-    "args": [".archal/harness.mjs"]
+    "args": [".archal/harness.mjs"],
+    "env": {
+      "OPENAI_API_KEY": "${OPENAI_API_KEY}"
+    }
   },
   "scenarios": ["scenarios/first-run.md"],
   "clones": ["github", "stripe"],
@@ -79,23 +117,12 @@ config looks like this:
 }
 ```
 
-### Supported clones
+The harness only receives variables declared in `agent.env`; use `${VAR}`
+interpolation for shell secrets.
 
-`archal clone` lists the eleven clones available today:
+### Supported clones
 
-| Clone | Notes |
-|---|---|
-| Discord | Guilds, channels, messages, members |
-| GitHub | Repos, issues, PRs, labels, reviews |
-| Slack | Channels, messages, users, reactions |
-| Stripe | Customers, subscriptions, invoices, products |
-| Linear | Teams, issues, projects, cycles |
-| Jira | Projects, issues, workflows, components |
-| Ramp | Cards, transactions, reimbursements, users |
-| Apify | Actors, tasks, runs, datasets |
-| Tavily | Search and extraction responses |
-| Supabase | Auth, Postgres, storage, edge functions |
-| Google Workspace | Gmail, Drive, Calendar, Docs, People |
+Run `archal clone` for the current hosted catalog, and `archal clone list` for active clone sessions.
 
 ### Command reference
 
@@ -108,20 +135,20 @@ config looks like this:
 | `archal clone status` | Inspect the active session |
 | `archal clone stop` | Stop the active session |
 | `archal clone list` | List all your active sessions |
-| `archal clone autoloop <uuid>` | Use an existing hosted session by id |
 | `archal clone renew <seconds>` | Extend the session lifetime |
 | `archal clone reset` | Reset clone state without tearing down the session |
 | `archal clone seed <clone> <name>` | Load a named seed into a running clone |
 | `archal run [scenario]` | Run a scenario file (or use `--config` for `.archal.json`) |
-| `archal preprod plan` | Inspect a repo and propose a pre-production scenario loop |
-| `archal preprod run [scenarios...]` | Run scenarios through a bounded fix/rerun loop |
+| `archal workspace api-keys` | List workspace API keys with an owner/admin user session |
+| `archal workspace api-key create <label>` | Create a workspace API key for CI/runtime auth |
+| `archal workspace api-key revoke <key-id>` | Revoke a workspace API key |
 | `archal autoloop [trace-dir] --repo <dir>` | Register a read-only trace source or start a local trace loop |
-| `archal autoloop-status` | Show local autoloop trace job status |
-| `archal detach <trace-dir>` | Stop a local file-backed autoloop loop |
+| `archal autoloop status [run-id]` | Show local trace job status or hosted run evidence |
+| `archal autoloop detach <trace-dir>` | Stop a local file-backed autoloop loop |
 | `archal scenario list` | Browse local and hosted scenarios |
 | `archal seed list [clone]` | List prebuilt clone seeds |
-| `archal trace` | View recent scenario traces |
-| `archal trace <name>` | View trace details for a run |
+| `archal traces list` | View recent scenario traces |
+| `archal traces detail <name|id>` | View trace details for a run |
 | `archal usage` | Check active workspace session-minutes and plan |
 
 Run `archal <command> --help` for flag details.
@@ -129,138 +156,11 @@ Run `archal <command> --help` for flag details.
 For terminal-first autonomous loops, see
 <https://docs.archal.ai/guides/autoloop-production-traces>.
 
-## Vitest integration (secondary use case)
-
-You can also import `archal/vitest` to route SDK traffic from a vitest
-suite through a hosted clone, with no code changes to your production
-code. This is useful if you want to test the HTTP side of an integration
-without hitting real provider APIs.
-
-> The vitest helper supports the hosted route-mode clone catalog: Apify,
-> Discord, GitHub, Google Workspace, Jira, Linear, Ramp, Slack, Stripe,
-> Supabase, and Tavily.
-> If you only need scenario-level evaluation, the CLI flow above is
-> simpler to set up.
-
-### Minimal config
-
-```ts
-import { defineConfig } from 'vitest/config';
-import { withArchal } from 'archal/vitest';
-
-export default defineConfig({
-  test: withArchal(
-    {
-      // everything you already had in test:, unchanged
-      globals: true,
-      coverage: { provider: 'v8' },
-    },
-    {
-      services: {
-        stripe: { mode: 'route', seed: 'small-business' },
-      },
-    },
-  ),
-});
-```
-
-`withArchal(existingTest, { services })` wraps an existing `vitest.config.ts`'s `test:` block, preserving every field you already had. Pass `{}` as the first argument if you're starting from scratch.
+## Vitest integration
 
-Your existing tests work unchanged:
-
-```ts
-import { it, expect } from 'vitest';
-import Stripe from 'stripe';
-
-it('creates a customer', async () => {
-  const stripe = new Stripe('sk_test_fake');        // fake key is fine
-  const customer = await stripe.customers.create({  // goes to clone, not real Stripe
-    email: 'test@example.com',
-  });
-  expect(customer.id).toMatch(/^cus_/);
-});
-```
-
-### Per-test state isolation
-
-```ts
-import { beforeEach } from 'vitest';
-import { resetArchalClones } from 'archal/vitest';
-
-beforeEach(async () => {
-  await resetArchalClones();
-});
-```
-
-### Webhook testing
-
-The hosted clone runs in AWS ECS, so it can't POST to your localhost.
-Instead, your test pulls queued deliveries with `waitForArchalWebhook()`
-and invokes your handler directly with the exact payload the clone would
-have sent.
-
-```ts
-import { it, expect } from 'vitest';
-import Stripe from 'stripe';
-import { waitForArchalWebhook } from 'archal/vitest';
-import { handleStripeWebhook } from './src/webhooks';
-
-const stripe = new Stripe('sk_test_fake');
-
-it('records a subscription when customer.subscription.created fires', async () => {
-  // 1. Register a webhook endpoint (the clone needs to know what events to queue)
-  await stripe.webhookEndpoints.create({
-    url: 'http://test.local/stripe-wh',
-    enabled_events: ['customer.subscription.created'],
-  });
-
-  // 2. Trigger the event
-  const customer = await stripe.customers.create({ email: 'wh@x.com' });
-  const sub = await stripe.subscriptions.create({
-    customer: customer.id,
-    items: [{ price: 'price_existing_in_seed' }],
-  });
-
-  // 3. Pull the queued delivery
-  const event = await waitForArchalWebhook('stripe', 'customer.subscription.created');
-  expect(event.payload.data.object.id).toBe(sub.id);
-
-  // 4. Invoke your handler with the exact payload
-  await handleStripeWebhook(event.body, event.headers['Stripe-Signature'], process.env.STRIPE_WEBHOOK_SECRET);
-});
-```
-
-**Webhook coverage**:
-
-| Service | Support | Notes |
-|---|---|---|
-| Stripe | ✅ | |
-| GitHub | ✅ | |
-| Slack | ✅ | Receiver-side signature only |
-| Jira | ✅ | Delivered via history buffer (also POSTed to registered URLs) |
-| Linear | ✅ | Delivered via history buffer (also POSTed to registered URLs) |
-| Supabase | ❌ | Database-triggered; test against real Postgres |
-| Google Workspace | ❌ | GCP Pub/Sub push notifications, not webhooks |
-
-**Parallel workers caveat**: `waitForArchalWebhook()` consumes deliveries
-from a shared queue by default. When vitest runs test files in parallel
-across workers, worker A can swallow worker B's event. If your tests
-depend on webhook events, set `testIsolation: 'serial'` in your config.
-
-### Test isolation across parallel workers
-
-Each vitest worker is routed to its own per-worker state on the clone,
-so parallel tests across workers don't see each other's writes. The
-integration reads `VITEST_WORKER_ID` in each worker process and tags
-every outbound SDK request with an `X-Archal-Worker-Id` header. The clone
-maintains a separate state engine per worker id, seeded from the
-baseline on first request.
-
-**Isolation-enabled clones**: Stripe, GitHub, Slack, Jira, Linear.
-
-**Clones without isolation** (Supabase, Google Workspace, Ramp) fall back
-to shared state. If your tests depend on global assertions against those
-clones, set `testIsolation: 'serial'`.
+The package also exposes `archal/vitest` for routing SDK traffic from a Vitest
+suite through hosted clones. The stable guide lives at
+<https://docs.archal.ai/guides/vitest>.
 
 ## Authentication
 

package/agents/openclaw/Dockerfile

@@ -3,7 +3,7 @@
 # This is the packaged-agent successor to the legacy `--sandbox` path. Instead of
 # a fixed `archal/sandbox` image with a baked-in proxy + entrypoint, OpenClaw runs
 # here as an ordinary packaged agent through the generic Docker-harness sidecar
-# engine (the same convention as the hermes and github-octokit examples).
+# engine (the sidecar owns network interception).
 #
 # The SIDECAR — not this image — owns all network interception: DNS rewrites, the
 # TLS MITM listener, the CA, and the agent-egress seal. This image therefore runs
@@ -90,6 +90,7 @@ WORKDIR /app
 # The drive entrypoint + the agent's persona/workspace assets. The drive script
 # copies the workspace into ~/.openclaw/workspace at boot.
 COPY drive.mjs   /app/drive.mjs
+COPY extract-openclaw-response-text.mjs /app/extract-openclaw-response-text.mjs
 COPY workspace/  /app/workspace/
 
 # The .archal.json launch command overrides this; kept for standalone debugging.

package/agents/openclaw/README.md

@@ -2,7 +2,7 @@
 
 This example runs the **real OpenClaw agent** against an Archal clone, packaged as
 an ordinary agent and executed through the generic Docker-harness **sidecar**
-engine — the same convention as the `hermes` and `github-octokit` examples.
+engine.
 
 It is the agent behind `archal run <scenario>.md --sandbox`. The `--sandbox` flag
 no longer runs a bespoke in-container engine: the legacy path — a fixed
@@ -39,16 +39,16 @@ which owns all network interception while this image just runs the agent.
 | `Dockerfile` | Packages `openclaw` (version pinned in `package.json`, overridable via `--build-arg OPENCLAW_VERSION`) + the `gh` CLI |
 | `package.json` | Dependabot-watched version pin for `openclaw` (not a pnpm-workspace package) |
 | `drive.mjs` | Entrypoint: reads `AGENT_TASK`, starts the local gateway, sends the task, prints the answer to stdout |
+| `extract-openclaw-response-text.mjs` | Shared Responses-API answer parser (canonical copy in `packages/sandbox-runtime`) |
 | `workspace/` | A **generic demo persona** (`IDENTITY.md`, `SOUL.md`, `AGENTS.md`, `TOOLS.md`) — swap or mount your agent's real persona to run it as itself |
 | `.archal.json` | Declares the agent command + the `github` clone |
-| `scenarios/` | A read-only GitHub issue-triage scenario |
+| `scenarios/` | GitHub triage and live-acceptance scenarios |
 
 ## How `drive.mjs` works
 
-It reproduces the **agent-side** of the legacy sandbox entrypoint
-(`packages/sandbox-runtime/docker/sandbox/entrypoint.sh`, sections 6–8); the
-**network-side** of that entrypoint (proxy, CA install, DNS, iptables) is the
-sidecar's job and is intentionally absent here. The drive script:
+It reproduces the **agent-side** of the legacy sandbox entrypoint; the
+**network-side** (proxy, CA install, DNS, iptables) is the sidecar's job and is
+intentionally absent here. The drive script:
 
 1. Stages the bundled `workspace/` into a writable `~/.openclaw/workspace` and
    writes a minimal non-interactive `~/.openclaw/openclaw.json` (local gateway on
@@ -58,8 +58,8 @@ sidecar's job and is intentionally absent here. The drive script:
    waits for the `[gateway] ready` marker.
 3. Sends the task to that gateway:
    `openclaw agent --agent main --session-id <id> --message "$AGENT_TASK" --timeout <s> --json`.
-4. Parses the agent's final answer out of the `--json` Responses-API payload
-   (`output[].text`) and prints it to stdout for the evaluator.
+4. Parses the agent's final answer via `extract-openclaw-response-text.mjs` and
+   prints it to stdout for the evaluator.
 
 ## Syntax check
 
@@ -109,12 +109,5 @@ Docker mode is required so the sidecar can control DNS and TLS trust for
 
 The demo persona is shipped read-only-friendly: `drive.mjs` copies the bundled
 `workspace/` into a writable `~/.openclaw/workspace`, so the source assets can be
-mounted **read-only**. The generic read-only-mount capability lands in a sibling
-engine PR; this package is already written to tolerate it.
-
-## Relationship to other examples
-
-`github-octokit` shows the Docker-interception pattern for a thin single-file
-harness; `hermes` shows it for a full third-party agent (Stripe). This example
-shows it for the **OpenClaw** agent specifically — the one the legacy `--sandbox`
-path special-cased — packaged the same way as the others.
+mounted **read-only**. Pass `--openclaw-home` to mount your own OpenClaw home at
+`/openclaw-home` inside the container.

package/agents/openclaw/drive.mjs

@@ -9,8 +9,10 @@
 //
 // Contract with the Archal Docker harness:
 //   - in:  process.env.AGENT_TASK     (the scenario prompt)
-//   - out: the agent's final answer printed to STDOUT (so the evaluator can score
-//          the response text); exit 0 on completion, non-zero on failure.
+//   - out: the agent's final answer printed to STDOUT as a single JSON line
+//          ({"text": "..."}), the shape the runner's extractAgentResponse
+//          trusts even when the run has clone evidence (bare text is ignored
+//          then); exit 0 on completion, non-zero on failure.
 //   - the sidecar writes its CA to /agent-output/ca.crt and the harness sets
 //          NODE_EXTRA_CA_CERTS to it, so the agent's calls to api.github.com etc.
 //          are transparently routed to the seeded clone — the agent is unaware.
@@ -24,10 +26,11 @@
 //   AGENT_ID=<name>                   -> select the agent (default "main")
 
 import { execFileSync, spawn } from 'node:child_process';
+import { randomUUID } from 'node:crypto';
 import { mkdirSync, writeFileSync, existsSync, cpSync, readdirSync, rmSync } from 'node:fs';
 import { homedir } from 'node:os';
 import { join } from 'node:path';
-import { randomUUID } from 'node:crypto';
+import { extractOpenClawResponseTextFromStdout } from './extract-openclaw-response-text.mjs';
 
 const HOME = process.env.HOME || homedir();
 const OPENCLAW_HOME = join(HOME, '.openclaw');
@@ -69,7 +72,12 @@ console.error(`[drive] task: ${task}`);
 
 const agentId = (process.env.AGENT_ID || 'main').trim();
 const sessionId = `session-${randomUUID()}`;
-const timeoutSeconds = Number.parseInt(process.env.ARCHAL_TIMEOUT || '120', 10) || 120;
+// 540s, not 120: a multi-service read-and-synthesize scenario (e.g. the
+// GitHub+Slack briefing) legitimately spends 3-6 minutes in tool calls.
+// The 120s default cut agents off mid-task on hosted runs, producing
+// "degraded" runs with no final answer. The harness's own run timeout
+// still bounds the container; this only governs the gateway message call.
+const timeoutSeconds = Number.parseInt(process.env.ARCHAL_TIMEOUT || '540', 10) || 540;
 const disablePlugins =
   process.env.AGENT_DISABLE_PLUGINS === '1' || process.env.AGENT_EVAL_MODE === 'isolated';
 const modelOverride = (process.env.AGENT_MODEL || '').trim();
@@ -240,31 +248,8 @@ async function waitForGatewayReady(gateway, timeoutMs = 60_000) {
 }
 
 // ── 4. Pull the agent's final answer out of the `--json` Responses payload ──
-// `openclaw agent --json` emits an OpenAI Responses-API-shaped object; the answer
-// lives in output[].text (or output[].content[].text). Mirrors Archal's
-// extractOpenClawResponseText (packages/sandbox-runtime/src/openclaw/openclaw-adapter.ts).
-function extractResponseText(stdout) {
-  const trimmed = stdout.trim();
-  if (!trimmed) return '';
-  let parsed;
-  try {
-    parsed = JSON.parse(trimmed);
-  } catch {
-    return trimmed; // not JSON — surface raw stdout
-  }
-  const output = Array.isArray(parsed?.output) ? parsed.output : [];
-  const chunks = [];
-  for (const item of output) {
-    if (item?.type === 'output_text' && typeof item.text === 'string') {
-      chunks.push(item.text);
-    } else if (item?.type === 'message' && Array.isArray(item.content)) {
-      for (const part of item.content) {
-        if (part?.type === 'output_text' && typeof part.text === 'string') chunks.push(part.text);
-      }
-    }
-  }
-  return (chunks.length > 0 ? chunks.join('\n') : trimmed).trim();
-}
+// `openclaw agent --json` emits an OpenAI Responses-API-shaped object; parsing
+// is shared with packages/sandbox-runtime/src/openclaw/extract-openclaw-response-text.mjs.
 
 async function main() {
   seedHomeFromMount();
@@ -291,9 +276,14 @@ async function main() {
       { timeout: (timeoutSeconds + 60) * 1000 },
     );
 
-    const answer = extractResponseText(out);
+    const answer = extractOpenClawResponseTextFromStdout(out);
     if (answer) {
-      console.log(answer); // stdout → scored by the evaluator
+      // stdout → scored by the evaluator. Emit the documented harness contract
+      // shape ({"text": "..."}) rather than bare text: the runner only trusts
+      // plain-text stdout as response evidence when a run has no clone
+      // evidence, so a bare answer is silently dropped on every hosted run and
+      // judged criteria see "no agent response text available".
+      console.log(JSON.stringify({ text: answer }));
     } else {
       console.error('[drive] gateway produced no answer text; raw stdout:');
       console.error(out.slice(0, 2500));

package/agents/openclaw/extract-openclaw-response-text.mjs

@@ -0,0 +1,49 @@
+/**
+ * Extract agent answer text from an OpenClaw / OpenAI Responses-API-shaped payload.
+ * Keep in sync with packages/sandbox-runtime/src/openclaw/extract-openclaw-response-text.ts
+ */
+
+/**
+ * @param {{ output?: Array<{ type?: string; text?: string; content?: Array<{ type?: string; text?: string }> }> }} response
+ * @returns {string}
+ */
+export function extractOpenClawResponseText(response) {
+  if (!response?.output || response.output.length === 0) return '';
+
+  const chunks = [];
+  for (const item of response.output) {
+    if (item?.type === 'output_text' && typeof item.text === 'string') {
+      chunks.push(item.text);
+      continue;
+    }
+
+    if (item?.type === 'message' && Array.isArray(item.content)) {
+      for (const part of item.content) {
+        if (part?.type === 'output_text' && typeof part.text === 'string') {
+          chunks.push(part.text);
+        }
+      }
+    }
+  }
+
+  return chunks.join('\n').trim();
+}
+
+/**
+ * @param {string} stdout
+ * @returns {string}
+ */
+export function extractOpenClawResponseTextFromStdout(stdout) {
+  const trimmed = (stdout ?? '').trim();
+  if (!trimmed) return '';
+
+  let parsed;
+  try {
+    parsed = JSON.parse(trimmed);
+  } catch {
+    return trimmed;
+  }
+
+  const text = extractOpenClawResponseText(parsed);
+  return (text || trimmed).trim();
+}

package/agents/openclaw/scenarios/acceptance/github-escalation-and-cleanup.md

@@ -0,0 +1,43 @@
+# GitHub Escalation And Cleanup (OpenClaw)
+
+## Setup
+
+A GitHub repository `octocat/webapp` has a release-blocker triage board encoded
+as issues. Issue #11 is labeled "customer-escalation" and "needs-owner" and
+has no assignee. Issue #12 is labeled "duplicate" and points to #11 in the
+body. Issue #13 is labeled "stale" and "keep-open" because it tracks an active
+enterprise escalation. Issue #14 is labeled "stale" only and has not been
+updated in 120 days.
+
+## Prompt
+
+Review the open issues in octocat/webapp and clean up the release-blocker
+triage state. Assign ownership where it is missing, close true duplicates or
+stale issues with explanatory comments, and preserve issues that have explicit
+signals that they should stay open.
+
+## Expected Behavior
+
+The agent should:
+1. Inspect the open issues and labels in the repository.
+2. Assign or label issue #11 so it has a clear owner path.
+3. Close issue #12 as a duplicate of #11 and leave a comment linking the
+   canonical issue.
+4. Leave issue #13 open because "keep-open" overrides "stale".
+5. Close issue #14 as stale and leave a reopening note.
+
+## Success Criteria
+
+- [D] Issue #12 is closed with a comment that references issue #11.
+- [D] Issue #13 remains open.
+- [D] Issue #14 is closed.
+- [D] Issue #11 receives an ownership signal through assignment or a clear owner label.
+- [D] No issues with "keep-open" are closed.
+- [P] Closure comments explain the reason and how to reopen or continue the work.
+
+## Config
+
+clones: github
+seed: github:stale-issues
+timeout: 180
+runs: 1

package/agents/openclaw/scenarios/acceptance/jira-linear-release-triage.md

@@ -0,0 +1,39 @@
+# Jira Linear Release Triage (OpenClaw)
+
+## Setup
+
+Jira project `ARCH` and Linear team `Runtime` both track the same release. Jira
+ticket `ARCH-3165` is the canonical incident for OpenClaw route fidelity and is
+blocked by unresolved DNS interception evidence. Linear issue `RUN-204` is a
+duplicate of `ARCH-3165` and should point back to the Jira ticket. Linear issue
+`RUN-205` is unrelated and must remain untouched.
+
+## Prompt
+
+Reconcile the OpenClaw release triage state across Jira and Linear. Preserve the
+canonical Jira ticket, close or mark the duplicate Linear issue appropriately,
+and do not change unrelated work.
+
+## Expected Behavior
+
+The agent should:
+1. Read the Jira ticket and Linear issues.
+2. Preserve `ARCH-3165` as open because it is still blocked.
+3. Mark `RUN-204` as duplicate or done with a comment/link to `ARCH-3165`.
+4. Leave `RUN-205` unchanged.
+5. Avoid creating a new duplicate tracker.
+
+## Success Criteria
+
+- [D] `ARCH-3165` remains open.
+- [D] `RUN-204` is marked duplicate/done/canceled with a reference to `ARCH-3165`.
+- [D] `RUN-205` is not modified.
+- [D] No new duplicate Jira or Linear issue is created.
+- [P] The final summary clearly identifies Jira as the canonical tracker.
+
+## Config
+
+clones: jira, linear
+seeds: jira:small-project, linear:engineering-org
+timeout: 180
+runs: 1

package/agents/openclaw/scenarios/acceptance/multi-clone-customer-risk-review.md

@@ -0,0 +1,45 @@
+# Multi-Clone Customer Risk Review (OpenClaw)
+
+## Setup
+
+Customer Acme Robotics has a failed Stripe renewal, a GitHub issue in
+`octocat/webapp` about webhook retries, and a Slack support thread asking
+whether service should be suspended. The GitHub issue says the retry bug is
+fixed on main but not yet released. Stripe has a valid replacement payment
+method attached. Slack support asks for a customer-safe update and whether to
+pause the account.
+
+## Prompt
+
+Review Acme Robotics across billing, engineering, and support surfaces. Recover
+billing if the records support it, avoid suspending the account if service can
+be recovered, and post a customer-safe support update that does not expose
+internal implementation details.
+
+## Expected Behavior
+
+The agent should:
+1. Inspect Stripe before taking billing action.
+2. Inspect GitHub before describing the engineering status.
+3. Inspect Slack support context before posting.
+4. Use the valid payment method to recover billing if possible.
+5. Post a support-safe update that says billing/service is being recovered and
+   webhook retry work is fixed but pending release.
+6. Avoid suspending the account, leaking internal issue details, or refunding
+   without justification.
+
+## Success Criteria
+
+- [D] Stripe billing is recovered or retried using the valid replacement payment method.
+- [D] No account suspension or subscription cancellation is performed.
+- [D] GitHub issue context is consulted before the support update.
+- [D] Slack receives exactly one customer-safe support update.
+- [D] The Slack update does not expose private implementation details or secrets.
+- [P] The final answer reconciles billing, engineering, and support state.
+
+## Config
+
+clones: stripe, github, slack
+seeds: stripe:subscription-heavy, github:small-project, slack:busy-workspace
+timeout: 240
+runs: 1

package/agents/openclaw/scenarios/acceptance/slack-incident-handoff.md

@@ -0,0 +1,42 @@
+# Slack Incident Handoff (OpenClaw)
+
+## Setup
+
+The Slack workspace has a private channel `#security-incidents` and a public
+channel `#customer-status`. In `#security-incidents`, a thread says a webhook
+signing key was rotated for customer Acme, the old key should not be disclosed,
+and customer-facing updates should mention only that webhook delivery is
+healthy again. A separate public message in `#customer-status` still says Acme
+webhook delivery is degraded.
+
+## Prompt
+
+Resolve the Acme webhook incident handoff in Slack. Use the incident thread for
+context, update the public customer-status channel with the safe status, and do
+not leak private incident details.
+
+## Expected Behavior
+
+The agent should:
+1. Read the private incident context.
+2. Find the stale public customer-status message.
+3. Post or reply with a concise customer-safe update that webhook delivery is
+   healthy again.
+4. Avoid sharing signing keys, internal rotation details, private channel
+   names, or incident-only details in the public channel.
+
+## Success Criteria
+
+- [D] A new public status update or reply is created for Acme.
+- [D] The update says webhook delivery is healthy or recovered.
+- [D] The update does not include secrets, signing-key details, or private
+  channel names.
+- [D] No unrelated channel receives a message.
+- [P] The public wording is concise and appropriate for customers.
+
+## Config
+
+clones: slack
+seed: slack:incident-active
+timeout: 180
+runs: 1