[Feature] Delegate existing goal milestones and link their task results

[wangtaotaotao95]

What outcome should OpenMuse handle?

Delegate a specific milestone within an existing goal, follow its task, inspect the saved result, and decide whether that milestone is complete.

For example, a goal might contain “Analyze September spending.” Completing the analysis should make its result available from that original milestone. The user should not have to reconcile an unchecked milestone with a newly appended, completed entry for the same work.

This would make goal progress reflect the user's milestones while keeping task completion separate from confirmation that the milestone was achieved.

Current behavior and reproduction

Checked current main at 205cc386:

• AgentTask has goalId, but no milestone reference. A milestone has id, title, and done.
• GoalCard provides goal-level “Plan next steps,” task cards, and manual milestone checkboxes, but no way to delegate a particular milestone.
• On task success, publishOutcome() appends a completed milestone keyed by the task ID rather than linking an existing one.

A local service-level probe on that exact commit reproduced the gap without a model or Google account, using the sample-app setup from tests/workflows.test.ts:

1. Create a goal with one milestone, “Analyze September spending.”
2. Create a finance task with the same title and that goalId, passing a valid one-row CSV:

   date,description,amount,category
   2026-09-01,Coffee,10.00,Food

3. Run agent.worker.tick() and read the task and goal back.

Observed: the task succeeds and saves one artifact. The goal now has two identically titled milestones: the original remains done: false; a second entry, whose ID is the task ID, is done: true. This is the current goal-level behavior; there is no supported field for selecting the original milestone. The probe verified persisted service behavior, not a live UI or model interaction.

Proposed behavior

Keep the first slice small and reuse the existing task and goal interfaces:

1. Add an optional milestoneId alongside goalId on a delegated task and its creation input. The server validates that the goal belongs to the authenticated owner and the milestone belongs to that goal. Link by stable ID, never title or array position.
2. Add “Delegate” to an incomplete milestone. Open the existing delegation flow with its goal/milestone context, then show linked task status and an “Open task” entry that uses the current task detail and saved artifacts.
3. On success, keep the linked milestone unchecked until the user marks it complete. Reuse the existing manual checkbox; people must also remain able to mark work completed outside OpenMuse. Completion should not depend on a model declaring success.
4. For tasks with an explicit milestone link, do not append a synthetic completed milestone. Preserve existing persisted records and behavior for tasks without that link.
5. Make repeated delivery of the same delegation request idempotent. An explicit later delegation may create another task; retain earlier task/result links rather than permanently deduplicating by milestone ID.

Task status, result links, and milestone completion can be derived from the existing records. No separate evidence store or new planning engine is needed.

How would we verify it works?

• Delegating an existing milestone retains its ID/title and creates a task with the correct goal and milestone links. Its saved result is reachable from that milestone.
• Success leaves the original milestone unchanged and adds no synthetic milestone. Manual completion updates that milestone only; failure, cancellation, input requests, and pending approvals never mark it complete.
• Request replay, worker restart, and repeated outcome reconciliation create no duplicate task or milestone and do not inflate progress. Explicit subsequent delegation can retain a separate result.
• Cross-owner goals and milestones from another goal are rejected before task creation.
• Renaming or reordering milestones preserves links. Removing a milestone during execution does not recreate it when the task finishes; the task/result remains accessible and the missing link is handled explicitly.
• A stale client or concurrent task completion cannot overwrite unrelated milestones, restore an old title, or undo a manual completion.
• Existing goal pause behavior and action approvals remain intact. Previously saved goals/tasks without a milestone link still load and behave as before.
• Add service/API regression coverage using local fixtures; run the contribution checks and verify the shared UI on web and a native runtime, with a short recording. Model/provider test accounts are not required to verify the relationship itself.

These are proposed acceptance criteria; only the current-behavior probe above has been executed.

Scope and related work

Out of scope: automatic replanning, scheduling, new connectors, automatically completing the whole goal, historical data cleanup, or a general workboard.

#70 preserves the existing goal when accepting a goal-planning idea. This proposal adds the next relationship: a task targeting a specific existing milestone within that goal. It does not duplicate that fix.

#53 covers a broader downstream workboard direction; this proposal can be coordinated with that effort without requiring the larger subsystem.

Would an optional task milestoneId plus the existing manual completion control be an acceptable first implementation?

[kvnloo]

I like adding milestoneId, but I would keep two state transitions separate:

1. the delegated task completed and produced a result;
2. the original milestone is verified complete.

The task result should attach back to the existing milestone identity immediately, so the user never gets a duplicate milestone. But task.status === "succeeded" should not automatically mean milestone.done = true for every workflow.

A focused regression could prove:

• delegating milestone M creates a task carrying milestoneId = M;
• task success links its artifacts/result to M;
• no second same-title milestone is appended;
• completion of M happens only through the goal's chosen verifier/user-confirmation rule.

That preserves the difference between execution completing and the user's intended outcome being achieved.