Explore test sharding for Once test capabilities

Context

Once now has a generic test capability surface with normalized test metadata and results. The current CI runs Rust tests as a single workspace command per Unix platform, ShellSpec as a single job per Unix platform, and a narrower CAS test job on Windows.

The test metadata shape already has a sharding field, but current providers report it as unsupported. Before adding runner-specific behavior, we should define what sharding means at the Once layer.

What to explore

• Which unit should Once shard: test target, package, test binary, discovered test case, runner-native shard, or action?
• How should shard identity flow through cache keys, output directories, logs, normalized result files, and retries?
• How should once query tests, once query affected-tests, once test, and the MCP test tools expose shardable work?
• How should CI consume shards: static matrix entries, a generated matrix, --shard index/total, or a scheduler-oriented interface?
• How do affected tests and sharding compose when only a subset of tests needs to run?
• Which runners can support native sharding, and which need Once to partition discovered tests before execution?
• How should merged results preserve per-shard logs and still produce one target-level status?

Expected outcome

• A short design proposal for the test sharding model and CLI/MCP surface.
• A proposed schema for the test_info.sharding payload.
• A recommendation for the first runner to prototype against.
• A validation plan that covers Rust tests, ShellSpec, affected tests, and CI integration.

Notes

A useful first pass might keep the implementation deliberately small: model shard identity in the test action, make result paths shard-aware, and prove the interface with one runner before expanding to runner-native support elsewhere.

No GitHub comments yet.