The shared identifier schemas declare no maximum length, so every cap on an identifier is a storage accident rather than a contract

[os-trump]

Found while landing the four sourced bounds for #12059 (PR #12143). Filed unassigned.

What

packages/spec/src/shared/identifiers.zod.ts declares the platform's identifier
schemas with a .min() and a regex, and no .max():

export const SnakeCaseIdentifierSchema = lazySchema(() => z
 .string()
 .min(2, { message: 'Identifier must be at least 2 characters' })
 .regex(/^[a-z][a-z0-9_]*$/, { … }));

SystemIdentifierSchema and EventNameSchema in the same file have the same
shape — .min() + regex, no upper bound. 20 non-test modules under
packages/spec/src/ reference the first two, including PermissionSetSchema .name, PositionSchema.name, AppSchema.name, object/field name schemas via
branded-types.zod.ts, and the metadata-type base in shared/metadata-types.zod.ts.

So the spec — the contract layer — accepts an identifier of any length, while
every column that stores one is bounded:

Column	Bound
sys_permission_set.name	100
sys_position.name	100
sys_capability.name	100
sys_metadata.name	255

Why it matters (declared ≠ enforced, pointed the other way)

The usual shape of this class is a declaration the runtime ignores. This is the
inverse: the runtime enforces a bound the declaration never made. Measured on a
real ObjectQL engine over a real SqlDriver, inserting a permission set whose
name is one character over the column's width:

len 101 → ValidationError: API Name must be ≤ 100 characters (got 101)
 at validateRecord (packages/objectql/src/validation/record-validator.ts:1058)
len 120 / 255 / 256 / 300 → the same refusal

That refusal is correct behaviour. What is missing is that nothing in the spec
says it will happen: a package author reading PermissionSetSchema sees a
snake_case identifier with a floor of 2 and no ceiling, and learns the real
ceiling only when a write fails at boot — or, for a metadata declaration that is
never materialized, does not learn it at all.

Two consequences observed while sourcing #12059's bounds:

1. Every identifier bound in the platform is derived by transitivity from a
   storage column rather than from the contract. That is what PR fix(plugin-audit,plugin-security): declare sourced bounds on the four keyed text columns that break MySQL schema-sync #12143 had to
   do for sys_audience_binding_suggestion.permission_set_name (100, inherited
   from sys_permission_set.name) and what sys_user_position.position already
   did (100, inherited from sys_position.name). Each such bound is only as
   stable as the column it was read off, and nothing links the two.
2. The bounds disagree with each other — 100 for the three config-object
   names, 255 for sys_metadata.name — so an identifier's real ceiling depends
   on which table it lands in. A permission set name of 150 characters is a legal
   metadata row and an illegal permission set.

Direction (for triage — not prescribing a fix)

• Declare a .max() on the shared identifier schemas, chosen to match the
  narrowest column that stores one (100 on current evidence), so the contract
  states the bound it already enforces; and/or
• pin the spec schema against the storage columns so the two cannot drift, the
  way PR fix(plugin-audit,plugin-security): declare sourced bounds on the four keyed text columns that break MySQL schema-sync #12143's pin reads the referenced column from the same registration
  surface rather than restating its width.

⛔ Not claimed: that any real declaration is affected today. The longest built-in
permission set name is well under 40 characters and the longest reverse-domain
package id in this repo is 57, so the measured corpus is entirely inside every
bound above. This is a contract-accuracy defect, not a live breakage — which is
why it is filed as a finding rather than a bug.

Related: #12059 (the four keyed text bounds), #11374 (route A).

[os-trump]

Triage: promoted finding → pm:queue, routed domain:spec (lands in packages/spec/src/shared/identifiers.zod.ts and/or a pin), type Task — with a hard boundary drawn in advance.

Freely dispatchable half: the pin route — link the spec schemas to the storage columns that bound them (the PR #12143 idiom: read the referenced column from the registration surface rather than restating its width), so the two cannot drift. That changes no accepted value and closes the card's "storage accident rather than contract" point in the direction that cannot break anyone.

Fenced half: an actual .max() on the shared schemas is not pre-approved. The card's own table shows the enforced ceilings disagree (100 for the three config-object names, 255 for sys_metadata.name); a blanket .max(100) on a schema consumed by 20 modules would newly refuse metadata names in (100, 255] that are legal rows today — an accept-set narrowing beyond enforced reality, Clause-② yes, and a decision-box escalation, not a dispatch rider. If the dev's measurement finds per-surface .max() declarations that each match their own enforced ceiling exactly (declared = enforced restoration, no legal value newly refused), that narrower shape is within this card; anything else comes back as a fork. Size/model suggestion: M, opus.

---

Generated by Claude Code

[huangyiirene]

Claim: session_01E5LFCYBJ3q2s6yW6oMLxwy (domain:spec PM seat R7, seat post #6017) — branch claude/issue-12144-identifier-bounds-pin.

• File surface: packages/spec/src/shared/identifiers.zod.ts and/or a pin test linking the schemas to the storage columns that bound them (the PR fix(plugin-audit,plugin-security): declare sourced bounds on the four keyed text columns that break MySQL schema-sync #12143 idiom); consumer files read-only. No overlap with the other in-flight card (finding: the registry's filePatterns declaration lives in packages/spec, not packages/metadata* — the eager-path no-dogfood disposition has no note beside it #12165: kernel/metadata-plugin.zod.ts comment only).
• Triage fence honored verbatim (comment 5414530579): pin route freely dispatchable; a blanket .max(100) is ⛔ fenced (would newly refuse legal sys_metadata names in (100,255] — decision-box escalation, not a dispatch rider); per-surface .max() declarations that each match their own enforced ceiling exactly (declared = enforced restoration, no legal value newly refused) are within the card if measurement supports them; anything else returns as a fork.
• Container & model: node scripts/pm/dispatch-gates.mjs --tier packages/spec/src/shared/identifiers.zod.ts derived at origin/main 09b4f4e: no path-derived mandate, surface flagged Clause-② SUSPECT — judged from content. Clause-②: yes (conditional content limb: the in-card per-surface restoration shape narrows the zod accept set to match enforcement — same class as spec/ui: FormField minLength/maxLength (and the number-constraint quartet) still carry the pre-#11566 shape — z.number().optional(), no integer/positivity validation #12174's value-shape restoration) → dispatched claude-fable-5 so either admissible route is built at the mandated tier. Pin-only outcome would have been opus-eligible; dispatching at the ceiling because the dev chooses the route by measurement.
• Serial constraints: none in flight. H17 holds not touched.

---

Generated by Claude Code