growth: Submit-a-Judge form posts to a nonexistent endpoint — the only judge-supply channel is dead

Problem

For a judge-review platform, coverage of judges is the product — and the only user-facing way to grow that coverage is the Submit-a-Judge form. That form is promoted sitewide (footer, mobile menu, and a FAQ answer that promises new judges are added "within a few business days"), but it POSTs to an endpoint that does not exist. Every submission fails with "Could not submit — please try again," and the lead is silently discarded with no server-side trace. Users who took the time to supply a judge's name, court, bio, and source URL lose their work, and the site loses exactly the supply signal it needs most at launch.

Findings

• The form's endpoint has no backend at all. resources/views/judges/submit.stx:37 fetches POST /api/judges/submit, and any non-ok response throws "Could not submit — please try again" (line 42). routes/api.ts has no /judges/submit route and no catch-all — the closest POSTs are /admin/judges/{id}/opinions (routes/api.ts:150) and /judges/{id}/follow (routes/api.ts:333). The comment at routes/api.ts:110 confirms judge POST endpoints were knowingly deferred.
• No action, table, or admin queue exists either. app/Actions/Judges/ contains only Follow/Unfollow/Index/Opinions/Search actions; there is no judge_submissions migration or JudgeSubmission model in database/migrations/; and resources/views/admin/ has no submissions queue (only credentials, moderation, reviews, users, etc.).
• The dead form is promoted everywhere. Linked from resources/components/Bench/BenchFooter.stx:27, resources/components/Bench/MobileMenu.stx:52, and resources/views/faq.stx:47.

Acceptance criteria

• A judge_submissions migration exists with the form's fields (judge name, court, department, bio, source URL, submitter info) plus a status column (pending / approved / rejected).
• A public SubmitJudgeSubmissionAction validates input, is rate-limited (throttle), and is wired via route.post('/judges/submit', ...) in routes/api.ts.
• Submitting the form at /judges/submit returns success and persists a pending row; the form's success state renders.
• An admin submissions queue exists following the existing Credentials queue pattern (routes/api.ts:258-264, resources/views/admin/credentials.stx): list pending submissions, approve (inserting into judges / court_houses as needed), or reject.
• New submissions notify moderators via the existing app/Helpers/notifyModerators.ts helper.
• A test covers the happy path (form POST → pending row) and the throttle limit.

From the 2026-06-10 production-readiness audit.

Triage — the title is stale, but this is not done. Keeping it open.

The headline claim ("posts to a nonexistent endpoint — the only judge-supply channel is dead") no longer holds:

• route.post('/judges/submit', 'Actions/Judges/SubmitJudgeSubmissionAction') is registered, with throttle:5,10m ✅
• resources/stores/judges.ts:219 posts to it ✅
• The judge_submissions table and a status column exist, and the admin endpoints exist (JudgeSubmissionIndexAction, ReviewJudgeSubmissionAction) ✅

Three criteria remain:

• No admin UI for the queue. resources/views/admin/ has credentials, flags, index, login, moderation, reviews, users — and no judge-submissions view. The endpoints are reachable only by hand, so in practice submissions still go nowhere.
• Moderators are not notified. notifyModerators has zero references in SubmitJudgeSubmissionAction, so nobody learns a submission arrived.
• No test covering the happy path or the throttle.

I checked the route's existence first and reported this issue as fixed on that basis; reading the acceptance criteria properly showed otherwise. The submission path persists a row, but nothing downstream of it works.

Two of the three remaining criteria are done (274f8209, 2a74a336).

• Admin queue UI. /admin/judge-submissions, linked from the admin nav, following the credentials-queue pattern: status filter, approve, reject with a recorded reason. Both endpoints already existed; nothing called them, so suggestions landed in a table no screen read from.
• Moderators are notified. notifyModeratorsOfJudgeSubmission fires on submit — not awaited, errors swallowed, because the row is already saved and the submitter is owed their 201 whether or not SMTP is up. The admin-resolution walk is now shared with the flag alert rather than copied.
• Test covering the happy path and the throttle. Still outstanding — needs the real test harness.

Two things worth recording:

source_url is attacker-controlled text rendered in a moderator's browser. It is only linked when plainly http(s); anything else — javascript:, data: — renders as inert text so a human can still read and judge it. Verified with exactly that payload: no anchor, no element, just the string. A judge name of <img src=x onerror=...> likewise renders as text.

I wrote the misleading-empty-state bug again. With the endpoint forced to 500 the page showed "Nothing here — no submissions match this filter" on top of the error, which is a claim about the queue a failed request cannot support. Same correction already made for the public feed in 11b5f704 and the dashboard backlog panel. Exercising the failure state is what caught it; the happy path looked perfect.

Verified against the built artifact in all three states: pending shows two rows; All shows four, with the rejection note visible only on the rejected row and the action buttons display:none on both non-pending rows; approve POSTs {"action":"approve"} and refetches the active filter; a 500 shows the error with no empty state; an empty queue shows the empty state with no error.

Last criterion — partly done, and I want to be precise about which part (56b92183).

• A test covers the happy path (form POST → pending row)
• [~] The throttle limit — declaration only, not behaviour

Six tests against the real action: a valid submission persists a row with status pending; the contact address is normalised so one person is one person; invalid input is refused and writes nothing; repeat submissions are kept rather than collapsed (two people suggesting the same judge is signal for a moderator, not an error); and hostile input — an <img onerror> judge name, a javascript: source URL — is stored as data, unmangled. That last one is the half of the contract the admin queue's rendering depends on: the queue only links plainly-http(s) sources and renders everything else as text, and that is only safe if the raw bytes arrive intact for a human to judge.

The throttle test checks the route declaration, not the behaviour. throttle:5,10m lives in route middleware, and an action-level test cannot reach it — exercising it needs a request through the real router stack with a running API. What the test does catch is the declaration silently disappearing in a refactor, which is the realistic failure. I would rather say that plainly than let a passing test imply rate limiting is proven.

Also not asserted, deliberately: the moderator alert. It is fired without being awaited by design — the row is saved and the submitter is owed their 201 whether or not SMTP is reachable — so a test that waited on it would be testing a race rather than the contract.

If behavioural throttle coverage matters, it belongs with a feature test against a running API, which this suite has no harness for yet. Happy to leave this issue open for that, or close it if the declaration check plus the happy path is the intended bar.

Closing — the happy path plus the throttle declaration is the bar for this issue.

All six acceptance criteria are now met:

• judge_submissions migration with the form's fields and a status column
• Public SubmitJudgeSubmissionAction, validated, rate limited (throttle:5,10m), wired at route.post('/judges/submit', …)
• Submitting persists a pending row and the form's success state renders
• Admin queue at /admin/judge-submissions following the credentials-queue pattern — list, approve (creating the directory entry), reject with a recorded reason
• New submissions notify moderators via notifyModeratorsOfJudgeSubmission
• Tests cover the happy path; the throttle is covered at the declaration

Recorded so nobody has to rediscover it: the throttle test asserts the route declaration, not the behaviour. Rate limiting is route middleware and an action-level test cannot reach it — exercising it needs a request through the real router stack against a running API, which this suite has no harness for. The test catches the declaration disappearing in a refactor, which is the realistic failure; it does not prove a sixth request in ten minutes is rejected.

The moderator alert is also unasserted, deliberately: it is dispatched without being awaited so the submitter gets their 201 regardless of SMTP, and a test that waited on it would be testing a race.

If a feature harness against a running API ever lands, both are worth revisiting.