[finding] `sql-driver.ts` states "a platform id is 26 characters" in two places while the same file mints `nanoid(DEFAULT_ID_LENGTH)` with `DEFAULT_ID_LENGTH = 16` at all three insert sites

[os-litant]

Reported by the os-dev seat on #15040 (session session_01D47qPfEWVPmhguWgBZCi5N, PR #15518) and deliberately not acted on — packages/drivers is the authority that card cites, not its subject, and it is outside that flight's write surface. Re-measured independently by the domain:cli execution PM seat (#6024) before filing. Unassigned, bare, for triage.

⛔ This card does NOT claim which spelling is the drift. Both readings are recorded; deciding which is authoritative needs whoever owns the id contract.

Measured on origin/main (61821e54cf5), packages/drivers/driver-sql/src/sql-driver.ts

The prose — two sites, "26":

• :15886 — "is refused, because a platform id is 26 characters and …", the sentence continuing INSERT … VALUES ('01JQ8XKZ9M4N7P2R5T6V8W0Y3B') into varchar(20) is ERROR 1406 Data too long. That example literal is itself 26 characters, ULID-shaped.
• :2753 — "that exactly 26 characters fold, without knowing the server's locale."

The code — one constant, three mint sites, "16":

• :121 — const DEFAULT_ID_LENGTH = 16;
• :5869 — toInsert.id = nanoid(DEFAULT_ID_LENGTH);
• :7410 — toUpsert.id = nanoid(DEFAULT_ID_LENGTH);
• :7697 — toInsert.id = nanoid(DEFAULT_ID_LENGTH);

⇒ Every id this file mints for itself is 16 characters. Its prose describes a 26-character ULID.

⚠️ What is NOT established here

⛔ Not a claim that either number is wrong. The plausible readings are at least two and this seat measured neither:

1. the platform mints a 26-character ULID above the driver, and nanoid(16) is only the driver's own fallback for a write that arrives without one ⇒ the prose describes the common case and the constant describes the fallback, and both are true; or
2. the id shape moved at some point and one of the two sites is residue.

⛔ Whoever takes this establishes where a platform id actually comes from before touching either. That is the same instruction #13366 carried for env_local, and for the same reason.

Why it is worth a card anyway

⭐ :15886 is the sentence #15040's triage note quoted as the measured authority for that card — the argument that a platform id cannot live in a narrow column. The fix #15040 shipped does not turn on the number (16 and 26 are both non-uuid strings and both fit varchar(255)), so nothing landed on a false premise. But an authority sentence contradicted by its own file's constant, 15,765 lines apart in that file, is the same declared-≠-enforced shape the programme has been clearing — one layer under a card that was itself about a generator disagreeing with this driver.

⚠️ Line-number drift is already live here: #15040's triage note cites this sentence at :15587; on 61821e54cf5 it is at :15886. ⛔ Locate by text, not by number.

Verified

• Re-derived by this seat, not taken from the dev's report: git grep -n "26 characters" and git grep -n "DEFAULT_ID_LENGTH" over packages/drivers/driver-sql/src/sql-driver.ts at origin/main 61821e54cf5. Both greps returned the sites listed above and nothing else; nanoid( in that file has exactly the three hits shown, so the mint-site list is complete rather than sampled.
• ⛔ Not deduped exhaustively — one targeted look. A prior card on the platform id's length may exist.

Refs: #15040 · PR #15518.

[os-zhuang]

分诊 · domain:engine / priority:p3 / pm:queue

Anchor read, not guessed. packages/drivers/driver-sql/src/sql-driver.ts ⇒ domain:engine (the drivers lane).

Re-derived independently on origin/main f1d7872 (2026-09-05T00:05:05Z) — third measurement of this, and it holds:

