[joshunrau]

The audit log offered Entity and Action filters that nothing ever wrote, and most admin changes were never recorded. This makes the written pairs a single declared list, derives the filters from it, and records the admin activity the triage asked for. The log stays an admin activity log: an update names the fields it changed, never their values.

Reviews commit by commit: four Phase 1 commits, then one per entity.

Phase 1

• AUDITED_ACTIONS in packages/schemas/src/audit/audit.ts declares every (entity, action) pair the API writes.
• AuditLogger.log is typed against it, so a call with an undeclared pair does not compile.
• The web Entity and Action menus are derived from it, and each is narrowed by the other's choice. Session is no longer offered. The Prisma enums are unchanged.
• .agents/docs/architecture/auth-and-permissions.md and the comment in admin-audit-logs.spec.ts now point at the map instead of listing call sites.

Phase 2

Entity	Events now written	Where	Metadata
User	CREATE, UPDATE (admin edit, permissions, self-edit); archive and unarchive become ARCHIVE / UNARCHIVE	create in UsersController (setup and demo seeding share the service method), the rest in UsersService	targetUserId, plus fields on updates
Assignment	DELETE, one entry per assignment actually deleted, in its group	AssignmentsService.deleteBulk	assignmentId
Instrument	series CREATE and DELETE, in the owning group	InstrumentsService	instrumentId, title
Subject	DELETE, one entry, groupId: null	SubjectsController, after the service call returns	subjectId, force, recordCount
Instrument record	UPDATE, DELETE	update in InstrumentRecordsService.updateById; delete in the controller (the gateway rollback shares the service method)	recordId and fields; on delete also instrumentId, subjectId
Group	CREATE, UPDATE	create in GroupsController (demo seeding shares the service method), update in GroupsService	fields on updates

Updates go through AuditLogger.logUpdate with changedFields (apps/api/src/audit/audit.utils.ts). It compares the stored row with the written one, ignores updatedAt, and treats a reordered list of ids as unchanged, because the web forms resubmit every field and rebuild id lists in their own order. An update that changed nothing writes no entry, which matches how series archiving already behaves. Entries are still written after the change, not in its transaction. Sessions and record creation are not logged, as decided.

Services that now receive the request user instead of the ability: UsersService.updatePermissions, AssignmentsService.deleteBulk, GroupsService.updateById and InstrumentRecordsService.updateById. No route's path, guard, body or response changed.

Judgment calls

• "Changed fields" means fields whose stored value changed, not the keys the request sent. Otherwise every save of the user or group form would list every field.
• The drop-the-other-choice rule is not written. With both menus narrowed by each other, neither menu can offer a choice that invalidates the other, so that code could never run.
• User archive metadata loses its action key, now that the action column says ARCHIVE or UNARCHIVE. Earlier rows stay as they were, under UPDATE.
• Deleted assignments are logged one per assignment (the same as emailed links), not one per bulk request.
• The record count for a subject delete is read in the controller just before the delete, and only when force is set. An unforced delete removes no records, and a caller with delete Subject may hold no rule on records at all. SubjectsService.countDeletableRecords uses the same scope as the forced delete. deleteById itself is untouched, for Force-deleting a subject who has a remote assignment fails with 500 and deletes nothing #1748.
• InstrumentRecordsService.updateById copies the stored data before merging, because lodash mergeWith writes into its target. Without the copy the diff would always be empty. A unit test pins this.
• changedFields throws a TypeError on a value with no fields. Record data is typed as any JSON value, and an empty diff would hide the update.
• Updates read the stored row first. UsersService.updateById now always loads the user, where before it did so only to check a new password. A missing id is therefore a 404 before any write. updateSelfById reads by id alone, like its existing where: { id } write. A group manager in no group holds no read User rule that matches themselves, so a scoped read would 404 their own profile save.

Verification

• Unit: audit.utils.test.ts and audit.logger.test.ts (including a @ts-expect-error call with an undeclared pair); each service and controller test asserts its new log call and the refused-path no-op; logs.test.tsx covers the derived Entity and Action options and the narrowing, with logFixture paired as SEND_EMAIL / ASSIGNMENT.
• E2E: testing/src/specs/admin-audit-logs.spec.ts filters by an entity still offered and asserts Session is gone. A new admin audit log coverage block has one test per event: users, assignments, series, subjects, records and groups. Group creation is also found through the page's group, entity and action filters. Subject and record events are checked through ApiClient.findAuditLogs, which now takes an entity.

Results: pnpm lint green. pnpm test:coverage 100% statements, branches, functions and lines, 450 of 450 files. pnpm test:e2e on chromium with one worker: 369 of 370 passed.

Exceptions:

• Firefox e2e was not run locally, to keep machine load down; CI runs the @smoke set.
• One unrelated e2e failure in the full run. admin-instrument-repos.spec.ts:196 ("should fit both tables to the page without a horizontal scroll bar") measured an overflowing sync log table. That spec passed 25 of 25 when re-run on its own, and nothing on this branch touches that page.

Closes #1473

Co-Authored-By: Claude Opus 5.5