Question answered

How is Superbee divided into stable semantic, reusable capability, host, and distribution layers, and which of those boundaries are supported entry points for an installed user?

Superbee keeps bundle meaning and storage contracts in one core. Private workspace packages build Git collaboration, serving, Views, rendering, publication, and host integrations around that core. The public superbee package then composes and ships those capabilities without asking users to install or coordinate the internal packages separately.

One public package, staged code entry points

Stable 0.1.3 exposes the installed superbee executable and does not declare import exports. At the pinned current-main boundary and on npm next (0.1.4-pre.1), the same package adds the root superbee export, the read-only snapshot API at superbee/publication, and its bounded bridge at superbee/publication/bridge. Those import paths remain prerelease behavior until 0.1.4 is promoted to stable. The package also ships the agent skill, references, and notices. The source boundary is declared in the superbee package manifest; the current release page remains the installed stable authority.

Nine private @superbee/* workspaces surround the public superbee package workspace. They let contributors test and evolve responsibilities independently, but they are not separate products or installation steps. The CLI build emits the executable plus separate publication and bridge modules, then embeds already-built UI assets; those facts are visible in the build entry point and its source-bundle aliases.

Four inward-facing layers

The package manifests make those inward dependencies reproducible: core defines the base, and its production dependency block contains no Superbee workspace; board-git, the reference server, view-runtime, and markdown-renderer depend inward on it. The UI server, MCP App, and publication facade compose several of those reusable capabilities. The UI package depends, among Superbee workspaces, only on the rendering and View contracts it consumes at runtime.

The visual is a conceptual layer flow, not the full package DAG. A grouped arrow means one or more packages in the upstream group use the downstream layer; it does not claim that every package has every possible edge. The dashed publication edge shows that the prerelease snapshot and bridge modules are built beside the CLI in the same npm artifact. The diagram scales inline with the page; use Expand when its labels need more room on a narrow screen. The table and prose remain the complete readable equivalent, while the pinned manifests preserve the exact package responsibilities and dependencies.

Core architecture constraints

• Core is the semantic authority. Adapters can transport or present bundle state, but they do not create a second definition of documents, Kinds, links, or mutation safety.

• Dependencies point inward. Core remains reusable without a CLI, host UI, Git board, or publication site; outer packages may combine inner capabilities.

• The CLI is the composition and distribution root. Its aliases allow one self-contained executable while the workspace graph remains modular for development.

• Publication is read-only. Views cannot mutate the source bundle on their own. A bundle-propose View may submit one versioned proposal; the trusted shell applies it only after separate human confirmation and version checks.

For how these layers meet humans, agents, Git, and public sites, continue to the system context. For the write path and its transaction authorities, continue to the document mutation lifecycle.

Evidence