Send newly filed frontend bugs from Mozilla staff for automatic triage

[msujaws]

hackbot's frontend-triage agent produces a root-cause analysis and fix plan for a Firefox frontend bug, and posts it to the bug when it's confident — but nothing was starting runs, so every triage needed a human to trigger it from the hackbot UI. This rule starts them for newly filed bugs, hourly.

Depends on mozilla/bugbug#6439, which makes a confident result apply itself and report to Slack. That should land first, otherwise a triggered run just records actions for manual review.

Scope

Deliberately narrow, because the agent's analysis lands on the bug unattended:

• Reporters we expect to file well. Staff membership comes from the IAM roster we already maintain (People.is_mozilla), which covers QA too now that they file from @mozilla.com addresses. The roster is also why this lives here rather than in bugbug: it maps a staffer's Bugzilla address to them, so employees who file from a personal account are still in scope, and a @mozilla.com address IAM doesn't know about is not.
• One component to start, Firefox :: New Tab Page. The component list is config, so widening it is an edit to configs/rules.json.

The rule makes no Bugzilla writes of its own — it starts runs and reports what it started. max_triggers (3) caps how many runs one invocation may start, since each is real LLM spend. Bugs left over — over the cap, or whose run failed to start — are excluded from both the report and the cache, so they come back on the next run rather than being silently dropped.

Notes

HACKBOT_API_URL defaults to https://hackbot-api.moz.tools so the cron host needs no extra environment, the way BUGBUG_HTTP_SERVER does; set it to point at another deployment. It needs hackbot_api_key in configs/config.json.

People is injectable via the constructor because configs/people.json is gitignored and absent in CI — otherwise the reporter filter couldn't be tested at all.

Added to CheckWikiPage.skipped_rules while this is a pilot; it wants a wiki entry before it's considered general-purpose.

Testing

72 passed, including 24 for this rule: the reporter filter (staff kept, personal-address staffer kept, community dropped, unknown @mozilla.com dropped), the query shape, the trigger/cap behaviour, and the email template rendering.

Dry-run against live Bugzilla, with the roster check stubbed to a simple @mozilla.com test since configs/people.json needs IAM secrets:

matched the Bugzilla query : 14
survived the reporter filter: 13     (one @gmx-topmail.de dropped)
would POST to               : https://hackbot-api.moz.tools/agents/frontend-triage/runs

Widened to 90 days it's 131 matched → 86 kept, dropping @gmail.com, @aggies.usu.edu, @gmx-topmail.de and @protonmail.com — so the filter is doing real work.

Observed volume is ~2.8/day on active days with a peak of 8, so the cap acts as a burst limiter rather than a throttle. Worth knowing that the first production run fires 3 immediately, since the cache starts empty and there's already a backlog in the window; it drains over the following few hours.

[marco-c]

Instead of @mozilla only, we could extend to everyone with "editbugs", which we also expect to file well.
You can simply change the query to check group membership (see for example the spambug case).