Skip to content

finding: packages/spec/liveness/doc.json carries a _note describing a tags defect that is already fixed #9310

Description

@os-zhuang

Surfaced while grounding the #9299 coverage sweep, and reported rather than edited because it sits outside that card's file surface. Filed unassigned for triage to route (it lands in packages/spec).

The stale claim: packages/spec/liveness/doc.json's _note records that DocSchema declares no tags key, so authoring tags: on a doc was a parse error, every doc reached the resolver with tags === undefined, and a book group's include: { tag: '<t>' } could therefore never match.

Why it is stale: DocSchema declares tags today — packages/spec/src/system/doc.zod.ts:126, tags: z.array(z.string()).optional(), with the fix's own history in the comment block immediately above it (L111–L122).

Re-check: git grep -n "tags" origin/main -- packages/spec/src/system/doc.zod.ts

Why it is worth a card rather than a shrug: the liveness ledgers are read as ground truth about what a key does at runtime — a note asserting a key "can currently never match" invites the enforce-or-remove conclusion for a property that now works. This is the same class of defect the sweep was correcting in SWEEP.md: a factual claim that was true when written and aged into falsehood, in a file whose entire job is to be believed.

Scope: correct or delete the stale _note paragraph. No behavior change.

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions