fix(goap): fleet_incident_response re-dispatches for resolved conditions — needs cooldown/dedup

[mabry1985]

Problem

The GOAP engine continues dispatching fleet_incident_response for fleet.no_agent_stuck even after the condition has been fully resolved. The auto-triage-sweep stuck loop generated 18 incidents (INC-003–INC-018), all now resolved. Fleet health currently shows 0 failures, 0 orphaned skills, 0 WIP — yet the goal keeps firing.

This is the same feedback loop documented in INC-015/INC-016: the GOAP engine doesn't check whether prior incidents for the same goal violation are already resolved before re-dispatching.

Expected behavior

• GOAP should check if there are existing resolved incidents for the same goal+agent combination within a cooldown window (e.g. 1h)
• If the underlying metric (failure rate, orphaned skill count) has returned to healthy, the goal should not re-fire
• Dispatch dedup should prevent the same action from being dispatched when the world state no longer violates the goal

Current behavior

• Goal fleet.no_agent_stuck fires repeatedly
• fleet_incident_response is dispatched to Ava each time
• Each dispatch generates a new incident, paging the operator again
• The fleet health domain shows the condition is already resolved

Related

• INC-003 through INC-018 (all resolved)
• protoAgent#145 (consolidated orphaned skill sources + dispatch dedup failure)
• protoMaker#3503 (non-idempotent bug_triage handler — original root cause)
• protoAgent#144, fix(actions.yaml): reroute bug_triage from auto-triage-sweep → quinn #146 (auto-triage-sweep routing fix)

[protoquinn]

QA Triage — Quinn / auto-triage

Verdict: CONFIRMED HIGH — known recurring pattern, board-filed

---

Pattern match

This is a documented recurring failure class in QA memory:

• Bug pattern fix(goap): orphaned skill auto-triage-sweep.bug_triage — agent not registered, 100% failure rate #49: GOAP fleet_incident_response dispatch loop — (goal,agent,skill) dedup proposed
• Bug pattern fix(goap): auto-triage-sweep dispatches bug_triage to non-existent agent — 100% failure, orphaned skill #51: GOAP cooldown/suppression gap — corrective action re-dispatches every tick while fix is pending
• Bug pattern fix(routing): remove orphaned auto-triage-sweep agent from bug_triage skill routing #92: GOAP fleet_incident_response feedback loop — wave 8 umbrella (16 incidents, 35 issues)

This is at minimum the 3rd distinct wave of this exact failure mode. The GOAP planner has no post-resolution world state check and no cooldown state for (goal, agent, skill) tuples.

---

Root cause (confirmed)

Two compounding gaps:

1. No world state re-evaluation before dispatch — the planner does not re-check whether the goal condition is still violated at dispatch time. If the metric has returned to healthy between plan and execution, the action fires anyway.
2. No cooldown/dedup on resolved incidents — there is no suppression window for (goal, agent, skill) tuples where a prior incident for the same combination was resolved within the cooldown period (proposed: 1h).

---

Related issues

• fix(goap): CONSOLIDATED — 3 orphaned skill sources + dispatch dedup failure (supersedes #76–#136) #145 — consolidated GOAP dedup failure (supersedes fix(goap): remove orphaned auto-triage-sweep agent — route bug_triage to Quinn #76–fix(goap): remove orphaned auto-triage-sweep agent from bug_triage routing — causes feedback loop #136); same root cause, different goal
• fix(goap): investigate_orphaned_skills dispatched when orphanedSkillCount = 0 — goal already satisfied #147 — investigate_orphaned_skills dispatched when orphanedSkillCount = 0; same class
• fix(actions.yaml): reroute bug_triage from auto-triage-sweep → quinn #146 / [CRITICAL] actions.yaml routes bug_triage to non-existent auto-triage-sweep actor #144 — actions.yaml routing fix (prerequisite, addresses phantom actor dispatch)
• protoMaker#3503 — non-idempotent bug_triage handler (original upstream root cause)

---

Recommended fix

Three-layer guard in the GOAP dispatch path:

1. Pre-dispatch world state check — re-evaluate the goal condition immediately before dispatching. If the metric is healthy, skip dispatch and mark goal satisfied.
2. Resolved-incident cooldown — before dispatching fleet_incident_response for a (goal, agent) pair, query incident history. If a resolved incident for the same pair exists within the cooldown window (1h), suppress dispatch.
3. In-flight dedup — if an incident for the same (goal, agent, skill) tuple is already open/in-progress, do not create a new one.

This is consistent with the dedup proposal in #145 and should be implemented as a single GOAP planner guard rather than per-action patches.

---

Severity: HIGH — 18 incidents generated in this wave alone; alert fatigue risk; operator paging on already-resolved conditions.

Trust tier: @mabry1985 is tier 1 — report accepted as-is, no reproduction required.

Board feature filed for tracking.