Record the brief
record_briefRecords a problem's goal, assumptions, and criteria as its brief, creating or replacing the case file so stale requirements are detected before optimization.
Instructions
Record the brief of a problem YAML: what the user wants and the assumptions that you state. Say it, then go on.
A case is one problem YAML with the STL files it names, one brief and many runs. This call makes the case
(the files <yaml stem>.case.json and <yaml stem>.case-log.jsonl beside the YAML) or replaces its brief.
The case keeps the SHA-256 of the YAML and of each region file with the brief, and the values of the method keys
of the YAML. If a file or a requirement key changes later, case_status and run_topopt say that the brief is
stale and name it. For a case with no brief or a stale brief, run_topopt returns awaiting_user with an override.
A change of a method setting (for example settings.solver or settings.voxel_size) is a fact and not stale:
run_topopt goes on, and brief_facts names the key with both values, so that you can report it.
yaml_path: the problem YAML in the work folder. A YAML outside the work folder (an example in the code
folder, for example) gets no case file: the reply gives the fact and the options. A YAML in the code
folder of a source checkout is recorded, with a fact and an option (a work folder is the better place).
text: the brief in plain words: the goal, the loads and where they come from, the mounting, the material,
the critical sizes.
assumptions: a list of {"text": ..., "origin": ...}. origin is user (the user said it), inferred
(you concluded it) or default (a default value). The YAML assumptions list is a list of strings
that run.json copies; the reply names the texts that differ from the brief.
criteria: what the result has to show, in the same form (optional).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| criteria | No | ||
| yaml_path | Yes | ||
| assumptions | No |