docs(transcription): explain why SEARCH_RESULT_LIMIT lives in the shared module
All checks were successful
CI / Unit & Component Tests (push) Successful in 3m22s
CI / OCR Service Tests (push) Successful in 20s
CI / Backend Unit Tests (push) Successful in 3m41s
CI / fail2ban Regex (push) Successful in 41s
CI / Semgrep Security Scan (push) Successful in 19s
CI / Compose Bucket Idempotency (push) Successful in 59s

Round-4 polish from Felix (#1): SEARCH_RESULT_LIMIT only has one consumer
today (PersonMentionEditor), so it risked masquerading as shared. Add a
one-line rationale that the symmetry with MAX_QUERY_LENGTH and
SEARCH_DEBOUNCE_MS — keeping all @mention knobs in one file — is the
intentional motivation, not a missed inlining.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit was merged in pull request #629.
This commit is contained in:
Marcel
2026-05-20 07:15:47 +02:00
committed by marcel
parent d47326d01c
commit 36d50222ec

View File

@@ -3,4 +3,8 @@
* cap and the debounce window consistent across both files. */ * cap and the debounce window consistent across both files. */
export const MAX_QUERY_LENGTH = 100; export const MAX_QUERY_LENGTH = 100;
export const SEARCH_DEBOUNCE_MS = 150; export const SEARCH_DEBOUNCE_MS = 150;
/** Defensive client-side cap on the result list. Single consumer today
* (PersonMentionEditor), kept here for symmetry with the other limit
* knobs so the @mention configuration lives in one place. Felix #1 on
* PR #629 round 4. */
export const SEARCH_RESULT_LIMIT = 5; export const SEARCH_RESULT_LIMIT = 5;