Yoke Function Call Reference
Registered function ids are the typed control-plane interface. Use their
yoke <subcommand> adapters; Git, gh and external tools remain command-shaped.
Read the operation's --help for payload, target, authorization and recovery.
The dispatcher verifies claims before the canonical domain handler executes.
Live startup recipes: yoke packets render --role main_agent; request a topic
with --detail full for its complete schema and recipes.
Operation families
Each registered id has one catalog owner:
| Work | Catalog |
|---|---|
| Work/path/coordination claims and decisions | Claims |
| Items, sections, progress, readiness and lifecycle | Items |
| Projects, settings, strategy, Packs, environments and shared files | Project configuration |
| QA cases, evidence and test machines | QA |
| Sessions, actors, deployment, messaging and live services | Runtime |
| Generated tasks, dispatch and reviews | Tasks |
| Pinned definitions, canon updates and routing | Workflows |
| Lane preparation, landing, merge and close-out | Worktrees |
Envelope
Models: yoke_contracts.api.function_call. Client item selectors are complete
public refs; the serving engine alone resolves internal item keys. Task targets
also carry task_num. Other record ids retain their own domain meaning.
{"function":"<registered id>","version":"v1","request_id":"<uuid>",
"actor":{"session_id":"<session>"},
"target":{"kind":"item","public_ref":"PREFIX-N"},
"payload":{},"preconditions":{},"options":{}}
Responses carry success, function, version, request_id, result,
warnings[], one optional error (code, message, jsonpath,
recovery_hint) and event_ids[]. Consume typed fields. Primary mutation
failure and downstream-degraded warnings are different outcomes; inspect both.
Post-write verification marked degraded is partial-state evidence, never green.
Read deadlines
A registered function declaring no side effects shares a 25-second handler budget in local, self-hosted and hosted dispatch. The HTTPS relay waits 30 seconds for a response and never resends a call that timed out: the server keeps running the original, so a copy would only queue behind it. The server reserves five seconds for its response and failure evidence. Browser dispatch and the local UI proxy use the same handler budget; neither declares an extra browser timer.
The budget is checked at native-call boundaries, never by interrupting running Python. Each PostgreSQL transaction arms its server-side statement timeout once, from the budget remaining when the transaction starts; nested HTTP reads inherit the same deadline, and the handler is checked again when it returns. Subprocesses and native database protocols always finish or time out on their own terms. Mutations retain their existing execution and replay contracts.
An expired read returns read_deadline_exceeded (HTTP 408), with a recovery
hint, and YokeFunctionCalled records the failed outcome for Performance.
Retry a narrower read: name a project or section, or use --limit and
--offset. Request --full only when the caller needs detail. Plan pickers,
search and intake follow summary pages; Test plans explicitly requests full
rows for outcomes, execution targets, attachments and case counts.
Dropped connections
Handlers open a fresh database connection on every invocation. When that
connection drops mid-statement (consuming input failed, SSL SYSCALL error, unexpected eof), a side-effect-free function runs once more inside
the same read budget. A function that can change state is never resent,
because the lost statement may already have committed. A second drop, or any
drop in a state-changing function, returns control_plane_connection_lost
(HTTP 500, so the HTTPS client does not resend it). Its recovery is to re-read
the targeted state and rerun once yoke env list shows the control plane
reachable; the deploy driver adds yoke watch deploy -- RUN-ID, because a run
resumes where it stopped. The one call the driver re-sends itself is QA stage
dispatch, which is idempotent: a lost answer is sent again up to three times,
5s then 15s apart, and a refusal is never re-sent. Any other exception a handler raises answers
handler_exception with the function id and exception class, on in-process
dispatch as on the HTTPS route, never a raw traceback. The HTTPS server logs
function_call_handler_failed with the request id, exception class and the
traceback's frame locations (file, line, function), never the message or
payload, so an operator can find the failing line.
Locks a handler could not take
Every write that serializes on a deployment run takes the run row through one
bounded lock: it waits at most 2 seconds, then refuses run_busy with the
holder's pid, its state and how long it has held the lock. Dispatch answers
three lock outcomes by name instead of handler_exception, because each means
another transaction held what this call needed and this call's open
transaction did not commit:
| Code | Cause |
|---|---|
run_busy |
The deployment run row stayed locked past its 2-second bound. |
lock_timeout |
Another lock wait outlived a lock_timeout. |
statement_cancelled |
An operator cancelled the statement, or a server timeout ended it. |
Callers retry these instead of failing. The deploy driver re-dispatches a QA or
approval stage on its 15-second check, and repeats other run calls after 15s,
30s, then 60s. If the run stays busy past the cap it stops with
deployment_run_stayed_busy, leaving the run unchanged and unfailed;
re-run yoke watch deploy -- RUN-ID. yoke qa plan run and yoke qa case run, and so yoke watch qa-plan and yoke watch qa-case, back off on the same
schedule. They stop with run_busy_retries_exhausted after seven attempts.
Claim verification
| Catalog value | Dispatcher obligation |
|---|---|
none |
No work-claim check; handler/project/org authorization still applies. |
item |
Active target item claim belongs to calling session. |
epic |
Calling session holds the target task's parent item claim. |
qa_subject |
Verify the case's item/run/project subject and recording authority. |
self_only |
Target claim belongs to calling session. |
steering |
Require a live steering seat covering the target project/document; refusal names steering_seat_required, seat acquisition or yoke say --steering. |
These six values come from yoke_core.domain.yoke_function_registry; none
means Python None. Claim policy never grants project/org permissions.
Identity, replay and rollout
Use a stable request id for one intended write. Same function/id replays its
ledger response; cross-function reuse refuses. After ledger expiry a call is new.
Never repeat a mutation merely to request --json; request its receipt initially.
Mutations remain committed when a separately reported downstream side effect
degrades. Required operational facts belong to durable owners, not event history.
universe.prune.run manages idempotency by reselecting remaining eligible rows;
it stores no result receipt. Its foreground command does not resend a lost
mutating pass and reports that pass's count as unknown. See
universe retention for the output-only exception.
The registry owns ids, request schemas, handler/claim metadata, adapter status
and minimum serving versions. New ids declare their serving floor; below-floor
calls refuse with a served recovery or operator escalation. Clients tolerate
absent optional response fields from older builds without inventing selectors.
HTTP dispatch/health remain cross-version infrastructure boundaries; agents use
registered adapters. internal adapter status grants no access by itself.
Source maintainers enumerate the catalog with
yoke_core.domain.handlers.__init_register__.register_all_handlers and
yoke_core.domain.yoke_function_registry.list_entries; request schemas come
from schema_for. The source Atlas renderer is
python3 -m yoke_core.tools.atlas_render_docs render.
See DB reference for domain contracts and the CLI entrypoint.
- Claims
Read claim function identities, policies and operation obligations.
- Items
Read item function identities and structured-write contracts.
- Project configuration
Read configuration, strategy and shared-file operation contracts.
- QA
Read QA function identities and execution and evidence obligations.
- Runtime
Read runtime function identities, actor roles and output authority.
- Tasks
Read generated-task, dispatch and review operation contracts.
- Workflows
Read workflow function identities, immutable pins and routing contracts.
- Worktrees
Read lane preparation, landing, merge and close-out contracts.
- Models
Read effective-dated model catalog and publication functions.
- Landing attempts
Read durable evidence for a new landing of an item that already landed.
- Steering dependencies
Read dependency deadlocks, waiting chains and minimal-edge recovery.