HR

Fixed and merged to dev on nuvita-hr, plus a load-bearing companion permission-seed change on nuvita-admin (merged together) - the ticket renamed HR's document permission keys, so without the companion change every role holding the old keys would have silently lost document access.

Confirmed the core security issue directly: every file-serving path (employee documents, generated letters, employee photos) returned a freshly-generated Azure SAS URL straight to the browser, bypassing the portal's own auth/audit layer entirely - anyone who got hold of a URL could access the file with no permission check. Also confirmed HR had no canonical documents table at all; what existed was an ad-hoc parallel storage mechanism, not the platform's established pattern (the same divergence #142 flagged in passing).

Built hr.documents as a proper canonical table, column-for-column matching EMR's reference implementation of the platform's documents pattern, wired through the shared IDocumentStorage abstraction - and removed the old parallel storage mechanism entirely, no trace left. No endpoint returns a bare file URL anymore; every download now streams through a permission-checked endpoint.

Migrated generated letters and new employee-photo uploads fully onto the new table. Credential evidence got an upload-and-attach option added to the existing detail view (the create flow still only offers the old free-text link for now - flagging as a reasonable scope cut, since attaching a file requires the credential to already exist).

Flagged, not done:

• The legacy employee-documents table and any documents stored under the old mechanism were not backfilled into the new table - a one-off migration tool would be needed to move old files over without losing them, and that needs real validation before running against production data, same caution as #140's data-fix.
• Storage is local-filesystem only for now, matching the platform's actual current state everywhere (Azure Blob support doesn't exist yet anywhere on the platform, including in EMR, the reference module) - a real production deployment needs that added to the shared kernel first, which is intentionally out of this ticket's scope (a shared-kernel change affects every module, not just HR).
• Upload validation checks file type and size only, not deeper content signature sniffing - matches HR's prior validation depth, flagged as a possible future hardening.

Tests: HR backend unit 1315/1315 passed; HR backend integration 250/250 passed; HR frontend 105/105 files, 824/824 tests passed, type-check clean; Admin backend 4077/4077 passed. Includes a schema migration (new hr.documents table + employee photo FK) - ordinary, safe to run normally. Role re-seed needed for the renamed permission keys.