Make query term and clause limits configurable with bounded resource policy #63

Outcome

Make the current 64-term and 256-clause query ceilings configurable under explicit resource policy, preserving existing defaults and loud rejection above the effective limits.

Verified current behavior

Source inspection of the native protocol limits and query engine shows fixed MAX_QUERY_TERMS = 64 and MAX_QUERY_CLAUSES = 256. Selected fields and expansion can multiply compiled clauses, so a short query can exceed the clause ceiling. This is a configurable-capability request; no production incident or new runtime reproduction is claimed here.

Acceptance criteria

• Define validated configuration for analyzed-term and clause budgets, with 64/256 as backward-compatible defaults. Distinguish operator-controlled safety ceilings from caller-selected lower budgets; callers must not bypass host policy.
• Specify the scope of each budget: Boolean leaf counts, analyzed terms, field multiplication, synonym/fuzzy/prefix expansion, and structured-filter clauses. Preserve separate policies where the costs differ.
• Apply effective limits consistently across TypeScript normalization, packed/native decoding, query construction, search, traversal, tracing where supported, and expensive-query classification. Enforce bounds before excessive allocation or expansion.
• Report effective limits through capability metadata and actionable errors. Reject over-budget queries without silently dropping terms, fields, clauses, or expansions.
• Qualify memory, CPU, queue fairness, and deadline behavior with larger term counts, many selected fields, and concurrent expensive queries before allowing higher profiles.
• Add Rust/Node boundary and configuration-parity tests, retain existing defaults, and document compatibility and any index-reopen/rebuild implications. Query-policy changes should not change analyzer/index semantics accidentally.

Accepted implementation boundaries

Verified in Make analyzed query capacity configurable per handle: text-tree structure now follows the configured compiled-clause budget instead of an independent 256-leaf/child cap. Each AND/OR child costs one and NOT costs two before descendant allocation, including empty/stopword-only branches; native analysis enforces final cost. A 300-branch, single-term, single-field OR needs 600 clauses. Facade normalization and native admission use the handle policy; standalone decoding uses the supported 4,096-clause ceiling; direct Rust searches prewalk before analysis. Depth eight, raw-text/request byte bounds, structured-filter 256 bounds and phrase/fuzzy construction guards remain separate.

Raised-policy handles conservatively route non-ASCII text through expensive admission because normalization can expand text. This is an accepted policy constraint; a less conservative estimate remains unqualified. The unintended summing of terms across independent leaves and the missing Boolean/NOT construction costs are fixed in the admission follow-up.

The earlier fixed text-structure disposition is superseded by the host-derived policy; the marker below is retained as review history. Higher profiles still require consumer workload qualification. Node/input-byte bounds are not exact heap accounting: repeated field lists create owned strings during decoding, and the finite 16-field fixture does not qualify a maximum-width schema.

Review-Deferral: 143217e712f68ef2 severity=nit category=maintainability
Review-Deferral: 0cbd7b3d7c1a0002 severity=nit category=performance

Manual raw-handle wrappers report and preflight using the caller-supplied policy, as documented in the library API. The public writer/reader factories supply the matching configuration; a manual mismatch fails closed. Reading effective policy back from native remains an optional boundary refinement, not part of Harper adoption or a demonstrated policy bypass.

Review-Deferral: de12ac4323b63cea severity=nit category=correctness

Scope and priority

Parent: Epic: Extend fulltext search capabilities beyond the initial wrapper API.

Autocomplete result/expansion qualification and continuation remain in Add bounded deep-result traversal and qualify autocomplete limits. Harper configuration plumbing and product API integration are follow-up consumer work; this issue owns the native library contract.

Proposed backlog capability with no committed release. P3 follows the parent backlog and the absence of a specific committed roadmap dependency or blocked customer. Effort: High because the policy crosses the public/native contract, query planning, and workload qualification. No customer or security incident is associated with this request.

Comment generated by kAIle (GPT-6)