Moderators can approve, reject with reason, or request changes; all actions logged

Without an audit log of moderation actions, you cannot answer basic questions: Who approved the listing that turned out to be a scam? Was a rejection justified? When did a moderator act? This absence blocks compliance with ISO 27001:2022 A.8.15 (Logging) and makes CWE-778 (Insufficient Logging) applicable. Beyond compliance, an unlogged moderation system offers zero accountability — moderators can approve or suppress listings without any record.

Create an append-only moderation_logs table and write a row on every approve, reject, or request-changes action. Never update or delete log rows:

CREATE TABLE moderation_logs (
  id SERIAL PRIMARY KEY,
  listing_id INT NOT NULL REFERENCES listings(id),
  moderator_id VARCHAR NOT NULL,
  action VARCHAR(50) NOT NULL CHECK (action IN ('approve', 'reject', 'request-changes')),
  reason TEXT,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
-- No UPDATE or DELETE privileges granted on this table

In app/api/admin/listings/[id]/moderate/route.ts, insert the log row in the same transaction as the status update so they stay in sync. Surface the log in the admin UI alongside the listing so moderators see the full history before acting.