Audit hash-chain verification endpoint and ops card

[BigMick03]

Closes #58

Title

feat: add read-only audit integrity verification API and Ops dashboard status

Summary

This PR adds a read-only audit integrity verification surface that allows authorized operators to verify the integrity of tamper-evident audit chains directly from the application, without exporting audit logs or manually running verifyHashChain(entries).

The implementation leverages the existing hash-chain verification logic in src/lib/audit/hash-chain.ts and introduces an authenticated API endpoint along with an Ops dashboard status card.

Motivation

Fortexa already records tamper-evident audit entries using entryHash and previousHash and provides verifyHashChain(entries) for offline validation.

This feature exposes that capability through authenticated application interfaces, enabling operators to:

• Verify audit integrity on demand.
• Detect broken or tampered audit chains.
• Monitor audit health from the Ops dashboard.
• Reduce manual operational effort.

Scope

API

Added an authenticated read-only endpoint:

GET /api/audit/integrity

The endpoint:

• Verifies the current operator's audit chain.
• Supports operator/admin scope for verifying all accessible chains if consistent with the existing authorization model.
• Does not modify audit history.

Response

Returns a compact response similar to:

{
  "valid": true,
  "checkedEntries": 1427,
  "firstBrokenEntryId": null,
  "reason": null,
  "timestamp": "2026-06-28T12:00:00Z"
}

If verification fails:

{
  "valid": false,
  "checkedEntries": 931,
  "firstBrokenEntryId": "audit_931",
  "reason": "Hash chain mismatch",
  "timestamp": "2026-06-28T12:00:00Z"
}

Ops Dashboard

Added an Audit Integrity card displaying:

• Latest verification status
• Valid/Invalid indicator
• Checked entry count
• Verification timestamp
• Failure reason (when applicable)

The dashboard is read-only and intended for operational monitoring.

Security

The implementation preserves existing security boundaries:

• Authenticated access only.
• Viewer/operator sessions cannot access another user's audit history.
• Admin/operator scope follows existing authorization rules.
• No audit entries are modified.
• Legacy history is never rewritten.
• No additional runtime dependencies introduced.

Compatibility

This feature reuses the existing:

• verifyHashChain(entries)

implementation without changing audit generation or export behavior.

Existing audit export functionality remains unchanged.

Tests

Executed:

npm run test

Added test coverage for:

• Valid audit chain
• Tampered hash detection
• Missing or broken hash links
• Legacy audit entries
• Empty audit history
• Unauthorized access
• Operator/admin authorization scope
• API response structure
• Ops dashboard rendering

Acceptance Criteria

• Authenticated audit integrity verification endpoint added.
• Existing hash-chain verification reused.
• Compact verification response returned.
• Ops dashboard displays integrity status.
• Valid chain verification tested.
• Tampered chain detection tested.
• Legacy entries handled correctly.
• Empty audit history handled correctly.
• Existing audit export behavior unchanged.
• npm run test passes.

Notes

This is a read-only operational feature. It does not alter audit records, recompute hashes, migrate legacy data, or change the existing audit logging pipeline. Its purpose is to expose existing integrity verification capabilities through secure API and UI surfaces for easier operational monitoring.

[vercel]

@BigMick03 is attempting to deploy a commit to the karagoz's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@BigMick03 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[karagozemin]

Thanks for the audit integrity PR. I ran the relevant checks and they pass locally:

• npm ci
• npm test -- src/app/api/audit/integrity/route.test.ts — 9 tests passed
• npm run build — passed
• git diff --check origin/main...HEAD — passed

However, GitHub reports merge conflicts against current main. Please update/rebase the branch and resolve the conflicts, then I can merge after re-running the same checks.

[karagozemin]

Rechecked after the branch update. The focused API test passes:

npm test -- src/app/api/audit/integrity/route.test.ts => 9 passing tests.

I still cannot merge because targeted eslint fails in the Ops dashboard UI:

• src/components/ops-dashboard.tsx:332:20 error 'ShieldCheck' is not defined react/jsx-no-undef
• src/components/ops-dashboard.tsx:334:20 error 'ShieldAlert' is not defined react/jsx-no-undef
• src/components/ops-dashboard.tsx:174:16 warning 'loadError' is defined but never used

Also, tsconfig.tsbuildinfo is included in the PR diff and should be removed. Please add/fix the missing icon imports, clean the unused state, and remove the generated build info file, then I can re-run the same checks.

[karagozemin]

Thanks for the PR! The build passes locally ✅, but after other PRs landed on main this branch now has merge conflicts and can't be merged as-is. Could you rebase onto the latest main and resolve the conflicts? Once it's mergeable I'll merge right away. 🙏

[karagozemin]

Rechecked: thanks for the updates. However this PR now has merge conflicts with main, so I cannot merge it as-is. Could you rebase/merge the latest main, resolve the conflicts and push? I will take another look and merge afterwards.