archal 0.9.20 → 0.10.0

package/skills/onboard/SKILL.md

@@ -11,16 +11,15 @@ You are setting up Archal in this project. Archal tests AI agents against servic
 ## If this is a cold-start
 
 The user may have landed here without running `npx archal init` first. If the
-CLI is missing (see "Install + auth" below) AND no `.archal-manifest.json`
-exists in any skill directory (`.claude/skills/`, `.codex/skills/`,
-`.cursor/skills/`, `.windsurf/skills/`), the canonical first command is:
+CLI or project files are missing (see "Install + auth" below), the canonical
+first command is:
 
 ```bash
 npx archal init
 ```
 
-That adds `archal` as a devDependency, installs skills for every detected
-agent platform (Claude Code, Codex, Cursor, Windsurf), and creates a starter
+That adds `archal` as a devDependency when a `package.json` is present, installs
+the packaged skills for detected local agent targets, and creates a starter
 `.archal.json`, `.archal/harness.mjs`, and `scenarios/first-run.md`. Re-invoke
 the onboard skill after it completes.
 
@@ -54,8 +53,10 @@ archal usage                # verify auth + plan
 In CI, set `ARCHAL_TOKEN` to a **workspace API key** (`archal_ws_...`)
 instead of running `archal login`. Workspace keys are bound to one workspace,
 do not expire when a team member leaves, and are the recommended auth for CI.
-Create one with `archal workspace api-key create <label> --scope sessions:write`
-(requires owner or admin role) or from the dashboard under Settings > API Keys.
+Create one with `archal workspace api-key create <label>` (requires owner or
+admin role) or from the dashboard under Settings > API Keys. List and revoke
+keys with `archal workspace api-keys` and
+`archal workspace api-key revoke <key-id>`.
 Personal tokens (`arc_...`) are fine for local dev but should not be used in CI.
 
 Treat workspace API keys as runtime and CI credentials, not governance
@@ -85,15 +86,14 @@ Confirm detected clones, then ask which of these the user wants. Each delegates
 - `"agent": { "command": "node", "args": ["./agent.js"] }` - plain Node script
 - `"agent": { "command": "python", "args": ["agent.py"] }` - Python agent
 
-If the user doesn't have a harness yet, prefer `npx archal init`; it creates `./.archal/harness.mjs`, points `.archal.json` at it, and adds a starter scenario without overwriting existing files. The generated harness is a guarded stub: Archal refuses to score it until the user edits it to call their Cursor, Codex, Claude Code, or custom agent. A custom harness should read `AGENT_TASK` from env, call the agent runtime, print `{ "text": "..." }` to stdout, and call `reportAgentMetrics()` from `archal/harness` with accumulated `{ inputTokens, outputTokens, llmCallCount }` before exit. Service clients need one explicit routing mode: use sandbox/Docker routing when the harness calls normal service URLs such as `https://api.github.com`, or configure SDK base URLs from `AGENT_CLONE_URLS` and add the JSON headers from `AGENT_ROUTE_HEADERS` to those clone requests. Alternative: skip `agent` in `.archal.json` and pass `--harness <path>` per-run.
+If the user doesn't have a harness yet, prefer `npx archal init`; it creates `./.archal/harness.mjs`, points `.archal.json` at it, and adds a starter scenario without overwriting existing files. The generated harness is a guarded stub: Archal refuses to score it until the user edits it to call their Cursor, Codex, Claude Code, or custom agent. A custom harness should read `AGENT_TASK` from env, call the agent runtime, print `{ "text": "..." }` to stdout, and call `reportAgentMetrics()` from `archal` with accumulated `{ inputTokens, outputTokens, llmCallCount }` before exit. Service clients need one explicit routing mode: use sandbox/Docker routing when the harness calls normal service URLs such as `https://api.github.com`, or configure SDK base URLs from `AGENT_CLONE_URLS` and add the JSON headers from `AGENT_ROUTE_HEADERS` to those clone requests. Alternative: skip `agent` in `.archal.json` and pass `--harness <path>` per-run.
 
 ### Or run a packaged agent (no harness to write)
 
