Community

Packs in the community now.

A second kind rather than a second system: plan 041 D11's shared shape was never built, so the two kinds are two listings the page shows together (plan 042 D1).

curl "$MORSE/community/packs" \
  -H "Authorization: Bearer $MORSE_TOKEN"

[
  {}
]

A folder of your own, holding a copy of each document (plan 042 D6) — or the folder from a copy you already hold, if packs.adopt found one still live and wrote nothing new (this task's blocking finding: a repeat adopt must cost nothing, not merely go uncounted).

The decorator's 201 is the common case — a genuine first copy — and the route overrides it to 200 when created comes back False: 201 means "created", and nothing was, here. created itself never reaches the wire; it exists only to pick the status code, so the body keeps the one {folder_id, documents} shape every caller already expects, same as the 201 case. The refusal's code comes from the error, not from this route: every PackError was a 404 here, so an author refused their own pack read as "no such pack" where the template route says 409 (review finding M2).

curl -X POST "$MORSE/community/packs/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/adopt" \
  -H "Authorization: Bearer $MORSE_TOKEN"

Waiting for a decision, oldest first — the queue is two people's reading time (D13), so the one that has waited longest goes first. Full sections, not just headings: a reviewer reads what they are approving.

Two kinds, one queue (plan 042 D1): templates and packs are unrelated tables, so each is its own query, tagged with kind and merged here — ORDER BY created_at only works within one SELECT, so the oldest-first rule for the combined list is enforced in Python instead.

curl "$MORSE/community/review" \
  -H "Authorization: Bearer $MORSE_TOKEN"

[
  {}
]

Kind-aware approve for the queue's two rows.

The old /review/{template_id}/approve above keeps working unchanged — the frontend still calls it, and Task 6 is what moves it over — and the two routes do not collide: this one always has four path segments after /review's mount point, the old one three, so FastAPI's routing never has to choose between them (verified by exercising both, Task 5).

curl -X POST "$MORSE/community/review/…/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/approve" \
  -H "Authorization: Bearer $MORSE_TOKEN"

Kind-aware reject, mirroring approve_kind.

curl -X POST "$MORSE/community/review/…/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/reject" \
  -H "Authorization: Bearer $MORSE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Annual plans are billed up front." }'

Let a template into the community. Admins only (plan 041 D7).

Records who approved it and when, and clears any earlier rejection note. From here anyone can adopt it, which copies it — so approving is a decision about this text, and the author editing it afterwards sends it back for review rather than quietly changing what people adopt. rejected as well as in_review, because reject is also the takedown (D8): without it, an admin who took something down in error could only put it back in psql. Restoring is the same decision as approving and leaves the same trail — this admin, now, and no rejection note, since the reason for a takedown goes with the takedown. A template nobody offered has no status at all and is still out of reach: this stays a decision about something submitted, not a way to publish any row.

curl -X POST "$MORSE/community/review/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/approve" \
  -H "Authorization: Bearer $MORSE_TOKEN"

Rejects something waiting, or takes down something approved in error — the same route either way, with the same reason trail (D8).

curl -X POST "$MORSE/community/review/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/reject" \
  -H "Authorization: Bearer $MORSE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "note": "Annual plans are billed up front." }'

What is in the community right now: approved templates, newest first.

Adoption count is the only social signal there is (D12), so it is the one number shown alongside what a reviewer already approved.

curl "$MORSE/community/templates" \
  -H "Authorization: Bearer $MORSE_TOKEN"

[
  {}
]

A copy, not a link (D9).

The new row is entirely the adopter's own — editing or deleting it never touches the original, and nothing the original's author or an admin does to the original reaches it either.

curl -X POST "$MORSE/community/templates/3f9c1a24-5e6f-4b31-9a77-1b2c3d4e5f60/adopt" \
  -H "Authorization: Bearer $MORSE_TOKEN"