Found while sweeping the runtime-services chapter's enumerations for #9684. Out of that card's scope (its diff is versioning.mdx plus the docs gate), and it is a code-comment defect, not a docs one.
What was measured
packages/spec/src/contracts/email-service.ts:11 states:
* Aligned with CoreServiceName 'email' in core-services.zod.ts.
CoreServiceName (packages/spec/src/system/core-services.zod.ts) has noemail member. Its members are metadata, data, auth, file-storage, search, cache, queue, automation, analytics, realtime, job, notification, ai, i18n, ui. Email is subsumed under notification (// Email/Push/SMS).
The runtime slot is nevertheless real and is spelled email — @objectstack/plugin-email calls ctx.registerService('email', ...), which is what content/docs/kernel/runtime-services/email-service.mdx documents and what check:runtime-services-index verifies. So the surface is fine; only the JSDoc's claim about where the name comes from is false.
Why it matters
It is the same class as #9630: a naming claim a reader can follow to a throw. Here the reader who trusts the comment goes looking for CoreServiceName.enum.email and finds nothing — and the plausible "fix" (adding an email member to the enum) would invent a core-service identifier nobody registers, which is exactly the move #9630's resolution forbids.
Not new: the 2026-06 docs-accuracy audit recorded it as a code-side follow-up (docs/audits/2026-06-handwritten-docs-accuracy-followups.md, guides/runtime-services/email-service.mdx section) and it was never filed.
Suggested resolution
Delete or correct the line — e.g. name the registry slot ('email', registered by @objectstack/plugin-email) and, if the relationship to notification is worth stating, state that instead. Check the sibling contracts under packages/spec/src/contracts/ for the same copied sentence before closing.
Refs #9684, #9630.
Found while sweeping the runtime-services chapter's enumerations for #9684. Out of that card's scope (its diff is
versioning.mdxplus the docs gate), and it is a code-comment defect, not a docs one.What was measured
packages/spec/src/contracts/email-service.ts:11states:CoreServiceName(packages/spec/src/system/core-services.zod.ts) has noemailmember. Its members aremetadata,data,auth,file-storage,search,cache,queue,automation,analytics,realtime,job,notification,ai,i18n,ui. Email is subsumed undernotification(// Email/Push/SMS).The runtime slot is nevertheless real and is spelled
email—@objectstack/plugin-emailcallsctx.registerService('email', ...), which is whatcontent/docs/kernel/runtime-services/email-service.mdxdocuments and whatcheck:runtime-services-indexverifies. So the surface is fine; only the JSDoc's claim about where the name comes from is false.Why it matters
It is the same class as #9630: a naming claim a reader can follow to a throw. Here the reader who trusts the comment goes looking for
CoreServiceName.enum.emailand finds nothing — and the plausible "fix" (adding anemailmember to the enum) would invent a core-service identifier nobody registers, which is exactly the move #9630's resolution forbids.Not new: the 2026-06 docs-accuracy audit recorded it as a code-side follow-up (
docs/audits/2026-06-handwritten-docs-accuracy-followups.md,guides/runtime-services/email-service.mdxsection) and it was never filed.Suggested resolution
Delete or correct the line — e.g. name the registry slot (
'email', registered by@objectstack/plugin-email) and, if the relationship tonotificationis worth stating, state that instead. Check the sibling contracts underpackages/spec/src/contracts/for the same copied sentence before closing.Refs #9684, #9630.