03.2 / Yukh system / Accepted state
Accepted state without session custody.
RFC-0003 assigns accepted delivery state to Projects. The current yukh-projects repository implements that responsibility for GitHub Projects; its broader role is under architecture review rather than assumed universal.
Status: published and synthetically qualified. The GitHub Projects implementation includes a controlled-apply profile, but publication and synthetic convergence do not constitute a live apply qualification or make GitHub Projects a universal Yukh dependency.
The problem
When accepted delivery state lives only inside chats, local notes or one agent's memory, parallel participants cannot reliably distinguish proposals from reviewed outcomes.
Responsibility
Today, reconcile declared accepted state with GitHub Projects through deterministic plans, bounded mutations and verifiable postconditions. The stable cross-suite concern is accepted work state; GitHub Projects is the current adapter target.
Authority boundary
Under RFC-0003, Projects retains accepted portfolio and delivery state. It does not coordinate live participants, grant execution authority or turn a message into an accepted mutation. Architecture qualification may later move the stable contract behind multiple adapters only through an explicit superseding decision.
Public contracts
- Desired state: consumer-neutral declarations of the accepted project structure and policy.
- Plan: the deterministic difference between declared and observed GitHub Projects state.
- Apply result: bounded mutations with stable identifiers and diagnostics.
- Postconditions: evidence that observed state now satisfies the accepted declaration.
How it interacts
Coordination carries who is acting, reviewing or handing work over. MCP may expose reconciliation as a governed capability. yukh-projects currently persists accepted delivery state in GitHub Projects without making the tracker itself a universal Yukh semantic.
Next direction
Keep the GitHub adapter useful and qualified while the suite review tests whether accepted work state should become an explicit abstract contract with additional adapters. Any authority/topology change requires a later RFC; this page does not make that change.