Engine: each command lists what it needs, and execute checks it first

CommandSpec gains `requires: &[Requirement]` (crates/engine/src/requirement.rs): an open
design, geometry, nodes, a mesh, something to analyse, materials and sections for the
elements, sets, the definition an edit or delete acts on, a step, a result. Session::execute
checks them before running, so a command missing one fails at once with no partial work,
naming each missing piece and the toolbar entry that provides it ("Needs a material —
Properties › Material"). Requirements are real prerequisites (the model's own reference
checks and model.check's rules), never a workflow order. engine.commands / list_commands
list them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UhhZMBTviDQxZvwnyP89fo

docs/architecture.md

@@ -352,6 +352,14 @@ step count and by an estimate of the memory the kept states hold (oldest steps g
 Commands of kind `Session` (`file.*`, `edit.*`) are never journalled. `file.save` and `file.open`
 write and read `.fieldcraft` files; the desktop app autosaves unsaved work for `file.recover`.
 
+Each command lists what it cannot run without (`requires`: an open design, geometry, a mesh, a
+material, a step, a result, …; `crates/engine/src/requirement.rs`), next to its id. A requirement
+is a real prerequisite, never a workflow order. `Session::execute` checks them first and fails
+without doing anything, naming each missing piece and the toolbar entry that provides it ("Needs
+a material — Properties › Material"). The desktop UI reads the same check
+(`Session::availability`, a few counts, evaluated every frame) to grey ribbon buttons, command
+search results and Solve, with the same text as their tooltip.
+
 ## Test corpus
 
 Meshers are measured on our own parts (`docs/adr/0001-libraries.md`, test geometry). Each part is

docs/mcp.md

@@ -91,8 +91,8 @@ software on the computer.
 
 | Tool | Arguments | What it does |
 |---|---|---|
-| `list_commands` | `filter?` | Every command with its label, parameter documentation and `schema` (its parameters as JSON Schema: types, units as `x-dimension`, defaults, required fields, one-of variants); `filter` matches id and label. |
-| `execute` | `command`, `params?` | Run any command (`list_commands`). A failure leaves the model unchanged and names what to fix. |
+| `list_commands` | `filter?` | Every command with its label, parameter documentation and `schema` (its parameters as JSON Schema: types, units as `x-dimension`, defaults, required fields, one-of variants) and `requires` (what the session must hold first: `design`, `geometry`, `mesh`, `material`, `step`, `result`, …); `filter` matches id and label. |
+| `execute` | `command`, `params?` | Run any command (`list_commands`). A failure leaves the model unchanged and names what to fix; a command whose `requires` are not met fails before doing anything, naming each missing piece and the command that provides it. |
 | `batch` | `commands: [{command, params}]` | Run steps in order, stop at the first error; the reply has every result and the failing step (`failed.index`, `failed.command`, `failed.error`). Steps before it stay applied (`undo` takes them back). |
 | `inspect_model` | — | `model.info` (counts, units, definitions), `model.activity` (the step table) and `geometry.bodies` (bodies with measures and persistent face names, which sets name as `{body, face}`). |
 | `check_model` | — | `model.check`: errors and warnings, each naming its item. |