Repository navigation
[Direction]: Shared Goal Authority and cross-host coordination #3245
Description
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
- extract the provider-neutral coordination command/precondition/receipt/
outcome core; - qualify a file-backed provider on the same contract;
- prove target-scoped conflicts and atomic original-receipt replay with
deterministic fixtures; - only then evaluate a live NoKV provider behind the same LoopX authority
boundary.
The first useful command remains a bounded claim_work contract. 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
- independently review the provider-neutral claim contract and illegal
transitions; - add deterministic conflict, retry, replay, and stale-generation fixtures;
- document deployment and failure boundaries without provider credentials or
private payloads; - propose one narrow file-backed parity slice before provider-specific runtime
code.
Activity
huangruiteng commentedon Aug 16, 2026
Direction governance is now merged in
#3248.
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.
huangruiteng commentedon Sep 2, 2026
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.
huangruiteng commentedon Sep 27, 2026
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.