GraphSpec.problem — and who owns a brief across a boundary #10

The one field three independent sources need: ChatGPT's nested-graph handoff, its README handoff, and the subgraph-as-unit proposal. GraphSpec has no problem today (verified — its ClassVars are name, nodes, joins, decisions, edges, state_type, deps_type, input_type, output_type).

The rule

• StepSpec.problem — what every implementation of this role must address.
• GraphSpec.problem — the reusable graph's own problem.
• Neither overrides, replaces or fills in the other, and absence stays distinguishable from a supplied brief. A missing brief must never read as "this stage is easy."

Worked case: a parent role is "extract claims with supporting quotations"; a child graph is "extract factual claims." Choosing that child does not remove the parent's quotation requirement, and matching types cannot establish semantic compatibility.

UI

Show the graph's brief, the selected role's brief, and a nested graph's brief separately. Switching implementations must not change the role's brief, and a child's brief must never be substituted when the role's is missing.

⚠️ StepSpec.problem now renders in the Panel, non-empty only, with browser tests — it reached the payload and stopped there until #8's last commit. Same mistake is available here.

Out of scope

No rubric field. A rubric belongs where something can run it, which is a graph boundary — and there is no step-level runner (grepped: no step_battle/run_step/StepRunner anywhere). No mandatory prose fields: a required brief makes the ones written to satisfy a type-checker indistinguishable from the ones written because someone thought.