OAuth slice 6: audit provenance — record which application acted, alongside the human

[mforce]

Slice 6 of #788. Depends on #795. It can land in parallel with the screen slices.

Make the audit log show when an assistant took an action, rather than a person typing it.

The shape

ActorUserId and ActorEmail stay the human. That is a requirement, not a style choice. AGENTS.md #500 states that ICurrentUser is "an authorization input, not a label", and FlockScopeGuard reads its roles. The person authorized the action and remains the actor.

What this adds is provenance, the application that acted.

Why first-class columns rather than DetailsJson

AuditEvent already has a DetailsJson column, and using it would be cheaper. It was rejected because:

• Provenance is not a detail. It is who acted, which belongs beside the actor fields.
• It must be filterable. "Show me everything assistants did last month" is the question this exists to answer, and a JSON blob is not indexable for it.

The slice therefore adds two new columns on AuditEvents (application id and display name), a migration, and regenerated docs/schema/ in the same PR (#417).

Care needed

AuditEvents is the table this repo is most careful about. #508 gave it a monotonic Sequence ordering key, and #505 deliberately decided not to time-partition it. Read both before altering it. Adding columns is compatible with each, but the change must not disturb the ordering guarantees.

Surfacing

The existing audit UI should show the application. Today a row shows only the person's name even when an assistant acted, so an Owner reviewing history cannot tell a human typo from an assistant misfiring. This slice closes that gap.

Related

#272 (GDPR). This new dimension inherits the existing ActorEmail tension between erasure and pseudonymisation, because AuditEvent stores immutable snapshots and offers no way to change them.

Done when

An action performed through an assistant records both the human and the application, the audit UI shows it, and a user can filter on it.

[mforce]

Amendment, 2026-10-06: what #514 changed for this slice

The body above stays as written. Paths were checked against main at 8cb14e67.

• Audit reads go through Insights. Since [C] #514 slice 14: Insights read facade for reports, exports and audit reads #856 the audit UI reads through IInsightsModule.ListAuditEventsAsync, which returns AuditEventRead. Add the application id and display name to AuditEventRead, and add the new filter to that contract method. Reading the columns from outside the contract is a CW1004 build error.
• Writes are unchanged. AuditEvent stays in Cluckwork.Domain.Auditing, which is Platform, so any module may reference it. The fix(api): order same-instant audit events by a durable monotonic key, not a random Guid #508 and chore(infra): do not partition AuditEvents by time — record why, and what to do instead #505 cautions in the body still apply.
• Screen. The audit page now follows the MUI revamp (milestone 9). Surface the application in the existing layout and follow docs/designs/822-mui-revamp.md.

[mforce]

Mockups for selection, 2026-10-08

Refreshed 2026-10-08: every label now says "Connected apps", the maintainer's chosen term. OAuth calls these "clients"; the UI does not.

Design directions for showing app provenance in the audit log, inside the chosen Audit composition. Nothing is chosen yet. The interactive lab and README are on branch docs/788-oauth-screen-mockups (not pushed yet), in docs/designs/788-oauth-screens/.

The agent recommends C: every row shows who acted on a second line, so an Owner can tell a person from a connected app without opening the row.

Audit log provenance

A, desktop 1280 and phone 390

B, desktop 1280 and phone 390

C, desktop 1280 and phone 390