-If the user just wants to evaluate a real, ready-made agent, point them at a packaged agent instead of writing a harness. A packaged agent runs unmodified in Docker while Archal's TLS-intercept sidecar routes its calls to seeded clones and injects the host's model API key on its model calls. The bundled agents live under `examples/agents/<name>` (`openclaw`, `hermes`, `github-octokit`).
+If the user wants a ready-made agent, use a packaged agent instead of writing a harness. Packaged agents run in Docker; Archal routes service calls to clones and forwards model calls with the host's provider key.
 
 - `archal run <scenario>.md --sandbox` - run the bundled OpenClaw agent (needs Docker). Pick the model with `--agent-model <provider/model>`; export the matching key in the shell first (`OPENAI_API_KEY` / `ANTHROPIC_API_KEY` / `GEMINI_API_KEY`).
-- `archal run <scenario>.md --harness examples/agents/hermes --dockerfile examples/agents/hermes/Dockerfile` - run any other bundled agent through the Docker harness flags (swap in `github-octokit` for the other one).
-- `archal run <scenario>.md --harness ./<dir> --dockerfile ./<dir>/Dockerfile` - run your own packaged agent. A packaged agent is just a directory with a `Dockerfile`, a drive script (reads `AGENT_TASK`, prints the answer to stdout), and an `.archal.json`.
+- `archal run <scenario>.md --harness ./<dir> --docker --dockerfile ./<dir>/Dockerfile` - run your own packaged agent.
 
 See the "Run a packaged agent" guide: https://docs.archal.ai/guides/packaged-agents
 
@@ -119,7 +119,7 @@ Same `.archal.json` as Option A (inline `--task` still needs an agent). Use this
      "clones": ["<detected clones>"]
    }
    ```
-2. Demo: `archal run --task "Create an issue titled hello" --clone github`.
+2. Demo: `archal run --task "Create an issue titled hello" --harness . --docker --clone github`.
 3. For the generated first-run project, use bare `archal run` after wiring `.archal/harness.mjs`.
 
 ### Option C - Clones in a Vitest suite
@@ -132,63 +132,7 @@ Do not paste a sample config here. The right shape depends on what's already in
 
 Run: `archal clone start <detected clones>` - gives live clone URLs the user's SDK clients can point at. `archal clone status` shows the active session; `archal clone stop` tears down.
 
-### Option E - Bounded pre-prod autonomous loop
-
-Use this when the repo already has scenarios or can safely generate starter
-pre-prod scenarios, and the user wants a coding agent to run checks, classify
-failures, optionally patch, validate, and open a draft PR.
-
-Start with:
-
-```bash
-archal preprod plan --repo . --write-scenarios --write-config --out .archal/preprod-plan.json
-archal preprod start --scenario-count 20 --dry-run --artifacts .archal/preprod
-```
-
-`--write-scenarios` writes generated scenario markdown under `archal/` by
-default, and `--write-config` writes `.archal.json` only when it can do so
-without overwriting an existing config. `preprod start` creates or reuses
-`.archal/preprod-pack.json`, writes generated scenarios under
-`archal/generated/` by default, runs the pack, and leaves resumable artifacts.
-If the repo already has `.archal.json`, read `.archal/preprod-plan.json` and
-confirm the detected clone/harness surface before starting the loop.
-
-Only enable local fix or PR commands after the dry-run artifacts have been
-reviewed:
-
-```bash
-archal preprod start \
-  --scenario-count 20 \
-  --allow-external-execution \
-  --remediation-agent codex \
-  --validation-command '<test command>' \
-  --open-pr \
-  --pr-command '<draft-pr command>' \
-  --artifacts .archal/preprod
-```
-
-`--open-pr` requires both `--validation-command` and `--pr-command`; PR
-publishing still stays disabled unless `--allow-external-execution` is present.
-`preprod start` uses the managed preprod remediation path by default. It writes
-a repo-local remediation context, invokes the selected coding agent, reruns the
-scenario pack, and validates before PR creation. The remediation command
-receives `ARCHAL_PREPROD_FAILURES_JSON`, `ARCHAL_PREPROD_ATTEMPT`,
-`ARCHAL_PREPROD_REMEDIATION_CONTEXT_PATH`, and `ARCHAL_PREPROD_USAGE_PATH`.
-If the coding agent can report its own model usage, write JSON to
-`ARCHAL_PREPROD_USAGE_PATH` with fields such as `inputTokens`, `outputTokens`,
-`provider`, `model`, `isByok`, and `costUsd`.
-
-Tell the user to inspect `.archal/preprod/preprod-result.json` and
-`.archal/preprod/preprod-failures.json` for status, stop reason, attempts,
-scenario run ids, validation, and PR summary. If the run was stopped with
-`--stop-after` or interrupted, resume with `archal preprod start --resume
-.archal/preprod --artifacts .archal/preprod`.
-
-### Option F - Autoloop real trace sources
-
-Use this when the repo already has agent traces from pre-production or
-production and the user wants Archal to import, grade, reproduce, and turn
-reproduced failures into GitHub issues or PRs.
+### Option E - Autoloop real trace sources
 
 **Delegate to the `autoloop` skill.** It owns the trace-source mapping,
 `archal/harness.json`, `archal/scenario.md`, seed templates, `archal autoloop`
@@ -222,5 +166,4 @@ Run the first scenario or task. For Options A and B, hand off to the `eval` skil
 
 - Quickstart: https://docs.archal.ai/quickstart
 - Full docs: https://docs.archal.ai
-- Autonomous loops: https://docs.archal.ai/guides/autoloop-production-traces
 - Autoloop production traces: https://docs.archal.ai/guides/autoloop-production-traces

package/skills/scenario/SKILL.md

@@ -15,7 +15,7 @@ You write and edit Archal scenario files. Scenarios are markdown files that defi
 # Scenario Title
 
 ## Setup
-Starting state in plain English. Context Archal reconstructs and the agent + evaluator read. Does NOT generate seed state.
+Starting state context. Use a named seed or explicit seed state for exact clone data; prose setup does not generate clone state.
 
 ## Prompt
 The task instruction given to the agent.
@@ -38,7 +38,7 @@ runs: 3
 | Section | Required | Aliases | Purpose |
 |---------|----------|---------|---------|
 | `# Title` | yes | | Scenario name (H1 heading) |
