| name | goal |
| description | Define and run one bounded Hypo-Workflow delivery outcome without fake Milestones. Use for /hw:goal or when the user wants one explicit acceptance target that a capable model can execute after approval. |
Goal Delivery
输出语言规则
用户可见内容遵循项目输出语言；缺失时跟随当前对话语言。内部 schema key 保持英文。
A Goal is a peer of Cycle: one Design, one execution boundary, and one final manual acceptance.
Use the Root Core Call Contract: import from the installed bundle, pass the target workspace as root, create the store with an explicit zero-argument Clock, and give every mutation a unique safe { id }. Issue transition Receipts only after the host has shown the full binding and received explicit user confirmation.
- Gather outcome, acceptance criteria, constraints, and repository evidence. Use
assessPlanReadiness; ask only unresolved material questions.
- Compile with
compileGoalDesign. Do not add milestones.
- Select execution topology from task size and policy.
- For each selected Worker, have the host Agent generate and show a bounded Task Assessment, validate it with
validateTaskAssessment, and call selectWorkerRouting. Persist only the semantic decision and assessment, never the generating prompt.
- Apply
execution.worker_routing.mode: off omits the hint, advisory records an explicit unsupported-host fallback, and required blocks that Worker start when the semantic handoff is unavailable. Routing does not change topology or acceptance.
- Persist the proposal with
createDeliveryStore(...).proposeGoal; report the Design in chat.
- Approval uses a scoped
delivery.approve Receipt and moves only to waiting_to_start.
- Begin work only after a separate explicit-start intent and
delivery.start Receipt.
- Verify real file-bound worker evidence, request final acceptance, then use
/hw:accept or /hw:reject.
Revision feedback writes Feedback plus a revised Design Record and returns to needs_revision; it never authorizes product edits or auto-starts.
