Design: define verification matrix for learning parallel runtime

[devkade]

Design: define verification matrix for learning parallel runtime

Parent: #167
Related: #168, #171, #172

Summary

Define the test and verification matrix required before the objective-driven learning parallel runtime can be considered implementation-ready.

Scope

Cover verification for:

• schema validation;
• event replay;
• DAG readiness;
• claim/lease race prevention;
• worker heartbeat and stale detection;
• policy simulation determinism;
• RewardRecord emission;
• objective/evaluation guardrails;
• repair task creation;
• integration dry-run;
• retention/safe-close lifecycle;
• .ilchul storage compatibility.

Non-goals

• No implementation in this issue.
• No CI policy change unless split into a follow-up.

Acceptance criteria

• Unit test matrix is defined.
• Integration test matrix is defined.
• E2E smoke path is defined.
• Failure-mode tests are defined.
• Required fixtures/artifacts are listed.
• Minimum evidence for closing each child issue is documented.

Verification

• Review against Roadmap: objective-driven learning parallel runtime harness #167 child issues.
• Confirm every runtime invariant has a corresponding test category.

[devkade]

Design decision

needs-design is resolved by #167's Development Order.

Decisions:

• Design: define verification matrix for learning parallel runtime #191 is the verification gate before runtime readiness claims or default changes.
• The matrix should be defined after Steps 1-5 are concrete enough to test, but it should not block starting those implementation steps.
• Required categories: schema validation, event replay/snapshot reconstruction, DAG readiness, claim/lease race prevention, worker heartbeat/stale detection, evidence-required completion, fake adapter integration, reward-ledger record shape, and .ilchul storage compatibility.
• Every MVP invariant listed in Roadmap: objective-driven learning parallel runtime harness #167 must map to at least one unit, fixture, integration, or smoke test category.
• Verification evidence should distinguish unit guarantees from integration/smoke confidence.

Implementation can proceed as Step 6 of #167.