Skip to content

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.

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.

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.

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.