Case Foundry

Prerequisites

• Ready coverage setup, active Stories, and actionable tuple targets.
• A current input snapshot whose freshness can be verified.

Case Foundry coordinates bounded case preparation from the saved coverage setup and Coverage Stories. Use Generate for the first run and Update after the governed inputs change. A blocked action means required setup, readiness, or upstream evidence is not yet available.

Run states and freshness

A Foundry run reports QUEUED, RUNNING, COMPLETED, PARTIAL, FAILED, or CANCELLED. Keep the run identity and input snapshot together when diagnosing it. Completion can report Cases added, synthesized, or retrieved; these counts explain construction activity, not acceptance into trusted benchmark evidence.

The workspace distinguishes a fresh result from one whose input snapshot changed. If coverage setup, Story structure, or relevant dataset context changed after the run began, update the Foundry work. Do not use an old completion badge as proof that the current coverage contract has been handled.

Before and after Foundry

Before running, make the setup ready, activate the intended Stories, and check tuple targets. If a specialist must settle an ambiguous standard, request an Expert Contribution instead of generating around the ambiguity.

After running, open Case Review. Prepared candidates start as reviewable material rather than automatically becoming durable benchmark Cases. Inspect their evidence fit, sources, facet traces, inputs, and generated artifacts. Remove weak or redundant candidates and resolve material failures before inclusion.

Failure handling

For a partial or failed run, preserve successful bounded work, read the failure detail, and retry only the missing scope when the product offers that action. Cancellation stops the current operation; it does not roll back Cases already materialized by a completed portion. Recheck freshness after any retry.

Object and state changes

A Foundry action creates a run and can prepare, synthesize, retrieve, or add candidate Cases. Update creates new bounded work from changed input. The run does not create a Dataset Snapshot or bypass Case Review.

Success criteria

• Terminal status and input freshness are known.
• Summary counts are interpreted as construction activity.
• Prepared candidates move to review rather than automatic trust.

Common failure modes

• Treating COMPLETED as Case acceptance.
• Retrying stale work without updating its input.
• Generating around an unresolved correctness question.

Related reference pages

Related troubleshooting pages

Source confidence

Code-backed: the active Foundry API, run types, and workspace hook define actions, states, freshness, and summary counts. Case acceptance is verified in the separate Case Review surface.