You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[finding] Internal issue-ids inside published zod refusal MESSAGE strings — the customer-facing error-prose population #11052's skills-corpus ruling never covered #12124
Observed 2026-08-25 while reviewing the newTabUrl co-constraint refine; filed unassigned by the spec PM seat (session_01NDGG54XF5gbTLdQzCtnaVV). Observation, not a defect claim on any single PR — the new refine's (#11842) tail exactly matches the file's existing idiom, which is why it was accepted and this is carded separately.
The population
packages/spec/src/** zod refusal message: strings carry internal issue-ids that render verbatim in customer-facing os validate / parse-refusal output. Measured on main:
packages/spec/src/data/filter.zod.ts:1454: message: 'A field condition's keys are field names, never $-prefixed operators (#7711).'
Not exhaustive — a git grep -nE "message:.*#[0-9]{4}" over packages/spec/src is the census command.
Why this is its own decision, not a rider
The 2026-08-23 strip ruling and its follow-ups covered the published skill catalog (skills/**, then the generated artifacts sourced from spec TSDoc). Refusal messages are a THIRD population: they ship in the published @objectstack/spec source AND are printed to the customer at validation time — arguably the most customer-visible of the three — but a customer cannot open the tracker the ids point at. To that reader they are noise that looks like a citation (same reasoning as the skills-corpus card).
Counter-consideration for triage: inside messages the ids sometimes anchor a documented-decision reference the repo's own agents grep for; stripping them trades internal navigability for customer-facing cleanliness, and the internal reader still has git log. Whether the convention flips, and whether a gate should hold it (the doc-authoring corpus rule does not scan message strings), is a corpus-wide convention decision — the same shape the skills-corpus card went through before its ruling.
Observed 2026-08-25 while reviewing the newTabUrl co-constraint refine; filed unassigned by the spec PM seat (
session_01NDGG54XF5gbTLdQzCtnaVV). Observation, not a defect claim on any single PR — the new refine's(#11842)tail exactly matches the file's existing idiom, which is why it was accepted and this is carded separately.The population
packages/spec/src/**zod refusalmessage:strings carry internal issue-ids that render verbatim in customer-facingos validate/ parse-refusal output. Measured on main:packages/spec/src/ui/action.zod.tsmessage blocks alone carry ~10 distinct ids (ActionSchema.onSuccessand a handler-returnedredirectUrlare both reachable on onetype: 'script'action, and the spec rules neither — renderer-side precedence is deciding it today #11519, [P0][security] Agent access control is a no-op (permissions/visibility/access) #1884, feat(spec): reject unknown keys on an action param instead of stripping them (#3405) #3746, 排查「手抄 spec 清单 + "keep in sync" 注释」模式:一天内确认三例,全部曾静默漂移 #3786, [P3] Retire the three deprecated aliases — via the ADR-0087 D2 conversion layer, not by deleting the keys #3855,POST /data/sharing/rules绕过SharingRuleSchema:criteria缺失或拼错静默变成"共享该对象全部记录",与 ADR-0049 "never seeded as a permissive match-all" 直接冲突 #3896, 未知键静默剥离仍是全仓默认:把 #3405 的 strict 收紧从一个 schema 推广到整个可授权面(ADR-0078 完整性闸门) #4001×2, [P3] objectuiActionDef's[key: string]: anyabsorbs every retired and misspelled action key — removing a spec key produces no compile error #4075, spec: SettingsManifest 的 SpecifierSchema 新增valueDomain闭合枚举 —— 声明存在时标准域为执行边界,options 退化为 UI 便利列表(#5712 裁决的 spec 半边) #5933, spec:ActionSchema的visible/disabled统一为boolean | string(CEL) | {dialect,source}(#4075 step 3 前置,维护者 2026-08-06 已裁决) #5970).packages/spec/src/data/filter.zod.ts:1454:message: 'A field condition's keys are field names, never $-prefixed operators (#7711).'git grep -nE "message:.*#[0-9]{4}"overpackages/spec/srcis the census command.Why this is its own decision, not a rider
The 2026-08-23 strip ruling and its follow-ups covered the published skill catalog (
skills/**, then the generated artifacts sourced from spec TSDoc). Refusal messages are a THIRD population: they ship in the published@objectstack/specsource AND are printed to the customer at validation time — arguably the most customer-visible of the three — but a customer cannot open the tracker the ids point at. To that reader they are noise that looks like a citation (same reasoning as the skills-corpus card).Counter-consideration for triage: inside messages the ids sometimes anchor a documented-decision reference the repo's own agents grep for; stripping them trades internal navigability for customer-facing cleanliness, and the internal reader still has git log. Whether the convention flips, and whether a gate should hold it (the doc-authoring corpus rule does not scan message strings), is a corpus-wide convention decision — the same shape the skills-corpus card went through before its ruling.