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
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:
@@ -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;
|
||||||
|
|||||||
Reference in New Issue
Block a user