One record per probe

The harness stays maintainable when a new probe is a new record, not a new branch. The runner should know how to iterate, call a provider, time it, and save a result. It should not know what any individual case means.

Use one boring record shape

A useful minimum is id, input, expected, and skill. Add fields only when the scorer or provider can interpret them generically. Differences that live in if probe.id == ... branches are missing data.

Build an offline probe runner

Complete the probe set and the generic runner. Passing means a sixth probe can flow through the same function without adding an id-specific branch. The stub is deliberately local: this exercise does not need a model, network, or API key.

Save the probe set

Link the repository, gist, or shared document containing the probe records. In the reflection, note which field you were most tempted to encode as a runner branch.

Time the offline run

Run the full probe set against the stub provider and record wall-clock time. This baseline tells you how much overhead the harness itself contributes.

Audit the probe shape

Inspect the records while the set is still small enough to change cheaply.