With the D1 gate in place, a team that selects "urgent only" gets a PR only if the signal was already urgent when it was discovered. The missing half is dispatching when someone raises a signal's priority: signal lands quietly, a human marks it Urgent, the PR opens.
Change
- Publish a domain event on priority change in
update-signal-triage.ts, which today deliberately stays silent for priority-only edits (update-signal-triage.ts:98).
- Route it in
apps/workers/src/workers/domain-events.ts to the dispatch request, with a new signal.prioritized trigger.
- Add the trigger to
AGENT_DISPATCH_TRIGGERS and to the checkbox list in the settings form, with its own label and description.
- Decide and document whether the trigger fires on any change or only on a raise. Raise-only avoids a PR when someone downgrades a signal into the configured set from above.
Verification
request-agent-dispatch tests for the new trigger, including the guardrail interaction (the daily cap and cooldown are keyed per source, so repeated re-prioritising must not open a PR per edit).
- Existing dispatch triggers unaffected.
With the D1 gate in place, a team that selects "urgent only" gets a PR only if the signal was already urgent when it was discovered. The missing half is dispatching when someone raises a signal's priority: signal lands quietly, a human marks it Urgent, the PR opens.
Change
update-signal-triage.ts, which today deliberately stays silent for priority-only edits (update-signal-triage.ts:98).apps/workers/src/workers/domain-events.tsto the dispatch request, with a newsignal.prioritizedtrigger.AGENT_DISPATCH_TRIGGERSand to the checkbox list in the settings form, with its own label and description.Verification
request-agent-dispatchtests for the new trigger, including the guardrail interaction (the daily cap and cooldown are keyed per source, so repeated re-prioritising must not open a PR per edit).