[
{
"id": "orch-scheduled-job-list-get",
"concept": "scheduled_job",
"verbs": "list/get",
"capability": "Scheduled job: list/get",
"semantics": "Enumerate the harness's install-scoped scheduled jobs and read one job's definition",
"hermes": "variant",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓* `hermes cron list` over `~/.hermes/cron/jobs.json` (per profile); no per-job `get` at the pin — `cron status` reports the scheduler, not a job",
"openclaw_detail": "✓ `openclaw cron list` + `cron get <id>` (JSON) / `cron show <id>` over the shared state DB, via the Gateway",
"orchestrator_detail": "✓ `cron/jobs.json` per profile folder, in Hermes's own job schema (`docs/ORCHESTRATOR-IR.md` §6); the file IS the source of truth — there is no other store and no daemon copy of it",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron list"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron list"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron get"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "cron/jobs.json"
},
{
"kind": "store",
"harness": "orchestrator",
"path": "profiles"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "fn collect_hermes_shaped_jobs"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "HarnessId::ORCHESTRATOR => crate::orchestrator_profile_dirs"
}
],
"orchestrator_note": "ORC-7: `jobs list|get --harness orchestrator` read every profile folder's `cron/jobs.json` through the SAME reader Hermes's rows go through (one implementation, a harness-id parameter), projecting schedule, payload, delivery, enabled/state and next/last run onto the uniform row and returning the native record verbatim from `get`. Executed against a seeded root (receipt orc7-orchestrator-registry-receipt-2026-09-04.json). Unlike the Hermes row there is no second door to miss: the orchestrator has no CLI, and its daemon writes this same file — the loop's tick claims and fires due jobs into it (ORC-5), so a listed job is a job something schedules.",
"provenance": "inventory concept 6 (Scheduled job), build list: observed + controlled, M",
"status": "partial",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "cron/jobs.json"
},
{
"kind": "store",
"harness": "hermes",
"path": "profiles/<name>/cron/jobs.json"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "pub fn list_jobs"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.jobs.list\""
},
{
"kind": "store",
"harness": "openclaw",
"path": "state/openclaw.sqlite"
},
{
"kind": "store",
"harness": "openclaw",
"path": "cron/jobs.json"
}
],
"note": "ORCH-7 landed the observed half: `harness.v1.jobs.list|get` and `supercode jobs list|get` read Hermes's `cron/jobs.json` (under HERMES_HOME and each `profiles/<name>/cron/`) and OpenClaw's `cron/jobs.json`, projecting both onto one row (schedule, payload, session target, delivery, enabled/state, next/last run, profile) with the native record returned verbatim by `get`. Still missing, and why this is not `implemented`: the read is over the harnesses' FILES only. Neither `hermes cron list` nor OpenClaw's Gateway `cron list` is called, so a job a running gateway holds but has not flushed is invisible; and OpenClaw upstream has moved its cron store into the shared SQLite state DB, which this loader does not open — such an install reports `absent_store` honestly rather than failing. Review 2026-09-03: at the pin OpenClaw stores jobs in `state/openclaw.sqlite` (`cron_jobs`); `cron/jobs.json` is only the table's store_key — the loader now reads the SQLite table first and the file as legacy (receipt orch7-openclaw-jobs-receipt-2026-09-03.json)."
},
{
"id": "orch-scheduled-job-create-update-pause-resume-run-delete",
"concept": "scheduled_job",
"verbs": "create/update/pause/resume/run/delete",
"capability": "Scheduled job: create/update/pause/resume/run/delete",
"semantics": "Create, edit, pause/resume, run-now and delete a scheduled job through the harness's own verb",
"hermes": "yes",
"openclaw": "variant",
"orchestrator": "yes",
"hermes_detail": "✓ `hermes cron create|edit|pause|resume|run|remove` (all six verbs, install-scoped)",
"openclaw_detail": "✓* `openclaw cron add|edit|enable|disable|run|rm` — pause/resume are spelled `enable`/`disable`",
"orchestrator_detail": "✓ a job is a record in `cron/jobs.json`, written by the package's own `save(state, root)`; there is no CLI verb behind it — the write door is the daemon's operator socket, and the package's own CLI when the daemon is down",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron create"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron edit"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron pause"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron resume"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron run"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron remove"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron add"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron edit"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron enable"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron disable"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron run"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron rm"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "code",
"path": "crates/harness/src/jobs_control.rs",
"symbol": "fn orchestrator_mutate"
},
{
"kind": "code",
"path": "crates/harness/src/jobs_control.rs",
"symbol": "fn orchestrator_args"
},
{
"kind": "code",
"path": "crates/harness/src/orchestrator_door.rs",
"symbol": "pub fn call"
},
{
"kind": "code",
"path": "sdk/orchestrator/operator.mjs",
"symbol": "export async function applyOperator"
},
{
"kind": "code",
"path": "sdk/orchestrator/mcp/bridge.mjs",
"symbol": "async function dispatchOperator"
},
{
"kind": "store",
"harness": "orchestrator",
"path": "cron/jobs.json"
}
],
"orchestrator_note": "ORC-13 landed the write half. `jobs create|update|pause|resume|run|delete --harness orchestrator` go through the orchestrator's OWN door the way hermes's rows go through `hermes cron …`: the uniform row is translated onto the IR's job vocabulary (§2.6 — typed schedule, prompt, hermes's `deliver` grammar) and handed to `applyOperator` inside the `supercode-orchestrator` package, which dispatches the matching `events.operator` and lets the reducer's `save` effect write the folder. supercode writes no file of that folder itself. Two doors, one code path: the daemon's local socket `<root>/orchestrator.sock` while the lease names a live pid (so the write is ordered on the loop's own queue and the running loop's state and the folder can never disagree), and `node bin/orchestrator.mjs <op> --root …` when it is down. After each verb the row is re-read through the SAME ORC-7 loader `jobs list` uses, `ran` narrates the exact door, and a verb the reducer refused surfaces the reducer's own line (`jobs_delete: no job …`) rather than a silent no-op. A field the model has no home for is refused, never dropped: there is no session-target (a fire opens its own binding on the job's origin surface, §4.3) and no `command`/`system_event`/`script` payload. Receipted end-to-end on a fresh temp root, both doors, with the folder hashed before and after (receipt orc13-orchestrator-write-door-receipt-2026-09-04.json).",
"provenance": "inventory concept 6 (Scheduled job), controlled tier",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/jobs_control.rs",
"symbol": "pub fn mutate"
},
{
"kind": "code",
"path": "crates/harness/src/jobs_control.rs",
"symbol": "fn hermes_command"
},
{
"kind": "code",
"path": "crates/harness/src/jobs_control.rs",
"symbol": "fn openclaw_command"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.jobs.create\""
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.jobs.delete\""
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn job_mutation_cmd"
}
],
"note": "ORCH-18 landed the controlled tier: `harness.v1.jobs.create|update|pause|resume|run|delete` and `supercode jobs <verb> --harness X` translate the uniform row onto the HARNESS'S OWN verb and run it — `hermes cron create|edit|pause|resume|run|remove` with HERMES_HOME (a profile is its own HERMES_HOME), `openclaw cron add|edit|disable|enable|run|rm` through the Gateway whose URL and token supercode resolves from openclaw's own config via the registry connect descriptor. supercode runs no cron engine: after each verb the row is re-read through the ORCH-7 loader, every outcome narrates the exact command in `ran` with the credential redacted, and a failed verb surfaces the harness's own stderr. Receipted end-to-end on both pinned installs (orch18-hermes-jobs-receipt-2026-09-03.json on hermes 0.21.0 — 6 verbs, `hermes cron list --all` agreeing at every step; orch18-openclaw-jobs-receipt-2026-09-03.json on an isolated openclaw 2026.7.1-2 gateway — the same 6 verbs plus a step where the harness itself refuses and its sentence surfaces, `openclaw cron list --all --json` agreeing at every step). Honest edges, all refused rather than faked: Claude Code has jobs but no client-callable verb (they are created by the model inside a session), hermes has no session-target verb, and openclaw has no script payload. Measured against the pin: `openclaw cron edit` rejects `--json`."
},
{
"id": "orch-run-list-get",
"concept": "run",
"verbs": "list/get",
"capability": "Run: list/get",
"semantics": "List one job's past fires and read a fire's outcome",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "yes",
"hermes_detail": "✓* `hermes cron runs` (alias `history`) over `cron/executions.db`; the listing is per-scheduler, not a per-run `get`",
"openclaw_detail": "✓* `openclaw cron runs --id <jobId>` (with `--run-id` for one exact run) over the `cron_run_logs` table in the shared state DB",
"orchestrator_detail": "✓ `cron/executions.db` per profile folder, Hermes's `executions` columns verbatim (`docs/ORCHESTRATOR-IR.md` §6)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "cron runs"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "cron runs"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "cron/executions.db"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn collect_hermes_shaped"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn orchestrator_ledgers"
}
],
"orchestrator_note": "ORC-7: `runs list|get --harness orchestrator` read every profile folder's fire ledger through the same reader as Hermes's, including ORCH-13's delivery join against that folder's own `delivery_obligations`. Executed against a seeded root with one fire and its obligation, which reported `delivered`. The ledger is only ever populated by the scheduler ORC-5 builds; reading it is complete now, and a home whose ledger does not exist reports `absent_store` per profile rather than an empty history.",
"provenance": "inventory concept 7 (Run / fire), build list: observed only, S; fact-finders F2/F4 closed",
"status": "partial",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "cron/executions.db"
},
{
"kind": "store",
"harness": "hermes",
"path": "profiles/<name>/cron/executions.db"
},
{
"kind": "store",
"harness": "openclaw",
"path": "state/openclaw.sqlite/cron_run_logs"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "pub fn list_runs"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn join_hermes_session"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.runs.list\""
}
],
"note": "ORCH-8 landed the observed half: `harness.v1.runs.list|get` and `supercode runs list|get` read Hermes's `cron/executions.db` (under HERMES_HOME and each `profiles/<name>/cron/`, since a Hermes profile home is itself a full HERMES_HOME) and OpenClaw's `cron_run_logs` in the shared state DB (`state/openclaw.sqlite` at the pin — `cron_run_receipts` is upstream `main`'s spelling, not this version's), projecting both onto one row: run id, job, the harness's own status word, claimed/started/finished, error, and the session the fire opened. Hermes writes no link from a fire to its session, so that join is recovered from the `cron_<job_id>_<YYYYMMDD_HHMMSS>` id whose instant falls inside the fire's own [claimed_at, finished_at] window, then followed to a compression chain's tip; a fire with no session in its window answers null rather than borrowing a neighbour's. `get` returns the store's row verbatim beside the uniform one. Still missing, and why this is not `implemented`: the read is over the harnesses' STORES only — neither `hermes cron runs` nor OpenClaw's Gateway `cron runs` is called, so a fire a running scheduler holds but has not committed is invisible; the row's `delivery` field is filled by ORCH-13 from each harness's own delivery record (see `orch-delivery-target`), and stays null for a fire neither ledger matches."
},
{
"id": "orch-conversation-surface-key-and-scope",
"concept": "conversation",
"verbs": "surface key + scope",
"capability": "Conversation: surface key + scope",
"semantics": "A conversation is addressed by an explicit surface key and carries a declared scope/expiry policy",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "yes",
"hermes_detail": "✓* `session_key` = `agent:<profile>:<platform>:<chat_type>:<chat_id>[:<thread>][:<participant>]` in `state.db sessions`, listed by `hermes sessions list`; scope/expiry is an idle/daily config policy, not a per-conversation field",
"openclaw_detail": "✓* `agent:<id>:<channel>:<kind>:<id>[:thread]` (DMs collapse to `agent:<id>:main`), listed by `openclaw sessions list`; scope is `session.dmScope`/`groupScope` config",
"orchestrator_detail": "✓ `bindings` table per profile folder — the one record Hermes keeps inside its sessions table, ours as a first-class row (`docs/ORCHESTRATOR-IR.md` §2.5); the key renders as `agent:<profile>:<platform>:<chat_type>[:…]`, Hermes's own form",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "sessions list"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "sessions list"
}
],
"orchestrator_status": "partial",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "state.db/bindings"
},
{
"kind": "code",
"path": "crates/interchange/src/catalog.rs",
"symbol": "fn discover_orchestrator"
},
{
"kind": "code",
"path": "crates/interchange/src/catalog.rs",
"symbol": "fn orchestrator_descriptor"
}
],
"orchestrator_note": "ORC-7 landed the surface half: `sessions list --harness orchestrator` lists one row per binding with the surface badge, the trigger (`cron` when the row carries a `recurrence_job_id`, `webhook` on that platform, `channel` otherwise), the profile folder it belongs to, and the worker harness + session id the binding addresses. Missing: the SCOPE half. `expiry:` (idle minutes, daily reset hour, per-chat/per-user/per-thread scope) is a `config.yaml` block no reader surfaces, so a listed conversation does not say when it will expire; and the binding is not joinable to its worker transcript by any verb — reading the conversation still means addressing the worker harness's own session by hand.",
"provenance": "inventory concept 5 (Conversation), build list: observed + controlled, M; ORCH-3 derivation tables",
"status": "partial",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "state.db/sessions/session_key"
},
{
"kind": "store",
"harness": "openclaw",
"path": "agents/<agentId>/sessions"
},
{
"kind": "code",
"path": "crates/interchange/src/ontology/binding.rs",
"symbol": "pub fn parse_hermes_session_key("
},
{
"kind": "code",
"path": "crates/interchange/src/ontology/binding.rs",
"symbol": "pub fn parse_openclaw_session_key("
},
{
"kind": "code",
"path": "crates/interchange/src/ontology/surface.rs",
"symbol": "pub struct SurfaceKey {"
}
],
"note": "ORCH-3 landed the READ half of the key: both harnesses' session keys are parsed into the shared `SurfaceKey` noun (platform/channel, chat kind, chat id, thread, participant, agent/profile) — Hermes's from the `session_key` column plus the gateway columns that override it, OpenClaw's from the transcript header's `sessionKey` — and `inspect --json` exposes them. Two halves are missing: `sessions list` still prints title/cwd only, so a listed conversation cannot be picked by its surface (that is ORCH-6), and scope/expiry is not modelled at all — neither Hermes's idle/daily policy nor OpenClaw's `dmScope`/`groupScope` is read."
},
{
"id": "orch-conversation-new-reset-archive-delete",
"concept": "conversation",
"verbs": "new/reset/archive/delete",
"capability": "Conversation: new/reset/archive/delete",
"semantics": "Start a new, reset, archive or delete a conversation through the harness's own verb",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "variant",
"hermes_detail": "✓* `hermes sessions delete <id>` is per-session; `sessions archive` is a BULK filter verb (--older-than / --title / --cwd ...) with no per-session selector, so \"archive THIS conversation\" is not expressible. `/reset` IS carried by the ACP door (acp_adapter/server.py `_SLASH_COMMANDS`) and clears the conversation in place; `/new` is GATEWAY-only (gateway/slash_commands.py) and the ACP adapter sends any unrecognized `/word` to the model as prose",
"openclaw_detail": "✓* `openclaw sessions cleanup` (store maintenance) and `sessions compact` only — the pinned CLI has no `archive` or `delete` subcommand. BOTH `/new` and `/reset` are carried by its ACP door (openclaw@2026.7.1-2 `dist/commands-*.js` BASE_AVAILABLE_COMMANDS), so a live driven session can run them",
"orchestrator_detail": "✓* `/new` and `/reset` are chat commands the DAEMON applies to a binding (`docs/ORCHESTRATOR-IR.md` §4.5, §2.7), reachable from outside a chat through its operator door; there is no archive or delete — a binding ends, and its transcript belongs to the worker",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "sessions delete"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "sessions prune"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "sessions archive"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "sessions cleanup"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "sessions compact"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "code",
"path": "crates/harness/src/sessions_control.rs",
"symbol": "fn orchestrator_mutate"
},
{
"kind": "code",
"path": "crates/harness/src/sessions_control.rs",
"symbol": "SessionDoor::Daemon"
},
{
"kind": "code",
"path": "crates/harness/src/orchestrator_door.rs",
"symbol": "pub fn call"
},
{
"kind": "code",
"path": "sdk/orchestrator/operator.mjs",
"symbol": "export async function applyOperator"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn session_lifecycle_cmd"
},
{
"kind": "store",
"harness": "orchestrator",
"path": "state.db"
}
],
"orchestrator_note": "ORC-13: the two verbs the orchestrator's model HAS are now controlled. `sessions new|reset --harness orchestrator --surface <platform|chat_type|chat_id|thread_id|participant_id>` reach the very reducer a human's `/new` or `/reset` chat message reaches (§4.5) — through the daemon's operator socket while it is up, and through the package's own CLI when it is down. The conversation is named by its SURFACE, not by an id: an orchestrator conversation is a BINDING (§2.5) and a binding has no id of its own, so `--surface` is the selector and `--session` is refused for it. Afterwards the binding is re-read through the same ORCH-6 discovery loader `sessions list --harness orchestrator` uses, and its `end_reason` is what proves the verb landed. A surface with no LIVE binding refuses by name rather than reporting an empty success. Archive and delete stay refused, and not for want of a door: the model has neither — a binding ends, and the transcript belongs to the worker harness the binding addresses, which is where `sessions.archive|delete` is performed. Receipted on a fresh temp root with a seeded conversation (receipt orc13-orchestrator-write-door-receipt-2026-09-04.json).",
"provenance": "inventory concept 5 (Conversation), controlled tier; corrected against the pinned CLIs (the inventory lists `openclaw sessions archive|delete`, which v2026.7.1-2 does not register)",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/sessions_control.rs",
"symbol": "pub fn door"
},
{
"kind": "code",
"path": "crates/harness/src/sessions_control.rs",
"symbol": "pub async fn mutate"
},
{
"kind": "code",
"path": "crates/harness/src/sessions_control.rs",
"symbol": "async fn opencode_call"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.sessions.reset\""
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "async fn mutate_session"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn live_session_command_cmd"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "async fn session_control_cmd"
}
],
"note": "ORCH-19 landed the controlled tier as far as the harnesses' own doors reach: `harness.v1.sessions.new|reset|archive|delete` and `supercode sessions archive|delete --harness X` / `sessions new|reset --harness X --session <live runtime>` go through the HARNESS'S OWN door and re-read the row afterwards. Hermes: `/reset` typed into a live driven session over the same `send_input` a human's message takes, plus `hermes sessions delete <id> --yes`. OpenClaw: `/new` and `/reset` in a live driven session, joined through the registry's connect descriptor. Codex: `codex archive <id>` / `codex delete <id> --force` under an isolated CODEX_HOME. OpenCode: its own running server's session API (never a direct DB write). supercode's own store keeps the Domain 5 verb unchanged. Still `partial`, and each gap is a REFUSAL that names its reason, never a silent no-op: hermes has no per-session archive verb (its `sessions archive` is bulk-by-filter) and its ACP door does not carry `/new` (gateway-only, and an unrecognized `/word` there would go to the model as prose); openclaw registers neither `archive` nor `delete` at the pin; Claude Code publishes no conversation lifecycle verb at all (retention window only). Receipted on this box: orch19-codex-sessions-receipt-2026-09-03.json (real codex 0.152.0, isolated CODEX_HOME, archive moves the rollout into `archived_sessions/` and delete removes it, supercode's own listing agreeing both ways), orch19-hermes-reset-receipt-2026-09-03.json (real hermes-acp on an isolated HERMES_HOME + mock provider; `state.db` read read-only through a copy), orch19-openclaw-new-receipt-2026-09-03.json (isolated pinned 2026.7.1-2 gateway; the gateway itself answers \"New session started.\" / \"Session reset.\" where the mock model would have answered otherwise). Zero model spend in all three.",
"cost": "architectural"
},
{
"id": "orch-pending-request-list",
"concept": "pending_request",
"verbs": "list",
"capability": "Pending request: list",
"semantics": "Enumerate the permission/approval requests currently awaiting an answer",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "variant",
"hermes_detail": "✓* live only: a request exists while a turn is blocked on it, surfaced over the `hermes acp` bridge (ACP `session/request_permission`) or the chat prompt; `state.db` keeps no pending queue",
"openclaw_detail": "✓* live only over `openclaw acp` / the Gateway; `openclaw approvals get` fetches the exec-approvals POLICY snapshot, not a queue of outstanding requests",
"orchestrator_detail": "✓* a worker's permission/question request is relayed to the surface and held in `runtime.pending_requests`, which is NEVER persisted (`docs/ORCHESTRATOR-IR.md` §2.8, §4.2)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "acp"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "acp"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "approvals get"
}
],
"orchestrator_status": "absent",
"orchestrator_evidence": [],
"orchestrator_note": "Absent, and for the same reason it is only `partial` for the other two: a request exists solely inside the process holding the worker connection. Here that process is the daemon, which keeps them in `runtime.pending_requests` — never persisted (`docs/ORCHESTRATOR-IR.md` §2.8) — and publishes no query door. `approvals list --harness orchestrator` refuses: the orchestrator's runtime descriptor declares `respond_to_requests: false`, which is what makes the concept absent rather than empty.",
"orchestrator_cost": "architectural",
"provenance": "inventory concept 12 (Approval), build list: observed + controlled, M; corrected against the pinned CLIs (neither `hermes approvals` nor `openclaw approvals pending|resolve|grants` exists at the pin)",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/approvals.rs",
"symbol": "pub fn classify_live_request("
},
{
"kind": "code",
"path": "crates/harness/src/approvals.rs",
"symbol": "\"session/request_permission\" => acp_request(payload)"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.approvals.list"
},
{
"kind": "code",
"path": "crates/harness/src/support.rs",
"symbol": "descriptor.runtime.capabilities.respond_to_requests"
}
],
"note": "ORCH-9 (observed tier): `harness.v1.approvals.list` / `supercode approvals list` enumerate the requests waiting for an answer in one uniform row (id, harness, kind, status, subject, session_id, runtime_id, requested_at_ms, age_ms, options). Both harnesses mount as `AcpRuntimeBackend`, so a request raised on a session supercode drives arrives as ACP `session/request_permission`, becomes listable while the turn is blocked on it, and stops being listable when `runtimes.respond` answers it. PARTIAL, and the pin is why: at hermes 0.21.0 there is no `hermes approvals` at all and at openclaw 2026.7.1-2 there is no `approvals pending | resolve | grants` (both upstream-main-only), so no STORED operator approval or mined allowlist proposal exists for supercode to read — the `live` kind is the whole listing, and `stored`/`proposal` are defined in the type for a later pin without being produced. Still missing at any pin: a request raised on a Hermes/OpenClaw surface supercode is not attached to, which needs a Gateway client, not a supercode-side registry."
},
{
"id": "orch-pending-request-resolve",
"concept": "pending_request",
"verbs": "resolve",
"capability": "Pending request: resolve",
"semantics": "Answer one outstanding request (allow once / allow always / deny) from any surface",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "variant",
"hermes_detail": "✓* live only: the answer travels back in-band on the ACP session that raised it",
"openclaw_detail": "✓* live only, in-band on the ACP/Gateway session that raised it",
"orchestrator_detail": "✓* an admin's reply on the surface answers the request (§4.2), and `worker.permission.default` decides when nobody answers in time",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "acp"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "acp"
}
],
"orchestrator_status": "absent",
"orchestrator_evidence": [],
"orchestrator_note": "Absent: the daemon's reducer already relays a worker's request to the surface and answers it from an admin's reply or the `worker.permission` timeout (ORC-4, §4.2), but that is the DAEMON resolving it. supercode has no channel into that process, and the registry says so mechanically — the orchestrator's runtime capabilities are all false, so `approvals resolve` never selects it.",
"orchestrator_cost": "architectural",
"provenance": "inventory concept 12 (Approval), controlled tier; ORCH-4 registry tiers",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/support.rs",
"symbol": "descriptor.runtime.capabilities.respond_to_requests"
},
{
"kind": "code",
"path": "crates/harness/src/support.rs",
"symbol": "harness.v1.approvals.resolve"
},
{
"kind": "code",
"path": "crates/harness/src/approvals.rs",
"symbol": "pub fn plan_reply"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "async fn approvals_resolve"
},
{
"kind": "code",
"path": "crates/harness/src/runtime/adapters.rs",
"symbol": "impl RuntimeBackend for AcpRuntimeBackend"
}
],
"note": "Implemented for the LIVE kind, which is the whole of this concept at the pin: `harness.v1.approvals.resolve` takes a row id from `approvals.list` and one uniform decision (allow_once | allow_always | deny), translates it onto the option token the request itself enumerated — ACP `optionId` by `kind`, opencode's `once | always | reject`, supercode's own frontend decisions — and sends it through `harness.v1.runtimes.respond`, so both harnesses answer on their own ACP door with no adapter change. Codex's `*Approval` reverse request enumerates no options and no vocabulary is invented for it: those rows refuse by name and stay `runtimes.respond`'s to answer. The `stored` and `proposal` kinds stay typed and unproduced — neither hermes nor openclaw has an approvals store at the pin — so there is nothing left to resolve here until a re-pin lands one."
},
{
"id": "orch-profile-list-get",
"concept": "profile",
"verbs": "list/get",
"capability": "Profile: list/get",
"semantics": "Enumerate the harness's routed config homes and read one profile's definition",
"hermes": "yes",
"openclaw": "variant",
"orchestrator": "yes",
"hermes_detail": "✓ `hermes profile list` + `profile show` over `~/.hermes/profiles/<name>`",
"openclaw_detail": "✓* `openclaw agents list` over `~/.openclaw/agents/<id>`; no per-agent `get`/`show` verb at the pin",
"orchestrator_detail": "✓ a profile IS a folder: the root of `SUPERCODE_ORCHESTRATOR_HOME` for `default`, `profiles/<name>/` otherwise (`docs/ORCHESTRATOR-IR.md` §6)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "profile list"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "profile show"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "agents list"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "config.yaml"
},
{
"kind": "store",
"harness": "orchestrator",
"path": "profiles"
},
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "fn orchestrator_rows"
},
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "OrchestratorProfile"
}
],
"orchestrator_note": "ORC-7: `profiles list|get --harness orchestrator` answer from the folders themselves — `kind: orchestrator_profile`, the folder as `home`, `default` flagged, the routes that target the profile counted across every folder's table, the conversations counted from the profile's own `bindings` table, and the `worker:` block's harness and model in the row (`worker` is a new optional column, `-` for every other harness). Executed against a seeded root with two profiles.",
"provenance": "inventory concept 2 (Profile / Agent), build list: observed + controlled, M",
"status": "implemented",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "profiles/<name>/config.yaml"
},
{
"kind": "store",
"harness": "hermes",
"path": "config.yaml/gateway/profile_routes"
},
{
"kind": "store",
"harness": "hermes",
"path": "state.db/sessions/profile_name"
},
{
"kind": "store",
"harness": "openclaw",
"path": "openclaw.json/agents/list"
},
{
"kind": "store",
"harness": "openclaw",
"path": "openclaw.json/bindings"
},
{
"kind": "store",
"harness": "openclaw",
"path": "agents/<agentId>/sessions"
},
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "pub fn list_profiles("
},
{
"kind": "code",
"path": "crates/harness/src/profiles.rs",
"symbol": "pub fn get_profile("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.profiles.list\" | \"harness.v1.profiles.get\""
}
],
"note": "ORCH-10 landed the read tier through both harnesses' own files. Hermes: `HERMES_HOME/profiles/<name>/` plus the implicit `default` (HERMES_HOME itself), its route count from `gateway.profile_routes` in `config.yaml` and its session count from the `state.db` `profile_name` partition (NULL for the default). OpenClaw: `agents/<id>/` plus the `agents.list` array in `openclaw.json` (read as JSON5), its route count from `bindings[].agentId` and its session count from the same `agents/<id>/sessions` filter discovery uses. One row shape either way — name, harness, kind, home, default, routes, sessions, model — over `harness.v1.profiles.list|get` and `supercode profiles list|show`. What this row does NOT cover, by design: the CONTENTS of a profile home (SOUL.md, MEMORY.md, skills, tools) belong to the memory and skills rows, and creating or deleting one is the `profile: create/delete` row. Receipted on the build box against the installed harnesses: for hermes-agent 0.21.0, `supercode profiles show --harness hermes default` reports the same profile and the same model pin (`anthropic/claude-opus-4.6`) as `hermes profile list`; for the real `~/.openclaw`, the rows are the two agents `openclaw.json` declares with the one slack binding on `account-manager` and per-agent session counts of 5 and 4, matching the directories."
},
{
"id": "orch-profile-create-delete",
"concept": "profile",
"verbs": "create/delete",
"capability": "Profile: create/delete",
"semantics": "Create and delete a routed config home through the harness's own verb",
"hermes": "yes",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓ `hermes profile create` / `profile delete` (the inventory's \"create: setup flow, not enumerated\" is wrong at the pin — both are registered subcommands)",
"openclaw_detail": "✓ `openclaw agents add [name]` / `agents delete <id>` (deletes the workspace + state)",
"orchestrator_detail": "✓ creating a profile is creating the folder and its `config.yaml` through the package's `save()`; deleting it removes the record and RENAMES the folder into `profiles/.trash/<name>-<stamp>/`",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "profile create"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "profile delete"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "agents add"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "agents delete"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "code",
"path": "crates/harness/src/profiles_control.rs",
"symbol": "fn orchestrator_mutate"
},
{
"kind": "code",
"path": "crates/harness/src/orchestrator_door.rs",
"symbol": "pub fn call"
},
{
"kind": "code",
"path": "sdk/orchestrator/reducer.mjs",
"symbol": "case 'profiles_create'"
},
{
"kind": "code",
"path": "sdk/orchestrator/operator.mjs",
"symbol": "export function performRemoveProfileDir"
},
{
"kind": "store",
"harness": "orchestrator",
"path": "profiles"
}
],
"orchestrator_note": "ORC-13: `profiles create|delete --harness orchestrator` go through the package's operator door. `create` adds an empty folder record to `state.profiles` and lets the reducer's `save` effect write the home — so `config.yaml` is emitted by the one writer that owns its canonical order, and the `save(load(root)) == root` invariant holds by construction rather than by care. `delete` removes the record and emits a `remove_profile_dir` effect the loop (and the cold path, through the same shared function) performs by RENAMING the folder to `profiles/.trash/<name>-<stamp>/`; nothing is ever unlinked, and both the package's loader and `orchestrator_profile_dirs` skip a dot-prefixed folder so a trashed home is not a profile. The root folder IS the `default` profile (§6) and refuses deletion by name. Two fields are refused rather than dropped: there is no clone source, and a workspace is the `worker.cwd` key inside the folder, not a creation argument. The row is re-read through the ORCH-10 loader afterwards. Receipted on a fresh temp root, both doors (receipt orc13-orchestrator-write-door-receipt-2026-09-04.json).",
"provenance": "inventory concept 2 (Profile / Agent), controlled tier",
"status": "implemented",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/profiles_control.rs",
"symbol": "pub fn mutate"
},
{
"kind": "code",
"path": "crates/harness/src/profiles_control.rs",
"symbol": "fn hermes_command"
},
{
"kind": "code",
"path": "crates/harness/src/profiles_control.rs",
"symbol": "fn openclaw_command"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.profiles.create\""
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.profiles.delete\""
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn profile_mutation_cmd"
}
],
"note": "ORCH-21 landed the controlled tier: `harness.v1.profiles.create|delete` and `supercode profiles create|delete --harness X` translate the uniform row onto the HARNESS'S OWN verb and run it — `hermes profile create [--clone-from <from>] --no-alias <name>` / `hermes profile delete --yes <name>` with HERMES_HOME pointing at the ROOT home the caller addressed, and `openclaw agents add <id> --workspace <dir> --non-interactive --json` / `openclaw agents delete <id> --force --json` over openclaw's own `OPENCLAW_STATE_DIR` / `OPENCLAW_CONFIG_PATH` contract (neither agents verb takes a `--url`/`--token`; `agents delete` offers the change to a running Gateway itself). supercode owns no config plane: after each verb the row is re-read through the ORCH-10 loader, every outcome narrates the exact command in `ran`, and a failed verb surfaces the harness's own stderr. Receipted end-to-end on both pinned installs (orch21-hermes-profiles-receipt-2026-09-03.json on hermes 0.21.0 — create → `hermes profile list` shows it → delete → gone, on an isolated HERMES_HOME with `~/.local/bin` untouched; orch21-openclaw-profiles-receipt-2026-09-03.json on an isolated openclaw 2026.7.1-2 gateway — the same round trip with `openclaw agents list --json` agreeing at every step). Honest edges, all refused rather than faked: Codex profiles are `[profiles.<name>]` tables a human authors in `config.toml` and supercode presets are compiled-in code, so both refuse with `unsupported_action`; hermes has no workspace flag and openclaw has no clone source, so either field is refused rather than dropped; openclaw's own non-interactive `agents add` requires `--workspace`, so `profiles.create --harness openclaw` requires it too. Two behaviors measured against the pin and handled here: `hermes profile create` also writes a wrapper script to `~/.local/bin/<name>` (a path HERMES_HOME does not govern), so the programmatic form passes `--no-alias`; and `openclaw agents delete` leaves an EMPTY `agents/<id>` shell behind after pruning the config entry, `agent/` and `sessions/`, so the ORCH-10 loader now drops an undeclared empty directory — `openclaw agents list` does not report it either."
},
{
"id": "orch-skills-list",
"concept": "skills",
"verbs": "list",
"capability": "Skills: list",
"semantics": "Enumerate the capability packages installed for a profile/agent",
"hermes": "yes",
"openclaw": "yes",
"orchestrator": "variant",
"hermes_detail": "✓ `hermes skills list` (installed) + `skills browse`/`search` (registries)",
"openclaw_detail": "✓ `openclaw skills list` + `skills info <name>` / `skills check`",
"orchestrator_detail": "✓* jobs and webhook subscriptions NAME skills (`skills: […]`), but the orchestrator keeps no skills store of its own — the skill is installed in the WORKER harness's home and read through that harness's own door",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "skills list"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "skills list"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "skills info"
}
],
"orchestrator_status": "absent",
"orchestrator_evidence": [],
"orchestrator_note": "Absent by design of the folder, not by omission: `docs/ORCHESTRATOR-IR.md` §6 lists no skills path, so `crate::skills` has no root to open and `skills list --harness orchestrator` refuses rather than answering an empty list. The honest answer for a profile's skills is its worker's answer — `skills list --harness <worker>` against the worker's home — which is a small delegation on top of the `worker:` block this change already reads.",
"orchestrator_cost": "trivial",
"provenance": "inventory concept 15 (Skills), build list: observed + controlled, S",
"status": "implemented",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "skills/SKILL.md"
},
{
"kind": "store",
"harness": "hermes",
"path": "profiles/<name>/skills"
},
{
"kind": "store",
"harness": "openclaw",
"path": "skills/SKILL.md"
},
{
"kind": "store",
"harness": "openclaw",
"path": "plugin-skills"
},
{
"kind": "store",
"harness": "openclaw",
"path": "workspace/skills"
},
{
"kind": "code",
"path": "crates/harness/src/skills.rs",
"symbol": "pub fn list_skills("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.skills.list"
}
],
"note": "`crate::skills` opens each harness's own skill roots read-only and `harness.v1.skills.list` / `supercode skills list [--harness] [--scope]` return the uniform row (name, harness, scope, location, description, version, enabled): Hermes `HERMES_HOME/skills` plus `profiles/<name>/skills`, walked rather than listed because Hermes groups skills by category; OpenClaw's managed `<config>/skills`, `plugin-skills`, `workspace/skills` and `workspace/.agents/skills`. Registry-side browse/search (`hermes skills browse`, `openclaw skills search`) queries the hub, not the installed set this row enumerates; installing and removing is the controlled tier (`orch-skills-install-remove`)."
},
{
"id": "orch-skills-install-remove",
"concept": "skills",
"verbs": "install/remove",
"capability": "Skills: install/remove",
"semantics": "Install and remove a capability package through the harness's own verb",
"hermes": "yes",
"openclaw": "variant",
"orchestrator": "variant",
"hermes_detail": "✓ `hermes skills install` / `skills uninstall` (plus `tap` for sources)",
"openclaw_detail": "✓* `openclaw skills install` / `skills update` — no remove verb at the pin; removal goes through `openclaw plugins` or the managed directory",
"orchestrator_detail": "✓* installing a skill for a profile means installing it in that profile's WORKER harness home; the orchestrator has no installer of its own",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "skills install"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "skills uninstall"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "skills install"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "skills update"
}
],
"orchestrator_status": "absent",
"orchestrator_evidence": [],
"orchestrator_note": "Absent: nothing in supercode installs a skill on the orchestrator's behalf. The worker's own skills door (ORCH-22) is what would do it, and choosing WHICH home a profile's skill lands in is part of the worker-home layout (`<harness>/` subfolder, §6) that no code writes yet.",
"orchestrator_cost": "architectural",
"provenance": "inventory concept 15 (Skills), controlled tier",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "pub fn mutate_skill"
},
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "fn hermes_command"
},
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "fn openclaw_command"
},
{
"kind": "code",
"path": "crates/harness/src/skills_control.rs",
"symbol": "pub const OPENCLAW_REMOVE_REFUSAL"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.skills.install\""
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.skills.remove\""
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn skills_install_cmd"
}
],
"note": "ORCH-22 landed the controlled tier for Hermes in full and OpenClaw by half, which is exactly what the pin publishes. `harness.v1.skills.install|remove` and `supercode skills install|remove --harness X` run the HARNESS'S OWN verb and return the row re-read through the ORCH-11 loader, with `ran` narrating what was executed. Hermes: `hermes skills install <identifier> --yes` / `hermes skills uninstall <name> --yes` with HERMES_HOME, receipted end to end on the installed 0.21.0 against an isolated home (docs/interop/research/orch22-hermes-skills-receipt.json: install -> `hermes skills list` names it -> remove -> gone). Its positional is a registry identifier or an HTTP(S) URL to a SKILL.md and its fetch is SSRF-guarded, so there is no local-directory form at all; supercode refuses a local path for hermes rather than handing it to a verb that cannot take it. OpenClaw: `openclaw skills install <skill-ref> [--global] [--as]` works, receipted against an isolated pinned install with a LOCAL directory ref (docs/interop/research/orch22-openclaw-skills-receipt.json), but the pin has NO `skills remove`, so the uniform verb refuses with UnsupportedAction rather than deleting files out of the harness's managed directory behind its back. That missing half is why this row is partial and not implemented; re-pinning OpenClaw to a build with a remove verb closes it."
},
{
"id": "orch-memory-show-search",
"concept": "memory",
"verbs": "show/search",
"capability": "Memory: show/search",
"semantics": "Read and search the persistent cross-session memory of a profile/agent",
"hermes": "variant",
"openclaw": "extension",
"orchestrator": "no",
"hermes_detail": "✓* built-in memory is `MEMORY.md`/`USER.md` per profile (always on); `hermes memory status|off|reset` configures the external provider — there is no CLI show/search verb, the files are the door",
"openclaw_detail": "ext `openclaw memory search|status|index|promote`, contributed by the bundled `memory-core` extension rather than the core CLI",
"orchestrator_detail": "",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "memory status"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "memory search"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "memory status"
}
],
"orchestrator_status": "not_applicable",
"orchestrator_evidence": [],
"orchestrator_note": "The orchestrator's model has no memory concept: §6 lists no memory document, and its `AGENTS.md` is the profile's PERSONA, read natively by the worker from its cwd (§2.2) — not a memory store supercode may show or search. A profile's memory is its worker harness's memory, read through that harness's own door. Not a gap; a deliberate absence.",
"provenance": "inventory concept 14 (Memory), build list: observed (show/search), S",
"status": "implemented",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "memories/MEMORY.md"
},
{
"kind": "store",
"harness": "hermes",
"path": "USER.md"
},
{
"kind": "store",
"harness": "hermes",
"path": "profiles/<name>/memories"
},
{
"kind": "store",
"harness": "openclaw",
"path": "workspace/MEMORY.md"
},
{
"kind": "store",
"harness": "openclaw",
"path": "workspace/memory"
},
{
"kind": "store",
"harness": "openclaw",
"path": "workspace/DREAMS.md"
},
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "pub fn show_memory("
},
{
"kind": "code",
"path": "crates/harness/src/memory.rs",
"symbol": "pub fn search_memory("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.memory.show"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "harness.v1.memory.search"
}
],
"note": "ORCH-12 landed the read tier by opening each harness's own memory files, with no engine on supercode's side: `harness.v1.memory.show|search` and `supercode memory show|search --harness X` return one uniform document row (name, harness, scope, profile, path, size, updated_at, preview, truncated, and `content` only under `full`) and one match row (path, line, excerpt) from a case-insensitive substring scan (`--regex` for a pattern). Hermes 0.21.0: `get_memory_dir()` is `get_hermes_home()/\"memories\"` holding `MEMORY.md` (the agent's notes) and `USER.md` (what it knows about the user) (`tools/memory_tool.py:55-57` at tag `v2026.7.20`), read for HERMES_HOME itself (scope `user`) and for every `profiles/<name>` home (scope `profile`), plus the root-level `MEMORY.md`/`USER.md` names Hermes's own export manifest lists (`hermes_cli/profiles.py:238`). OpenClaw 2026.7.1-2: memory-core classifies a workspace-relative path as memory when it is `MEMORY.md`, `DREAMS.md`/`dreams.md`, or under `memory/` (`extensions/memory-core/src/memory/qmd-manager.ts:156-165` at tag `v2026.7.1-2`), relative to the agent workspace `resolveAgentWorkspaceDir` names — the agent's own `workspace` key in `openclaw.json`, else `$OPENCLAW_WORKSPACE_DIR` / `<home>/workspace` (+`$OPENCLAW_PROFILE`) for the default agent and `<home>/workspace-<id>` for any other (`src/agents/agent-scope-config.ts:181`, `src/agents/workspace-default.ts:12`) — so the files are read directly and no gateway or search index is required. That precedence, and the `main`-then-first default for a config-less install, were corrected against `openclaw memory status` on the pinned CLI (`docs/interop/research/orch12-memory-receipt-2026-09-03.json`), which also shows why the read tier opens the files rather than shelling out: `openclaw memory search` needs a paid embeddings provider and a built index. `hermes memory status|off` and `openclaw memory search|index|forget|promote|reset` stay the harnesses' own verbs; the write side (forget/reset) is out of scope by demand, so this row is the show/search pair only."
},
{
"id": "orch-delivery-target",
"concept": "delivery_target",
"verbs": "on jobs/runs",
"capability": "Delivery target on jobs/runs",
"semantics": "Where a job's or turn's output is delivered, as a first-class field on the job/run",
"hermes": "variant",
"openclaw": "variant",
"orchestrator": "yes",
"hermes_detail": "✓* job `deliver` = origin|local|home|explicit plus the `delivery_obligations` table in `state.db` (state/attempts/last_error); `hermes send --to <platform>[:chat[:thread]]` is the standalone door",
"openclaw_detail": "✓* job `--channel`/`--to` fields with announce|webhook|none; `openclaw message send` / `message broadcast` are the standalone doors",
"orchestrator_detail": "✓ `deliver` / `failure_deliver` on a job (`origin | home | local | <platform>:<chat>[:<thread>]`) and one `delivery_obligations` row per outbound message, Hermes's columns (`docs/ORCHESTRATOR-IR.md` §2.6)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "send"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "message send"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "message broadcast"
}
],
"orchestrator_status": "partial",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "state.db/delivery_obligations"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn hermes_delivery"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "fn hermes_row"
}
],
"orchestrator_note": "ORC-7: the `deliver` field is read on every orchestrator job row, and a fire's actual delivery (target, state, attempts, last error, delivered instant) is joined from the profile folder's own `delivery_obligations` by the same ORCH-13 code path Hermes's rows use — executed and observed `delivered` on the seeded fire. Missing, exactly as for Hermes: the obligation ledger has no listing verb of its own, so an obligation not tied to a fire (a turn's reply, a webhook's answer) is invisible; and `local`/`home` targets name no platform surface, so those fires answer `None` rather than a guessed destination.",
"provenance": "inventory concept 9 (Delivery target), build list: observed; sending later by demand, S",
"status": "partial",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "state.db/delivery_obligations"
},
{
"kind": "store",
"harness": "hermes",
"path": "cron/jobs.json"
},
{
"kind": "store",
"harness": "openclaw",
"path": "state/openclaw.sqlite/cron_run_logs"
},
{
"kind": "store",
"harness": "openclaw",
"path": "state/openclaw.sqlite/cron_jobs"
},
{
"kind": "code",
"path": "crates/harness/src/jobs.rs",
"symbol": "pub struct JobDeliver"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn hermes_delivery"
},
{
"kind": "code",
"path": "crates/harness/src/runs.rs",
"symbol": "fn openclaw_delivery"
}
],
"note": "ORCH-13 landed the READ this row is: a job row's `deliver` carries `{target, chat_id, thread_id, account, mode}` and a run row's `delivery` carries `{target, state, attempts, last_error, delivered_at}`, both through `harness.v1.jobs.list|get` / `runs.list|get` and a `DELIVERY` column on both CLI tables. Hermes: the job's `deliver` word plus its `origin{platform, chat_id, thread_id}`, and the `delivery_obligations` ledger inside `state.db` (`gateway/delivery_ledger.py`) for the outcome. OpenClaw: `delivery_mode` and the `delivery_channel`/`to`/`thread_id`/`account_id` columns of `cron_jobs` (folded in beside `job_json.delivery`), plus `cron_run_logs.delivery_status`/`delivery_error`/`delivered` for the outcome — with the address joined from the job, because the run log records only whether a delivery happened. Still missing, and why this is not `implemented`: (a) Hermes's ledger is the GATEWAY's, keyed by conversation `session_key` and platform surface and naming no job and no fire, so a fire is matched to it by the fire's own [claimed_at, finished_at] window (session key first, the job's delivery surface second), and an execution timestamp carrying no UTC offset cannot be placed on the ledger's epoch line at all — it answers null rather than assuming a timezone; (b) the read is over the harnesses' STORES only: neither harness's CLI is called, so a delivery a running gateway holds but has not committed is invisible. Sending stays deliberately out of scope — supercode never runs a channel.",
"cost": "architectural"
},
{
"id": "orch-channel-list-status",
"concept": "channel",
"verbs": "list/status",
"capability": "Channel: list/status",
"semantics": "Enumerate the transports/accounts the install is connected to and report each one's health",
"hermes": "variant",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓* platform blocks in `config.yaml`; `hermes gateway list` reports profiles + gateway status and `hermes send --list` enumerates deliverable targets — there is no channels noun",
"openclaw_detail": "✓ `openclaw channels list|status|capabilities|logs` (plus add/remove/login/logout)",
"orchestrator_detail": "✓ `platforms:` blocks per profile folder, Hermes-shaped, with credentials as `{dotenv: NAME}` / `{env: NAME}` REFS — never values (`docs/ORCHESTRATOR-IR.md` §2.4, §6)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "gateway list"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "send"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "channels list"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "channels status"
}
],
"orchestrator_status": "partial",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "config.yaml"
},
{
"kind": "code",
"path": "crates/harness/src/channels.rs",
"symbol": "fn hermes_rows"
},
{
"kind": "code",
"path": "crates/harness/src/channels.rs",
"symbol": "HarnessId::ORCHESTRATOR => {"
}
],
"orchestrator_note": "ORC-7: `channels list|status --harness orchestrator` read each profile folder's `platforms:` block through the Hermes reader, with the env-variable fallback deliberately OFF for the orchestrator — a credential is a ref in the folder, so a variable Hermes happens to read can never conjure a channel this home never declared. `configured` is still decided by the key NAME (`is_credential_key`), so a `{dotenv: …}` map counts as configured and its value is never read or printed. Missing (the same half Hermes's row is missing): `status` is always `unknown`. The daemon does connect the adapters it has — `loopback` is the only one built (ORC-4; real platforms are ORC-9) — but no adapter reports liveness back to any store a reader could join, so the row cannot say more than `configured`.",
"provenance": "inventory concept 3 (Channel), build list: observed, S",
"status": "partial",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "config.yaml/platforms"
},
{
"kind": "store",
"harness": "openclaw",
"path": "openclaw.json/channels"
},
{
"kind": "code",
"path": "crates/harness/src/channels.rs",
"symbol": "pub fn list_channels("
},
{
"kind": "code",
"path": "crates/harness/src/channels.rs",
"symbol": "pub fn channel_status("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.channels.list\" | \"harness.v1.channels.status\""
}
],
"note": "ORCH-14 landed the LIST half through both harnesses' own config files. Hermes: the `platforms:` block of `HERMES_HOME/config.yaml` (`enabled`, the platform's own credential keys, and the bridged `extra` map), plus the platforms `gateway/config.py::_apply_env_overrides` would enable from the environment alone — reported by the var's PRESENCE, never its value. OpenClaw: `channels.<name>` in `openclaw.json` (read as JSON5), split one row per `accounts.<accountId>` and named `<channel>/<accountId>`. One row shape either way — name, harness, kind, account, enabled, configured, status, sessions — over `harness.v1.channels.list|status` and `supercode channels list|status`, with the session count taken from the same discovery rows `sessions list` shows, bucketed by surface platform. No credential is read or emitted: `account` values come only from a fixed allowlist of public identifier key names and `configured` is decided by key NAME and by `env_var_os(..).is_some()`, proven by a scan of every emitted row — and of every CLI line — against the fixtures' fake secrets. Why this is not `implemented`: STATUS is live. Both harnesses answer a channel's connection state from a RUNNING gateway (`hermes gateway status`, `openclaw channels status` over the Gateway socket), so every row honestly reports `unknown` rather than inferring `up` from a config file; that half needs the Gateway client this repo does not have. Out of scope by design: OpenClaw's `channel_pairing_*`, `channel_ingress_events` and `delivery_queue_entries` tables in the state DB are the pairing, inbound-trigger and delivery-target concepts, not channel config."
},
{
"id": "orch-routing-list",
"concept": "routing",
"verbs": "list",
"capability": "Routing: list",
"semantics": "Show which surface tuples bind to which profile/agent",
"hermes": "variant",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓* `gateway.profile_routes` in `config.yaml`, read/written with `hermes config get|set` — no dedicated routing verb",
"openclaw_detail": "✓ `openclaw agents bindings` (and `agents bind|unbind` to mutate)",
"orchestrator_detail": "✓ `gateway.profile_routes` in each profile folder's `config.yaml`, Hermes's own shape and precedence (thread > chat > guild > platform) (`docs/ORCHESTRATOR-IR.md` §2.3)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "config get"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "config set"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "agents bindings"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "config.yaml"
},
{
"kind": "code",
"path": "crates/harness/src/routes.rs",
"symbol": "fn hermes_rows"
},
{
"kind": "code",
"path": "crates/harness/src/routes.rs",
"symbol": "HarnessId::ORCHESTRATOR => {"
}
],
"orchestrator_note": "ORC-7: `routes list --harness orchestrator` reads every profile folder's route table with Hermes's own specificity weights, and emits the unmatched-traffic default row exactly once, for the ROOT folder — a named profile's config does not get to claim it. Executed against a seeded root; `--profile` filtering works because the rows carry the target profile like every other harness's.",
"provenance": "inventory concept 4 (Routing / binding), build list: observed; write later, S",
"status": "implemented",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "config.yaml"
},
{
"kind": "store",
"harness": "openclaw",
"path": "openclaw.json"
},
{
"kind": "code",
"path": "crates/harness/src/routes.rs",
"symbol": "pub fn list_routes"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.routes.list\""
}
],
"note": "ORCH-15 (observed): `harness.v1.routes.list` / `supercode routes list` read Hermes `gateway.profile_routes` (config.yaml; weights thread 8 > chat 4 > guild 2 > platform 0) and OpenClaw `bindings[]` (openclaw.json; the documented cascade ranked exact peer 8 … channel 1) with the default profile/agent as the rank-0 row. Editing a route stays the harness's own config edit.",
"cost": "trivial"
},
{
"id": "orch-inbound-trigger-list",
"concept": "inbound_trigger",
"verbs": "list",
"capability": "Inbound trigger: list",
"semantics": "Enumerate the webhooks / mapped events that can open a turn without a human prompt",
"hermes": "yes",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓ `hermes webhook list` over dynamic subscriptions (`/webhooks/<name>`; `subscribe`/`remove`/`test` complete the set)",
"openclaw_detail": "✓ `openclaw hooks list` + `hooks info <name>` / `hooks check` over mapped hooks (e.g. `hook:gmail:<id>` sessions)",
"orchestrator_detail": "✓ `webhook_subscriptions.json` per profile folder, Hermes's shape; the route is `/webhooks/<name>` (`/p/<profile>/webhooks/<name>` for a named profile) and the secret is a ref (§2.6)",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "webhook list"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "hooks list"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "hooks info"
}
],
"orchestrator_status": "implemented",
"orchestrator_evidence": [
{
"kind": "store",
"harness": "orchestrator",
"path": "webhook_subscriptions.json"
},
{
"kind": "code",
"path": "crates/harness/src/triggers.rs",
"symbol": "fn hermes_rows"
},
{
"kind": "code",
"path": "crates/harness/src/triggers.rs",
"symbol": "HarnessId::ORCHESTRATOR => {"
}
],
"orchestrator_note": "ORC-7: `triggers list --harness orchestrator` reads every profile folder's subscriptions through the Hermes reader, reporting name, events, delivery target, enabled, and `authenticated` by the PRESENCE of a secret — the value is never read. Executed against a seeded root. The daemon does serve `POST /webhooks/<name>` (ORC-5, HMAC-verified), but the port it bound is runtime state no store carries, so a listed trigger's row cannot say WHERE it is reachable — the same limit as the gateway-health row below.",
"provenance": "inventory concept 10 (Inbound trigger), build list: observed (list), S; note that `hermes hooks` is lifecycle shell hooks (Domain 7), not inbound",
"status": "implemented",
"evidence": [
{
"kind": "store",
"harness": "hermes",
"path": "webhook_subscriptions.json"
},
{
"kind": "store",
"harness": "hermes",
"path": "config.yaml"
},
{
"kind": "store",
"harness": "openclaw",
"path": "openclaw.json"
},
{
"kind": "code",
"path": "crates/harness/src/triggers.rs",
"symbol": "pub fn list_triggers"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "\"harness.v1.triggers.list\""
}
],
"note": "ORCH-16 (observed): `harness.v1.triggers.list` / `supercode triggers list` read Hermes webhook subscriptions (`webhook_subscriptions.json`) + static routes (`platforms.webhook.extra.routes` in config.yaml) and OpenClaw's pinned `hooks` block (built-in /wake and /agent endpoints + `hooks.mappings[]`) from openclaw.json. Per-route HMAC secrets and the hook token are read for presence only and never emitted. Note: at the pin `openclaw hooks` manages INTERNAL lifecycle hook packs, not inbound triggers — the spec's CLI door was wrong; the config file is the store.",
"cost": "trivial"
},
{
"id": "orch-gateway-health",
"concept": "gateway_health",
"verbs": "status/health",
"capability": "Gateway health",
"semantics": "Report whether the always-on daemon that owns channels and automation is up and healthy",
"hermes": "yes",
"openclaw": "yes",
"orchestrator": "yes",
"hermes_detail": "✓ `hermes gateway status` (plus `hermes status` for the whole install)",
"openclaw_detail": "✓ `openclaw gateway health` + `gateway status` (service + probe), `gateway probe`, `openclaw health`",
"orchestrator_detail": "✓ one daemon per home, whose lease `<home>/orchestrator.lock` names the serving pid; it multiplexes adapters, so like Hermes it has no single endpoint",
"hermes_evidence": [
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "gateway status"
},
{
"kind": "cli_verb",
"harness": "hermes",
"verb": "status"
}
],
"openclaw_evidence": [
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "gateway health"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "gateway status"
},
{
"kind": "cli_verb",
"harness": "openclaw",
"verb": "health"
}
],
"orchestrator_status": "partial",
"orchestrator_evidence": [
{
"kind": "code",
"path": "crates/harness/src/orchestrator.rs",
"symbol": "pub fn live_lease"
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "HarnessId::ORCHESTRATOR => {"
},
{
"kind": "code",
"path": "crates/cli/src/main.rs",
"symbol": "fn orchestrator_status_cmd"
}
],
"orchestrator_note": "ORC-7: the GATEWAY column of `harness list` and `supercode orchestrator status` both answer from the lease `<home>/orchestrator.lock` plus a liveness check on the pid it names, so a lease whose process is gone reports DOWN as a stale lease and never up. Executed: down → start → up → stop → down. Missing: everything a health answer holds beyond up/down. The daemon does bind a webhook listener (ORC-5) and connect its adapters, but the bound port and the per-adapter state and breaker live in `runtime` (§2.8), which is never persisted and which the daemon publishes only on its own stdout — so the row carries no endpoint, no uptime, no last tick, and no version (the entry is a Node module, not a CLI with `--version`).",
"provenance": "inventory concept 1 (Gateway), build list: observed (status/health), S",
"status": "partial",
"evidence": [
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "fn gateway_health("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "fn openclaw_gateway_endpoint("
},
{
"kind": "code",
"path": "crates/harness/src/harness_service.rs",
"symbol": "fn probe_running_instance("
}
],
"note": "ORCH-17 (observed): every `harness.v1.harnesses.list` row carries `gateway {state up|down|unknown, endpoint, version, evidence, checked_at_ms}` and `supercode harness list` shows a GATEWAY column. State is derived from the UNI-7 running-instance probe (OpenClaw: TCP connect to the gateway endpoint resolved from openclaw.json — url, else port, else ws://127.0.0.1:18789; Hermes: state.db-wal freshness under ~/.hermes) and the executable version. Partial: Hermes's own `hermes gateway status` text IS consulted since #687 (launchd `supervised … (PID n)` / `not running` / `not installed` parsed; the WAL heuristic is the fallback), but it has no JSON form and Hermes exposes no single endpoint, so `endpoint` stays null; OpenClaw's `gateway status` needs the token and is not called.",
"cost": "trivial"
}
]