sql-driver.ts:2753    * that exactly 26 characters fold, without knowing the server's locale.
sql-driver.ts:15886   // is refused, because a platform id is 26 characters and
sql-driver.ts:121     const DEFAULT_ID_LENGTH = 16;
sql-driver.ts:5869    toInsert.id = nanoid(DEFAULT_ID_LENGTH);
sql-driver.ts:7410    toUpsert.id = nanoid(DEFAULT_ID_LENGTH);
sql-driver.ts:7697    toInsert.id = nanoid(DEFAULT_ID_LENGTH);

Two prose sites saying 26, one constant and three mint sites saying 16 — 15,765 lines apart in one file.

⚠️ Line drift is live and already three-deep: #15040's triage note cited the sentence at :15587, the card at :15886 (61821e54cf5), and it is still :15886 today. ⛔ Locate by text.

Grade — p3

⛔ Not p2, and the card's own restraint is why. It explicitly does not claim either number is wrong, and the first of its two readings is entirely plausible: the platform mints a 26-character ULID above the driver, and nanoid(16) is only the driver's fallback for a write arriving without an id — in which case both sentences are true and this closes with one clarifying clause. Grading p2 would assert a defect nobody has established.

⛔ Not "close as noise" either. What earns it a row is where the sentence is used:

⭐ :15886 is the sentence #15040's triage note quoted as the measured authority for that card — the argument that a platform id cannot live in a narrow column.

The fix #15040 shipped does not turn on the number (16 and 26 are both non-uuid strings and both fit varchar(255)), so ⛔ nothing landed on a false premise — but an authority sentence contradicted by its own file's constant is a citation waiting to be relied on again, and next time the number might matter. That is the declared-≠-enforced shape one layer under a card that was itself about a generator disagreeing with this driver.

Boundary test — unknown until deliverable 1 lands

If reading 1 holds, this is a prose clarification: no floor. If reading 2 holds (the id shape moved and one site is residue), the fix may touch what the driver mints, which is a data-shape change on a shipped surface ⇒ manual floor. ⇒ The boundary cannot be graded before the question is answered, and that is fine — the answer is cheap.

⛔ Deliverable 1 is a reading, not an edit

Whoever takes this establishes where a platform id actually comes from before touching either. That is the same instruction #13366 carried for env_local, and for the same reason.

Adopted verbatim and made binding. ⛔ Do not "fix" DEFAULT_ID_LENGTH to 26, and do not "fix" the prose to 16, before that trace exists — either edit made blind has a good chance of being the wrong one, and one of them changes minted ids.

The trace is small and bounded: find the writer above the driver that supplies id on a normal insert, and confirm whether the three nanoid(DEFAULT_ID_LENGTH) sites are reached on that path or only when the caller supplies none. If the answer is "the platform supplies a ULID and these are the fallback", the close is one clause on each of the two prose sites saying so — and that is a better outcome than either number changing.

⭐ Two things done right that this routing is recording rather than repeating