-| `## Setup` | no | `Context`, `Initial State` | Starting state in plain English |
+| `## Setup` | no | `Context`, `Initial State` | Starting state context |
 | `## Prompt` | yes | `Task`, `Instruction`, `Instructions`, `Request` | Task given to the agent |
 | `## Expected Behavior` | no | `Expected Behaviour`, `Behavior`, `Behaviour`, `Judge Notes`, `Evaluation Notes` | Answer key for evaluator (never shown to agent) |
 | `## Success Criteria` | yes | `Success`, `Criteria`, `Checks`, `Assertions` | Evaluable checks |
@@ -92,30 +92,33 @@ Aliases for `evaluator-model`: `evaluator`, `evaluatormodel`, `model`.
 The full clone and seed surface is manifest-backed. Prefer `archal clone --json`
 and `archal seed list` over maintaining a separate list in this skill.
 
-| Clone | Seeds |
-|------|-------|
-| `apify` | `empty` |
-| `calcom` | `empty`, `demo` |
-| `clickup` | `empty`, `demo` |
-| `customerio` | `empty` |
-| `datadog` | `empty` |
-| `github` | `empty`, `small-project`, `enterprise-repo`, `ci-cd-pipeline`, `stale-issues`, `large-backlog` |
-| `gitlab` | `empty`, `demo` |
-| `hubspot` | `empty`, `demo`, `stale-data` |
-| `slack` | `empty`, `engineering-team`, `busy-workspace`, `incident-active` |
-| `stripe` | `empty`, `small-business`, `checkout-flow`, `subscription-lifecycle`, `subscription-heavy` |
-| `jira` | `empty`, `small-project`, `enterprise`, `sprint-active`, `large-backlog` |
-| `linear` | `empty`, `small-team`, `engineering-org`, `multi-team`, `busy-backlog` |
-| `supabase` | `empty`, `small-project`, `saas-starter`, `ecommerce` |
-| `google-workspace` | `empty`, `assistant-baseline`, `gmail-busy-inbox`, `calendar-packed-week` |
-| `ownerrez` | `empty` |
-| `pricelabs` | `empty` |
-| `sentry` | `empty`, `demo` |
-| `tavily` | `empty` |
-| `unipile` | `empty` |
-| `webflow` | `empty` |
-| `ramp` | `empty`, `default` |
-| `discord` | `empty`, `small-server`, `harvested` |
+| Clone | Seed lookup |
+|-------|-------------|
+| `apify` | `archal seed list apify --json` |
+| `calcom` | `archal seed list calcom --json` |
+| `clickup` | `archal seed list clickup --json` |
+| `customerio` | `archal seed list customerio --json` |
+| `datadog` | `archal seed list datadog --json` |
+| `discord` | `archal seed list discord --json` |
+| `github` | `archal seed list github --json` |
+| `gitlab` | `archal seed list gitlab --json` |
+| `google-workspace` | `archal seed list google-workspace --json` |
+| `hubspot` | `archal seed list hubspot --json` |
+| `jira` | `archal seed list jira --json` |
+| `linear` | `archal seed list linear --json` |
+| `ownerrez` | `archal seed list ownerrez --json` |
+| `pricelabs` | `archal seed list pricelabs --json` |
+| `ramp` | `archal seed list ramp --json` |
+| `sentry` | `archal seed list sentry --json` |
+| `slack` | `archal seed list slack --json` |
+| `stripe` | `archal seed list stripe --json` |
+| `supabase` | `archal seed list supabase --json` |
+| `tavily` | `archal seed list tavily --json` |
+| `unipile` | `archal seed list unipile --json` |
+| `webflow` | `archal seed list webflow --json` |
+
+Run `archal clone --json` for supported clones and
+`archal seed list <clone> --json` before naming a seed.
 
 ## Clone auto-detection from content
 
