feat: cases (reports, reviews, requests, appeals) and notifications (#9)

Phase 3, part 1 (`docs/design.md`, "Next"): cases and notifications. File blocks, API tokens and two-factor sign-in come as separate PRs.

**Cases**
- One queue (Console → Cases) for everything someone has to decide. Each case has:
  - a thread of notes, where internal notes are visible only to those deciding
  - an assignee (moderators assign cases to moderators)
  - a decision, Resolve or Decline, with a written resolution that the person who opened it sees
- **Reports:** anyone signed in can report a product or catalog from its page (the API also takes rooms and people).
  - Limits: 10 an hour, one open report per person and thing, and you can't report yourself.
  - Reports about a product go to the teams of the catalogs hosting it, as well as to moderators.
  - Only the reporter and moderators know who reported. The audit entry for a report isn't tagged with what it's about, so a product's creator can't find out from their audit log either.
- **Rating reviews:** a creator lowering a rating from adult to general now opens a review instead of being refused. The rest of the edit still saves. Resolving the review lowers the rating, recorded in the product's history.
- **Removal requests:** a catalog's team can ask moderators to remove a product it hosts, everywhere. Resolving it removes the product.
- **Deletion requests:** a catalog's owner asks for deletion from the catalog's console page, and a moderator decides, as agreed. Resolving it marks the catalog `deleted`: its key stops working, nothing is available from it, and its changes feed says so.
- **Appeals:**
  - From the audit log, the person an action affected can appeal it, once: their product removed, delisted or edited by someone else; their catalog suspended or rejected; a ban from a catalog or a declined request to join.
  - Another moderator decides. An admin may decide an appeal of their own action, and the audit log flags it.
  - Resolving records the decision; the moderator then undoes the action where it's done. For that, there's now a Restore for removed products (Console → Products, for moderators); the design mentioned one, but it was never built.
- The console shows a "Cases" tab, and a to-do with the number of open cases the person could decide.

**Notifications**
- A bell in the header with the unread count, and a notifications page with "Mark all as read".
- Each is also sent to the person's proxies over the realtime connection (`{"type": "notification"}`), so the client can show them later.
- They cover:
  - a moderator edited or locked your product, or undid a change (with the reason)
  - your product was removed or restored
  - your case was decided
  - someone replied on your case
  - a catalog decided your membership

**Also changed**
- A product's creator and moderators can now see it when it's adult, even without an adult account. Before, a creator who made their own product adult couldn't open its page any more, and neither could moderators. Getting and wearing adult products still need an adult account.

**Not done yet** (in `docs/console.md`): email notifications (the hub sends no email yet), canned reasons, private moderator notes on people and products, and second approval for the most destructive actions.

**Migration** `0012_cases`: the `moderation_case`, `case_note` and `notification` tables. (`case` is a reserved word in SQL, hence the table's name.)

**Checks**
- 51 API tests pass. The 7 in the new `cases.test.ts` cover:
  - who sees and decides each kind of case, and that the reporter stays private
  - rate limits and duplicate reports
  - the thread and internal notes, and assigning
  - what deciding each kind of case does
  - appeals by the person affected only, decided by another moderator
  - restoring a removed product
  - the notifications
- Type checks pass.
- On a local hub I went through every flow with the website's own forms: report from a product page; the catalog owner's note and decision; assigning, an internal note and a decision as admin; removal by a moderator, the creator's appeal from the audit log, the admin's decision and Restore; a creator's rating review and the decision lowering the rating; a deletion request and its decline; the notifications, the bell's count, and Mark all as read.
- Fixed along the way:
  - The catalog's team could see who reported.
  - A missing Resolve/Decline choice was treated as Decline; now it's refused.
  - The Unassign button sent the typed name instead of nothing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Phase 3, part 1 (`docs/design.md`, "Next"): cases and notifications. File blocks, API tokens and two-factor sign-in come as separate PRs.

**Cases**
- One queue (Console → Cases) for everything someone has to decide. Each case has:
  - a thread of notes, where internal notes are visible only to those deciding
  - an assignee (moderators assign cases to moderators)
  - a decision, Resolve or Decline, with a written resolution that the person who opened it sees
- **Reports:** anyone signed in can report a product or catalog from its page (the API also takes rooms and people).
  - Limits: 10 an hour, one open report per person and thing, and you can't report yourself.
  - Reports about a product go to the teams of the catalogs hosting it, as well as to moderators.
  - Only the reporter and moderators know who reported. The audit entry for a report isn't tagged with what it's about, so a product's creator can't find out from their audit log either.
- **Rating reviews:** a creator lowering a rating from adult to general now opens a review instead of being refused. The rest of the edit still saves. Resolving the review lowers the rating, recorded in the product's history.
- **Removal requests:** a catalog's team can ask moderators to remove a product it hosts, everywhere. Resolving it removes the product.
- **Deletion requests:** a catalog's owner asks for deletion from the catalog's console page, and a moderator decides, as agreed. Resolving it marks the catalog `deleted`: its key stops working, nothing is available from it, and its changes feed says so.
- **Appeals:**
  - From the audit log, the person an action affected can appeal it, once: their product removed, delisted or edited by someone else; their catalog suspended or rejected; a ban from a catalog or a declined request to join.
  - Another moderator decides. An admin may decide an appeal of their own action, and the audit log flags it.
  - Resolving records the decision; the moderator then undoes the action where it's done. For that, there's now a Restore for removed products (Console → Products, for moderators); the design mentioned one, but it was never built.
- The console shows a "Cases" tab, and a to-do with the number of open cases the person could decide.

**Notifications**
- A bell in the header with the unread count, and a notifications page with "Mark all as read".
- Each is also sent to the person's proxies over the realtime connection (`{"type": "notification"}`), so the client can show them later.
- They cover:
  - a moderator edited or locked your product, or undid a change (with the reason)
  - your product was removed or restored
  - your case was decided
  - someone replied on your case
  - a catalog decided your membership

**Also changed**
- A product's creator and moderators can now see it when it's adult, even without an adult account. Before, a creator who made their own product adult couldn't open its page any more, and neither could moderators. Getting and wearing adult products still need an adult account.

**Not done yet** (in `docs/console.md`): email notifications (the hub sends no email yet), canned reasons, private moderator notes on people and products, and second approval for the most destructive actions.

**Migration** `0012_cases`: the `moderation_case`, `case_note` and `notification` tables. (`case` is a reserved word in SQL, hence the table's name.)

**Checks**
- 51 API tests pass. The 7 in the new `cases.test.ts` cover:
  - who sees and decides each kind of case, and that the reporter stays private
  - rate limits and duplicate reports
  - the thread and internal notes, and assigning
  - what deciding each kind of case does
  - appeals by the person affected only, decided by another moderator
  - restoring a removed product
  - the notifications
- Type checks pass.
- On a local hub I went through every flow with the website's own forms: report from a product page; the catalog owner's note and decision; assigning, an internal note and a decision as admin; removal by a moderator, the creator's appeal from the audit log, the admin's decision and Restore; a creator's rating review and the decision lowering the rating; a deletion request and its decline; the notifications, the bell's count, and Mark all as read.
- Fixed along the way:
  - The catalog's team could see who reported.
  - A missing Resolve/Decline choice was treated as Decline; now it's refused.
  - The Unassign button sent the typed name instead of nothing.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: dhkatz <[email protected]>

apps/web/app/console/cases/actions.ts

@@ -0,0 +1,98 @@
+"use server";
+// Cases (reports, reviews, requests, appeals) and notifications, from the website.
+import { revalidatePath } from "next/cache";
+import { redirect } from "next/navigation";
+import { api, unwrap } from "@/lib/api";
+import { attempt, field, type ActionState } from "@/lib/actions";
+
+/** Reports a product, catalog, room or person. */
+export async function report(_: ActionState, form: FormData): Promise<ActionState> {
+  const kind = field(form, "about");
+  const id = field(form, "id");
+  if (!["product", "catalog", "room", "person"].includes(kind)) return { error: "Nothing to report." };
+  return attempt(async () => {
+    unwrap(await api.cases.post({ kind: "report", about: { [kind]: id }, reason: field(form, "reason") }));
+    revalidatePath("/console/cases");
+    return "Reported. Moderators will look at it; you'll be told what they decide.";
+  });
+}
+
+/** Appeals an action from the audit log. */
+export async function appeal(_: ActionState, form: FormData): Promise<ActionState> {
+  let id = 0;
+  const state = await attempt(async () => {
+    const { case: c } = unwrap(await api.cases.post({ kind: "appeal", audit: Number(field(form, "audit")), reason: field(form, "reason") }));
+    id = c.id;
+  });
+  if (state?.error) return state;
+  redirect(`/console/cases/${id}`);
+}
+
+/** A catalog's team asks moderators to remove a product everywhere. */
+export async function requestRemoval(_: ActionState, form: FormData): Promise<ActionState> {
+  return attempt(async () => {
+    unwrap(
+      await api.cases.post({
+        kind: "removal-request",
+        about: { product: field(form, "product") },
+        catalog: field(form, "catalog"),
+        reason: field(form, "reason"),
+      }),
+    );
+    revalidatePath("/console/cases");
+    return "Asked. Moderators will decide.";
+  });
+}
+
+/** A catalog's owner asks for it to be deleted. */
+export async function requestDeletion(_: ActionState, form: FormData): Promise<ActionState> {
+  const id = field(form, "id");
+  let kase = 0;
+  const state = await attempt(async () => {
+    kase = unwrap(await api.catalogs({ id }).delete.post({ reason: field(form, "reason") })).case;
+  });
+  if (state?.error) return state;
+  redirect(`/console/cases/${kase}`);
+}
+
+const onCase = (form: FormData) => {
+  const id = Number(field(form, "case"));
+  return { id, done: () => revalidatePath(`/console/cases/${id}`) };
+};
+
+export async function addNote(_: ActionState, form: FormData): Promise<ActionState> {
+  const { id, done } = onCase(form);
+  return attempt(async () => {
+    unwrap(await api.cases({ id }).notes.post({ body: field(form, "body"), internal: form.get("internal") === "on" }));
+    done();
+  });
+}
+
+export async function assign(_: ActionState, form: FormData): Promise<ActionState> {
+  const { id, done } = onCase(form);
+  return attempt(async () => {
+    const to = field(form, "to");
+    unwrap(await api.cases({ id }).assign.post({ to: to || null }));
+    done();
+  });
+}
+
+export async function decide(_: ActionState, form: FormData): Promise<ActionState> {
+  const { id, done } = onCase(form);
+  const decision = field(form, "decision");
+  if (decision !== "resolve" && decision !== "decline") return { error: "Choose to resolve or decline it." };
+  return attempt(async () => {
+    unwrap(await api.cases({ id }).decide.post({ decision, resolution: field(form, "resolution") }));
+    done();
+    revalidatePath("/console/cases");
+    revalidatePath("/console");
+  });
+}
+
+export async function markAllRead(_: ActionState): Promise<ActionState> {
+  return attempt(async () => {
+    unwrap(await api.notifications.read.post({}));
+    revalidatePath("/notifications");
+    revalidatePath("/", "layout");
+  });
+}