Skip to content

finding(types,i18n): eight doc comments claim alignment with @objectstack/spec symbols the spec does not export #4597

Description

@yinlianghui

Observation-class finding, measured while implementing #4592 (the spec-alignment claim rule). Nothing is changed for it there — #4592 owns scripts/** only, and these declarations belong to other surfaces. Filed so the next one is a decision rather than an accident.

What was found

Eight exported declarations carry a doc comment claiming alignment with a @objectstack/spec symbol that the installed spec (17.0.0-rc.6) does not export at all:

declaration file claimed spec symbol
SpecPluralRule packages/i18n/src/utils/spec-formatters.ts:28 PluralRuleSchema
SpecDateFormat packages/i18n/src/utils/spec-formatters.ts:90 DateFormatSchema
SpecNumberFormat packages/i18n/src/utils/spec-formatters.ts:133 NumberFormatSchema
SpecLocaleConfig packages/i18n/src/utils/spec-formatters.ts:179 LocaleConfigSchema
FieldChangeEntry packages/types/src/views.ts:398 FieldChangeEntrySchema
Mention packages/types/src/views.ts:417 MentionSchema
Reaction packages/types/src/views.ts:434 ReactionSchema
RecordSubscription packages/types/src/views.ts:449 RecordSubscriptionSchema

Verified by resolving @objectstack/spec from node_modules and enumerating every export name across every subpath (4834 names) — the same machinery scripts/check-spec-symbol-derivation.mjs already uses. None of the eight names appears.

Example, packages/types/src/views.ts:434:

/**
 * Reaction — An emoji reaction on a feed item.
 * Aligned with @objectstack/spec ReactionSchema.
 */
export interface Reaction { ... }

Why it may matter

This is the harm the derivation guard's own header argues, in its purest form: "a wrong canonical-claim is not stale documentation — it is a planted premise for the next session." A drifted claim at least points at something real, so a reader can compare and find the difference. A dangling claim points at nothing: the next agent goes looking for the spec's ReactionSchema to check the shape against, does not find it, and has no way to tell whether the spec retired it, renamed it, never had it, or the comment was always wrong.

It is also the sub-class that no structural instrument can reach. #4592 measured the alternative — comparing local key sets against spec object types — and it cannot see any of these eight, because there is no spec-side shape to compare against. Only the prose says anything at all.

Note that whether each declaration's SHAPE is right is a separate question this finding does not answer; several may be perfectly good local types that simply mis-cite their provenance.

Deliberately not established here

  • Whether the spec ever exported these names. Not researched. They may be pre-17 names retired long ago (#3362 is that pattern), names from a different package, or names that never existed. The fix differs per case: re-point the comment, derive from whatever the spec calls it now, or delete the claim.
  • Whether any of the eight shapes has drifted from whatever the spec models today under another name.
  • Priority. No user hits this and no metadata is refused; it is a provenance-accuracy observation about comments, which is why it is filed as an observation rather than a defect.

All eight are named individually in the shrink-only CLAIM_DEBT ledger added by #4592, so the gate reports them and none can silently acquire a fresh unbacked claim. Burning one down is a one-line ledger edit plus the comment fix.

Refs #4592, #4588, #3103, #3561.


Generated by Claude Code

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions