04 — Information Architecture (Audit Module)

• 1. Placement in the shell
• 2. Route table (module-owned; extends 00-shared/05 §4)
• 3. Screen hierarchy
• 4. Modal hierarchy (module)
• 5. Screen relationships
• 6. Nested nav
• 7. Quick actions / FAB / context menus
• 8. Deep links (proposed routing table)
• 9. Accessibility of IA
• 10. Peripheral: what Audit owns vs shared

Where Audit screens live in the shell (00-shared/05). Audit is an authenticated, admin-gated surface inside the Settings area. Everything derives from the single read endpoint GET /audit-logs (audit.controller.ts:10) and the shared shell.

1. Placement in the shell

AppShell
 └─ Settings (/settings)                         [settings.read surface, admin]
    ├─ /settings/audit          ← Audit log (this module, canonical route)
    │   └─ /settings/audit/:id  ← Audit entry detail (in-memory; no refetch, OQ-4)
    └─ /settings/access-audit   ← Permission audit preset (RBAC module,
                                   design-docs/rbac/05 S6) — same endpoint

• Audit is a read-only sibling of RBAC's "Access audit" view. Both query GET /audit-logs (audit.controller.ts:17-34); the RBAC one pre-filters on RBAC actions and is documented in design-docs/rbac/04-08. Canonical detail + diff live in this module. Unify under one route (proposed) (OQ-4/route OQ).
• Gate: client requires audit.read (permissions.constants.ts:54) even though the server currently only requires a JWT (OQ-5).

2. Route table (module-owned; extends 00-shared/05 §4)

3. Screen hierarchy

flowchart TD
    SET[/settings/] --> AUD[/settings/audit/]
    AUD --> ENT[/settings/audit/:id/]
    AUD --> EXP[/settings/audit/export/ (planned)]
    AUD --> RBA[/settings/access-audit/ (RBAC module, same data)]

• List is the hub: filter bar → results → row tap → detail (push on phone, master-detail pane on tablet/desktop ≥ 840 px, 00-shared/05 §3).
• Detail returns preserving scroll + filters (list state kept alive).
• Export is a modal sheet from the list overflow, not a standalone flow today.

4. Modal hierarchy (module)

Following 00-shared/05 §5:

1. Snackbar/toast — "New entry", "Copied JSON", "Filters cleared".
2. Bottom sheet — realtime "New activity" banner expansion, JSON value inspector (nested values), export format picker (planned).
3. Dialog — none destructive (module is read-only; no delete/confirm flows exist).
4. Full-screen page — entry detail on phone (JSON tree needs space); list on desktop.
5. Loader — AppSkeleton rows for list; no full-screen loader.

5. Screen relationships

• List ↔ Detail: master-detail on ≥ 840 px (detail pane updates on row select); push-on-top on phone.
• Filter bar state lives in the list cubit; changing filters resets to page 1 (03 §2).
• Realtime WS appends integrate into the list (journey 5) — no separate screen.
• RBAC access-audit reuses the same list component with a preset filter set.

6. Nested nav

• Settings uses StatefulShellBranch (00-shared/05 §3); audit list keeps scroll/filter state across shell switches.
• Breadcrumbs (desktop): Settings › Audit log › Entry on detail.

7. Quick actions / FAB / context menus

• No FAB (read-only module; nothing to create).
• List row AppMenu: View entry, Copy entry ID, Export (planned).
• Keyboard (desktop): / or Ctrl+F focuses filter bar, Esc clears filters, arrows navigate table rows, Enter opens detail, g then i (entry id) copy (proposed).

8. Deep links (proposed routing table)

9. Accessibility of IA

• One headlineMedium per screen; filter bar before results in focus order; table exposes column headers via semantics (00-shared/09 §7); live region announces "N entries" after filter changes and realtime appends.

10. Peripheral: what Audit owns vs shared

• Audit owns: list + filter bar, entry detail + diff, export sheet (planned).
• Shared owns: 403/404/500/offline screens, session-expiry overlay, notification center — preserved from 00-shared/05 §8.