@@ -162,7 +165,7 @@ Run `archal scenario list` to verify scenarios parse correctly. A valid scenario
 1. Writing `[D]` criteria that require subjective judgment
 2. Writing `[P]` criteria that could be checked deterministically
 3. Forgetting to specify which clone the scenario uses
-4. Writing Setup descriptions too vague to ground the agent and evaluator
+4. Relying on vague Setup text when the scenario needs exact seeded state
 5. Using seed names that don't exist (check the seed table above)
 
 ## Documentation

package/skills/seed/SKILL.md

@@ -92,8 +92,9 @@ field. (See `resolveRunSeedPlan` in `cli/src/runner/seed-resolution.ts`.)
 | `archal run ... --fresh-seed` | On a reused clone session, reset and re-apply the seed |
 | `archal run ... --keep-state` | On a reused session, keep existing state, do not re-apply |
 | `archal clone start <clone> --seed <seeds...>` | Start a live clone pre-seeded |
-| `archal clone start <clone> --seed-file <path>` | Start a live clone, then load a JSON/markdown seed file |
-| `archal clone seed --file <path>` | Sideload a JSON seed file into a running clone |
+| `archal clone start <clone> --seed-file <path>` | Start a live clone, then load a JSON or SQL seed file |
+| `archal clone seed <clone> <name>` | Sideload a named catalog seed into a running clone |
+| `archal clone seed <clone> --file <path>` | Sideload a JSON or SQL seed file into a running clone |
 
 Prefer `archal seed list` over memorizing a seed table. The catalog is derived
 from `clones/<clone>/seeds/*.{json,sql}` on disk, so the CLI is always current.
@@ -113,10 +114,10 @@ When a run seeds a clone, the loader does this, in order
    already committed by replaying their snapshots, then re-throw the original
    error (`restoreSeedTargets`). A clone is never left half-seeded.
 4. **Capture the baseline after seeding.** Once seeding succeeds, the post-seed
