Storybook Sense — stbk

Mission

• Request: determine where Storybook makes genuine sense for this fleet, rather than impose a component explorer on incompatible applications.
• Phase 1 — Publish the masterplan:
  • Ground scope, topology, provenance and verification in real source.
  • Publish the decision at wiki.stbk.loca.zone before building Storybook.
• Phase 2 — Reflect and perfect:
  • Critique the published plan, resolve contradictions and republish the corrected decisions.
• Phase 3 — Realize:
  • Build and verify the agreed Storybook delivery at stbk.loca.zone.
• Ordering: publication first, reflection second, implementation third; the plan is not a retrospective description of an existing build.

Verdict in one screen

• Value: expose component surfaces and states that already exist but are currently reached through whole applications.
  • Import genuine component files where their dependency graphs permit isolation.
  • Adapt inline application surfaces only with explicit source attribution; do not invent a reusable library that the source does not contain.
  • Demonstrate behavior, keyboard interaction and source styling, not merely successful rendering.
• Renderer boundary: one native Storybook instance serves one renderer.
  • Svelte, Vue 3 and React will not share one native instance.
  • Composition through refs will federate independently built instances into one browsable shell; it will not merge their renderers.
• CSS boundary: matching renderers are necessary, not sufficient.
  • bits/src/app.css supplies a hand-written Tailwind ink/brand skin, including .btn and global dark base rules.
  • sflw/src/app.css and svelte-chat/src/app.css use Tailwind plus daisyUI with custom CSS-first themes.
  • Loading the bits skin beside daisyUI in one preview document would collide on shared classes and base rules; separate preview bundles will preserve both regimes.
• First-delivery decision: two native Svelte instances.
  • fleet: root instance, daisyUI regime, direct sflw source imports and attributed svelte-chat adaptations.
  • bits: separately built instance under a sub-path, original ink skin, referenced by the root through composition.
  • Cost accepted: two builds and preview environments, not one universal configuration.
• Fence: existing fleet projects will remain byte-unchanged; stories, adaptations and integration configuration will belong to stbk.

Topology

flowchart TB
  subgraph First["First delivery: two native Svelte instances"]
    Fleet["fleet: root shell and Svelte preview; daisyUI regime"]
    Bits["bits: referenced Svelte instance; separate sub-path and ink skin"]
    Sflw["sflw: direct source imports"]
    Chat["svelte-chat: attributed adaptations inside stbk"]
    Demos["bits: direct demo imports"]
    Fleet -->|"refs composition; independent build"| Bits
    Sflw --> Fleet
    Chat --> Fleet
    Demos --> Bits
  end
  subgraph Deferred["Deferred: outside first delivery"]
    Vue["Vue lane: airi; UnoCSS and workspace setup"]
    React["React lane: iconmania; CSS and gallery fixtures"]
    Html["HTML lane: click2punch; iframe page embeds"]
    Php["PHP boundary: wrdp; templates need rewrite; vanilla exception"]
  end
  Fleet -.-> Vue
  Fleet -.-> React
  Fleet -.-> Html
  Fleet -.-> Php
  style Vue stroke-dasharray: 5 5
  style React stroke-dasharray: 5 5
  style Html stroke-dasharray: 5 5
  style Php stroke-dasharray: 5 5

• Solid paths: committed first-delivery composition and provenance.
• Dashed paths: deferred integration boundaries, not configured references or promised native PHP rendering.
• Shared daisyUI tooling will not mean a shared generic theme: sflw and svelte-chat source palettes will remain distinct within their story environments.

Scope at a glance

Project	Framework	Included in first delivery	Why
sflw	Svelte 5	Yes	Existing component files permit direct imports; src/lib/components/SourcePanel.svelte has string props and local copy feedback. The selected custom-node story will require a real SvelteFlow fixture.
svelte-chat	Svelte 5	Yes	UI is inline in src/routes/r/[room]/+page.svelte, not a reusable component library. Selected surfaces will be adapted inside stbk with exact source-range attribution, not labelled imported components.
bits	Svelte 5; upstream Bits UI	Yes	Existing demos such as src/lib/demos/dialog/BasicDemo.svelte combine real primitives with local state. Its custom src/app.css skin requires a separate instance rather than daisyUI substitution.
airi	Vue 3	No	Requires a Vue renderer and UnoCSS integration; its pinned pnpm workspace includes catalogs, patches and a pnpm-invoking postinstall. It already has Histoire stories, so another explorer needs a deliberate integration case.
iconmania	React 19	No	Requires a React renderer and its hand-written src/styles.css; gallery helpers in src/app/workspace-data.ts request SVG/PNG artwork under /api/gallery/, requiring real fixture responses for faithful gallery stories.
click2punch	Vanilla HTML/CSS/JavaScript prototypes	No	Current prototypes/2026-09-15-punch-ui/ documents use floating-major daisyUI 5 and Tailwind browser 4 CDN dependencies. Later HTML stories can embed whole pages in iframes, not import them as components.
wrdp	PHP/WordPress; vanilla JavaScript exception	No	PHP templates require WordPress execution and would need rewriting for native Storybook use; no root package manifest exists. QuizWizz’s assets/js/qwizz-player-renderer.js exposes real DOM factories that could support later HTML stories without rewriting PHP.

• Evidence basis: read-only scout inventories and source inspection; complete paths, versions and isolation hazards are recorded in 20-fleet-evidence.
• Inclusion means the selected source-grounded subset, not complete application coverage; the exact delivery contract is in 30-first-delivery.

Read next

• 10-topology-options: renderer and CSS boundaries, alternatives, and the costs behind the composition decision.
• 20-fleet-evidence: source inventories, dependency provenance, actual reuse seams and reasons for deferral.
• 30-first-delivery: exact stories, import-versus-adaptation contracts, and behavioral acceptance gates.
• 40-runtime-and-hosting: build/runtime choices, static serving, domains and the owner’s bounded deployment procedure.

Status

• Phase: phase-1 plan, written before implementation.
• Next: reflection will challenge this plan and may correct it before republication and realization.
• Build state: no Storybook has been built at the time of writing; no live Storybook or successful browser verification is claimed.
• Evidence boundary: source inspection supports the decisions; build, interaction and hosting verification remain required delivery work.