v1.5.0

Runtime Capability Plugins

• Custom sink and worker kinds — arbiter handler clauses and worker runtime clauses now accept host-registered identifiers instead of only the built-in transport list. chain and worker remain reserved runtime kinds, while chain://... and worker://... remain runtime-owned source schemes.
• Portable capability protocol — a new gRPC CapabilityService contract lets non-Go hosts implement source loaders, sink handlers, and worker runtimes over a shared SDK-facing protocol.
• Reference runtime hook-up — arbiter-runtime --capability-grpc ... now dials one remote capability service, binds its declared source schemes, sink kinds, and worker kinds into the workflow runner, and exposes that manifest on /status.
• Explicit worker-runtime boundary — sink handlers no longer implicitly count as worker runtimes. Workers stay typed capabilities, so a worker kind must be explicitly registered on the worker-runtime surface before a bundle can run.
• Unified runtime capability status — the workflow runner now exposes one inspectable capability surface across sources, sinks, and worker runtimes, tagged by owner (core, host, or plugin) instead of only dumping raw plugin manifests.
• Runtime gRPC introspection — arbiter-runtime can now serve RuntimeService.GetRuntimeCapabilities, and the CLI plus Node/Python/Rust SDKs expose that same unified capability surface without scraping HTTP /status.
• Unified transport hardening — arbiter-runtime --grpc now uses the same bearer-token and TLS/mTLS hardening model as arbiter serve, instead of exposing a separate plaintext-only control surface.
• Explicit plugin transport — capability-plugin dialing now uses the same target grammar as the rest of Arbiter (grpc://, grpcs://, http://, https://, or bare host:port) plus explicit token, CA, server-name, and plaintext flags.
• Inspectable runtime posture — /status and RuntimeService.GetRuntimeCapabilities now expose the runtime control surface's effective auth/TLS/public-listener posture and the bound capability-plugin connection's target/auth/TLS/server-name posture, so operators can inspect the real runtime shape instead of reconstructing it from flags.
• Inspectable agent posture — arbiter-agent /status now exposes local control-listener posture, upstream transport posture, readiness policy/reason, and per-bundle bundle/override watch connectivity alongside the existing sync counters.
• Agent transport hardening parity — arbiter-agent now supports the same local bearer-token and TLS/mTLS hardening shape as arbiter-runtime on its local gRPC surface, so the reported control posture is backed by real configuration instead of placeholders.
• Canonical operator surfaces — arbiter-runtime /status, arbiter-agent /status, and arbiter runtime-capabilities now use the same small inspection vocabulary and section order instead of mixing flat counters, ad hoc headings, and transport-specific nouns.
• Status over gRPC — the canonical operator surfaces now travel over RPC too: RuntimeService.GetRuntimeStatus exposes readiness -> issues -> transport -> capabilities -> activity, AgentService.GetAgentStatus exposes readiness -> issues -> transport -> sync, ControlService.GetControlStatus exposes readiness -> issues -> transport -> bundles -> overrides -> sessions -> audit, and the CLI now ships arbiter runtime-status, arbiter agent-status, plus arbiter control-status.
• Hosted control-plane introspection — arbiter serve now exposes real /status output instead of identity-only JSON, including listener auth/TLS posture, persisted bundle/override files, active bundle versions, live expert-session occupancy, and explicit audit posture (jsonl vs discard, durable vs non-durable).
• Audit health, not just audit config — the hosted control-plane audit section now reports whether recording is currently healthy, plus write/error counters and the last successful or failed audit write timestamps, so operators can see when decision recording is configured but not actually succeeding.
• Persistence health, not just persistence config — the hosted control-plane bundles and overrides sections now report whether file-backed state is currently healthy, plus write/error counters and the last successful or failed persistence write timestamps, so operators can see when durable state is configured but not actually sticking.
• Readiness follows durability health — hosted control /readyz now uses the same readiness judgment as the readiness section, so configured bundle persistence, override persistence, or audit recording failures take the control plane out of readiness instead of leaving probes green.
• Canonical issue lists — runtime, agent, and hosted control status now all expose an explicit issues surface with shared severity, scope, subject, code, message, and blocking fields, so operators and SDKs can inspect concrete failures and insecure transport posture without reconstructing them from mixed booleans and free-form reasons.
• CLI issue gating — arbiter runtime-status, arbiter agent-status, and arbiter control-status now accept --fail-on-issues, so automation can fail fast on blocking status issues without scraping terminal output.
• Issue-code contract — the status issue vocabulary is now centralized and documented, so issues.code is an explicit operator-facing contract instead of a scattered implementation detail.
• Issue catalog surfaces — the canonical status-issue vocabulary now carries explicit runtime/agent/control surface membership and is exposed directly through arbiter status-issues plus GetStatusIssueCatalog on runtime, agent, and control gRPC services.
• HTTP issue catalogs — runtime, agent, and hosted control now also expose scoped GET /status/issues JSON catalogs, so HTTP-first operators can inspect the same issue contract without gRPC tooling.
• Remote CLI issue catalogs — arbiter status-issues now accepts a live target plus auth/TLS flags, auto-detects runtime vs agent vs control surfaces, and prints the remote-advertised issue catalog instead of assuming the local CLI build matches the running process.
• Versioned operator identity — runtime capability/status, agent status, hosted control status, and issue-catalog surfaces now advertise operator.product, operator.build_version, and operator.operator_contract_version; the CLI prints that contract stamp on every remote inspection command and can fail on mismatches via --fail-on-contract-mismatch, so tooling can verify build and operator-contract compatibility directly from a live process.

SDKs

• SDK surface parity — the shipped Node, Python, and Rust clients now track the current gRPC control-plane surface instead of lagging behind it. Strategy evaluation, strategy-candidate override mutation, structured TraceStep fields, and explicit kill_switch_state now flow through the vendored SDK contracts as well.
• Runtime and agent status clients — the shipped Node, Python, and Rust wrappers now expose runtime-status and agent-status RPCs alongside runtime-capability introspection, so embedders do not need to scrape HTTP /status.
• Hosted control-status clients — the shipped Node, Python, and Rust wrappers now also expose ControlService.GetControlStatus, so hosted control-plane introspection is not Go-only.
• Status-issue catalog clients — the shipped Node, Python, and Rust wrappers now also expose GetStatusIssueCatalog, so automation can inspect the issue vocabulary itself instead of hardcoding string lists.
• SDK operator contract guards — the Node, Python, and Rust clients now expose operator-contract inspection helpers plus optional strict compatibility enforcement on runtime-capability, runtime-status, agent-status, control-status, and status-issue catalog RPCs.
• Capability-service mirrors — the Node, Python, and Rust SDK trees now mirror the runtime capability proto as well, so embedders can implement source/sink/worker plugins in those languages instead of being limited to Go interfaces.
• Capability server helpers — Node and Python now ship CapabilityServer helpers, and Rust ships CapabilityPlugin plus handler traits, so SDK authors can register source/sink/worker behavior without hand-writing raw gRPC service plumbing.

Docs

• Authoring house style — the README now gives a firmer opinion on .arb layout: typed declarations first, shared governance next, one dominant decision surface per file, runtime-edge modules at the boundary, explicit split triggers, inward import direction, colocated .test.arb files, and canonical governance -> match/bind -> effect clause order across modalities.