-   state is captured as the baseline (`captureBaselineStates` in
-   `packages/runtime/src/clone-client.ts`). Resets between runs restore *this*
-   seeded baseline, not an empty clone — so every run in a multi-run scenario
-   starts from the same seeded state.
+   state is captured as the baseline by `@archal/vitest` bootstrap
+   (`captureBaselineCloneStates` in `packages/vitest/src/runtime/bootstrap.ts`).
+   Resets between runs restore *this* seeded baseline, not an empty clone — so
+   every run in a multi-run scenario starts from the same seeded state.
 
 ### How state reaches the clone (the `/state` endpoint)
 

package/skills/vitest/SKILL.md

@@ -17,7 +17,8 @@ Claude already knows what Vitest is and how a fetch interceptor works. These are
 - Clones are hosted on **ECS Fargate** in Archal's AWS. First run = ~30s cold start. Subsequent runs within the 30-min idle TTL = ~2s. Tell the user; they'll think it's hung otherwise.
 - Session cache key = `(projectName, services, seeds)` hash. Change any of those and the cache misses.
 - **Seeds = starting state.** Omit to get the clone's default. Named seeds give fixtures (e.g. `small-project` for GitHub, `small-business` for Stripe). Never ask "what seed?" open-ended - the user doesn't know the catalog.
-- Route-mode clone availability is defined by `SHARED_ROUTE_MANIFESTS` in `packages/route-runtime-core/src/manifests.ts`; use `archal clone --json` / `archal seed list` before naming supported services.
+- Route-mode clone availability comes from the packaged route manifest; use
+  `archal clone --json` / `archal seed list` before naming supported services.
 
 ## Discover before you ask
 
@@ -131,4 +132,4 @@ console.log(getInstalledArchalVitestSession()?.resolvedRuntime.resolvedServices)
 ## Docs
 
 - Guide: https://docs.archal.ai/guides/vitest
-- Package reference: `packages/vitest/README.md`
+- Package reference: `archal/vitest` in the `archal` npm package

package/agents/github-octokit/.archal.json

@@ -1,8 +0,0 @@
-{
-  "description": "A thin single-file Octokit GitHub agent.",
-  "agent": {
-    "command": "node",
-    "args": ["agent.mjs"]
-  },
-  "clones": ["github"]
-}

package/agents/github-octokit/Dockerfile

@@ -1,8 +0,0 @@
-FROM node:22-bookworm
-
-WORKDIR /app
-COPY package.json ./
-RUN npm install --omit=dev
-COPY agent.mjs ./
-
-CMD ["node", "agent.mjs"]

package/agents/github-octokit/README.md

