[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.