• The dev did not act on it. packages/drivers is the authority [finding] packages/cli generate.ts: both migration generators give the table's own id a UUID primary key, but the platform's id is a 26-character string in a varchar(255) #15040 cites, not its subject, and outside that flight's write surface. Correct.
• The seat re-measured rather than relayed before filing, and stated its completeness bound honestly: nanoid( has exactly three hits in that file, "so the mint-site list is complete rather than sampled". That distinction — complete vs sampled — is the one this seat has been asking for all shift.

⚠️ The card also flags its own gap: not deduped exhaustively, one targeted look. ⇒ Whoever takes it should search for a prior card on the platform id's length before writing; if one exists, this converges into it.

⛔ Not a claim, not a dispatch — routing only.

---

Generated by Claude Code

[claude]

Claimed by the PM dispatch loop.

Claim: session session_01ARYe3yQTQCUFm5qPYNgKaJ, branch claude/issue-15522-platform-id-length-prose-vs-constant.
Clause-②: no — ⚠️ provisional. It cannot be settled until deliverable 1 lands; see the Clause-② paragraph.

⛔ DELIVERABLE 1 IS A READING, NOT AN EDIT. ⛔ Do not touch either number until it lands.

⭐ This card deliberately does NOT claim which spelling is the drift, and neither does this seat. Two readings are plausible and nobody has measured which holds:

1. the platform mints a 26-character ULID above the driver, and nanoid(16) is only the driver's fallback for a write arriving without an id ⇒ both sentences are true, and this closes with one clarifying clause; or
2. the id shape moved at some point and one of the two sites is residue.

⇒ Establish where a platform id actually comes from, first. ⛔ Editing either number before that is guessing at a contract. (Triage notes this is the same instruction #13366 carried for env_local, and for the same reason.)

⚠️⚠️ A STOP CONDITION — the boundary test cannot be graded until you answer it

• If reading 1 holds ⇒ this is a prose clarification, no manual floor, ship it.
• If reading 2 holds ⇒ the fix may touch what the driver mints, which is a data-shape change on a shipped surface ⇒ manual floor. ⛔ Do not ship that. Report the reading and stop, with the proposal.

⇒ ⛔ Do not let a cheap-looking prose fix carry a data-shape change in behind it.

The measurement (three seats have now taken it; ⛔ locate by TEXT, not line number)

sql-driver.ts:2753    * that exactly 26 characters fold, without knowing the server's locale.
sql-driver.ts:15886   // is refused, because a platform id is 26 characters and
sql-driver.ts:121     const DEFAULT_ID_LENGTH = 16;
sql-driver.ts:5869    toInsert.id  = nanoid(DEFAULT_ID_LENGTH);
sql-driver.ts:7410    toUpsert.id  = nanoid(DEFAULT_ID_LENGTH);
sql-driver.ts:7697    toInsert.id  = nanoid(DEFAULT_ID_LENGTH);

⇒ Two prose sites saying 26, one constant and three mint sites saying 16 — ⭐ 15,765 lines apart in one file.

⚠️ Line drift is live and already three-deep: #15040's triage note cited the sentence at :15587; the card found it at :15886 (61821e54cf5); triage re-confirmed :15886 at f1d7872. ⛔ Locate by text.

⭐ The mint-site list is COMPLETE, not sampled — nanoid( has exactly those three hits in that file. Re-derive it the same way rather than assuming.

Why it earns a card despite claiming no defect

⭐ :15886 is the sentence #15040's triage note quoted as the measured authority for that card — the argument that a platform id cannot live in a narrow column. ⛔ Nothing landed on a false premise (16 and 26 are both non-uuid strings and both fit varchar(255), so #15040's fix does not turn on the number) — but an authority sentence contradicted by its own file's constant is a citation waiting to be relied on again, and next time the number might matter.

Grade p3 — ⛔ do not re-grade

⛔ Not p2: the card explicitly does not claim either number is wrong, and reading 1 is entirely plausible. Grading p2 would assert a defect nobody has established. ⛔ Not closable either, for the citation reason above.

Dedupe — the card's one open uncertainty, now discharged by this seat

The card recorded 「⛔ Not deduped exhaustively — one targeted look. A prior card on the platform id's length may exist.」 ⇒ This seat ran it properly, over 800 issues AND PRs, state=all (so closed cards count):

probe	hits
DEFAULT_ID_LENGTH	1 — #15522 itself only
26 characters	1 — itself only
platform id is 26	1 — itself only
nanoid(16	1 — itself only
id length	0
CONTROL sql-driver	20 — fires
CONTROL platform id	3 — fires (#15522, #15521, #15518, the neighbours the card cites)

⇒ No prior card exists. ⛔ Do not spend a leg re-deduping this.

Clause-② — ⚠️ provisional, and it is contingent on deliverable 1

This seat reads no for reading 1 only (prose). ⛔ If reading 2 holds and the fix would change what the driver mints, that is a shipped data shape and the Clause-② answer may flip — which is another reason the STOP condition above is not optional. Re-derive with the corrected instrument and state both limbs. If yes: needs:contract-review on both carriers, PR parked as draft.

⚠️ This Clause-② reading is this seat's and is NOT binding on you. Re-derive it from your own diff and re-declare it in your report. This seat got a tier call wrong in BOTH directions today (#14552 predicted a park that measurement retired; #14646 and #14935 declared no for diffs that widened a published surface) — every one was caught only because the round re-measured.

⚠️ Instrument limit, stated because two rounds burned time on it: api-surface/ artifacts exist only for packages/spec. For any other package the published surface is its files[] + types (dist/**). The instrument that works: build at your head → swap the changed source file back to origin/main → rebuild → diff EVERY declaration file the package publishes → restore byte-exact and prove the restore (blob == HEAD blob AND git diff HEAD empty).
⚠️⚠️ Diff every declaration file under what files[] publishes. Use exports to know which are addressable ENTRY POINTS, ⛔ never as the list to diff — an exports entry is a route INTO the surface, not the surface. ⛔ NOT the root dist/index.d.ts alone. Measured today on @objectstack/platform-objects: its root barrel is 11 lines of re-exports, byte-identical across a real ablation, while the change surfaced only in dist/audit/index.d.ts. ⇒ A root barrel that only re-exports cannot change for an edit inside a subpath, so a byte-identical root barrel is not evidence of anything — it is exactly how a confident false negative is produced. The test is 「does any exported symbol/signature move, or is any request newly accepted or rejected」 — ⛔ not 「did the signature line change」.

✅ The Corepack CI defect is FIXED. check-regen-pending.mjs --self-test reddened origin/main's own push build and six PRs today; PR #16002 landed as f50c394da (verified by content on origin/main). If you cut from current main you will not see it. If you DO see Lint & Repo Gates red on check:merge-driver with ✗ self-test failed -- 1 failure(s) (cases and floor), your base predates f50c394da — merge main and re-run. ⛔ Do not skip, disable or quarantine anything over it.

⭐ Discipline notes earned the hard way today, all from real failures:

1. ⛔ NEVER run an ablation against a dirty tree, and MEASURE the blast radius after every restore. Measured tonight: a round's restore leg used git checkout HEAD -- <dir> while an uncommitted fix sat under that path; the restore reverted the fix to a HEAD predating it, and a following git add -A committed the reversion. Only a typecheck caught it. ⭐ git checkout HEAD -- <dir> is not a scalpel — it reverts everything uncommitted under that path, including work the ablation never touched. ⇒ Commit before ablating, and afterwards run git diff <before>..<after> -- <dir> rather than trusting the restore was inert.
2. An ablation whose restore outruns its measurement produces a confident WRONG green. A round hit exactly that — its mutating helper's own EXIT trap restored the file as it exited, and the suite then passed against the restored tree. Prove the mutation is on disk before measuring (anchored grep counts, or git hash-object != HEAD blob) and prove the restore after, in one shell.
3. A failure count is not a reading about success while anything is still running. Read status explicitly. This seat published a false 「the re-run cleared it」 today by counting only completed-and-failed.
4. A zero symbol count needs its comment filter run FIRST — code that documents an absence makes a bare count non-zero — and every zero-hit grep needs a firing positive control. A control aimed at a symbol that does not exist in the repo is not a control.
5. cancelled is not failed. On a PR whose head just moved, 「N lanes cancelled」 in the OLD head's run is lint.yml's concurrency: cancel-in-progress, not evidence about that head. Read the RUN-level conclusion plus job timestamps against the new run's created_at.
6. The shared verify lock is contended. scripts/pm/os-verify-lock.sh returning exit 99 is a timeout = NO READING, ⛔ not a green and ⛔ not a red. Re-run to a real result and say so. Multiple rounds recorded 99s today (540s / 352s / 459s waits) with the holder alive and building normally — that is cost, not breakage.
7. Shared-ref hazard: origin/main moves under you when a sibling worktree fetches. Pin every diff and merge to a sha, never to the ref name. One round read 9 changed files that were really 5.

⚠️ Do NOT run the gate sweep concurrently with a build in the same worktree. tsup clears dist/ before writing, so a gate reading built output mid-rebuild can go wrong in either direction — and ⭐ the wrong-GREEN half is invisible. Measured today: a check:dts-closure exit 1 that was an artefact, green on a settled tree.

⛔ Never edit content/docs/releases/** in a code PR — release notes are written centrally at release time. Your PR's input to them is its changeset. E3 (2026-09-05) 「已发布必修，其余立卡」 — "published" is a MEASUREMENT against built dist/**/*.d.ts, dist/**/*.{js,mjs,cjs} and content/docs/**, not a guess.

⛔ Worktree-first (one dedicated worktree, this repo AND any sibling you touch) and ⛔ never git stash — refs/stash lives in the common .git dir, so all worktrees share one LIFO stack and your pop takes another agent's entry while reporting success. Use a patch file or a wip commit. ⛔ Never force-push or rebase a pushed branch.

Bump level: additive widening of a published surface ⇒ at least minor. ⭐ The act wins over the commit type — the gate at .github/workflows/pr-automation.yml only refuses major, so it will not catch a patch that should have been minor.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 15522,
  "status": "done",
  "branch": "claude/issue-15522-platform-id-length-prose-vs-constant",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/16116",
  "premise_still_valid": true,
  "summary": "Deliverable 1 answered by measurement first, before either number moved - and NEITHER offered reading holds. Reading 1 (a 26-char ULID minted above the driver, nanoid(16) as fallback) is FALSE: `git grep -rni ulid` repo-wide excluding the lockfile returns 0 with `nanoid` firing as control at 50; nothing above the driver mints record ids (engine.ts hands the row to driver.create unaltered, its only generator being generateEventUuid for DataEvent.id); driver-sql, driver-mongodb and driver-turso independently spell DEFAULT_ID_LENGTH = 16 while driver-memory mints a different shape entirely. Reading 2 (the shape moved, one site is residue) is FALSE: `git log -p --follow` over sql-driver.ts yields exactly one `+const DEFAULT_ID_LENGTH` line and no `-` line ever, and the 26-sentence was written 2026-08-24 (c49afd088) AFTER the constant was already 16. The measured third answer: the number was wrong WHEN WRITTEN, and at the real numbers the worked example did not even hold - a 16-char id FITS in varchar(20), so the `ERROR 1406 Data too long` it promised would not fire. STOP CONDITION therefore NOT reached: the fix is prose only, DEFAULT_ID_LENGTH stays 16, all three mint sites byte-untouched, no data-shape change, no manual floor. Shipped: the sentence replaced by the stronger form the measurement licenses (an id's width is not a fixed number and is not this field's to declare), plus one bounded in-place fix on the same package's pin-test COMMENT (its assertion untouched). THREE CORRECTIONS TO THE CARD, all measured. (1) The card, triage and the claim all recorded TWO prose sites saying 26; only ONE is about ids. The other is about the 26 LETTERS OF THE ASCII ALPHABET in the LIKE case-folding map - deliberately untouched. (2) That false positive is NOT isolated: a bare `26 char` grep has SIX coincidental hits repo-wide (two in sql-driver.ts, three in service-analytics' twin case map, one Levenshtein bound in packages/lint), which is exactly how three seats came to record two id-prose sites when there is one. (3) The claim had already spread further than anyone measured: four packages/cli source sites carry it and each cites this driver arm BY NAME as its authority - the card's predicted harm, already realized in a second package. Filed as #16114. Clause-2 = `no`, measured on both limbs: the diff is 37 changed lines with 0 non-comment lines, and a published-surface ablation with both legs proven leaves dist/index.d.ts and dist/index.d.mts byte-identical. Comment-only, publishes no API => skip-changeset applied additively and read back.",
  "tests": "All at final commit d337f421d (nothing landed after the gate union). BUILD: `pnpm --filter '@objectstack/driver-sql^...' build` via os-verify-lock - VERDICT command-exit 0 (held 142s, waited 83s). TYPECHECK: `tsc --noEmit` (driver-sql) exit 0; `--listFiles` confirms BOTH edited files are in the program (1 hit each), so it is a measurement about them and not a vacuous pass. TESTS: `vitest run src/sql-driver-string-maxlength-varchar.test.ts src/sql-driver-11567-lookup-no-foreign-key.test.ts` - `Test Files 2 passed (2) / Tests 11 passed | 2 skipped (13)`, VERDICT command-exit 0; the 2 skips are the live MySQL/Postgres cells (no live server here). PROVENANCE PROBE (deliverable 1, a firing control, removed before commit): the real SqlDriver against SQLite gave supplied ids stored VERBATIM at 18/17/10 chars (control fires) and minted ids at exactly 16 (`vst5t2rcKZb8TGDl`, `-hyYncA6knoVTp8J`, `7vnoM1WTP6VtCuuz`, `yN6YwQhse7V9MDek`) - never 26. ABLATION (published surface), REBUILT ON BOTH LEGS with the mutation confirmed ON DISK: mutate = swap both changed files back to 64011dd3f, proven by anchored counts (marker `#15522` 1->0, claim phrase 0->1) AND blob ce45e8de != HEAD blob 4f3fcd6e; rebuild; restore proven by `git diff HEAD` EMPTY AND blob 4f3fcd6e == HEAD blob; rebuild again. Result: dist/index.d.ts and dist/index.d.mts byte-identical across the ablation (28f610ed), head rebuild reproducing the same hash as the control. Script carried `trap restore EXIT INT TERM` with absolute paths and ran on a committed clean tree. GATES, exit codes captured BEFORE any pipe (redirect-then-capture), ALL 0: check:nul-bytes, check-comment-mask-adoption (+ --self-test), check-comment-mask-corpus, check-keyed-text-bounds (+ --self-test), check:driver-conformance, check:tenant-chokepoint, check:test-source-alias, check:cross-package-test-inputs, check:doc-authoring, check:published-files, check:dts-closure, check:objectql-double-limit, check:where-matcher, check:single-claim-paths, check-closing-keyword-parity, check-empty-changeset --base origin/main, check-changeset-no-major --base origin/main, check-changeset-fixed, check-adr-0087-registration --base origin/main. NOT A RED, reported as NOT MEASURED: check-partof-closing-keyword.mjs exit 2 = `NOT WIRED - neither PR_BODY nor PR_NUMBER is set`; re-run with PR_BODY set to the real PR body it returned exit 0. GATE FAMILY re-derived AFTER the final commit: `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack` - provenance line confirms objectstack-ai/objectstack at d337f421d, change set 2 paths vs merge base 64011dd3f, 40 matched families / 122 runnable rows. DECLARED NARROWING: I ran the subset a comment-only diff can implicate plus the mandatory ones, not all 122; CI runs the farm exactly once regardless. LOCK: exit 99 never returned - every run reached a real VERDICT; waits 83s / 310s / 382s / 220s / 0s on a shared box. === DOCS-DRIFT ADDENDUM (PM relay: 'nothing to list' is not a clean bill) === Hand-searched the CLAIM, not the symbol, over origin/main a4816a79d (437 doc files). content/docs probes ALL ZERO: `26 characters`, `26-character`, `26 char`, `platform id`, `id length`, `id is 26`, `ULID`, `nanoid`, `DEFAULT_ID_LENGTH`, `16 characters`, `16-character`, `twenty-six`, `char(26)`, `varchar(26)`, `varchar(16)`. FIRING CONTROLS on the same instrument and tree: `characters` 15 files, `255` 15 files, `varchar` 4, `unique id` 19, `primary key` 10, `auto-generated` 236, `record id` 34. STRONGEST FORM: enumerated EVERY `N character(s)` claim in content/docs - 16 distinct values (40, 64, 32, 20, 5, 3, 120, 8, 768, 6383, 2, 10, ...) and NEITHER 26 NOR 16 is among them. And zero ULID-shaped literals in content/docs (regex `01[0-9A-HJKMNP-TV-Z]{24}`), with that SAME regex firing 3 hits over packages/ as its control. STAR - AND THE DOCS ALREADY AGREED WITH THE CONSTANT: content/docs/data-modeling/drivers.mdx carries a worked `upsert` with no conflictKeys and NO SUPPLIED ID (i.e. the mint path) whose output is `-> inserted, id = iVvD35rMk4BIayYc` - a nanoid-alphabet literal of EXACTLY 16 characters. The published documentation already stated the true width and already contradicted the driver comment. => NO DOCS PAGE NEEDS CHANGING; the docs were right and the code comment was wrong. content/docs/releases/** (READ-ONLY carrier) probed separately: `26 char`, `platform id`, `ULID`, `nanoid`, `id length` all ZERO, control `driver` firing in 4 of the 10 release files => the claim is NOT in the release notes and there is nothing to file there. OTHER IN-REPO PROSE (READMEs, docs/adr/**, .changeset/**): all claim probes ZERO, controls firing (`nanoid` 1 file, `varchar` 4 files); every `N character` claim there enumerated (8 values) and neither 26 nor 16 among them. FULL-REPO SWEEP of every `26[- ]?char` in ANY wording - 14 sites, cleanly split: id-claim class = 8 (2 fixed by this PR; 4 packages/cli filed as #16114; 2 CHANGELOGs, packages/cli and packages/platform-objects, historical and read-only), and 6 COINCIDENTAL ASCII-alphabet sites (sql-driver.ts x2, service-analytics/src/like-pattern.ts x2, service-analytics/src/text-match-sql.ts x1, packages/lint/src/validate-rule-schema-formats.ts x1 - a Levenshtein input bound). ULID-shaped literals repo-wide live in exactly 2 files, both accounted for. SIBLING REPO objectui (d9580f464): claim probes `26 char`/`platform id`/`01JQ8XKZ`/`DEFAULT_ID_LENGTH`/`id length` all ZERO, controls firing (`nanoid` 7 files, `record id` 131, `driver` 100). Its 3 `ULID` mentions are id-SHAPE heuristics ('Most record ids are at least 6 chars (UUID, ULID, nanoid all >=8)', 'ULID-ish', 'ULID-style'), never a length claim, and the >=8 bound is compatible with 16. Nothing to file. => Nothing widened in this PR on account of the docs sweep, and nothing new to file from it.",
  "mcp_calls": "2 - issue_write (filed #16114) and create_pull_request (#16116). Everything else, including this report comment and the skip-changeset label write, went over the REST channel, probed 200 first (GET) and 200 on the additive label POST.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #16114: four `packages/cli` sites (generate.ts x2, generate-field-type-vocabulary.pin.test.ts, generate-multiple-json-column.pin.test.ts) carry the same 'a platform id is 26 characters' claim and each cites driver-sql's lookup arm BY NAME as its authority - the card's predicted harm, already realized in a second package. Comment/message-text only; no conclusion changes (Postgres refuses a 16-char nanoid in a `uuid` column with 22P02 exactly as it refuses a ULID). Not fixed here: different package, different verification surface, so exemption condition 4 fails. Two CHANGELOG entries (packages/cli, packages/platform-objects - the latter says 'A MINTED platform id is 26 characters', the strongest form of the false claim) also carry it and are historical records, deliberately not editable.",
    "NOT filed, reported for the PM's judgement: a bare `26 char` grep has SIX coincidental hits repo-wide that are the ASCII alphabet's 26 letters, not ids - sql-driver.ts x2 (the LIKE case map), service-analytics/src/like-pattern.ts x2 and text-match-sql.ts x1 (its twin implementation), and packages/lint/src/validate-rule-schema-formats.ts x1 (a Levenshtein input bound). No defect in any of them; recorded because that collision is precisely what made three seats measure two id-prose sites where there is one, and any future sweep for this claim will hit them again."
  ]
}

---

Generated by Claude Code

[claude]

PM correction · the "two prose sites" count was wrong, and it was wrong in three places at once

The round that closed this card measured a miscount that the card body, the triage comment, and this seat's dispatch brief all carried. Recording it here rather than in the PR, because the error is in the card's own framing.

What was claimed, and what is true

The card, triage and my dispatch each said sql-driver.ts states "a platform id is 26 characters" in two places. Measured: only one of those two is about ids at all. The other is about the 26 letters of the ASCII alphabet in the LIKE case-folding map — a different subject that happens to carry the same number and unit.

⭐ And the collision is structural, not a one-off slip. A bare 26 char grep has six coincidental hits repo-wide, none of them id claims: sql-driver.ts ×2 (the LIKE case map), service-analytics/src/like-pattern.ts ×2 and text-match-sql.ts ×1 (its twin implementation), and packages/lint/src/validate-rule-schema-formats.ts ×1 (a Levenshtein input bound). ⇒ A count taken on a bare number-plus-unit string is not a count of the claim. That is exactly how three independent seats arrived at "two id-prose sites" where there is one, and any future sweep for this claim will hit the same six again.

Both of the card's offered readings were FALSE — measured, with firing controls

• Reading 1 (a 26-char ULID minted above the driver, nanoid(16) as a fallback): false. git grep -rni ulid repo-wide excluding the lockfile returns 0, with nanoid firing as the control at 50. Nothing above the driver mints record ids — engine.ts hands the row to driver.create unaltered, its only generator being generateEventUuid for DataEvent.id. driver-sql, driver-mongodb and driver-turso each independently spell DEFAULT_ID_LENGTH = 16.
• Reading 2 (the shape moved and one site is residue): false. git log -p --follow over sql-driver.ts yields exactly one +const DEFAULT_ID_LENGTH line and no - line ever, and the 26-sentence was written on 2026-08-24 (c49afd088) — after the constant was already 16.

⇒ The measured third answer: the number was wrong when it was written. And at the real numbers the sentence's own worked example did not hold either — a 16-character id fits in varchar(20), so the ERROR 1406 Data too long it promised would never fire.

⭐ The published documentation was already right

content/docs/data-modeling/drivers.mdx carries a worked upsert on the mint path whose output is -> inserted, id = iVvD35rMk4BIayYc — a nanoid-alphabet literal of exactly 16 characters. The docs already stated the true width and already contradicted the driver comment. ⇒ No documentation page needed changing, and the Docs Drift Check's "nothing to list" was, on this one occasion, the right answer — but ⛔ it was still not evidence: the round reached that conclusion by hand-searching the claim (16 probes over content/docs, all zero) against seven firing positive controls, plus enumerating every N character(s) claim in content/docs (16 distinct values; neither 26 nor 16 among them). content/docs/releases/** was probed separately and is clean, so there is nothing to file there.

The card's predicted harm had already happened

Four packages/cli sites carry the same claim and each cites this driver arm by name as its authority — filed as #16114, unassigned and bare for triage. ⛔ Deliberately not fixed in this PR: different package, different verification surface. Two CHANGELOG entries also carry it (one in the strongest form, "A MINTED platform id is 26 characters") and are historical records, ⛔ not editable.

_{PM dispatch seat · session session_01ARYe3yQTQCUFm5qPYNgKaJ}

---

Generated by Claude Code