[LuvvSumDev]

Description

Server investigations currently depend on transient console history and separate
performance and disconnect views. This adds an Incident Center where staff can
inspect recorded events, preserve a selected time range, add notes, and resolve or
reopen an incident. Evidence survives server-session cleanup.

The implementation adds SQLite event/incident/note tables through generated migration
0009, bounded capture with gap markers, independent evidence retention, and separate
view/manage/export permissions. Defaults are 30 days and a configurable 128 MiB
payload budget. Storage pressure evicts old history before incidents. Exports omit
console/staff free text, paths, resource names and player identifiers.

The navigation item sits directly below Performance. The page uses the webpanel's
shared Select, Calendar, Popover, Card, Collapsible, Alert, ScrollArea and form
components. Unknown API routes now return JSON instead of the SPA document, and the
API client handles non-JSON and malformed responses without exposing parser errors.

Related discussion: #93. This
change does not close that broader Prometheus/Grafana diagnostics request.

Generative AI Disclosure

• No, Generative AI was not used in the creation of this PR.
• Yes, Generative AI was used in the creation of this PR.
  • Tools used: OpenAI Codex.
  • Purpose / What it was used for: Implementation, code review, tests, and documentation.

---

Tests

• Tested in development mode
• Passes typecheck
• Builds & runs on Windows
• Builds & runs on Linux

---

Additional Notes

Feedback from the core maintainers would be especially useful on the retention
defaults, permission model, and diagnostic export contents before this is ready to
merge. This first release focuses on manual investigations; automatic detection,
Discord alerts, and automatic recovery are left for future discussion.

The main tradeoffs to review are:

• Retention: the 30-day default is a maximum, not guaranteed storage. When the
  payload budget is exceeded, older history is removed first, followed by older
  incidents, including unresolved ones. SQLite pages, indexes, and WAL add overhead
  beyond the configured payload budget.
• Privacy and exports: known secrets and common identifiers are redacted before
  persistence, but arbitrary personal information can remain in panel-only text.
  Exports therefore omit console messages and staff free text. Feedback is welcome
  on whether the remaining structured evidence is sufficient for troubleshooting.
• Integration: migration 0009 adds independent evidence storage so existing
  session cleanup cannot remove saved incident evidence. Existing permission groups
  receive no new access automatically.

Linux runtime validation is still needed before merging. Additional testing under
sustained console output would also help assess recording overhead on busy servers.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.

An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.

[Maximus7474]

Hey ! First of all, thank you for the interest in contributing to this project, it's really appreciated.

However I've got an issue between the discussed scope and actual implementation, whilst targeting the subject in the linked issue was the main objective the actual implementation feels like just an alternative audit log system. In the current state this feature is basically duplicating stored data.

Whilst you do add a manual "incident creation" option, I currently don't see a use for it where projects would favour that instead of using discord where they can further more chat on an incident.

On the technical front there is one concern, I haven't been able to investigate it yet but migrating the database from v8 to v9 succeeds in the flow but didn't create the tables leading to the IncidentRecorder flush method to throw errors which are suppressed by a statement that it would mark the events when the system recovers, which it doesn't. The issue was only resolved when deleting the database file, for additional details.

I'll mark this as a draft PR until we can clear out an outcome that is clearer.