Skip to content

[finding] Internal issue-ids inside published zod refusal MESSAGE strings — the customer-facing error-prose population #11052's skills-corpus ruling never covered #12124

Description

@os-litant

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:

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.

Metadata

Metadata

Assignees

No one assigned

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions