Build a scalable, filterable audit log system with a structured event schema

[Lakes41]

Difficulty: Advanced
Type: feature

Background
The /activity route currently renders an activity/audit log from mock data, but the README gives no indication of a formal event schema, pagination strategy, or filtering model suited to a growing, multi-guild audit trail.

Problem
As guilds, members, and passes scale, an unstructured or flat activity log won't support efficient filtering by actor, guild, action type, or date range, and lacks a stable schema that other parts of the system (e.g., webhooks) could reuse.

Expected outcome
A structured AuditEvent schema (actor, guildId, targetType, targetId, action, metadata, timestamp) backs the activity log, with server-side-style pagination and combinable filters (actor, guild, action type, date range), designed to later back onto a real datastore.

Suggested implementation

• Define the AuditEvent type in packages/integration-client, reusable by both the dashboard and the future webhook dispatch system.
• Refactor apps/dashboard/lib/mock-data.ts activity entries to conform to the new schema.
• Implement a query function supporting combined filters + cursor-based pagination (even against the in-memory array, structured as if it were a DB query).
• Update the Activity page UI to expose filter controls (actor, guild, action type, date range) wired to the query function.
• Document the schema and intended indexing strategy (e.g., composite index on guildId+timestamp) for a future real database.

Acceptance criteria

• AuditEvent schema defined and shared via packages/integration-client
• Combined filters (actor + guild + action + date range) work correctly
• Cursor-based pagination implemented and documented
• Migration notes for a real datastore included in docs/

Likely affected files/directories

• apps/dashboard/app/activity/
• apps/dashboard/lib/mock-data.ts
• packages/integration-client/
• docs/

[bridgetthnkechi87-cloud]

Hello Maintainer,

I would like to work on this issue.

I understand the goal is to turn the current mock activity log into a more structured audit trail model that can scale across guilds, members, passes, and future webhook/datastore integrations.

My approach would be to first review the current /activity page and mock activity data, then define a reusable AuditEvent schema in packages/integration-client with fields like actor, guildId, targetType, targetId, action, metadata, and timestamp. I’ll refactor the dashboard mock activity entries to conform to that schema, then add a query function that supports combined filters for actor, guild, action type, and date range with cursor-based pagination, even while still backed by in-memory data.

I’ll also update the Activity page UI with filter controls wired to the query function and document the schema, pagination model, and future datastore/indexing strategy under docs/.

I’ll keep the PR focused on the audit event schema, activity query model, UI filters, pagination, and documentation.

I’d be happy to take this up if assigned.

[grantfox-oss]

🦊 GrantFox — @bridgetthnkechi87-cloud has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #297)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@bridgetthnkechi87-cloud's PR #313 was approved and merged by @Lakes41.

🏆 @bridgetthnkechi87-cloud: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (366 total points). Track your full progress on GrantFox.

👏 Great work, @bridgetthnkechi87-cloud! Keep contributing to Adamantine-guild.