What happened?
Town ef9a9aca-760b-49fe-88c1-ad18eccfc060, rig razoredge (2f79fdd2-8874-4181-a34e-8fd001053010). This is a CORRECTED diagnosis superseding the "empty dispatch" theory in #4226.
Root cause (confirmed by polecat agent status + repeated escalations): the polecat role lacks the triage-resolve permission. Polecats ARE dispatched for gt:triage batch beads and DO complete the triage analysis, but when they call gt_triage_resolve the call fails with HTTP 403 ("polecat lacks triage-resolve perm"). This creates a self-confirming catch-22: the triage loop keeps generating triage beads, dispatches a polecat, the polecat finishes but cannot resolve, and escalates to the Mayor. The loop regenerates new triage beads/escalations roughly every few minutes.
Evidence:
- Polecat "Toast" (42db401e) status_message: "Triage complete — 1 request. Could not resolve via gt_triage_resolve (403: polecat lacks triage-resolve perm); escalated directly to the Mayor for a role-config fix."
- Three near-simultaneous high-severity escalations (91363620/b5c75aa4 earlier; d0696535, c56c27cf, 446be1f9 today) all titled "polecat role lacks triage-resolve permission".
Impact: continuous escalations flooding the Mayor; polecats get stuck "working" on triage beads they can never resolve; the board fills with failed triage batches.
Likely fix: grant the triage-resolve permission to the polecat role (or whatever role is assigned triage batches) on the control server. This is a role/permission config issue the Mayor cannot self-serve — no tool exists to edit agent role permissions.
Note: the gt_bead_delete array bug reported in #4226 is still valid and separate. Also observed this session: gt_bead_update to status=closed on a gt:triage batch bead silently lands it on status=failed instead of closed (mayor cannot force-close triage batches to closed).
Area
Agent Dispatch / Scheduling
Context
- Town ID: ef9a9aca-760b-49fe-88c1-ad18eccfc060
- Agent: Mayor (cbf9c6c1-ef23-406c-b420-ab4a0b0da96c)
- Rig ID: 2f79fdd2-8874-4181-a34e-8fd001053010
Recent Errors
gt_triage_resolve returns HTTP 403 "polecat lacks triage-resolve perm" for polecat agents. Also: gt_bead_update(status=closed) on a gt:triage batch bead results in status=failed rather than closed.
Filed automatically by the Mayor via gt_report_bug.
What happened?
Town ef9a9aca-760b-49fe-88c1-ad18eccfc060, rig razoredge (2f79fdd2-8874-4181-a34e-8fd001053010). This is a CORRECTED diagnosis superseding the "empty dispatch" theory in #4226.
Root cause (confirmed by polecat agent status + repeated escalations): the polecat role lacks the
triage-resolvepermission. Polecats ARE dispatched for gt:triage batch beads and DO complete the triage analysis, but when they call gt_triage_resolve the call fails with HTTP 403 ("polecat lacks triage-resolve perm"). This creates a self-confirming catch-22: the triage loop keeps generating triage beads, dispatches a polecat, the polecat finishes but cannot resolve, and escalates to the Mayor. The loop regenerates new triage beads/escalations roughly every few minutes.Evidence:
Impact: continuous escalations flooding the Mayor; polecats get stuck "working" on triage beads they can never resolve; the board fills with failed triage batches.
Likely fix: grant the
triage-resolvepermission to the polecat role (or whatever role is assigned triage batches) on the control server. This is a role/permission config issue the Mayor cannot self-serve — no tool exists to edit agent role permissions.Note: the gt_bead_delete array bug reported in #4226 is still valid and separate. Also observed this session: gt_bead_update to status=closed on a gt:triage batch bead silently lands it on status=failed instead of closed (mayor cannot force-close triage batches to closed).
Area
Agent Dispatch / Scheduling
Context
Recent Errors
Filed automatically by the Mayor via
gt_report_bug.