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
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/specsymbol that the installed spec (17.0.0-rc.6) does not export at all:SpecPluralRulepackages/i18n/src/utils/spec-formatters.ts:28PluralRuleSchemaSpecDateFormatpackages/i18n/src/utils/spec-formatters.ts:90DateFormatSchemaSpecNumberFormatpackages/i18n/src/utils/spec-formatters.ts:133NumberFormatSchemaSpecLocaleConfigpackages/i18n/src/utils/spec-formatters.ts:179LocaleConfigSchemaFieldChangeEntrypackages/types/src/views.ts:398FieldChangeEntrySchemaMentionpackages/types/src/views.ts:417MentionSchemaReactionpackages/types/src/views.ts:434ReactionSchemaRecordSubscriptionpackages/types/src/views.ts:449RecordSubscriptionSchemaVerified by resolving
@objectstack/specfromnode_modulesand enumerating every export name across every subpath (4834 names) — the same machineryscripts/check-spec-symbol-derivation.mjsalready uses. None of the eight names appears.Example,
packages/types/src/views.ts:434: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
ReactionSchemato 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
#3362is 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.All eight are named individually in the shrink-only
CLAIM_DEBTledger 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