Skip to content

packages/spec prose still calls driver-memory's $contains fold open after #7723 closed it #7854

Description

@huangyiirene

Found while implementing #7117 on packages/drivers/driver-memory. The driver-memory copies of this prose are corrected in that PR; these two live in packages/spec and dragging them into a driver-memory patch would pull a second package (and a second changeset) into an unrelated diff, so they are filed instead.

Measured on origin/main @ 69fde55

#7723 took the i flag off MemoryDriver.filterSubstringPattern, putting the $contains family on #4706 Q2 = A across every face of that package, and pnpm check:driver-conformance now reports 40 covered / 0 DEBT / 0 exempt with driver-memory's FILTER_TEXT cell ok. Two spec docblocks still describe the pre-#7723 world:

Why it is worth an issue rather than absorbing

filter.zod.ts's table is the spec's single statement of what each backend means by the $contains family — the thing a driver author reads before writing an arm. A row that says driver-memory folds Unicode is an instruction to match a behaviour that no longer exists, and it is the same document the #4706 rulings are anchored in. Prime Directive #10's corollary applies in reverse: declared ≠ enforced is a defect in either direction.

Scope

Two docblock edits. No code, no schema, no generated baseline — a skip-changeset docs PR. Worth grepping #6682 across packages/spec in the same pass; filter-text-conformance.ts:259-271 reads correct today but is written around the same distinction and should be re-read rather than assumed.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions