Authoring a Case

1. From chat — describe the problem; the agent drafts the CaseSpec.
2. From a template — pick a starter from the templates browser; the CaseSpec arrives pre-populated.
3. From an existing case — fork a case; the new CaseSpec inherits validated assumptions and applicability bounds.

Every edit — typed by you, suggested by the agent, or applied automatically by a solver pack — flows through typed patch operations. Patches are auditable; you can see who changed what, when, and why. Never edit a generated solver file by hand and expect the case to remember it — the spec is the source.

Reference geometry via named selections (patches, faces, regions). They keep boundary conditions, post-processing recipes, and report figures stable across mesh regenerations and CAD updates.

Add the validation plan to the CaseSpec before running. Late-added QoIs are still extractable, but their absence at run time often means the right monitors weren't recorded, forcing a re-run.

If you mean "this case is incompressible and laminar," say so in the CaseSpec. The solver pack will refuse to materialize a compressible setup and the memory layer will scope this case's findings correctly.