Summary
Admin-facing audit log dashboard for compliance review. v1 = minimal viewer over existing /api/audit-log endpoints — list, filter, detail panel. Lives in trinity-enterprise private submodule per #847 architecture (Phase 0 scaffolding shipped in #910).
Context
Audit log backend fully shipped (SEC-001 / #20): append-only audit_log table, hash-chain integrity, 365d retention, admin-gated REST surface. From architecture.md:
GET /api/audit-log — list with filters (event_type, actor_type, actor_id, target_type, target_id, source, start_time, end_time, limit, offset)
GET /api/audit-log/stats — counts by event_type / actor_type
GET /api/audit-log/{event_id} — single entry
GET /api/audit-log/export — CSV/JSON time-range export
POST /api/audit-log/verify — hash chain verify
Missing: UI for compliance / SOC2 reviewers who can't curl | jq. This issue ships that UI in the private repo, gated via EntitlementService seam from #910.
v1 Scope
- List view: paginated table over
GET /api/audit-log with filter controls for event_type, actor_type, actor_id, target_type, start_time, end_time.
- Detail panel: click row → expand
details JSON + show previous_hash / entry_hash (read-only).
- Entitlement-gated: route loads only when EntitlementService confirms the audit-log entitlement; no-op in OSS builds.
- Admin auth: same
admin role gating as backend; non-admins get 404.
Out of scope v1 (separate issues): CSV/JSON export UI, hash-chain verify button, stats tiles, SIEM webhook push.
Backend work expected
Most filter params exist. Likely additions:
- Distinct-value endpoints for filter dropdowns (
GET /api/audit-log/distinct/event-types, …/actor-types) — cheap aggregate, avoids frontend hardcoding the enum.
- Cursor pagination if offset is slow over 365d retention — defer, profile first.
Acceptance Criteria
Related
Notes
First concrete enterprise feature after #847. Treat as exemplar for future enterprise work — scaffold pattern, entitlement gating, CI w/ submodule.
Summary
Admin-facing audit log dashboard for compliance review. v1 = minimal viewer over existing
/api/audit-logendpoints — list, filter, detail panel. Lives in trinity-enterprise private submodule per #847 architecture (Phase 0 scaffolding shipped in #910).Context
Audit log backend fully shipped (SEC-001 / #20): append-only
audit_logtable, hash-chain integrity, 365d retention, admin-gated REST surface. Fromarchitecture.md:GET /api/audit-log— list with filters (event_type,actor_type,actor_id,target_type,target_id,source,start_time,end_time,limit,offset)GET /api/audit-log/stats— counts by event_type / actor_typeGET /api/audit-log/{event_id}— single entryGET /api/audit-log/export— CSV/JSON time-range exportPOST /api/audit-log/verify— hash chain verifyMissing: UI for compliance / SOC2 reviewers who can't
curl | jq. This issue ships that UI in the private repo, gated via EntitlementService seam from #910.v1 Scope
GET /api/audit-logwith filter controls forevent_type,actor_type,actor_id,target_type,start_time,end_time.detailsJSON + showprevious_hash/entry_hash(read-only).adminrole gating as backend; non-admins get 404.Out of scope v1 (separate issues): CSV/JSON export UI, hash-chain verify button, stats tiles, SIEM webhook push.
Backend work expected
Most filter params exist. Likely additions:
GET /api/audit-log/distinct/event-types,…/actor-types) — cheap aggregate, avoids frontend hardcoding the enum.Acceptance Criteria
Related
Notes
First concrete enterprise feature after #847. Treat as exemplar for future enterprise work — scaffold pattern, entitlement gating, CI w/ submodule.