feat(platform-objects): declare a sourced maxLength on sys_import_job.created_by (#11374 route A, last column)

[os-warren]

Part of #11374 — route A's last column.

Not a closing keyword by choice: #11374 also carries the C-half remainder (the

768-character key class, tracked on #11627 and its sub-issue #11701), so
whether this card closes is the PM's call, not this PR's. #11699 landed route A
for 13 keyed identity columns; sys_import_job.created_by sat in audit/,
outside that dispatch's declared file surface, and was left for this card.

The defect

sys_import_job.created_by is keyed by (created_by, created_at) and declared
no maxLength, so driver-sql emitted it TEXT and MySQL refused the index.
Per #11699's own measurement it was the only remaining
ER_BLOB_KEY_WITHOUT_LENGTH object outside the >768 class. Measured live, not
recalled — the driver's own message from the BEFORE leg:

[sql-driver] cannot create index 'idx_sys_import_job_created_by_created_at'
on "sys_import_job" — MySQL refuses a TEXT/BLOB column in a key without a key length

The bound and where it comes from — the veto surface

Route A's method is that every bound is derived from a named producer and
stated so a reviewer can veto the row. One column, one row:

Column	Bound	Source (named producer)
sys_import_job.created_by	255	Referenced-column transitivity from the value's actual producer. The rest-server import route stamps String(context?.userId ?? context?.user?.id ?? '') (packages/rest/src/rest-server.ts), i.e. a sys_user.id. driver-sql creates every table's primary key as table.string('id').primary() — knex's varchar(255) — so no id this column can ever receive exceeds 255. Confirmed physically in the same run: sys_import_job.id reads back varchar(255) from information_schema.

Two independent in-repo corroborations, both already landed, neither used as the
primary source:

• What this column would get if declared like its siblings. Every other
  actor column on a platform object is Field.lookup('sys_user', …), which
  driver-sql emits at DEFAULT_STRING_VARCHAR_CHARS = 255.
• Landed text declarations for the same value class.
  sys_metadata_audit.actor ("Acting principal — user id, system id, or
  'system'"), sys_metadata_commit.actor and sys_view_definition.owner all
  declare maxLength: 255.

Floor cleared with headroom. A minted platform id is 26 characters (measured
on #11431, where honouring a bound below that made a column structurally unable
to hold any id at all). 255 leaves 229 characters of headroom.

Ceiling respected. 255 is well inside the 768-character utf8mb4 key ceiling
(MAX_KEYABLE_VARCHAR_CHARS), so this stays out of the C class rather than
quietly merging the two ruled halves.

Measured on live servers — physical read-back, never the emitted DDL

MySQL 8.0.46 (@@global.time_zone = '+08:00', STRICT_TRANS_TABLES, utf8mb4)
and PostgreSQL 16.13, process TZ=America/New_York. All 44 distinct exported
platform objects through syncSchema, both legs at the same tree apart from the
one declaration.

	BEFORE (unbounded)	AFTER (this PR)
MySQL syncSchema failures	8 / 44 (7 ER_BLOB_KEY_WITHOUT_LENGTH + 1 ER_TOO_LONG_KEY)	7 / 44 (6 + 1)
sys_import_job itself	FAILED, ER_BLOB_KEY_WITHOUT_LENGTH	clean
created_by physical column	text, CHARACTER_MAXIMUM_LENGTH 65535	varchar(255)
idx_sys_import_job_created_by_created_at	absent	present
Postgres 16.13 control	0 / 44	0 / 44

Column shapes are read from information_schema.COLUMNS and the index list from
information_schema.STATISTICS — the physical catalog, not the DDL the driver
emitted.

The accept/reject flip

On the strict MySQL server, against the physical column:

Value length	BEFORE	AFTER
255 (boundary)	accepted, stored 255	accepted, stored 255
256	accepted, stored 256	refused — ER_DATA_TOO_LONG, rows 0
300	accepted, stored 300	refused — ER_DATA_TOO_LONG, rows 0

Refused, not truncated — which is why the changeset grades this minor
(behaviour-narrowing on a published object), matching #11699's tier. No value
the producing contract can emit is affected: the id being copied is itself
capped at 255 by its own column.

The pin: why this column escaped, and the fix for the class

⚠️ Answering the dispatch's question explicitly: route A's pin did NOT cover
audit/. It lived at identity/identity-keyed-text-bounds.test.ts and
imported ./index from identity/, so its enumeration could only ever see
identity objects. That is exactly how a keyed unbounded column in audit/
survived a pin whose stated job is to fail by name on keyed unbounded columns —
it policed a directory, not the defect class.

Extended rather than patched with a one-off assertion: the file moves to
packages/platform-objects/src/platform-keyed-text-bounds.test.ts and
enumerates every object the package exports. Measured effect on the
enumeration:

• objects walked: 20+ (identity only) → 45
• keyed text-family columns enumerated: 30+ → 78
• unbounded offenders surfaced by the widening: exactly two —
  sys_verification.value (already allowlisted, better-auth JSON blob) and
  sys_import_job.created_by (this PR). The widening drags in no new debt.

A new vacuity control asserts the enumeration reaches
sys_import_job.created_by (audit/), sys_metadata.name (metadata/) and
sys_setting.key (system/) — three different source directories — so a future
re-narrowing of the import fails by name instead of quietly enumerating less.
The UNBOUNDABLE allowlist and its anti-rot test are unchanged.

Ablation — mutation proven on disk before any result was read

Direction predicted in advance in both legs; every prediction held.

Leg A (pin discrimination, source level). Removed only maxLength: 255,
from the created_by block. Anchor was proven unique before writing
(ANCHOR HITS: 1) and the mutation proven on disk after
(created_by bound-block count 1 → 0; git diff --stat = 1 deletion). Green
baseline 4 passed → red Tests 1 failed | 3 passed (4), the failure naming
exactly:

sys_import_job.created_by (maxLength: undefined)

The red appeared with no build step between mutation and run, which is the
proof the suite read the mutated source rather than a stale artifact.

Leg B (physical level, the BEFORE measurement above). Same mutation, then
pnpm --filter @objectstack/platform-objects build, then
ablation-dist-preflight.mjs … --absent confirmed the bound was gone from all
66 built files — only then was the probe's result read.

Restore verified, not trusted. Both legs restored from a
trap … EXIT INT TERM using git checkout HEAD -- with an absolute path
(never git checkout -- FILE, which restores from the index the mutation step
itself wrote). Verified after each leg: git hash-object of the working file
equals git rev-parse HEAD:path (75930e4af21ade22f4b21f0996b4265ce14a781c),
and git status --porcelain empty. The restore leg was then rebuilt and
re-proven with the preflight in present mode — marker back in 4 built files,
so no mutated artifact is left behind to poison later runs in this worktree.

Gates

Union derived, not recalled:
node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack with no
paths passed (the script derives its own change set from the merge base). Its
stderr stamped the answer to this repo's tree. Every family run against the
final commit 59897f5e49, exit captured before any pipe.

13 path-matched + check:nul-bytes, all 0:
check:nul-bytes, check:changeset-gate-self-tests, check:objectui-changeset,
check:published-files, check:slot-lookup, check:test-source-alias,
check:type-source-resolution, check-adr-0087-registration.mjs,
check-changeset-no-major.mjs, check-empty-changeset.mjs,
check-plugin-teardown-shape.mjs, docs-audit/check-affected-docs.mjs,
docs-audit/check-drift-comment.mjs,
release-rehearsal-clone.mjs --self-test.

Convention-triggered, all 0: check:query-options-erasure,
check:type-check-coverage, check:engine-double-contract,
check:where-matcher, check:cross-package-test-inputs, check:i18n.

Suites and ratchets, at 59897f5e49:

• pnpm --filter @objectstack/platform-objects test → Test Files 30 passed (30) / Tests 475 passed (475)
• pnpm --filter @objectstack/platform-objects typecheck → exit 0, script name echoed (tsc --noEmit && tsc --noEmit -p tsconfig.scripts.json), so not a zero-match
• pnpm lint (full repo, eslint . --no-inline-config) → exit 0 in 2m23s. A full run; no narrowing claimed.
• pnpm check:type-check-debt --re-measure, its own verdict line:
  check-type-check-coverage --re-measure: OK — 32 ledger entr(ies) re-measured in 360.3s, 1898 raw tsc error(s) total, none above its recorded number.
• check:i18n first run exited 1 as a measured refusal (PREREQUISITE NOT MET — the workspace CLI is not built; nothing was checked), then green after building the CLI:
  check-i18n-bundles: OK (9 package(s) — all bundles in sync, no undeclared authoring keys).

Out of scope, deliberately

• sys_verification.value — better-auth stores OIDC authorization-code payloads
  there as a JSON blob; no bound provably admits every value. Stays allowlisted
  by name with its reason (driver-sql (MySQL): full-value UNIQUE on >768-char token columns is inexpressible on utf8mb4 — hash-shadow-key route for the four ruled cases (C half of the #11374 ruling) #11627).
• sys_account.issuer and the (issuer, account_id) composite — 2048 exceeds
  the 768 key ceiling; that is the C class (driver-sql (MySQL): full-value UNIQUE on >768-char token columns is inexpressible on utf8mb4 — hash-shadow-key route for the four ruled cases (C half of the #11374 ruling) #11627 / #11627 population re-measured after the A half: three additional members of the >768/unboundable keyed-text class (resource_id 1024, sys_verification [value], sys_account [issuer+account_id]) #11701).
• The hash-shadow-key route itself — driver-sql (MySQL): full-value UNIQUE on >768-char token columns is inexpressible on utf8mb4 — hash-shadow-key route for the four ruled cases (C half of the #11374 ruling) #11627.

Found while doing this, filed separately, NOT fixed here

The same defect class exists in sibling packages my pin cannot reach: four
keyed, unbounded Field.text columns in plugin-audit and plugin-security
(sys_activity.record_id, sys_audit_log.record_id,
sys_audience_binding_suggestion.package_id / .permission_set_name). Filed
unassigned rather than fixed — out of this card's declared surface.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/platform-objects, touching 2 documentable anchor(s).

23 hand-written doc(s) name something this change touched — list omitted above 15 rows. Re-derive on the tree named below: node scripts/docs-audit/affected-docs.mjs --json 3def551026963aed4c333b80fa5d82190ba35893.

⛔ 5 release-owned page(s) also affected — read-only, see AGENTS.md Documentation Guardrails.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 2 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 3def551026963aed4c333b80fa5d82190ba35893 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from 19d01fbfdeb5daedb20115f1bfde2bf320b147a2 — the merge of head 59897f5e49abffe5e7eef48eed16ef11ef4e5a68 into base 3def551026963aed4c333b80fa5d82190ba35893, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin 19d01fbfdeb5daedb20115f1bfde2bf320b147a2 && git checkout 19d01fbfdeb5daedb20115f1bfde2bf320b147a2
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 3def551026963aed4c333b80fa5d82190ba35893 59897f5e49abffe5e7eef48eed16ef11ef4e5a68 && git checkout -B drift-repro 3def551026963aed4c333b80fa5d82190ba35893 && git merge --no-ff 59897f5e49abffe5e7eef48eed16ef11ef4e5a68
node scripts/docs-audit/affected-docs.mjs --json 3def551026963aed4c333b80fa5d82190ba35893

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 3def551026963aed4c333b80fa5d82190ba35893 → pass the list as
args.docs, on the commit named under Which tree this was computed on.