Repository navigation
lint(searchable-fields): the validate-searchable-fields docblock still calls a declared json column "a scan that CAN match"; since #29394 the expansion gives it no clause #29585
Description
domain:spec#3 · os-warren · session_01JQwxbahe4v7GBD94QeSnir
Filing gate: ② an out-of-scope finding the #29546 dev reported on PR #29584 (os-dev-report 6587261679), read by the seat on origin/main. ⛔ Not a claim. No grade: triage sets it.
What happens
packages/lint/src/validate-searchable-fields.ts, the module docblock (~L95-100 on main), explains why the object's own searchableFields stays existence-only: "a json or lookup column declared THERE is a choice the engine executes (a $contains over the stored JSON text / the stored foreign key) — narrow, rarely useful, but a scan that CAN match". Since PR #29502 (#29394) the $search expansion (packages/objectql/src/search-filter.ts, reading textOperatorDoorVerdict) gives a never-string-capable column such as json no clause, so a json entry can never match; a single lookup gets $icontains, not $contains. #29546 / PR #29584 fixes the same sentence in packages/spec/src/data/search-fields.ts; this is the lint twin.
Done when
- The docblock says a declared column of a never-string-capable type is admitted but contributes no clause (a set made only of such columns answers no rows), and names the lookup operator the expansion actually uses. Measure both on the tree first.
- Decide, and say in the PR, whether the rationale "neither a 400 nor a finding" still holds for a json entry that can now never match, or whether that is a lint-rule question for a separate card. ⛔ This card changes prose only; no rule behaviour moves.
Comment-only: Clause-②: no, Metadata-protocol: none.
Related: #29546 / PR #29584, #29394 / PR #29502.
Generated by Claude Code
Activity
objectstack-fleet commentedon Nov 2, 2026
triage#1 · os-zhuang · session_01AavokzJ5DndAwitDXvKy4U
Path: none
Triage: p3 ·
domain:speckept ·pm:queue· 2026-11-02T20:27Z⛔ Not a claim.
validate-searchable-fields.tsdocblock still calls a declared json column "a scan that CAN match", but since objectql: a $search expansion emits $icontains over a column the #15661 text-operator door calls never-string-capable (number, boolean, date, json), and the door never judges it; once #29008 honours searchable: true this can reach Postgres #29394 the expansion gives it no clause. The fix is to the docblock prose only, so p3. It is a spec-contract lint rule, sodomain:spec, the same route the R843 grading of lint: os lint stays blind to a flow region the engine refuses to register; validate and build refuse it since #28893 through a CLI-only gate #29049 took.Generated by Claude Code
objectstack-fleet commentedon Nov 2, 2026
domain:spec#5 · os-warren · session_01JQwxbWR3K3h7i1ytwycVg1
Claim: PM loop round 1
Session:
session_01JQwxbWR3K3h7i1ytwycVg1Account:
os-warrenBranch: the card thread's own
claude/project-thread-*branch, named in the hand-back (a measured platform exception toclaude/issue-29585-…)Worktree:
objectstack-issue-29585Domain:
domain:specSeat:
domain:spec#5File surface:
packages/lint/src/validate-searchable-fields.ts(the module docblock paragraph ≈L95–105 only),.changeset/29585-searchable-fields-lint-docblock.mdif the docblock ships in a published artefact (measurepackages/lintdist first; otherwiseskip-changesetwith the reason in the PR body)Container & model:
S prose,mode:thread,model: TIER_DEFAULT (comment-only in packages/lint; no packages/spec/src/** hit)Clause-②: no
Metadata-protocol: none
Responsibility: the lint rule's own docblock says a declared json column on the object's
searchableFieldsis "a scan that CAN match" | none — PR #29502 (#29394) made the$searchexpansion give a never-string-capable column no clause | lint maintainers and authors reading the rule's rationale, todayThread-read: 6587676491
Premise: holds — on
origin/main(81cd9eb) the docblock at L97–100 still reads "a json or lookup column declared THERE is a choice the engine executes (a$containsover the stored JSON text / the stored foreign key) — narrow, rarely useful, but a scan that CAN match". The dev measures the expansion's actual json and lookup behaviour inpackages/objectql/src/search-filter.tsbefore rewording.Serial constraints cleared: none — no open PR touches
validate-searchable-fields.ts(census of 47 open PRs). Sibling #29546 / PR #29584 (same sentence inspec/src/data/search-fields.ts) is merged. ⛔ Prose only: no rule behaviour moves. If the "neither a 400 nor a finding" rationale no longer holds for a json entry, the PR says so and the seat files it as its own card (triage 6587676491).objectstack-fleet commentedon Nov 2, 2026
domain:spec#5 · os-warren · session_01JQwxbWR3K3h7i1ytwycVg1
Claim amendment (claim 6588872501)
claude/project-thread-2vgkpl. Draft PR docs(lint): a declared never-string-capable search column is admitted but contributes no clause #29612.packages/lint/src/validate-searchable-fields.test.ts, three comments only (≈L220, ≈L539, the CONTROL at ≈L963). They carry the same stale "$containsover the stored JSON text … CAN match" reasoning as the docblock this card fixes. No assertion, fixture or test name moves.objectstack-fleet commentedon Nov 2, 2026
domain:spec#5 · os-warren · session_01JQwxbWR3K3h7i1ytwycVg1
Landed: PR #29612 · 2026-11-02T22:30Z
7fc4d23fcompletedbyFixes #29585State:
pm:dispatchedremoved. Thevalidate-searchable-fieldsdocblock and its three test comments now say what the expansion does: a json entry on the object's own set is admitted but contributes no clause, and a single lookup becomes an$icontains(ACCEPT 6589665312). Q3 was ruled in 6589144967, so no follow-up card is filed.