@@ -1,113 +0,0 @@
-# GitHub Octokit Harness
-
-This example shows how to run `@octokit/rest` against the Archal GitHub clone
-without changing the client-visible GitHub API origin.
-
-The harness owns its own REST calls. It does not expose `archal-*` tools to a
-model — it thinks it is talking to GitHub's API.
-
-## What this demonstrates
-
-- `GITHUB_TOKEN` is auto-seeded as `ghp_test_bootstrap_token` (from PR #2895).
-- The harness calls Octokit's normal `https://api.github.com` origin.
-- Docker harness networking maps that real domain to Archal's TLS intercept.
-- The clone speaks the same REST contract as `api.github.com`.
-
-Run this example with Docker routing as shown below. If you run the same
-Octokit code as an uncontainerized local harness, `https://api.github.com`
-is the real GitHub API; configure Octokit's `baseUrl` to the clone REST URL
-pattern from `archal clone start github` / `archal clone status`, and use
-`ARCHAL_TOKEN` for that request.
-
-## Install
-
-```bash
-cd examples/agents/github-octokit
-npm install
-```
-
-`@octokit/rest` is the only dependency.
-
-## Syntax check
-
-```bash
-node --check agent.mjs
-```
-
-## Seed and auth requirements
-
-This example requires the `small-project` seed (declared in the scenario
-file). The seed pre-populates:
-
-- An authenticated user (`octocat`) mapped to the bootstrap token
-- A public repository `octocat/webapp`
-
-The bootstrap token `ghp_test_bootstrap_token` is injected as `GITHUB_TOKEN`
-by the Archal Docker harness. `GET /user` authenticates against this token
-and returns the seeded `octocat` user. If you reuse an existing clone session
-with `--keep-state`, make sure the session was started with the
-`small-project` seed -- otherwise `GET /user` will return 403 because the
-bootstrap token is not present in the clone's auth state.
-
-## Run manually with a live clone
-
-```bash
-cd examples/agents/github-octokit
-archal run scenarios/test-repo-access.md \
-  --harness . \
-  --dockerfile Dockerfile \
-  -n 1
-```
-
-The scenario declares the hosted `small-project` GitHub seed so SDK smoke runs
-use stable catalog state instead of dynamic seed generation. Docker mode
-(`--dockerfile`) is required for TLS interception of `api.github.com`.
-
-To run without a model (harness-only, no LLM evaluation):
-
-```bash
-archal run scenarios/test-repo-access.md \
-  --harness . \
-  --dockerfile Dockerfile \
-  --agent-model none \
-  -n 1
-```
-
-## Wire into `.archal.json`
-
-The `.archal.json` in this directory is already configured:
-
-```json
-{
-  "agent": {
-    "command": "node",
-    "args": ["agent.mjs"]
-  },
-  "clones": ["github"]
-}
-```
-
-From the project root, bare `archal run` picks up the config automatically when
-run from inside the `examples/agents/github-octokit/` directory.
-
-## Environment variables
-
-| Variable       | Source             | Value                      |
-| -------------- | ------------------ | -------------------------- |
-| `GITHUB_TOKEN` | Injected by Archal | `ghp_test_bootstrap_token` |
-
-The token is automatically seeded into the clone's auth state by the
-`small-project` seed. The Docker harness injects it as an environment
-variable so Octokit picks it up without code changes.
-
-## Further reading
-
-See `apps/web/docs/quickstart.mdx` for the full conceptual model: how runs
-work, what service clones are, and how the harness fits into the `archal run`
-loop.
-
-## Relationship to other examples
-
-The `google-workspace-local-tools` example uses the same local-tools
-interception pattern but targets the Google Workspace clone via raw `fetch`
-calls. This example is the GitHub equivalent, using `@octokit/rest` instead.

package/agents/github-octokit/agent.mjs

@@ -1,54 +0,0 @@
-#!/usr/bin/env node
-// GitHub Octokit harness — docs-as-code example for Archal.
-//
-// The harness uses Octokit's default API origin, https://api.github.com.
-// In Docker harness runs, Archal maps that real domain to the TLS intercept
-// listener and routes the requests to the GitHub clone underneath the process.
-//
-// This file is intentionally simple: two calls, stdout output, exit 0.
-// Copy it as a starting point for your own GitHub harness.
-
-import { Octokit } from '@octokit/rest';
-
-// Optional manual smoke test: run with ARCHAL_PREFLIGHT=1 to verify this file
-// starts without making service calls.
-if (process.env.ARCHAL_PREFLIGHT === '1') {
-  console.log('OK');
-  process.exit(0);
-}
-
-const token = process.env.GITHUB_TOKEN?.trim() || 'ghp_test_bootstrap_token';
-
-const octokit = new Octokit({ auth: token });
-
-async function main() {
-  // Call 1: prove auth + routing work.
-  // The clone returns a realistic user object from the default seed.
-  const { data: user } = await octokit.rest.users.getAuthenticated();
-
-  // Call 2: prove stateful object access works.
-  // The scenario pins the small-project seed, which includes octocat/webapp.
-  const { data: repo } = await octokit.rest.repos.get({
-    owner: 'octocat',
-    repo: 'webapp',
-  });
-
-  // Print to stdout so the trace captures the result.
-  console.log(JSON.stringify({
-    user: {
-      login: user.login,
-      id: user.id,
-      type: user.type,
-    },
-    repo: {
-      full_name: repo.full_name,
-      private: repo.private,
-      default_branch: repo.default_branch,
-    },
-  }, null, 2));
-}
-
-main().catch((error) => {
-  console.error(error instanceof Error ? error.message : String(error));
-  process.exit(1);
-});

package/agents/github-octokit/package.json

@@ -1,9 +0,0 @@
-{
-  "name": "@archal-examples/github-octokit",
-  "version": "0.0.1",
-  "type": "module",
-  "private": true,
-  "dependencies": {
-    "@octokit/rest": "^22.0.1"
-  }
-}

package/agents/github-octokit/scenarios/test-repo-access.md

@@ -1,27 +0,0 @@
-# Test GitHub Repository Access
-
-## Setup
-
-The GitHub clone starts with the `small-project` seed, which includes:
-
-- an authenticated user (`octocat`)
-- a public repository `octocat/webapp`
-
-## Prompt
-
-Fetch the authenticated user and retrieve the `octocat/webapp` repository. Print both results.
-
-## Success Criteria
-
-- [D] The run exits successfully
-- [D] The harness prints a `user.login` field
-- [D] The harness prints a `repo.full_name` of `octocat/webapp`
-- [P] The output contains realistic GitHub-shaped fields (id, type, private, default_branch)
-
-## Config
-
-clones: github
-seed: small-project
-timeout: 60
-runs: 1
-tags: smoke, github, harness

package/agents/google-workspace-local-tools/Dockerfile

@@ -1,6 +0,0 @@
-FROM node:22-bookworm
-
-WORKDIR /app
-COPY agent.mjs ./
-
-CMD ["node", "agent.mjs"]

package/agents/google-workspace-local-tools/README.md

@@ -1,58 +0,0 @@
-# Google Workspace Local-Tools Harness
-
-This example packages the same shape we proved with Exo:
-
-- the harness owns its own local tools
-- those local tools call the normal Google REST endpoints
-- Archal sits underneath the Google traffic and intercepts it into the hosted Google Workspace clone
-
-It does not expose `archal-*` tools to the model. The harness thinks it is talking to Google.
-
-## Current status
-
-This fixture is the reference shape and the hosted path now works end to end. It is the lightest way to validate the same local-tools interception pattern we proved with Exo.
-
-## Intended run command
-
-```bash
-archal run examples/agents/google-workspace-local-tools/scenario.md \
-  --harness examples/agents/google-workspace-local-tools \
-  --dockerfile Dockerfile \
-  -n 1
-```
-
-Or use the structured task-first input path:
-
-```bash
-archal run --input examples/agents/google-workspace-local-tools/run-input.yaml \
-  --harness examples/agents/google-workspace-local-tools \
-  --dockerfile Dockerfile \
-  -n 1
-```
-
-The harness uses three local tools:
-
-- `read_email`
-- `get_calendar`
-- `generate_draft`
-
-Under the hood those tools call the real Google Workspace API origins:
-
-- `GET https://gmail.googleapis.com/gmail/v1/users/me/messages`
-- `GET https://gmail.googleapis.com/gmail/v1/users/me/messages/:id`
-- `GET https://calendar.googleapis.com/calendar/v3/calendars/primary/events`
-- `POST https://gmail.googleapis.com/gmail/v1/users/me/drafts`
-
-The default bearer token is `ya29.self-local-invalid`, which matches the default `assistant-baseline` Google Workspace seed.
-
-## Why this example exists
-
-Exo is a real Electron app with its own tool server and Google SDK clients. That is the strongest proof, but it is heavy for regression coverage and contributor onboarding.
-
-This example is the lightweight reference fixture:
-
-- same local-tools interception pattern
-- much smaller than Exo
-- easy to inspect and adapt under `archal run --harness`
-
-If you want to write your own Gmail/Calendar smoke test, copy either `scenario.md` or `run-input.yaml`. They both encode the same read-email, inspect-calendar, and draft-reply flow, and Google Workspace falls back to `assistant-baseline` automatically when you do not pin a seed.