fix(quinn/bug_triage): handler is non-idempotent — re-triages and creates duplicate board features on every workstacean restart

[mabry1985]

Symptom

Every workstacean container restart triggers Quinn to re-triage every open issue with the `status: needs-triage` label, posting a duplicate "Triage — Quinn (QA)" comment and creating a NEW board feature each time. Same issue gets re-filed under multiple `feature-...-...` IDs.

Evidence (as of 2026-04-20 03:00 UTC):

Issue	Quinn comments	Board features created
protoMaker#3482	6	5+ separate `feature-...` IDs (issue is now CLOSED, label still present)
protoMaker#3483	5	5+
protoMaker#3484	6	6+

Bursts cluster at 02:10, 02:13, 02:47, 02:55 UTC — each maps 1:1 to a workstacean container recreate during today's audit work in protoWorkstacean.

Root cause

Two cooperating bugs:

1. `bug_triage` is not idempotent. The protoWorkstacean github plugin (`lib/plugins/github.ts:665-693` in `protoLabsAI/protoWorkstacean`) explicitly documents the dedup contract:

"Walk every monitored repo's open issues and re-dispatch any with the sweep label as synthetic inbound events. Runs on install and on the `github.triage.sweep` bus topic. Idempotent on the Ava side — the bug_triage skill checks for existing board features by issue number."

The data above proves Quinn isn't honoring that contract — she creates a new board feature on every dispatch instead of looking up by URL/number and no-oping.

2. Quinn doesn't transition the label after triaging. Every issue Quinn has triaged still carries `status: needs-triage`. So on the next workstacean restart, `_runTriageSweep` correctly identifies it as un-triaged and re-fires.

Neither bug alone causes the spam, but together they create a guaranteed "every restart = N duplicate triages" loop where N = open needs-triage issue count.

Reproduction

1. File a GitHub issue with the `status: needs-triage` label
2. Wait for Quinn to triage (one comment, one board feature created — correct)
3. `docker compose restart workstacean` (or any deploy that recreates the container)
4. Observe Quinn fire a SECOND comment + create a SECOND board feature on the same issue
5. Repeat — each restart adds another comment and board feature

Suggested fix (in apps/server, ~/dev/ava)

Two changes to Quinn's `bug_triage` handler — both in the protoMaker server. Pick the order based on what's easier to implement first; ideally both ship.

Primary: dedup at the handler. Before posting a triage comment / creating a board feature, query the board for an existing feature whose source URL == the incoming issue URL (or whose linked GitHub issue number matches). If found:

• No new feature
• No new comment, OR a single dedup-guarded comment like `"Already triaged — see feature {id}. No new action."` (note: gating that comment with a 24-hour cooldown prevents this from becoming its own form of spam)

Secondary: label transition. After successful triage, remove `status: needs-triage` and add `status: triaged` (or whatever board-linked label makes sense). This makes the label state machine truthful and means `_runTriageSweep` naturally skips already-handled issues. Also: when an issue closes (manual or via PR), the label should also be cleared if still present.

Why this matters

Quinn's triage is genuinely valuable — it converts user-filed bug reports into board features and routes them to the right project. The bug isn't "Quinn shouldn't triage"; it's "Quinn should triage exactly once per issue, then know it's done." Without this fix, every deploy is a noise event and the protoMaker board accumulates duplicate work items that look like a real backlog but aren't.

Companion cleanup (already in flight in protoWorkstacean)

A separate PR removes `subscribesTo: message.inbound.github.#` from the new `protomaker` entry in protoWorkstacean's `workspace/agents.yaml` (added in protoWorkstacean#433). That subscription was overscoped — protoMaker is an action target reached via explicit `targets: [protomaker]` GOAP dispatches, it shouldn't also broadcast-subscribe to all GitHub inbound events. Removing it doesn't fix the duplication root cause (which is in Quinn's handler) but removes one extra path that could amplify the issue under future config changes.

[github-actions]

👋 Thank you for submitting this idea!

Your issue has been added to our ideas pipeline. Here's what happens next:

1. Triage (1-3 days): Our team will review and label your idea
2. Discussion (ongoing): We may ask clarifying questions or gather community feedback
3. Acceptance (varies): If accepted, we'll add the status: accepted label
4. Implementation (varies): Our AI agents will implement accepted ideas and link the PR here

We appreciate your contribution to making this project better! 🚀

[mabry1985]

Companion cleanup landed in protoLabsAI/protoWorkstacean#434 (auto-merging now) — removes the overscoped subscribesTo from protomaker's agent registration. That's not the root fix, just one less amplification path. The two changes proposed in the issue body (idempotency check + label transition) still need to land in apps/server's bug_triage handler to actually stop the spam loop.

[protoquinn]

Triage — Quinn (QA)

Confirmed and filed. Board feature: feature-1776655568431-q50vb9nxu (severity: high, status: backlog).

Verdict: Valid bug, well-evidenced. Both root causes confirmed against the documented idempotency contract in lib/plugins/github.ts:665-693.

Root cause summary:

• Handler creates a new board feature on every dispatch — no dedup check against existing features by source URL or issue number
• Label status: needs-triage is never removed after triage, so _runTriageSweep correctly re-identifies the issue as un-triaged on every restart and re-fires

Required fix (both changes, same ship):

1. Before creating a feature or posting a comment, query the board for an existing feature whose source URL or linked issue number matches. If found: no-op.
2. After successful triage, remove status: needs-triage, add status: triaged. On issue close, clear label if still present.

Routing: Fix lives in Quinn's bug_triage skill handler in apps/server (~/dev/ava). Companion cleanup (protoWorkstacean#433 — removing overscoped subscribesTo from agents.yaml) does not fix the root cause but should still ship to remove the amplification path.

Note on #3483: That issue already has a board feature in review (feature-1776651030520-vp60q361y). The status: needs-triage label was not cleared — exactly the secondary bug described here. No new feature was created for it.

[protoquinn]

Triage — Quinn (QA)

Confirmed and filed. Board feature: feature-1776655794373-afxkk3vhs (severity: high)

Verdict: Both root causes are confirmed by the evidence. This is a real bug, not a false positive.

What's filed:

• Bug 1 (primary): bug_triage handler missing dedup check — no lookup by source URL or issue number before creating a board feature. Violates the idempotency contract documented in protoWorkstacean/lib/plugins/github.ts:665-693.
• Bug 2 (secondary): status: needs-triage label never removed after triage — causes _runTriageSweep to re-fire on every container restart.

Fix ownership: protoMaker server (apps/server) — agent flow changes route to Sam. Both fixes should ship together; either alone only partially closes the loop.

Companion: protoWorkstacean#433 (overscoped subscribesTo removal) is noted and tracked separately.

Immediate mitigation: Until the fix ships, manually removing status: needs-triage from already-triaged issues will stop the re-fire loop for those issues.