name: goal-management description: Manage the task list of approved work carried across turns, its progress, approvals, and completion. when_to_use: 'Goal requests or approved multi-turn work in progress; not one-turn tasks or recurring schedules.' dependencies: tools:

• type: tool

value: goal metadata: version: "1.0.1"

Goal management

Use goal to maintain durable tasks and their idle reminders. The tool schema owns arguments and limits; this guide owns the lifecycle and completion policy.

Admission and current state

Create a Goal for an explicit user or system/developer Goal request, or for user delegation or approval of work that runs past a single turn: a staged refactor or migration, repeated improvement passes, a partition list or candidate inventory carried between turns, or an open-ended objective that must be finished. A time budget is optional, and the user need not name Goal — approval of an assistant-proposed scope also qualifies. Resolve a short approval against the preceding proposal and retain any user constraints.

Create the Goal so that scope and state survive the turn boundary instead of being rebuilt or dropped. A single-turn task, planning, estimates, and deadlines alone do not qualify, and neither does an unaccepted assistant proposal.

If work needs approval, obtain it first; then create the Goal, or reconcile an existing one, before starting the approved work, including execution-stage exploration. An existing Goal does not authorize new scope.

For creation, use the requested or approved budget for time_limit_minutes; omit it when no budget was agreed — an untimed Goal runs on its objective alone. A stated budget commits that time: "a 5-hour Goal", "improvement rounds for 3 hours", or polishing for a period use time_mode: duration, the default when a budget is given. Use time_mode: max only when the user frames the budget as an upper bound ("at most", "within", "최대", "안에").

Use the latest returned state and revision. If unknown or stale, read status and reconcile before mutating. Never replay a stale mutation blindly. For multi-step work, record the approved milestones and keep them durable. One-step work does not need a ceremonial plan or a separate verification row.

Additional rounds

An approved request to continue for another period changes the work commitment, not just the conversation. Reconcile the Goal before research or execution:

• For the same unfinished objective, use resume with the approved remaining

budget in time_limit_minutes and new tasks or task updates in one call. This also covers a paused Goal or exhausted budget with all old rows done. Preserve completed rows and unfinished requirements; record the new round's work rather than leaving the old completed checklist unchanged.

• The resume budget runs from now and retains elapsed work. Omit it for a

plain continuation with no approved time change. Preserve time_mode unless the new request explicitly changes the time commitment.

• If the prior Goal is complete or stopped, create a new Goal for the approved

round; the runtime archives the prior record. Do not falsely complete or abandon unfinished work merely to get a fresh clock.

• Proceed only after the returned state has the intended active status,

remaining budget, and tasks. A statement that work will continue is not a substitute for the mutation. Reconcile a rejected update before continuing.

Maintain progress

• Update tasks at meaningful milestones and scope changes. Preserve unfinished

requirements; drop a task only after the user changes its scope.

• Prefer update_tasks for changed items; set_tasks replaces the full list.

Serialize mutations to the same Goal. resume accepts updates and additions atomically. resume a blocked Goal when the user's reply supplies what it was waiting for or asks to continue, and a cancelled-turn pause when the next instruction carries the objective forward; a user-initiated pause resumes only when the user asks. Bookkeeping alone does not authorize execution.

• Batch related task changes and independent work. Creation, status, and resume return full state; other

successful replies are brief and need no confirmation read.

Approval and waiting

Finish every approved step and decide choices within the objective yourself, including any option you would recommend; state those decisions in the report instead of asking. Park as awaiting_approval only work that needs the user's own action (a sign-in, a device check) or scope outside the objective, including a commit, push, release, deployment, or payment the user has not requested, together with anything its answer could invalidate. Record additions immediately and continue unaffected approved work.

Foreground app or window control, local and test-environment runs and the test resources they consume, reversible changes, and time or cost belong to in-scope work, not approval gates. Wanting confirmation for in-scope work is never a reason to stop.

Never pause on your own initiative: pause is only for the user's explicit request to pause this Goal. When no approved work can proceed without the user, ask the parked questions together and report that impasse with block. Respect a user-initiated pause until the user asks to continue; routine errors and retries are not reasons to stop.

A cancelled turn pauses the Goal with pauseReason: cancelled. The user stopped that turn, not the objective, and only the stop control retires a Goal. Judge the next instruction: resume and continue the work when it carries this objective forward or redirects it, and leave the Goal paused when it is unrelated or asks you to stay stopped.

Each continuation should do concrete work or wait on a verified live handle. Evidence that changes the next action is progress; repeated reports and plan updates alone are not. Reassess a no-progress turn and take the next safe action. Observation timeouts do not terminate the observed work or justify restarting it. An automatic continuation that ends without a tool call stops automatic turns until the task list changes, the user acts, or the time boundary arrives; end a turn that way only when no safe action remains, not to idle out the clock.

Completion and recovery

Distinguish a turn boundary, objective completion, and a budget stop. A Goal can stay active across turn-ending progress reports; never present such a report as completion of the whole objective.

Complete only after auditing every user condition against evidence. Reuse valid checks; a separate verification task is optional, verification itself is not. A maximum time budget allows verified early completion. A full-period commitment does not. Preserve an existing Goal's time mode; never extend its budget or change its meaning on your own. Do not end a Goal merely because a partial result is available.

For an achieved objective, reconcile the task records, call complete, and check the returned status before claiming Goal completion. A tool call or a plausible final response is not itself confirmation.

Time-budget extension

Elapsed-time budgets are a Mixdog extension to the persistent Goal lifecycle. Keep max upper bounds distinct from explicitly requested duration periods. An advance deadline warning does not stop the Goal or request an early final report; prioritize bounded approved work and needed verification. Under a max budget, do not invent unfinished tasks merely to fill remaining clock time. Under a duration commitment, when the recorded rows are done, find the next round's real improvements within the objective and record them as new tasks instead of idling or reporting completion.

At the boundary, the runtime first records duration_reached, disables automatic Goal work, and delivers closeout without cancelling the current turn. Finish or safely park only in-flight work, then report once. The elapsed period proves only that the time condition ended: call complete only if the whole objective is verified; otherwise retain unfinished tasks and the limited status. Do not resume or extend the Goal without the user's approval.

Blocked and redirected work

block stops the Goal immediately, with a stable description of an impasse that only external state or the user can clear. Do not block the first time a blocker appears: block only after the same condition has repeated for three consecutive Goal turns, counting the user-triggered turn and automatic continuations; after a resume, count only turns since that resume. Until then, continue any available work and re-check the blocker against current state with a tool each turn rather than restating it. When current state verifies an impasse that only the user can clear (their action, approval, credentials, or a resource they control), block on that turn. Once the threshold is met, block instead of reporting the same blocker again. Treat equivalent blockers as the same condition even when their wording or stated next step changes. Never block for difficulty, slowness, uncertainty, a choice you can make, confirmation for in-scope work, or clarification that would only help. Use abandon only when the user redirects away from the objective; it preserves a stopped record rather than declaring success.

Done when the returned Goal state accurately represents completed work, remaining approved work, or the justified waiting/terminal condition.