Skip to content

Decide whether every public export must have a Storybook story, and gate it if so #245

Description

@woksin

Context

While triaging leftover local branches from the Components v4 effort, one idea surfaced that is not present in main and is not covered by any existing gate.

An abandoned local branch (pi-agent-899c4c23, "Complete Storybook coverage") carried two files:

  • storybook-coverage.manifest.json — a reviewed manifest classifying all 686 public-barrel-reachable files
  • resolve-public-story-surface.mjs

Its Storybook stories (8 Display/*.stories.tsx) already landed in main. These two remaining files did not, and on the branch they were wired to nothing — no npm script, no CI job, referenced only by each other.

The actual gap

main has no equivalent invariant. Nothing matches public-story, story-surface, or storybook-coverage. Storybook/package.json's verify-indexes only validates the built index.json — it does not assert that every public export has a story.

So the question is open: should every public export be required to have a Storybook story?

Decision needed

  • If yes — this should be built fresh against today's export surface and wired into CI. The two stale branch artifacts are not a useful starting point and should not be resurrected.
  • If no — close this issue; the gap is intentional.

Provenance

The branch itself has been deleted. It is preserved in a verified git bundle at:

unfinished-work-audit-2026-08-21/preservations/local-only-refs-2026-09-03/Components.bundle

Recover with git bundle unbundle if the manifest is ever wanted for reference.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions