Compare commits

...

1 Commits

Author SHA1 Message Date
Jiang Bohan
a6c5795880 fix(server/child-done): require sibling dependency check before promoting backlog (MUL-2618)
The previous system-comment wording ("promote any waiting `backlog`
sub-issues") let a planner agent flip every backlog sibling to `todo` on
the first child-done signal, ignoring per-sibling stated dependencies.
Tighten the prompt so the agent must read each sibling's description,
only promote items whose dependencies are satisfied, and leave the
status alone (and comment to confirm) when the parent's higher-level
breakdown conflicts with what a sibling lists as a prerequisite.

This is the short-term mitigation; a structured `blocked_by` edge is
out of scope here and will be designed separately.

Co-authored-by: multica-agent <github@multica.ai>
2026-05-26 14:59:49 +08:00

View File

@@ -84,7 +84,7 @@ func (h *Handler) notifyParentOfChildDone(ctx context.Context, prev, issue db.Is
mentionPrefix := h.buildParentAssigneeMention(ctx, parent)
content := fmt.Sprintf(
"%sSub-issue [%s](mention://issue/%s) — \"%s\" — is done. Confirm whether to advance the next step on this parent (and promote any waiting `backlog` sub-issues).",
"%sSub-issue [%s](mention://issue/%s) — \"%s\" — is done. Before promoting any waiting `backlog` sub-issue, read each sibling's description and only promote items whose stated dependencies are already satisfied — do not rely on this parent's higher-level breakdown alone. If a sibling's description conflicts with that breakdown (e.g. it lists a prerequisite the parent treats as parallel), do NOT change its status — leave it `backlog` and post a comment to confirm first.",
mentionPrefix, identifier, childID, title,
)