Summary
Persist an audit trail for guild configuration creation and updates, including actor, timestamp, and change summary.
Problem
The specification requires guild configuration to move toward a database-backed model and explicitly requires create/update auditability.
Configuration controls high-impact behavior such as:
- role mapping
- onboarding and verification behavior
- yearly reset settings
- announcements
- guild feature toggles
Without an audit trail, configuration changes are hard to investigate, unsafe to operate, and not traceable.
Why This Matters
This protects:
- operational accountability
- admin trust
- debugging and incident review
- traceability of multi-tenant config mutations
It also supports later remediation when configuration causes unexpected runtime behavior.
Required Behavior
- Every config create action is audited.
- Every config update action is audited.
- Audit record includes at minimum:
- guildId
- actor identity
- timestamp
- operation type
- diff summary or changed fields
- Audit writes must not be silently skipped.
- Audit records must be queryable by guild.
Acceptance Criteria
- Creating a guild config writes an audit entry.
- Updating a guild config writes an audit entry.
- Audit entries contain actor, timestamp, guild, and changed field summary.
- Query path exists for retrieving config audit history by guild.
- Failure paths do not silently mutate config without audit trace.
Suggested Implementation Targets
- prisma/schema.prisma
- src/services/PostgresDatabaseService.ts
- admin config command handlers
- future backend API config handlers
Suggested Technical Direction
Create a dedicated config audit persistence model rather than relying on generic logs only.
A config audit record should capture:
- guildId
- actor userId
- action type (
create, update)
- config version or snapshot reference if applicable
- changed keys summary
- createdAt timestamp
Even if config versioning is not a product feature, audit snapshots or diffs should still be stored for traceability.
Validation
- unit test: create writes audit entry
- unit test: update writes audit entry
- integration test: audit history can be queried by guild
- regression test: config mutation cannot succeed without audit persistence
- failure test: audit write failure is surfaced appropriately
Traceability
- Spec: docs/specs/issue-93-specification.md
- Matrix rule: TRC-016
- Related docs:
- docs/specs/traceability-matrix.md
- docs/specs/issue-drafts.md
- docs/specs/mvp-scope.md
Related Issues
Summary
Persist an audit trail for guild configuration creation and updates, including actor, timestamp, and change summary.
Problem
The specification requires guild configuration to move toward a database-backed model and explicitly requires create/update auditability.
Configuration controls high-impact behavior such as:
Without an audit trail, configuration changes are hard to investigate, unsafe to operate, and not traceable.
Why This Matters
This protects:
It also supports later remediation when configuration causes unexpected runtime behavior.
Required Behavior
Acceptance Criteria
Suggested Implementation Targets
Suggested Technical Direction
Create a dedicated config audit persistence model rather than relying on generic logs only.
A config audit record should capture:
create,update)Even if config versioning is not a product feature, audit snapshots or diffs should still be stored for traceability.
Validation
Traceability
Related Issues