WORM archive of audit events and published configuration to an object-locked MinIO bucket #89

Stack-wide compliance hardening. Arose from the workflow-configuration design discussion (#80) but applies to the audit trail as a whole.

Context

audit_logs is append-only by application code: AuditLogRepository has no delete/update method. That protects against bugs, not against someone with database superuser access. Auditors may ask: "how do you know nobody quietly edited the history?"

MinIO (already in the stack) supports object lock in compliance mode (WORM): a locked object version cannot be deleted or overwritten by anyone, root included, until its retention period expires.

Scope

1. On each audit event (or in periodic batches), write a record to a compliance-mode, object-locked MinIO bucket, including a content hash.
2. Also archive each published workflow version (YAML + hash + author + eval run ID) the same way, once Epic: configurable multi-agent workflows (declarative definitions, versioned store, audited publish, iteration loop) #80's slice 3 lands.
3. A verification command that compares Postgres rows/hashes against the locked archive and reports any mismatch as evidence of tampering.
4. Air-gap and TLS: same constraints as the existing MinIO usage (Harden docker-compose to TLS-by-default (MinIO and other local services) #17).

Design cautions

• Compliance-mode lock periods cannot be shortened, even by an admin. Choose the retention period deliberately and document how it interacts with the retention policy in docs/SECURITY.md. Governance mode (overridable by privileged users) may be the right default for a template, with compliance mode as a documented opt-in.
• Batching vs. per-event writes trades durability against MinIO write volume. Decide in the plan.
• Failure handling: an archive write failure must not silently drop the record (retry/queue), and must not block the user-facing action. Decide explicitly.

User-visible signal

An archive/verification status on the Admin Dashboard (last archived event, last verification result).

RBAC

Admin feature for viewing status. Bucket credentials are deployment config (Kubernetes Secret).

Configuration call-out

Lock mode and retention period: likely env/Helm-only, deliberately not DB-editable (a DB-editable lock period would undermine the point of the control). Confirm in the plan.