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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions