Repository navigation
[Direction]: Shared Goal Authority and cross-host coordination #3245
Description
Activity
Direction governance is now merged in
#3248.- Canonical map: English · 中文
- Pinned community projection: Discussion #2851
- Claimable work: Contributor Task Board
This issue remains the long-lived direction and decision tracker. Concrete
implementation should use a separate bounded issue or task-board row with an
explicit base branch, smallest slice, non-goals, and validation plan.PostgreSQL provider hardening continues in #3839: required tenant scope, transaction-local tenant context, forced RLS on every coordination table, restricted runtime-role qualification, and connection eviction after uncertain cleanup. This remains provider-only—no authentication service, production runtime caller, or authority-source promotion—and therefore precedes shadow parity/canary work.
RFC task reconciliation: keep this issue as the Shared Goal Authority delivery tracker in the 39-RFC task map; no replacement issue is being opened.
The original body’s “draft / extract claim_work first” snapshot is historical. Current
mainhas native TS authority, File/SQLite paths, source capture, paged canonical reads and substantial transaction/recovery migration. The current RFC frontier and #3225 own the remaining cutover, retirement and qualification boundary. #4931, #4224, #3281 and #4726 retain their existing performance/provider scopes.Contributors should select a current unowned acceptance gap and coordinate with the active transaction owners; do not rebuild the original claim contract or interpret this update as provider/default promotion. This is source/ownership reconciliation, not a fresh real-backend test result.
Outcome
Let agents on different hosts coordinate over one explicitly shared LoopX goal
without turning a storage provider, host session, claim, or lease into a new
control-plane authority.
The canonical proposal is the
Shared-Goal Online Authority and Pluggable Coordination Provider RFC,
proposed by NoKV Lab and introduced through
#2787.
Current stage
Draft contract and provider qualification. NoKV is an unpromoted optional
provider candidate. The current RFC maps a static API baseline and does not
claim qualification against a live NoKV deployment.
This direction is deliberately named Shared Goal Authority and Cross-host
Coordination, not "a shared metadata database." Run history, status, quota,
scheduler state, host sessions, and evidence keep their existing owners; an
agent does not connect directly to NoKV, and NoKV does not become LoopX
authority.
Next qualifying slice
outcome core;
deterministic fixtures;
boundary.
The first useful command remains a bounded
claim_workcontract. Renew,release, reclaim, stale fencing, distributed quota, multi-tenant authentication,
high availability, and wider state synchronization are later decisions, not
implicit scope.
Contributor-ready cuts
transitions;
private payloads;
code.