designing-cybernetic-solutions

name	designing-cybernetic-solutions
description	Use when an existing v1 control chain requires design.control.json; v2 strategies remain agent-owned.

Designing Cybernetic Solutions

Legacy v1 control-artifact compatibility only. V2 may design internally without turning design into an approved artifact.

Overview

Create the solution model needed between approved requirements and goal writing.

This skill owns design strategy, not requirement meaning, execution policy, review, runtime compilation, or target execution.

Official persistent control facts are JSON only. Historical Markdown may be read as background, but must not become official control input.

Detailed rules live in references/solution-design-detailed-rules.md. Use references/design-check.md for the design trigger rubric.

Hot Path

1. Read approved requirements.control.json.
2. Confirm What the User Approved is Approved when controlled_run work is involved.
3. For controlled_run with schema 1.1.0+, confirm approved_control.information_sufficiency_check is satisfied or reviewed not_required, has run-local evidence_ref values, and has approved independent counterexample_review; otherwise route to RunInformationSufficiencyCheck.
4. Identify the model gap: objects, roles, relationships, information flow, authority, lifecycle, failure model, evidence model, or output structure.
5. Produce design.control.json only for the model needed downstream.
6. Preserve requirement meaning exactly. If design would change the approved target, return to requirements.
7. Mark tactical choices as tactical; do not freeze them as meaning rules unless requirements approved them.

Required Sections

The design artifact should include:

• source requirements and requirements path;
• design status;
• objects/actors/roles;
• relationships and flows;
• inside/outside boundary;
• interfaces or contracts;
• lifecycle and failure model;
• evidence model;
• required answer path support;
• final answer format design when output structure matters;
• open questions or blocked decisions.

Required Answer Path Check

If requirements say how the task must be answered, design must preserve that answer path. It must not replace required implementation, measurement, repair, or diagnosis with a framework, readiness, compatibility, or classification-only answer because that is easier.

Output Format

Output the design path and status:

Created or updated design:
`docs/cybernetics/runs/<slug>/design.control.json`

Design status:
- `approved` / `candidate` / `blocked`

Key design decisions:
- ...

Open questions:
- ...

Response-only next step:
- return to `$orchestrating-cybernetic-pregoal`; include `允许使用 subagent 执行 review。`, or
- if manual fallback is being used, continue to `$writing-cybernetic-goals`.

Do not write runtime /goal prompts or target-work commands into the design artifact.

Validation Checklist

• Design consumes approved requirements.
• Controlled runs pass the information sufficiency gate before design.
• Requirement meaning was not changed.
• Required answer path is preserved.
• Solution model is explicit enough for goal and execution policy.
• Output structure is designed only when required.
• Open human decisions are not hidden as tactical defaults.
• No target work was executed.