[Task]: Characterize file-backed claim_work with a provider-neutral parity fixture

[LIHUA919]

Task ID or area

#3245 / Shared Goal Authority and cross-host coordination

Technical direction

Shared Goal Authority and cross-host coordination

Intent

I need design feedback before implementation.

Summary

I would like to take the contributor-board slice that characterizes the shipped file-backed claim_work executor with a provider-neutral parity fixture.

On current main, tests/control_plane/test_coordination_executor.py exercises the authority semantics through an in-memory FakeProvider, while tests/control_plane/test_coordination_file_provider.py verifies the built-in file provider mainly at the storage/CAS layer. The missing contributor-sized seam appears to be one semantics-derived scenario matrix that drives the real CoordinationAuthorityExecutor through FileCoordinationProvider, proving that the shipped provider preserves the same public command/precondition/receipt/outcome contract.

This is intended as characterization, not a new authority or provider implementation.

Placement rationale:

• Capability owner: the existing shared-goal/todo coordination domain.
• Provider id: the built-in file coordination provider.
• Delivery: test-only characterization of the shipped provider and executor.
• The existing loopx/control_plane/coordination/ owner is sufficient; no new capability, extension, runtime call site, or provider-specific product abstraction is proposed.

I closed #3679 to respect the one-active-implementation-PR policy and currently have no open implementation PR in this repository. Please confirm whether this bounded slice is useful and may be assigned to me before I start implementation.

Proposed scope

In scope:

• Add a thin, data-driven conformance fixture whose expected outcomes are derived from the coordination domain contract rather than copied from provider output.
• Run the real CoordinationAuthorityExecutor over FileCoordinationProvider for a bounded matrix:
  • same-target competition has exactly one winner;
  • independent targets both apply through internal rebase;
  • A -> B -> replay A returns the exact original receipt after reconstructing the executor and file-provider handle;
  • same operation id with different command semantics is rejected with no state mutation;
  • stale provider generation does not duplicate authority transitions or receipts.
• Keep fixtures synthetic and public-safe.
• Preserve current public behavior and default provider selection.

Out of scope:

• Live NoKV, NoKV SDK/CLI integration, credentials, service startup, or provider promotion.
• New coordination commands, renew/release/reclaim, distributed quota, scheduling, host execution, migration, or HA.
• Refactoring production code unless the independent fixture exposes a narrow existing contract violation; any broader behavior change should be re-scoped before implementation.
• Re-deriving authority rules inside the fixture or creating a second reference implementation.

Intended base branch

main

Relevant files or commands

• loopx/control_plane/coordination/executor.py
• loopx/control_plane/coordination/file_provider.py
• tests/control_plane/test_coordination_executor.py
• tests/control_plane/test_coordination_file_provider.py
• Proposed focused fixture: tests/control_plane/test_coordination_provider_parity.py
• docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md

Validation plan

• python3 -m pytest -q tests/control_plane/test_coordination_executor.py tests/control_plane/test_coordination_file_provider.py tests/control_plane/test_coordination_provider_parity.py
• python3 -m py_compile loopx/control_plane/coordination/*.py tests/control_plane/test_coordination_provider_parity.py
• loopx check --scan-path loopx/control_plane/coordination --scan-path tests/control_plane --scan-path docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md
• git diff --check
• Before staging, run the repository's risk-based canary set required for control-plane changes.

Public/private boundary

• This issue does not include private benchmark traces, verifier output, credentials, internal document links, raw agent sessions, or local runtime state.
• I will not run or duplicate maintainer-owned benchmark cases unless a maintainer explicitly splits out a public task.

[Yue021130]

I would like to take this slice if it is still free. / 如果这个切片还空闲，我想接手。

Approach / 方案：按 issue 里列的边界，只做 test-only 刻画（characterization），不改产品代码：

• 新增 tests/control_plane/test_coordination_provider_parity.py，用一个数据驱动的矩阵驱动真实 CoordinationAuthorityExecutor over FileCoordinationProvider。
• 覆盖 issue 列出的 5 个场景：同一 target 竞争只有一个赢家、独立 target 通过内部 rebase 双双生效、A -> B -> replay A 在重建 executor 与 file-provider handle 后返回原始 receipt、同 operation id 不同命令语义被拒且不产生状态变更、陈旧 provider generation 不重复 authority 转换或 receipt。
• 期望值从 coordination 域契约推导，不从 provider 输出复制；fixture 保持 synthetic 且 public-safe。
• 保持默认 provider 选择与现有公开行为不变。

Questions / 想确认两点：

1. @LIHUA919 你还在推进这个吗？你目前有 feat(manager): reconcile uncertain delegated result delivery #4372 / fix(goal-frontier): diagnose missing final-outcome claims #4341 两个在途 PR，如果这条已经不再做，我就接手。
2. 这是你 issue 里写的 "I need design feedback before implementation"。我打算直接按上面的边界开一个 PR 当作设计提案（不改产品代码），这样 review 成本最低。若你更希望先讨论方案，我可以先在评论里贴完整矩阵再动手。