Feature request: force-rerun semantic for workflow_dispatch against the same bound issue

[samuelkahessay]

Feature request

When a workflow_dispatch run partially fails and an operator re-dispatches against the same issue_number, prior-run state (repo-memory, summary comments on the bound issue, or both) can cause the agent to conclude the work is already done and emit a noop. There is no mechanism to force a fresh evaluation.

This is a feature request for an explicit force-rerun semantic, not a bug report about any single component.

Observed behavior

Repo: Aurrin-Ventures/aurrin-platform, workflow: prd-decomposer, gh-aw v0.62.5, engine: copilot (gpt-5).

Run	Input	Outcome
1	issue_number=5	17/19 issues created. 2 failed (temp ID validation). Summary comment posted on #5. Run: failure.
2	issue_number=5	Closed child issues from run 1. Repo-memory still present. Agent: "Previous decomposition remains in place." 0 issues created. Run: success.
3	issue_number=5	Deleted memory/prd-decomposer. Agent still produced no output, only missing_tool. 0 issues created. Run: success.
4	issue_number=28	Fresh issue (same body, no prior comments) + cleared memory. Clean rerun succeeded.

Key: deleting the memory branch alone was not enough (run 3). A clean rerun required a fresh issue with no prior comments and cleared memory branches.

Impact

• Re-dispatching against a partially failed issue silently produces no work
• Operators must create a fresh issue to recover, fragmenting the conversation
• workflow_dispatch issue_number=N does not override prior-run state strongly enough to force a fresh pass

Relation to existing issues

• workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 (closed): targeted dispatch binding was ignored entirely — adjacent but different. The behavior here was observed on v0.62.5 after that fix shipped. Don Syme characterized workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 as mostly a prompting issue.
• ${{ steps.sanitized.outputs.text }} appears in generated prompt #21624 (closed): template variable leak in generated prompt — does not cover rerun semantics or persisted prior-run state.
• Targeted dispatch can drift into scheduled backlog triage when bound issues are integrity-filtered on public repos #21784 (open): targeted dispatch can drift when hidden state interferes — related in spirit but covers integrity-filtered dispatch drift, not same-issue reruns.

None of these cover the case where the agent does read the bound issue but concludes the work is already done based on prior-run artifacts.

Suggested approaches

1. Explicit force-rerun flag: a workflow_dispatch input or workflow-level config (e.g. force_fresh: true) that tells the agent to recompute from current repo state, ignoring prior completion signals for this issue.

2. Run-aware context handling: tag repo-memory entries and safe-output comments with run metadata so prior-run summaries aren't treated as authoritative for new runs.

3. Noop rejection guardrail: reject a success noop if the bound issue was never meaningfully re-evaluated in the current run — the scout report on workflow_dispatch targeted issue binding ignored — agent never reads bound issue, emits noop, workflow succeeds #21501 also identified this missing guard.

Environment

• gh-aw: v0.62.5
• Engine: copilot (gpt-5)
• Workflow: prd-decomposer