trimmedMinLengthPattern: unstated invalid-input domain (min=0 behaves as min=1)

[pnocera]

Found by an independent Codex review (round 6) of the Bun migration branch. Deferred from that branch: it is not a present behaviour bug, only a latent one.

What's wrong

trimmedMinLengthPattern(min) (src/types.ts) is the single source both halves of the contract read — the published JSON Schema pattern and the Zod refinement — so they can't drift. The formula (\S[\s\S]{n-2,}\S) is correct for positive integer minima, and the current min = 3 role behaviour is aligned on both sides and covered.

But the exported function accepts every number:

• min = 0 silently returns \S — rejecting the empty string as though the minimum were 1
• fractional and non-finite values produce nonsensical quantifiers rather than a clear failure

Current callers only pass 3, so nothing is broken today. The helper's general name and export overstate its safe domain.

Why it matters

The next schema that reuses the helper with a computed or zero minimum can publish a stricter or unusable contract without an obvious error — while the existing role-only agreement matrix stays green.

Location

src/types.ts — trimmedMinLengthPattern. Indirect coverage only, via the min = 3 call site (tests/transport/tools.test.ts, tests/unit/strict-validation.test.ts).

Recommended fix

Declare and enforce the intended domain:

• if it's for required strings, throw new RangeError unless min is a positive integer
• if zero is meant to be supported, return a pattern that accepts every string

Tests to add

Direct table tests for 1, 2, 3, a larger integer, 0, a negative, a fraction, NaN, and Infinity — rather than proving the helper only through its one min = 3 call site.