Organization support console and audit trail

Operators could manage individual users. They could not sit with one organization and see membership, effective access, usage, billing drift, and webhook failures together. That console is now in the admin area, and organizations keep their own audit log of who changed what.

Investigate without switching tenant

Search organizations by name, slug, id, member email, or linked billing ids. Ambiguous email matches stay explicit, and opening a result does not change the operator's active organization.

From there you get overview and access explanations, members and invitations, local billing next to a provider comparison, quota and usage aggregates, webhook attempts, and activity. Failures that are not tied to an organization stay visible globally.

Compare does not write. Resync updates verified local billing without replaying customer emails. Eligible webhook events can be retried with a reason and a ticket, under server-enforced budgets so two operators cannot claim the same attempt.

Ban, unban, edit, and impersonation now require that same reason and leave an action record. Impersonation has a banner and a single exit path, including for users who have no organization. History for a deleted user stays readable when support activity exists.

A log owners can actually open

Organizations record invitation issue, accept, and cancel; member removal and leave; role changes; and name or logo changes. Owners and admins need audit:view. The same list, filters, and detail sheet show up in organization settings and in Admin → Organizations → Audit log. Support reads go through a separate path and still do not switch the operator's tenant.

The log starts when you deploy it. Nothing is backfilled. Billing events, organization create and delete, and account-deletion cascades are out of scope. Records live with the organization and disappear when it is deleted.

For buyers extending the kit

The extend-support-console skill describes the panel, action, and catalog pattern. The audit guide in the kit docs covers the default events and how to record a new one inside a domain transaction.

Two additive migrations ship with this: the support-console tables, and the organization audit trail. The support search index needs pg_trgm on Postgres. Apply them through the normal migrate workflow.