fix S4.1 placeholders and S5 boolean mapping toward dialect-neutrality (Sean ruled dialect-free; SQLite-family recommendation withdrawn)

[ssilvius]

RULING ALREADY MADE -- this issue previously asked for it and asked for the wrong thing

Sean, 2026-07-28, verbatim: "this whole idea is dialect free." http-sql is dialect-free by design. Nothing is blocked on an operator decision.

This issue as originally filed recommended declaring the spec SQLite-family and asked @sean to rule. That recommendation is WITHDRAWN, and it was filed from a platform reflection (019faafb-7944) written before the ruling. Recording why it was wrong so nobody re-derives it:

The recommendation read sloppy labels as load-bearing semantics. The spec is transport -- it never parses the SQL (README.md:38 disclaims dialect normalization as an explicit non-goal), and the client writes whatever its target speaks. Nothing structurally breaks on Postgres:

• lastInsertId (S6.1:120) is already OPTIONAL and null-when-unavailable, which is correct for Postgres (it uses RETURNING).
• atomic (S4.2) works better on Postgres than on D1 -- real interactive transactions exist there.
• The tagged types (S5: blob base64, bigint decimal-string) are already dialect-neutral encodings.

So the finding survives, inverted: the spec has two spots of SQLite-flavoured text that should be fixed toward neutrality, not codified. That makes README.md:29's vendor-neutral goal true rather than aspirational, and lets implementations.md:32 keep soliciting Postgres honestly.

THE TWO FIXES

1. S4.1:49 -- wording only, no behavior change

Current: "params (OPTIONAL, array) -- positional parameters, in the order of ? placeholders in sql."

The normative content is the ordering rule. The ? is incidental and does not describe a $1-dialect server. Replace with language that names the ordering and leaves placeholder syntax to the dialect -- e.g. "in the order of the positional placeholders in sql", with a non-normative note that the placeholder syntax is the server's (? in SQLite/MySQL, $1 in PostgreSQL).

2. S5:70-78 -- the real leak, and it has a behavioral consequence

The type table maps JSON values to TEXT / INTEGER / REAL, which are SQLite type affinities rather than a general SQL type system. Most rows transfer fine as semantics. One does not:

JSON value	current mapping
boolean	INTEGER (1 or 0)

A PostgreSQL server following that row literally binds an integer into a boolean column and fails. This is not a naming quibble; it is a conformance defect for any server with a native boolean type.

Fix: express the mapping column as the server's corresponding type -- text, integer, real, boolean, null -- rather than as SQLite affinity names. SQLite-backed servers continue to store booleans as 1/0 because SQLite has no boolean type, but that becomes an implementation detail of those servers rather than a normative instruction to every server.

ACCEPTANCE CRITERIA

1. S4.1 no longer names ? as normative; the ordering rule is stated dialect-independently.
2. S5's type table maps boolean to the server's native boolean type, with the SQLite 1/0 representation noted as an implementation detail rather than the rule.
3. S5's remaining rows are expressed so a non-SQLite server can conform without reinterpretation.
4. README.md:29's "Vendor-neutral" goal is left unchanged and now accurate -- do not weaken it to "within the SQLite family."
5. implementations.md:32 keeps Postgres in the backend invitation.
6. A short note in S1 or S12 stating that the spec does not normalize dialects and carries whatever SQL the client writes -- making the existing README.md:38 non-goal normative where it belongs.
7. Per S11, these are clarifications plus one type-mapping correction. State in the PR whether the boolean change is treated as additive-minor or as a breaking fix, and justify it -- an existing SQLite server's behavior does not change, but a client that relied on receiving 1/0 from a boolean column on a non-SQLite server would.

DOWNSTREAM

• smugglr keeps the http-sql client profile and inherits no new constraint; it targets SQLite-family backends by design.
• fence names http-sql v0.1 as its wire format (architecture-v1 S1a). Fixing toward neutrality widens what fence can claim rather than narrowing it, which is the opposite of the withdrawn recommendation's effect. No operator gate needed.

PROVENANCE NOTE

Filed by the astro-data seat from a platform reflection that predated Sean's ruling. Both seats share the platform persona, so a stale artifact read by one seat became a decision request to the operator from the other. Rewritten by platform from the http-sql seat, 2026-07-29. The corrected position is in this seat's operating contract (019fabbd-dbf6).