PREWAVE-BE-105 — Persist Abuse-Signal Appeals and Moderation Decisions #806

Problem context

The abuse-signal appeal service stores appeal records in a bounded in-memory registry. The controller exposes appeal submission/listing and moderation workflows, but a process restart or multi-instance deployment can lose appeal records and produce inconsistent reviewer queues.

Technical scope

Replace the in-memory appeal registry with durable, owner-scoped persistence. Persist appeal ID, subject reference, reason, safe evidence reference, submission time, review status, assigned reviewer, decision, reason, and audit metadata. Preserve privacy-safe DTOs and the existing abuse-signal enforcement boundary. Enforce reviewer permissions and immutable decision history; do not store raw secrets or unbounded evidence in the appeal row.

Required tests

• Appeal survives restart and is visible consistently across API instances.
• Submitter sees only their own appeal; authorized reviewers see permitted queues.
• Reviewer assignment, decision, appeal status transition, duplicate submission, and concurrent updates.
• Audit history is immutable and evidence references remain access-controlled.
• Retention/deletion policy and privacy-safe response tests.

Security and architecture constraints

• Fail closed on missing, stale, unauthorized, or ambiguous state.
• Persist audit-critical state; do not rely on process-local maps for user appeals or financial operations.
• Canonical contracts and finalized events remain authoritative for protocol state.
• Do not fabricate scores, provider responses, payout hashes, receipts, or finality.
• Enforce owner/reviewer/service authorization and redact secrets and private evidence.

Acceptance criteria

• The identified in-memory, mock, or simulated behavior is replaced by the production-safe implementation.
• State is durable and consistent across process restarts and API instances where applicable.
• Authorization and privacy boundaries are covered by automated tests.
• Failure, retry, replay, and concurrency behavior is documented and tested.
• Exact-head required CI passes and independent review is recorded.

Dependencies

• Existing abuse-signal policy and enforcement configuration remain authoritative.

Non-goals

Changing abuse scoring, enforcement thresholds, or the abuse-signal policy.

Complexity and points

• Medium — 150 points

Candidate only. Activation remains maintainer-controlled; do not apply Stellar Wave as part of implementation.