Context
The durable audit_events table works well as a per-PR correlation key — a live query against production D1 returned a clean, chronologically-ordered timeline of every event for one real repo#PR target across many distinct event types. But the only public API over it, /v1/repos/:owner/:repo/agent/audit-feed (listAgentAuditEvents, src/db/repositories.ts:2942), hard-filters to eventType LIKE 'agent.action.%' OR 'agent.pending_action.%' — excluding roughly 140 of the ~150 distinct event types that actually exist in the table (gate overrides, public-surface publishes, auth events, moderation violations, finding-resolution events, etc.).
Separately, the maintainer's own cited example — "why was this PR labeled wrong" — isn't in the durable audit ledger at all. type_label_decision/type_label_error (src/queue/processors.ts:8017-8036) are only ever a console.log, never a recordAuditEvent call, so even the broadened query below wouldn't surface it without also fixing this.
Requirements
- Add a new, unfiltered query function (e.g.
listAuditEventsForTarget(env, { repoFullName, pullNumber, sinceIso?, limit? })) with no eventType restriction, reusing the existing repo#PR target-key correlation — no schema change needed, the data already supports this.
- Expose it via a new or extended API route (or a maintainer-only flag on the existing audit-feed route) so a maintainer can pull one PR's entire event history in one call.
- Add a
recordAuditEvent(env, { eventType: "github_app.type_label_decision", targetKey: \${repoFullName}#${pr.number}`, outcome, detail, metadata: { labels, source } })call alongside the existing console.log atprocessors.ts:8017-8036`, so label decisions become queryable through this same mechanism.
Deliverables
listAuditEventsForTarget in src/db/repositories.ts.- A route/flag exposing it in
src/api/routes.ts.
- The new
type_label_decision audit-event write in src/queue/processors.ts.
- Test coverage for the new query and the new audit-event write.
Expected outcome
"Why did X happen to PR #N" becomes a single API call pulling the PR's full decision history — including label decisions — instead of requiring a maintainer to already know which of ~150 event-type prefixes to look for, or to grep container logs.
Context
The durable
audit_eventstable works well as a per-PR correlation key — a live query against production D1 returned a clean, chronologically-ordered timeline of every event for one realrepo#PRtarget across many distinct event types. But the only public API over it,/v1/repos/:owner/:repo/agent/audit-feed(listAgentAuditEvents,src/db/repositories.ts:2942), hard-filters toeventType LIKE 'agent.action.%' OR 'agent.pending_action.%'— excluding roughly 140 of the ~150 distinct event types that actually exist in the table (gate overrides, public-surface publishes, auth events, moderation violations, finding-resolution events, etc.).Separately, the maintainer's own cited example — "why was this PR labeled wrong" — isn't in the durable audit ledger at all.
type_label_decision/type_label_error(src/queue/processors.ts:8017-8036) are only ever aconsole.log, never arecordAuditEventcall, so even the broadened query below wouldn't surface it without also fixing this.Requirements
listAuditEventsForTarget(env, { repoFullName, pullNumber, sinceIso?, limit? })) with noeventTyperestriction, reusing the existingrepo#PRtarget-key correlation — no schema change needed, the data already supports this.recordAuditEvent(env, { eventType: "github_app.type_label_decision", targetKey: \${repoFullName}#${pr.number}`, outcome, detail, metadata: { labels, source } })call alongside the existing console.log atprocessors.ts:8017-8036`, so label decisions become queryable through this same mechanism.Deliverables
listAuditEventsForTargetinsrc/db/repositories.ts.src/api/routes.ts.type_label_decisionaudit-event write insrc/queue/processors.ts.Expected outcome
"Why did X happen to PR #N" becomes a single API call pulling the PR's full decision history — including label decisions — instead of requiring a maintainer to already know which of ~150 event-type prefixes to look for, or to grep container logs.