Skip to main content
SpreadKnowledge is a multi-package React workspace. Each package has a defined responsibility and its own change and proof boundary; edits that cross a boundary require corroborating evidence in EyeParity and DIPP before review.

​
Packages

The composed SpreadKnowledge application. Owns top-level routes, product shells, and the wiring between components, vendor widgets, and auth. Changes here almost always require full-flow visual proof.
The shared React component library consumed by sk-app and vendor surfaces. Owns primitives, product-specific components, and their tokens. Changes require visual proof for every consumer surface that renders the affected component.
Adapters and shims for vendor SDKs used across SpreadKnowledge. Changes are behavior-scoped and require proof on the surfaces that render vendor output.
Reusable widget implementations built on sk-vendor. Owns embeddable analytics and research widgets. Changes require proof on both the widget in isolation and its host surface in sk-app.
The client-side authentication layer. Owns token acquisition, session refresh, and identity plumbing consumed by the app and widgets. Never copy or reuse auth state across product accounts.
The server-side rendering shell that hosts sk-app and the widget surfaces. Owns request handling, host validation, and the render pipeline into HTML.

​
Change and proof boundaries

A change to a package must include visual proof for every downstream surface it can affect. If a change crosses a boundary, add proof for each side.
  • Leaf changes in sk-components must be proven on every host surface that renders the touched component, not only the component in isolation.
  • Adapter changes in sk-vendor require proof on the widgets and app surfaces that render the adapter’s output.
  • Widget changes in vendor-widgets require proof of the widget in isolation and inside sk-app.
  • App changes in sk-app require full-flow proof: entry, primary action, and any downstream routes touched.
  • Auth changes in platform-auth-client require proof of signed-in and signed-out states on every affected surface, without reusing sessions between product accounts.
  • Shell changes in ssr-shell require proof of the SSR HTML and the hydrated client on both the app and widget surfaces.
Never copy auth state, Mintlify access, or deployment credentials between product accounts. Boundary violations discovered in review block the merge.