Naming & conventions
Chorus grew through two naming generations, and the seams show. This page declares the
canonical form for each surface, names every legacy spelling that remains
supported, and fences the spellings that are not aliases at all. Everything here is
grounded in the registry and schemas at HEAD — when docs and code disagree, the code
wins and the docs carry a canonical form pending note.
1. Tool names — chorus_<noun>_<verb> is canonical
Section titled “1. Tool names — chorus_<noun>_<verb> is canonical”RFC-291 and all newer tools use noun-verb: chorus_task_create, chorus_memory_store,
chorus_workspace_list. The Gen1 org/circle/gate tools use verb-noun
(chorus_create_ring, chorus_create_circle, chorus_update_role) — they are
documented under their real names and keep working; the convention split is historical,
not semantic. New tools must be noun-verb.
2. RPC methods — dot-form canonical, slash-form supported
Section titled “2. RPC methods — dot-form canonical, slash-form supported”The method registry (methodRegistry, src/rpc/methods.ts:1165-1377) holds 198
keys: 102 dot-form and 96 slash-form. Dot (memory.store, tasks.create) is the
canonical post-#416 catalog spelling; slash (memory/store, signals/emit) stays live
as back-compat. Three classes exist:
| Class | Examples | Note |
|---|---|---|
| Dot-only (canonical-native) | tasks.*, runs.*, signals.emit.<type> |
Never had a slash form. |
| Dual-registered | memory.store + memory/store, workflow.resume + workflow/resume |
Both resolve. |
| Slash-only (legacy) | roles/list, inbox/acknowledge, library/ask |
Dot names arrive with the catalog migration. |
Dot-form is not a mechanical rewrite of slash names — some ops were renamed in the
canonical (workspace/create_text → workspace.create_file). Look names up in the
registry; don’t derive them. See JSON-RPC for the full story.
3. Native task verbs vs legacy signal-task tools — NOT aliases
Section titled “3. Native task verbs vs legacy signal-task tools — NOT aliases”chorus_task_claim / chorus_task_update / chorus_task_create operate on native
RFC-291 execution tasks (task: ids). chorus_claim_task / chorus_cancel_task /
chorus_extend_claim operate on historical signal rows (signal: ids with
signal_type: "task") — a different subsystem with different ids and return shapes.
They are fenced as legacy-signal-only; never use them for new work, and never read one
family as an alias of the other. (chorus_cancel_task cancels a signal; native tasks
have no MCP cancel tool — use chorus_task_update with state: "cancelled".)
4. Lease parameters — lease_ms (milliseconds) is canonical
Section titled “4. Lease parameters — lease_ms (milliseconds) is canonical”| Surface | Canonical | Legacy alias (still works) |
|---|---|---|
chorus_task_claim (native) |
lease_ms |
— |
chorus_extend_claim (legacy signal) |
lease_ms |
— |
chorus_claim_task (legacy signal) |
lease_ms |
claim_lease_ms (wins if both set) |
chorus_task_heartbeat (native, MCP) |
lease_ms |
ttl_seconds (wins if both set) |
POST /tasks/{id}/heartbeat (HTTP) |
ttl_seconds — canonical form pending |
— |
The MCP heartbeat converts lease_ms to whole seconds (rounded up) before calling the
HTTP route, which still speaks ttl_seconds. Note the unit flip if you drop to raw
HTTP.
5. Resource id parameter — bare id
Section titled “5. Resource id parameter — bare id”Native/RFC-291, org, circle, and gate tools take a bare id. Legacy signal/memory/
webhook tools take <noun>_id (signal_id, memory_id, webhook_id) — documented
under their real names; don’t normalize one into the other when calling.
6. Ring references — ring (name or id)
Section titled “6. Ring references — ring (name or id)”The documented norm is a ring parameter accepting a ring name or record id (resolved
via RingScope). Older surfaces use to_ring (signal routing) and ring_id — both
remain as-is on the tools that have them; reference pages show the actual accepted
name per tool.
7. Emittable signal types — the 8 foundation types
Section titled “7. Emittable signal types — the 8 foundation types”task left the emittable set in RFC-291 phase 4. The foundation 8
(FOUNDATION_SIGNAL_TYPES, src/commands/handlers/signals.ts:8-17): pulse,
sense, query, alert, artifact, approval_request, proposal, shift.
CoreSignalTypes (src/signals/types.ts:16-27) now exports exactly these 8.
Emitting signal_type: "task" is rejected on every transport with
LEGACY_TASK_EMIT_REMOVED (422) — the emit schema deliberately still admits the
string at the validation layer (EmitSignalTypeSchema,
src/signals/validation.ts:12-17) so you get that specific, actionable error instead
of a generic enum failure, and the RPC registry keeps a signals.emit.task tombstone
that rejects with zero side effects (src/commands/handlers/signals.ts:45-60).
Create work with the native task API (chorus_task_create / tasks.create). Filter
surfaces (inbox/search/webhooks) still accept task — historical rows remain
readable.
How reference pages use these rules
Section titled “How reference pages use these rules”Examples on reference pages always show the actually accepted parameter names at
HEAD, so they stay copy-pasteable. Where code lags the canon (e.g. HTTP heartbeat
ttl_seconds), the page flags it canonical form pending rather than showing a name
that would error today.