feat: requester role with admin approval (stacks on #2662)

[vavallee]

Summary

Adds a requester role: an account that can browse the library read only, search for a book or an author and ask for it, but cannot grab, download, delete, use OPDS or see settings. Admins get a Requests queue; approving runs the ordinary add with the requester as the owner. This is PR 4 of the four feature plan.

Rebased onto main now that #2662 merged (as 9b312bf8). Approval calls its addBookCore and createAuthorCore rather than adding anything itself. See "Rebased onto main" below for how the conflicts with release discovery (#2663) and library adoption (#2671) were resolved.

Suggested review order

One commit per stage, each builds and passes its tests:

1. feat(auth): add the requester role and keep it through OIDC group sync: role constants, ValidRole, the six validators, the last admin guard, the OIDC group rule.
2. feat(auth): hold requesters to an allow list on every API route: auth.RestrictRequester, the limiter, OPDS, mountUnderURLBase. The security core; please read this one closely.
3. feat(api): let requesters ask for books and authors, and admins approve: migration 089, RequestRepo, the projection, /requests.
4. test(api): keep the catalogue sync when an approval searches on add: follows the base branch's new errCreateAuthorSearchNeedsSync.
5. feat(notifier): send requestCreated when a requester asks for something
6. feat(web): give requesters their own shell and admins a request queue
7. test(smoke): sign in as a requester against the real router
8. docs: document the requester role, request approval and the OIDC group rule
9. fix(auth): never let the auth mode elevate a requester, and limit creates and covers (security review items 1, 4, 6)
10. fix(api): rate limit request creates, make the pending cap atomic, renew approval claims (items 1, 2, 3, 5, 7, 8)
11. docs: requester restrictions hold in every auth mode, and the new limits
12. fix(api): withhold the API key from requesters only, as on main for everyone else
13. fix(db): annotate the two request queries gosec flags as SQL concatenation
14. fix(auth): do not let the mode grant replace a session whose role or epoch cannot be read (second review item 2)
15. fix(api): release the claim when an approval panics, cap webhooks per requester, unlink URLs (second review items 1, 3, 4, 5)
16. docs: the per requester webhook cap and link neutralising
17. test(api): teach the requester route tests about adoption and diagnose (after the rebase)

Where the guard sits and what it covers

useAPIAuth (cmd/bindery/sensitive_routes.go) is the one function both API trees call: r.Route("/api", ...) (the Arr compatible queue) and r.Route("/api/v1", ...). auth.RestrictRequester is installed in it directly after auth.Middleware, so both trees get it, and so does any route either tree gains later.

BINDERY_URL_BASE is applied by http.StripPrefix around the whole router, which rewrites r.URL.Path and r.URL.RawPath before dispatch, so the guard matches the unprefixed path. I lifted that block out of main() unchanged into mountUnderURLBase so the route test runs the same prefix handling; the test covers both trees with and without /bindery.

Every other authenticated or public surface:

Surface	Requester	Why
/api/v1/*	allow list only	guard
/api (Arr queue)	403	guard, same useAPIAuth
/opds/* (feeds, files, images)	403	role check added to OPDSAuth on both the cookie and the Basic path
/metrics	unchanged	mounted outside auth for Prometheus; a requester gets nothing an anonymous client does not
/__bindery_base.js, SPA static files	unchanged	public build assets, no data
/api/v1/images	allowed, rate limited	covers for the projection; same SSRF guarded proxy every role uses, with its own per requester bucket
websocket or event stream	none exist

Roles the guard leaves alone: admin and user. A request with no user id and no role only reaches the guard through AllowUnauthPath (setup, login and so on), which Middleware already constrained. A signed in user whose role lookup returned empty, or an unknown role, is restricted: fail closed.

The auth mode never elevates a requester: auth.Middleware passes a valid requester session through as the requester before the disabled and local-only grants, and OPDSAuth refuses it before its bypasses. The API key still acts as the admin whatever cookie rides along. In disabled and local-only mode a caller who signs out is still admin, so the docs recommend enabled or proxy for requester accounts.

Wiring of the add cores

The requests handler depends on a two method interface, requestAdder { addBookCore; createAuthorCore }, which *AuthorHandler satisfies. I preferred it to a *AuthorHandler field because the requests handler then cannot reach the author handler's repositories, provider or searcher, so the only way an approval adds anything is the code path the Add dialog runs; and the approval's own logic (claim, revalidation, owner context, release on failure, concurrency) is tested against a fake without a metadata provider. The real core is exercised too, in TestRequestsApprove_CreatesRowsOwnedByRequester and TestRequestsApprove_AuthorRequestUsesAdminChoices.

addBookParams has no profile or root folder fields, so a book approval offers format and search on add (what the Add Book dialog offers); an author approval offers the full set. Approval never sets SkipCatalogueSync, so it cannot hit the base branch's new errCreateAuthorSearchNeedsSync; a test proves it with the real core, and the sentinel maps to an admin facing sentence if a later change reaches it.

Security

S1, projection. GET /requests/library selects id, title, author name, primary series and position, image url, status and two EXISTS flags column by column (internal/db/requests_library.go), so no file path is ever read, and copies them field by field into requesterLibraryBook. TestRequesterLibraryBook_FieldAllowList walks the type by reflection and fails on any field or JSON name not on the list, or on an embedded struct. TestRequestsLibrary_ProjectionCarriesNoPaths seeds files under a marker path and asserts the marker, filePath, provider ids, monitored and owner appear nowhere in the body. /author, /book, /series stay off the allow list.

S2, server built payload. POST /requests decodes with DisallowUnknownFields from a 4 KiB MaxBytesReader and accepts exactly kind, foreignId, mediaType. The server calls GetBook or GetAuthor, stores the provider's cleaned title and author, and builds payload_json itself. 409 with a sentence for already in library (global check, including the provider's canonical id) or already requested by this user, 429 past the cap. Approve takes the admin's choices (strict decode, 8 KiB), claims the row, revalidates the stored payload against the row (kind, foreign id, id shapes, media type), rechecks the library, and runs the core in a context carrying the requester's id and role. TestRequestsCreate_ServerBuildsPayload sends title, rootFolderId, searchOnAdd, qualityProfileId, trailing objects and arrays: all 400. TestRequestsApprove_RevalidatesPayload tampers with the stored payload five ways: all 422 with no add.

S3, webhook text. requestCreatedPayload strips control and format characters (bidi overrides, zero width) with cleanRequestText, caps title 300, author 200, username 64 runes, and replaces every @ in all three with the fullwidth at sign. TestRequestsCreate_SendsSanitisedRequestCreated drives a hostile provider title, author and username through a real create.

S4, abuse limits. Per user token bucket (burst 20, one per 3 s) on /search/author, /search/book, /book/lookup and POST /requests for requesters only (the create handler also spends it if the guard did not), a separate larger bucket on /images, held in a map capped at 1024 users with idle eviction (swept at most once per 10 minutes, least recently used evicted when full). requests.max_pending_per_user, default 25, registry entry and validator (1 to 10000), enforced inside the insert so concurrent creates cannot pass it. Body caps as above.

S5, OIDC group sync. groupSyncRole: in the group gives admin; not in it and currently admin gives the configured default role (user when the default is admin, so leaving the group always demotes); otherwise the current role. Tests for all three plus BINDERY_OIDC_DEFAULT_ROLE=requester at config and provisioning. The last admin guard now refuses a demotion to any non admin role; before, it only checked role == "user", so SetRole(lastAdmin, "requester") would have left no admin.

S6, path matching. The matcher refuses before lookup: a set RawPath (any escape that is not canonical, including %2F and %31), any path path.Clean would change (dot segments, doubled or trailing slash), and a leftover %, backslash or control character. HEAD matches as GET. Only r.Method is read; a chi routing method that differs from it is refused. TestRestrictRequester_DeniesEveryListedRoute covers 81 denied method and path pairs, each in HEAD, trailing slash, doubled slash, ./, x/../, upper case, %2F, %2f and escaped letter spellings. The same spellings of every allow list entry are refused too. TestRestrictRequester_IgnoresMethodOverride covers three override headers.

Plan items

Item	Status
P6 matcher built once	done: defaultRequesterMatcher at package init; limiter bounded with idle eviction; author progress is one grouped query per page (fillAuthorProgress)
C2 role constants	done: auth.RoleAdmin/RoleUser/RoleRequester, auth.ValidRole used by all six validators; literals replaced only in files this PR touches
C7 notifier recipe	done, not redesigned
T1 existing doubles	stubMetaProvider, addBookBackCatalogueStub, the OIDC fakeIDP harness, vi.mock('../api/client')
T2 FuzzRequesterAllowList	done: raw request lines through http.ReadRequest into a router shaped like the real one; 60 s local run, 2.3M execs, no failure
T3 concurrency	TestRequestRepo_ClaimIsExclusive (8 racers, one claim) and TestRequestsApprove_ConcurrentApprovalsAddOnce (two approvals, one add, one 409), both under -race
T4 migration on populated DB	TestMigration089_OnPopulatedDatabase: existing webhook keeps on_request_created = 0, users kept, table empty, kind CHECK holds
T8 OIDC demotion fail before	below

Migrations

After the rebase, main carries 085, 087 (discovery) and 088 (adoption). 086 is still claimed by the two open PRs #2633 and #2607. This PR keeps 089, which is free.

Security review fixes

An independent review against a live binary found no allow list bypass. It found the eight items below, fixed in 0453d9b1, 5644ea10 and 72209077. The fail before evidence ran base compatible copies of the tests against 274f7f2c, the previous head of this branch, then the same files against the fix.

#	Finding	Fix	Test	Before (274f7f2c)
1	POST /requests not rate limited; failed lookups never fill the cap	Route marked LimitProvider, and Create spends the provider bucket itself before the lookup unless the guard already charged the request (a context flag, so no double charge)	TestRequestsCreate_RateLimitedInHandler (22nd rapid create is 429), TestRestrictRequester_CreateAndImagesLimited, TestRequesterLimiter_AllowRequester	22nd create 404; third create through a 2 token guard 200
2	Pending cap was count, provider call, insert	The count is a WHERE predicate inside the INSERT ... SELECT (and the reopen UPDATE); zero rows affected is the existing 429	TestRequestsCreate_PendingCapHoldsUnderConcurrency, TestRequestRepo_CreateCapIsAtomic (24 racers, cap 3, -race), TestRequestRepo_ReopenRespectsCap	pending 24 against a cap of 3
3	Create and withdraw in a loop sent a webhook each time	requestCreated for one (owner, kind, foreign id) at most once an hour, in memory, at most 4096 keys (expired dropped first, then the oldest)	TestRequestsNotify_RepeatWithinWindowSuppressed, TestRecentKeys_WindowAndBound	sent 5 requestCreated webhooks
4	local-only mode elevated a requester's cookie to admin; API key readable	auth.Middleware lets a valid session whose role is requester through as the requester before the mode grant, in every mode; OPDSAuth refuses a requester session before its disabled and local-only bypasses; GET /auth/config withholds the key when the named user's stored role is requester (narrowed in 88ef4c0c; admin and user as on main)	TestRequesterGuard_ModeNeverElevatesARequester (local-only and disabled: requester 403 on /queue, no key; role user in local-only still granted; anonymous local client still gets the key; API key still admin), TestRequesterGuard_OPDSModeNeverElevatesARequester, TestGetConfig_APIKeyNeverForRequesters	local-only requester GET /queue 204; /auth/config returned "apiKey":"k-requester-test"
5	Sanitiser only swapped @	notifier.SafeText (shared, in the notifier package): CleanText, then @ < > [ ] to fullwidth lookalikes. Covers <!channel>, <!here>, <@U123>, <@&role>, <link|label>, markdown links and images	TestSafeText_NeutralisesChatMarkup (one case per vector), TestRequestsCreate_SendsSanitisedRequestCreated	<!channel> [Free nitro](https://evil.example) passed through
6	/images unlimited for requesters	LimitImage, its own bucket: 240, then 4 a second, so a library page of 60 covers is unaffected	TestRestrictRequester_CreateAndImagesLimited	third image through a 2 token guard 200
7	A slow add could outlive the 5 minute claim; a second approve retook it	Checked first: createAuthorCore already runs the catalogue sync in a background job and returns once the author row exists; what stays synchronous is provider lookups and addBookCore's up to 15 s row poll, so completing earlier gains nothing. Instead each claim carries a random token and is renewed every third of the TTL while the add runs; renew, complete and release match the token. claimed_at is now milliseconds and 089 gains claim_token (089 has not shipped)	TestRequestsApprove_SlowCoreKeepsClaim (TTL 300 ms, add holds 1 s, second approve at 600 ms gets 409, one add), TestRequestRepo_ReleaseAndStaleClaim (a lost token cannot renew or release)	with the claim forced stale mid add: second approval 500, 2 adds
8	Case folded keys accepted	decodeStrict reads the object's keys first and refuses any key not exactly a field name	TestRequests_RejectCaseFoldedKeys	kind plus Kind answered 201

On item 7's before and after: with the claim forced stale by SQL (which bypasses renewal), the fixed code answers the first approval 409 rather than a 500 for either one, because the tokens stop the approvals completing or releasing each other's claims. What actually prevents a takeover is renewal, which TestRequestsApprove_SlowCoreKeepsClaim covers.

Items not taken: none.

API key narrowing, lint, and the second security review

API key narrowing (88ef4c0c). GET /auth/config now withholds the key only when the named user's stored role is requester, in every mode. Admin and user behave exactly as on main, including a role user session that local-only mode stamps admin: that session can regenerate the key, so hiding it would invite a rotation that breaks integrations. TestRequesterGuard_ModeNeverElevatesARequester now also checks that such a user session still receives the key, and TestGetConfig_APIKeyNeverForRequesters covers the matrix.

Lint (3a7de943). The required lint check (golangci-lint v2.11.4, golangci-lint run ./... with the repository .golangci.yml) failed with gosec G202 on internal/db/requests.go (request list query) and internal/db/requests_library.go (projection query). Reproduced locally with the same version, then fixed following the internal/db convention: a // #nosec G202 -- reason comment naming why no input reaches the SQL text (constants and fixed clauses only, every value bound). golangci-lint run ./... reports 0 issues.

The second review ran against 72209077 and found no guard bypass. The fixes are in c50830f8, 53789c3c and c3d27b3a. Fail before evidence ran base compatible copies of the tests against 3a7de943, then the same files against the fix.

#	Finding	Fix	Test	Before (3a7de943)
1	A panicking add core left the renewer running and the request in approving	defer stopRenew() (idempotent); a deferred recover releases the claim with its token and re-panics so Recoverer still logs	TestRequestsApprove_PanicReleasesClaim (pending again, 0 renewers running, second approval 200; the panic still reaches the caller)	status after a panicking approval approving
2	Role or epoch lookup failure let a valid requester cookie fall through to the mode grant	When the mode would grant admin but a correctly signed session's role or epoch could not be read, the request goes through as that user with no role: allow list only, RequireAdmin refuses	TestMiddleware_UnreadableSessionNotElevatedByMode (both failures, local-only), TestMiddleware_RequesterNotElevatedByMode (requester precedence in internal/auth, local-only and disabled, user keeps the grant)	both cases: local-only served GET /queue 200
3	Cycling create and withdraw over different ids sent one webhook per create	On top of the per item window, at most 10 requestCreated webhooks per requester per hour (in memory, bounded at 4096 owners); past that the webhook is skipped and one warning logged per hour. Requests are still stored	TestRequestsNotify_PerOwnerCap, TestOwnerBudget_WindowAndBound	15 ids cycled sent 15 webhooks
4	Bare URLs autolink in chat	SafeText replaces :// with : and two fullwidth solidi; backticks, underscores and similar are untouched	TestSafeText_BareURLsDoNotLink	https://evil.example/login kept
5	Dropping approving from the cap predicate survived every test	New repository test with a request in approving: create and reopen at the cap are refused	TestRequestRepo_CapCountsRequestsBeingApproved	with the predicate mutated to 'pending' only, the create was accepted

Rebased onto main

#2662 merged as 9b312bf8, so the three add core commits this branch was stacked on are gone from it; the branch now sits on main with git rebase --onto. Migration 089 needed no renumbering: main has 085, 087 (discovery) and 088 (adoption), and 086 is still claimed by two open PRs.

Conflicts, and how each was resolved:

Area	Resolution
internal/notifier/notifier.go, internal/models/notification.go, internal/db/notifications.go	Both events kept: the bookAnnounced constant, case and column stay, and requestCreated sits beside them. Every notification statement now carries on_book_announced, on_request_created
web/src/pages/settings/NotificationsTab.tsx, web/src/api/notifications.ts, en.json	Both toggles and both badges; the two save calls send both fields. The Request toggle gained aria-pressed, matching the New book toggle
web/src/App.tsx	One navLabel(item) renders both badges: the adoption count on Import and the pending count on Requests. navItemsFor keeps the requester shell and appends Requests for admins
web/src/api/client.ts	Both adoptionApi and requestsApi composed in
web/src/App.test.tsx	Both describes kept: the Import badge tests and the requester and admin nav tests, with both API mocks
README.md	Main's webhook line (which mentions new books found) kept, with the Requests bullet above it
docs/API.md	One eventType row listing bookAnnounced and requestCreated; the toggle paragraph names onBookAnnounced and onRequestCreated and both migrations
cmd/bindery/requester_routes_test.go	The route walk stub gained the adoption and diagnose methods, and the denied table names /library/unmatched* and /downloadclient/{id}/diagnose (3760cc96)

Discovery's announceText (in internal/api) and this PR's notifier.SafeText overlap: both strip control characters and cap length, but only SafeText neutralises mentions, Slack escapes, markdown links and URL schemes. I left announceText alone rather than change a merged feature's output here. Routing bookAnnounced through SafeText is a small follow up worth doing: an OpenLibrary title reaching that webhook can still carry @everyone.

Verification after the rebase: go build ./..., go vet ./..., Windows and darwin builds, go test ./cmd/... ./internal/... (exit 0), golangci-lint run ./... (0 issues), -race on auth, notifier, cmd/bindery, the request and notification tests in db, and the requester, requests, OIDC, OPDS, user management and add core tests in api, the smoke suite against a rebuilt binary, npx vitest run (92 files, 1054 tests), npx tsc -b, npm run build, and eslint (warnings only, all pre-existing).

Fail before evidence

The branch's tests use auth.RoleRequester and repository calls the base refuses, so I ran base compatible copies (string literals, the requester role written with SQL) against 11aefa67 (the tip of refactor/add-book-core), then the same files against this branch.

On the base:

--- FAIL: TestFailBefore_OIDCGroupSyncKeepsRequester
    Role="user", want requester (outside the admin group, not an admin, so unchanged)
--- FAIL: TestFailBefore_LastAdminToRequester
    SetRole(last admin, requester) err = invalid role "requester": must be admin or user, want the last admin refusal
--- FAIL: TestFailBefore_RequesterGuard
    requester POST /api/v1/queue/grab: status 204, want 403
    requester GET /api/v1/queue: status 204, want 403
    requester GET /api/queue: status 204, want 403
    requester GET /api/v1/book/7/file: status 204, want 403
    requester OPDS Basic: status 200, want 403

On this branch the same three tests pass. The OIDC one is plan item T8. The last admin case fails on the base for a different reason (the role is invalid there); the guard bug itself is latent until requester is valid, which is why the branch's TestSetRole_LastAdminCannotBecomeRequester and TestUserMgmt_SetRole_DemoteLastAdminToRequester exist. On the base a requester role row is read as a normal user, so every route answered.

Performance

• The allow list matcher is one chi tree built at init; a match is a tree lookup on the request path.
• The requester limiter is O(1) per call, with a sweep at most once per 10 minutes and a map capped at 1024 entries.
• GET /requests is two statements plus at most one grouped IN query per page for author progress.
• GET /requests/library is a count and one page query; series and format flags are correlated subqueries backed by idx_series_books_book and idx_book_files_book_id.
• Webhook delivery for requestCreated runs in a goroutine with a 30 s detached context, so a slow target does not hold up the requester.

Follow ups (not in this PR)

• The image cache has no total size cap. It predates this PR and affects role user as much as requesters; the requester bucket only slows a requester filling it.

• In disabled and local-only mode, a user session is still elevated to admin by the mode grant. This PR stops it only for requesters; changing it for user is a broader behaviour change.

• Repo wide replacement of the remaining "admin" and "user" literals with the constants (C2 says separate mechanical PR).

• A generic event set for notifications instead of one column per event (C7).

• Deferred by the plan: auto approve per user, quotas beyond the pending cap, per user notification targeting, proxy header role mapping.

• Profile and root folder choices for book approvals would need addBookParams to grow them.

Checklist

• Tests added or updated
• Doc-update gate cleared (docs/multi-user.md, docs/auth-oidc.md, docs/auth-proxy.md, docs/API.md, README Features)
• Changelog fragment changelog.d/requester-role.md

Test plan

• go build ./..., go vet ./...
• GOOS=windows go build ./..., GOOS=darwin go build ./...
• go test ./cmd/... ./internal/... (exit 0)
• -race: ./internal/auth ./internal/config ./internal/notifier ./cmd/bindery pass; ./internal/api for the requests, requester, OIDC, callback, user management, OPDS, settings and add core tests pass; ./internal/db for the request repo, migration 089, notification round trip and role tests pass. The whole ./internal/db package under -race hit the 10 minute default timeout on the shared machine (a timeout, not a failure), like internal/api in make test: internal/api race package hits the 30-minute timeout #2293
• go test -fuzz FuzzRequesterAllowList -fuzztime 60s ./internal/auth (2.3M execs, no failure)
• make smoke equivalent: binary built with the web assets, go test ./tests/smoke/... including the new requester case
• cd web && npx vitest run (86 files, 1018 tests), npm run build, npx tsc -b
• eslint on touched web files: no errors

🤖 Generated with Claude Code

https://claude.ai/code/session_016fJcCVbNnKsmj2MAAMwWj9

[codecov]

Codecov Report

❌ Patch coverage is 71.60386% with 324 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/api/requests.go	68.82%	127 Missing and 46 partials ⚠️
internal/db/requests.go	75.21%	33 Missing and 25 partials ⚠️
internal/db/requests_library.go	0.00%	41 Missing ⚠️
internal/api/opds_auth.go	25.92%	18 Missing and 2 partials ⚠️
internal/auth/requester.go	90.90%	4 Missing and 4 partials ⚠️
internal/auth/roles.go	0.00%	8 Missing ⚠️
internal/api/settings_handler.go	0.00%	6 Missing ⚠️
internal/api/requests_library.go	82.14%	3 Missing and 2 partials ⚠️
internal/api/auth_oidc.go	88.88%	1 Missing and 1 partial ⚠️
internal/auth/requester_limiter.go	96.07%	1 Missing and 1 partial ⚠️
... and 1 more

📢 Thoughts on this report? Let us know!

[github-actions]

Reviewed the requester role implementation. The two security-review passes have already addressed the main concerns. Three observations on what remains:

internal/api/opds_auth.go — limiter reset before role check

In the basic-auth path (around the limiter.Reset(ip) block), the per-IP login rate-limiter is reset before opdsRoleAllowed refuses a requester:

if limiter != nil {
    limiter.Reset(ip)        // fires for a correct-password requester
}
if !opdsRoleAllowed(w, u.Role) {  // refused here
    return
}

An OPDS brute-force originating from the same IP as a requester who knows their own password (or whose client retries automatically) will get the limiter counter reset on each of their successful auths, nullifying it for other users on that IP. Swapping the two blocks — refuse the role first, reset only if the user is allowed — closes it without touching normal paths. Low severity for a self-hosted install, but it's a one-line reorder.

internal/db/migrations/089_requests.sql — migration number

The PR body notes #2633 and #2607 both target 086. If either brings a follow-up at 087 or 088 before this merges, the numbering has a gap (migrations are applied in filename order and a gap is harmless, but it's easy to verify: ls internal/db/migrations | tail -5 before tagging).

In-memory notification dedup resets on restart

recentKeys (per-item webhook window) and ownerBudget (per-requester hourly cap) are process-local. After a restart a requester can immediately re-trigger requestCreated webhooks up to the burst limit. The code comments say "in memory"; the docs (docs/multi-user.md) don't surface it. Worth one sentence in the docs so operators aren't surprised after a container restart.

---

Everything else looks correct. The allow-list matcher's path-canonicality checks (raw path rejection, path.Clean, percent/backslash/control) are comprehensive. The claim-renewal token prevents the concurrent-approval race (TestRequestsApprove_SlowCoreKeepsClaim). Payload revalidation before the add core is tight. restrictedRole's fail-closed handling of empty roles (DB-error sessions held to the allow list) is right. decodeStrict with the reflection-based key check correctly covers the case-folding gap that DisallowUnknownFields leaves. The opdsSessionIsRequester early-exit before ModeDisabled is the correct placement.

— 🤖 Bindery triage bot (automated). Reply to correct me; a human will see it.