Classify failures versus unknown outcomes after partial apply #25

Goal

Detect and classify partial-apply outcomes as confirmed failure versus unknown, so recovery never replays an uncertain mutation.

Observations

• A partial apply can leave the API in an unknown state (for example, a timeout after send).
• Treating unknown as success or failure both risk duplication.

Decision gate

Approve the classification rules and the uncertainty boundary before implementing recovery.

Acceptance criteria

• Each mutation outcome is classified as applied, failed, or unknown.
• Unknown outcomes are never assumed applied or failed.
• Classification is recorded per mutation with a stable id.

Verification

• Injected timeout after send -> outcome recorded as unknown, no replay attempt.
• Injected hard error before send -> outcome recorded as failed.

Release checkpoint

Remaining risk: unknown is a real state, not a bug to hide. No auto-rollback as a workaround.

Tracking

Roadmap item: B05-01. All acceptance criteria remain pending; publication does not grant approval or release authority.

Dependencies

• Depends on Design enforceable per-module reconciliation intent artifacts #22 (B04-01).