Open Peer Check: allow edit/submit and assign peer checker on submit #335

Why

Mobile product wants implicit Peer Checker assignment: when a chapter reaches Peer Check without a pre-assigned checker, eligible peers can work the item, and whoever taps Send to Community Review becomes the recorded Peer Checker.

Today the API blocks that flow. When status === peer_check and peerCheckerId is null, ChapterAssignmentPolicy.edit / submit require peerCheckerId === user.id — so nobody can edit, upload verse audio (verse-audio auth uses the same edit policy), or PATCH /chapter-assignments/{id}/submit.

@mattrace-gloo flagged this as an API blocker on the mobile ticket before mobile UI can ship: fluent-mobile#442#issuecomment-5622893731.

Unblocks / related

• Implement Implicit Peer Checker Assignment fluent-mobile#442 — Implicit Peer Checker Assignment (product)
• Engineering write-up: fluent-mobile#442#issuecomment-5622893731
• feat(chapter-assignments): allow open Peer Check edit/submit and assign checker on submit #334 — PR implementing this issue (Closes #335)
• [#442]: Implement implicit Peer Checker assignment fluent-mobile#538 — mobile PR for build(deps-dev): bump vitest from 3.2.7 to 5.0.5 #442 (pairs with API feat(chapter-assignments): allow open Peer Check edit/submit and assign checker on submit #334)

Web uses PM assign for Peer Check today — open Peer Check is new API behavior aligned with mobile, not catch-up to web.

Current state (main)

• ChapterAssignmentPolicy.edit / submit: peer_check requires peerCheckerId === user.id
• Open Peer Check (peerCheckerId == null): no translator can upload verse audio, write translated verses, or submit
• submitChapterAssignment does not take the acting user and does not set peerCheckerId on peer_check → community_review
• PM assign path can set peerCheckerId — exclusive assignee behavior must stay unchanged

Proposed scope

1. Policy (ChapterAssignmentPolicy.edit / submit)

   • When status === peer_check and peerCheckerId == null: allow project members with content:update who are not the drafter (assignedUserId).
   • Deny the drafter on open Peer Check (align with mobile AC).
   • When peerCheckerId is already set (PM assign): keep exclusive checker behavior (unchanged).
   • Managers (content:assign) keep existing post-peer rules — do not open translator Peer Check rules for them.

2. Submit (PATCH /chapter-assignments/{id}/submit)

   • Pass authenticated user into submit.
   • On advance from open Peer Check: set peerCheckerId to the submitter in the same transaction; write peer-checker assignment history.
   • Concurrent open Peer Check submits: first-wins; loser no-ops with current assignment (no special conflict type).

3. Tests

   • Policy (open allow / deny drafter / PM exclusive / non-member denied)
   • Conditional submit update (CAS on open peer_checker_id)
   • Service race + route wiring

Acceptance criteria

• Non-drafter project member with content:update can edit/submit on open Peer Check (peerCheckerId null)
• Drafter is denied edit/submit on open Peer Check
• Submit from open Peer Check sets peerCheckerId to submitter and advances to community_review
• PM-assigned peerCheckerId exclusivity unchanged
• Concurrent open Peer Check submits: first-wins; no invalid checker assignment
• Manual QA: claim → draft → submit (T1) → open peer_check → T2 presence/submit → community_review with peerCheckerId = T2
• No OpenAPI contract change — submit stays PATCH with no body and the checker is derived from the authenticated user; covered by tests on policy, repository, service and route
• Deny edit/submit on open Peer Check when assignedUserId is null (inconsistent data)

Notes

Mobile should not ship alone against API without these changes (403 / false “done”). QA join point: API + mobile on the same release train.

Product details live on mobile #442 — match those behaviors where possible.