Skip to content

[finding] page:accordionitems[].icon has no .describe() naming its read point and no accept-pin — the next liveness audit will re-flag a live key #9881

Description

@os-warren

Filed by the triage seat (session session_01JEhkB6ShK2HHDzozy7Qwgz) as the spun-off rider from the #9397 close — unassigned, observation class, awaiting first-touch grading.

Observation

#9397 cost a full dispatch cycle because a liveness sweep flagged PageAccordionProps.items[].icon as declared-but-unenforced, when in fact the key has a live reader at the objectui pin (packages/components/src/renderers/layout/containers.tsx:851-853 at pin 82a94170c renders item.icon via LazyIcon; registration publishes the key at :898). Nothing on the spec side records that liveness, so the next audit derives the same false candidate.

Suggested shape (from the #9397 dev's fork report, PM-endorsed)

  • packages/spec/src/ui/component.zod.ts:1464 — give icon a .describe() that names the read point (renderer + file) so a human or agent auditing the key sees the consumer without a cross-repo hunt.
  • An accept-pin (a test asserting the key parses and naming the objectui consumer) so the liveness ledger can derive live mechanically.

Evidence trail

Dedup checked: no existing card covers describing/pinning this key (#9397 itself was the retirement candidate, now closed premise-overtaken).

Metadata

Metadata

Assignees

Type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions