The rule
component §5.2 (PR #27): an endpoint name MUST match ^[a-z][a-z0-9-]{0,61}[a-z0-9]$ — "the grammar blueprint §4.1 quotes for a slug", chosen because the name "becomes a DNS label".
Why the slug grammar is the wrong bound here
The name does not become a DNS label alone — it becomes part of one, composed beside other slugs. §5.2's own consequence rule ("anything naming a public address MUST name the endpoint it means") implies each PUBLIC endpoint publishes its own URL, and the natural implementation derives that URL by qualifying the component's hostname with the endpoint name in the same first label:
{endpoint}<sep>{component-slug}-{app-slug}-{hash}.example.com
Two properties the slug grammar breaks:
- Hyphenated names make the composition ambiguous. With
- as the separator, endpoint api on component web and component api-web produce the same label. A -- separator restores unambiguity only if neither side may contain -- — which the slug grammar permits (a--b is a valid slug). Whatever separator an implementation picks, a name drawn from the same alphabet as the slugs it composes with cannot be delimited.
- A 62-char name cannot compose at all. The label budget is 63 chars shared with the component slug, app slug, and hash; a name near the grammar's ceiling forces every implementation into truncation heuristics, which reintroduce collisions.
There is a third, smaller casualty: reference-path grammars that expose per-endpoint values as dotted segments (the platform's self.privateAddress.<endpoint> today, and per-endpoint public addressing tomorrow) use identifier-charset segments in which - is not representable — so a hyphenated endpoint name is already unreferenceable in the very places §5.2 says the name exists to be referenced.
Proposal
Narrow the endpoint-name grammar to ^[a-z][a-z0-9]{0,19}$ — lowercase alphanumeric, 1–20 chars, no hyphens:
- Alphanumeric-only makes any hyphen-based separator (
-, --) unambiguous by construction.
- 20 chars leaves ≥40 for the component/app/hash remainder of a 63-char label.
- Every plausible name (
web, api, grpc, metrics, console, admin) fits; a name that doesn't is describing something an endpoint name shouldn't.
This is a narrowing, so the #24/#27 timing argument applies: free before the first tag, breaking after. structural-029-endpoint-name-not-a-slug keeps its meaning; one new fixture (a hyphenated name rejected) pins the change.
The platform is adopting the narrower grammar now (its hostname composition requires it) and will emit it in its published schema; until this issue resolves, that is a deliberate divergence from the bundle's propertyNames pattern.
The rule
component §5.2 (PR #27): an endpoint name MUST match
^[a-z][a-z0-9-]{0,61}[a-z0-9]$— "the grammar blueprint §4.1 quotes for a slug", chosen because the name "becomes a DNS label".Why the slug grammar is the wrong bound here
The name does not become a DNS label alone — it becomes part of one, composed beside other slugs. §5.2's own consequence rule ("anything naming a public address MUST name the endpoint it means") implies each PUBLIC endpoint publishes its own URL, and the natural implementation derives that URL by qualifying the component's hostname with the endpoint name in the same first label:
Two properties the slug grammar breaks:
-as the separator, endpointapion componentweband componentapi-webproduce the same label. A--separator restores unambiguity only if neither side may contain--— which the slug grammar permits (a--bis a valid slug). Whatever separator an implementation picks, a name drawn from the same alphabet as the slugs it composes with cannot be delimited.There is a third, smaller casualty: reference-path grammars that expose per-endpoint values as dotted segments (the platform's
self.privateAddress.<endpoint>today, and per-endpoint public addressing tomorrow) use identifier-charset segments in which-is not representable — so a hyphenated endpoint name is already unreferenceable in the very places §5.2 says the name exists to be referenced.Proposal
Narrow the endpoint-name grammar to
^[a-z][a-z0-9]{0,19}$— lowercase alphanumeric, 1–20 chars, no hyphens:-,--) unambiguous by construction.web,api,grpc,metrics,console,admin) fits; a name that doesn't is describing something an endpoint name shouldn't.This is a narrowing, so the #24/#27 timing argument applies: free before the first tag, breaking after.
structural-029-endpoint-name-not-a-slugkeeps its meaning; one new fixture (a hyphenated name rejected) pins the change.The platform is adopting the narrower grammar now (its hostname composition requires it) and will emit it in its published schema; until this issue resolves, that is a deliberate divergence from the bundle's
propertyNamespattern.