Org Blocks

Blocks & Themes

@wabbit/tome-blocks-org-packv0.5.1

Render-ready organization/community blocks — division card, member card, member grid, event calendar, event list item, org chart, document link, and campaign banner; static today, scaffolded for future @wabbit/tome-org hydration.

Installnpm install @wabbit/tome-blocks-org-pack

Overview

@wabbit/tome-blocks-org-pack

Organization block pack for the Tome platform — render-ready blocks (DivisionCard, MemberCard, MemberGrid, EventCalendar, EventListItem, OrgChart, DocumentLink, CampaignBanner) for org/community surfaces.

Config descriptors are exported from .; React render components from ./render. All blocks are fully static today — they render exactly the props an author enters, and carry no @wabbit/tome-org peer dependency. The pack does detect whether @wabbit/tome-org is registered (isOrgLayerPresent/resolveOrgLayer in src/index.ts) and each block's config retains fields shaped to match the org layer's records — this is scaffolding for a future hydration wave, not a live integration. Trigger to build it: when a consumer needs a block in this pack to render live @wabbit/tome-org data, wire the resolver into a server-side wrapper at that seam.

Install

On a Tome site (meta-package path)

Not currently bundled by @wabbit/tome-blocks' registerAll() (a pre-existing scope decision — see that package's README, "Public API" section). Install this pack directly even on a Tome site.

On a stock Payload site — add to an existing blocks field

npm install @wabbit/tome-blocks-org-pack

@wabbit/tome-blocks-core is a required peer and installs automatically (npm 7+/pnpm). Add the blocks you want alongside your existing ones and render them — see @wabbit/tome-blocks-core's "Add Tome blocks to an existing Payload project" for the full walkthrough:

// payload.config.ts
import { memberCardBlock, eventCalendarBlock } from '@wabbit/tome-blocks-org-pack'
// blocks: [...existingBlocks, memberCardBlock.block(), eventCalendarBlock.block()]

// blockComponents.ts
import { renderers as orgRenderers } from '@wabbit/tome-blocks-org-pack/render/register'
import { adaptRenderersForPayload } from '@wabbit/tome-blocks-core/render'
// blockComponents: { ...adaptRenderersForPayload(orgRenderers) }

@import '@wabbit/tome-blocks-core/styles.css';

Registering everything from scratch instead:

// payload.config.ts
import { BlockRegistry, BundleRegistry } from '@wabbit/tome-blocks-core/registry'
import { register } from '@wabbit/tome-blocks-org-pack'

const blockRegistry = new BlockRegistry()
const bundleRegistry = new BundleRegistry()

register(blockRegistry, bundleRegistry)

// Use blockRegistry.resolveAll() to get Payload Block configs

| Peer | Range | Required | |---|---|---| | payload | >=3.67.0 | yes | | react | >=19.0.0 | yes | | react-dom | >=19.0.0 | yes | | @wabbit/tome-blocks-core | >=0.18.0 <1.0.0 | yes |

@wabbit/tome-org is an optional peer (peerDependenciesMeta) — see the detection note above.

Block list

| Slug | Name | Notes | |---|---|---| | division-card | Division Card | Org sub-unit/division summary card | | member-card | Member Card | Individual member profile card | | member-grid | Member Grid | Grid of member cards | | event-calendar | Event Calendar | Calendar view of org events | | event-list-item | Event List Item | Single event row (list context) | | org-chart | Org Chart | Hierarchical org structure display | | document-link | Document Link | Linked document/resource reference | | campaign-banner | Campaign Banner | Announcement/campaign call-out banner |

Public API

// config (Payload collections / Pages block list)
import { divisionCardBlock } from '@wabbit/tome-blocks-org-pack'
// render — DivisionCard (and every other block component) is exported from
// the `./render` barrel; there is no per-component subpath in the exports map
import { DivisionCard } from '@wabbit/tome-blocks-org-pack/render'

| Export | Subpath | Description | |---|---|---| | Block descriptors (divisionCardBlock, memberCardBlock, memberGridBlock, eventCalendarBlock, eventListItemBlock, orgChartBlock, documentLinkBlock, campaignBannerBlock) + register(blockRegistry, bundleRegistry) + isOrgLayerPresent() | . | Payload block config descriptors, bundle registration, and the @wabbit/tome-org layer-detection flag | | DivisionCard, MemberCard, MemberGrid, EventCalendar, EventListItem, OrgChart, DocumentLink, CampaignBanner + orgPackRenders map | ./render | Legacy self-registering render barrel | | renderers map + registerRenderers() | ./render/register | Explicit registration (server-safe adapter contract) — imports each component directly, no side effects on import | | getDemoProps(blockSlug, variant, ctx?) (plus tree-shakeable per-block demo functions) | ./demo | Pack-level demo-props dispatcher feeding the auto-gallery route; returns null for unknown slugs | | orgPackBlockMeta (per-block meta + variants, in registration order) | ./meta | Payload-free surface for the gallery storefront |

Server / client posture

All 8 renderers under src/render/ are plain static components — zero carry a 'use client' directive (verified 2026-07-12; scripts/assert-rsc-boundaries.mjs MANIFEST: blocks-org-pack: 0). They render safely from either a server or client component graph. Prefer the ./render/register subpath (registerRenderers()) when registering from payload.config.ts or any Node/server context — the legacy ./render barrel re-exports CSS Modules at its root, which crashes Node's ESM loader outside a bundler (see @wabbit/tome-blocks's README, "Two rules for consumers"); ./render/register imports each component directly and sidesteps that barrel-level hazard.

Built with tsup (bundle: false, dual ESM/CJS, CSS mirrored to dist/).

Blocks

`division-card`

A single division/department display — logo, name, description, member count, and named leader. The unit-level companion to member-card, summarizing a sub-org rather than a person. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Introducing a division, department, or regional sub-unit on an about/structure page
A "Our divisions" section where each unit gets a summary card with its leader and headcount
Leading into a member-grid or org-chart that drills into that division

Page types

about
docs
dossier

How to use

Provide name (required) plus description, memberCount, logoUrl, and leaderName — these are the only data source today, not a static fallback. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Division record. Use one card per unit, or several side by side, as the header for the people that belong to it. One variant (default).

Pairs with

member-grid
member-card
org-chart
document-link

Follows

org-chart

Precedes

member-grid
member-card

Avoid when

Profiling an individual rather than a unit — use member-card
You need the full three-level structure tree — use org-chart

application

`member-card`

A single member profile card — avatar, display name, role, and position for one person. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Spotlighting one person on an about/leadership page (a director, a guild leader, a founder)
A "meet the director" callout where a single profile carries the section
Inside a custom layout where you place individual cards by hand rather than a generated grid

Page types

about
portfolio
dossier

How to use

Provide one member: displayName (required), plus avatarUrl, rank, and position — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Member record. This is the single-member primitive — to lay out many people in a generated grid use member-grid, which renders the same card shape from an array. One variant (default).

Pairs with

member-grid
division-card
org-chart

Follows

division-card

Precedes

member-grid

Avoid when

Showing a team or roster — use member-grid (array-driven) instead of hand-placing cards
You need the org hierarchy itself rather than individuals — use org-chart

application

`member-grid`

A responsive grid of member cards under an optional heading — the team/roster directory block. Renders the same card shape as member-card from a list, with column count and an item cap. Fully static — renders the authored members array; no @wabbit/tome-org peer required.

When to use

A "Meet the team" / "Our people" / "Leadership" section listing many members at once
A company or community directory page where you want every member tiled in a grid
Any directory of people you want generated from data rather than placed card by card

Page types

about
portfolio
dossier

How to use

Set a heading, pick columns (2, 3, or 4), and cap with maxItems. Supply the members array — it is the only data source today, not a static fallback. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this grid to render a live Member collection. This is the array/layout counterpart to member-card — same per-person card, generated in bulk. One variant (default).

Pairs with

member-card
division-card
org-chart
campaign-banner

Follows

division-card
org-chart

Precedes

event-calendar

Avoid when

Featuring a single person — use member-card
You want the reporting hierarchy rather than a flat people grid — use org-chart

application

`event-calendar`

An upcoming-events list under an optional heading — each row carries a title, start time, status (scheduled/live/completed/cancelled), and location. The array/section counterpart to event-list-item. Fully static — renders the authored events array; no @wabbit/tome-org peer required.

When to use

An "Upcoming events" / "What's on" section on an org, community, or company page
A schedule of workshops, meetups, or streams where each entry needs date and status
Any place you want the next N events generated from data with a single block

Page types

about
docs
dossier

How to use

Set a heading and cap with maxItems, then supply the events array (title required, plus startsAt ISO string, status, location) — it is the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this block to render the live Event collection. Use this for the full list; drop a single event-list-item into a sidebar or feed when you only need one row. One variant (default).

Pairs with

event-list-item
campaign-banner
member-grid

Follows

campaign-banner
member-grid

Precedes

document-link

Avoid when

You only need one event row in a sidebar or feed — use event-list-item
Promoting a single flagship campaign rather than a dated list — use campaign-banner

application

`event-list-item`

A single event row — title, start time, status, and an optional click-through — sized for feeds, sidebars, and inline placement. The single-item primitive behind event-calendar. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Surfacing one upcoming event in a sidebar, footer, or "next event" callout
Inline within editorial content where a full calendar would be too heavy
Hand-placing individual event rows rather than generating a list

Page types

about
docs
blog

How to use

Provide title (required) plus startsAt (ISO string), status, and an optional href — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this row to render a live Event record. This is the single-row counterpart to event-calendar — same row shape, one at a time. One variant (default).

Pairs with

event-calendar
member-card
document-link

Follows

event-calendar

Avoid when

Listing several upcoming events — use event-calendar (array-driven) instead of stacking rows
You need date, status, and location laid out as a section header — use event-calendar

application

`org-chart`

A simple three-level hierarchy display — a top-level unit, its teams, and their groups — the structure-of-the-org block, showing reporting lines rather than individual profiles. Fully static — renders the authored teams array; no @wabbit/tome-org peer required.

When to use

An "Org structure" / "How we are organized" section showing the levels from department down to working groups
Orienting a reader before they meet the people — the map that member-grid then fills in
A dossier page where the unit hierarchy itself is the information

Page types

about
docs
dossier

How to use

Set divisionName (required) and supply the teams array (each team carries its squads) — it is the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this chart to render live org-structure records. Use it once near the top of a structure page to frame the divisions and people that follow. One variant (default).

Pairs with

division-card
member-grid
member-card

Precedes

division-card
member-grid

Avoid when

Showing people rather than structure — use member-grid or member-card
Summarizing one unit with its leader and headcount — use division-card

application

`document-link`

A linked document card — title, category label (SOP, Policy, Handbook), and last-updated timestamp pointing at a document URL. The resource/reference primitive for an org. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

A "Resources" / "Documents" / "Policies" section linking out to SOPs, handbooks, or forms
A knowledge-base or onboarding page where members find the canonical documents
Anywhere you want a clean, dated link card instead of a bare hyperlink

Page types

docs
about
dossier

How to use

Provide title (required) and href (required) plus category and updatedAt (ISO string) — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this card to render a live Document record. Stack several to form a resource list, often under a division-card or near an org-chart on a structure/docs page. One variant (default).

Pairs with

division-card
org-chart
event-calendar

Follows

division-card
org-chart

Avoid when

Linking to an event rather than a document — use event-list-item
You want rich body content inline rather than a link out — use a richText/content block

application

`campaign-banner`

A full-width campaign hero — campaign name, tagline, full-bleed banner image, objective count, and a CTA. The promotional top-of-page block for an org campaign or initiative. Fully static — renders the authored fields; no @wabbit/tome-org peer required.

When to use

Topping a campaign or initiative page with a cinematic banner and a single call to action
Announcing an active campaign on a community/org home or landing section
Driving members toward a campaign detail view or sign-up via the CTA

Page types

about
portfolio
dossier

How to use

Set codename (the campaign's display name, required) plus tagline, bannerUrl, objectiveCount, and the ctaLabel/ctaUrl pair — these are the only data source today. @wabbit/tome-org is not wired in yet; the isOrgLayerPresent/resolveOrgLayer seam in src/index.ts is scaffolding for a future hydration wave, to be wired when a consumer needs this banner to render a live Campaign record. Place it at the very top of the page as the hero, with the objective list, member-grid, or event-calendar following beneath. One variant (default).

Pairs with

event-calendar
member-grid
org-chart

Precedes

event-calendar
member-grid

Avoid when

You need a generic marketing hero outside the org-campaign context — use a marketing hero block
Listing dated events rather than promoting one campaign — use event-calendar

application

Exports

@wabbit/tome-blocks-org-pack
@wabbit/tome-blocks-org-pack/render
@wabbit/tome-blocks-org-pack/render/register
@wabbit/tome-blocks-org-pack/demo
@wabbit/tome-blocks-org-pack/meta

Changelog

v0.5.1patch

c3468b0: Layer detection now runs through blocks-core's `createLayerProbe` instead of a local `tryGetLayerRegistry` copy. The dynamic core import stays in this pack, and memo semantics are unchanged. The `@wabbit/tome-blocks-core` peer floor goes up to `>=0.18.0` because that is the first version exporting the helper.

c3468b0: Layer detection now runs through blocks-core's `createLayerProbe` instead of a local `tryGetLayerRegistry` copy. The dynamic core import stays in this pack, and memo semantics are unchanged. The `@wabbit/tome-blocks-core` peer floor goes up to `>=0.18.0` because that is the first version exporting the helper.

v0.5.0minor

404d325: Tome block packs now install into an existing Payload project the way the README says: one `npm install`, one CSS import, no undocumented steps. Proven by the new fresh-install smoke test (`scripts/blocks-fresh-install-smoke.mjs`) against a brand-new `create-payload-app` website-template site. **Consumers: list `@wabbit/tome-blocks-core` and `@wabbit/tome-ui` in your own `package.json`** if you import from them (npm 7+ and pnpm install required peers automatically, so a fresh `npm install` of a pack already brings them in). - **One shared `blocks-core` per site.** Every pack, `blocks-house` and `blocks-extras` now declare `@wabbit/tome-blocks-core` (and, where used, `-house` / `-extras`) as a required peer with an explicit range instead of a regular dependency, so a site gets exactly one hoisted copy and one adapter registry. - **No more ERESOLVE in plain Payload sites.** `blocks-core` no longer declares `@wabbit/tome-core` or `@wabbit/tome-catalog` (their optional peer graph pulled `better-auth` → `@sveltejs/kit` → `vite@8` against a site's `vite@7`). The `block-bundle` product type still auto-registers when both are installed; new structural types `BlockBundleProductTypeDeps`, `BlockBundleProductTypeRegistryLike`, `RegisterProductTypeHooksLike`. - **Tokens in one line:** `@import '@wabbit/tome-blocks-core/styles.css';` (new export; imports `@wabbit/tome-ui/tokens`). `@wabbit/tome-ui` is now a required peer of `blocks-core`. - **Rich text and images render with no adapter setup.** Built-in defaults render Lexical through `@payloadcms/richtext-lexical/react` and resolve populated Payload uploads; an unpopulated upload id warns once in every environment (previously content vanished silently in production). Registered adapters still win. - **Payload's spread-props convention:** new `adaptRenderersForPayload(renderers)` / `adaptRendererForPayload(Component)` wrap any pack's `renderers` map for a site that renders `<Block {...block} />`. - **Slug collisions with Payload's templates** (`cta`, `banner`, `archive`, `content`, `code`): new `applyBlockSlugOverrides(blocks, overrides)` and `remapRendererSlugs(renderers, overrides)` (`@wabbit/tome-blocks-core/slugOverrides`). Defaults are unchanged; no stored data migrates. - **`blocks-house`** owns `gsap` and `hls.js` as dependencies (previously optional peers that still broke the build when missing), and registers GSAP's `ScrollTrigger` itself before first use. - **Full-bleed bands actually span the grid.** Eight `pinnedBand` blocks (cinema-pack AmbientBand, MediaPanel, PullInterlude, SceneCaption, ScenePlate, ScrubStory, StatementBand; blocks-house FullBleedInterstitial) now declare `grid-column: 1 / -1` at their root as the contract requires. **Visible change:** inside a tome-ui `.grid`, these render edge to edge where they were previously squeezed to content width. - **`@wabbit/tome-ui`:** `.grid` declares `reading-start` / `reading-end` below 768px (aliased to the content column), so blocks placed on the reading column no longer collapse to a sliver on phones. - Every pack README gains an "Install into an existing Payload project" section and a peer table that matches `package.json`; `blocks-core`'s README carries the full walkthrough.

404d325: Tome block packs now install into an existing Payload project the way the README says: one `npm install`, one CSS import, no undocumented steps. Proven by the new fresh-install smoke test (`scripts/blocks-fresh-install-smoke.mjs`) against a brand-new `create-payload-app` website-template site. **Consumers: list `@wabbit/tome-blocks-core` and `@wabbit/tome-ui` in your own `package.json`** if you import from them (npm 7+ and pnpm install required peers automatically, so a fresh `npm install` of a pack already brings them in). - **One shared `blocks-core` per site.** Every pack, `blocks-house` and `blocks-extras` now declare `@wabbit/tome-blocks-core` (and, where used, `-house` / `-extras`) as a required peer with an explicit range instead of a regular dependency, so a site gets exactly one hoisted copy and one adapter registry. - **No more ERESOLVE in plain Payload sites.** `blocks-core` no longer declares `@wabbit/tome-core` or `@wabbit/tome-catalog` (their optional peer graph pulled `better-auth` → `@sveltejs/kit` → `vite@8` against a site's `vite@7`). The `block-bundle` product type still auto-registers when both are installed; new structural types `BlockBundleProductTypeDeps`, `BlockBundleProductTypeRegistryLike`, `RegisterProductTypeHooksLike`. - **Tokens in one line:** `@import '@wabbit/tome-blocks-core/styles.css';` (new export; imports `@wabbit/tome-ui/tokens`). `@wabbit/tome-ui` is now a required peer of `blocks-core`. - **Rich text and images render with no adapter setup.** Built-in defaults render Lexical through `@payloadcms/richtext-lexical/react` and resolve populated Payload uploads; an unpopulated upload id warns once in every environment (previously content vanished silently in production). Registered adapters still win. - **Payload's spread-props convention:** new `adaptRenderersForPayload(renderers)` / `adaptRendererForPayload(Component)` wrap any pack's `renderers` map for a site that renders `<Block {...block} />`. - **Slug collisions with Payload's templates** (`cta`, `banner`, `archive`, `content`, `code`): new `applyBlockSlugOverrides(blocks, overrides)` and `remapRendererSlugs(renderers, overrides)` (`@wabbit/tome-blocks-core/slugOverrides`). Defaults are unchanged; no stored data migrates. - **`blocks-house`** owns `gsap` and `hls.js` as dependencies (previously optional peers that still broke the build when missing), and registers GSAP's `ScrollTrigger` itself before first use. - **Full-bleed bands actually span the grid.** Eight `pinnedBand` blocks (cinema-pack AmbientBand, MediaPanel, PullInterlude, SceneCaption, ScenePlate, ScrubStory, StatementBand; blocks-house FullBleedInterstitial) now declare `grid-column: 1 / -1` at their root as the contract requires. **Visible change:** inside a tome-ui `.grid`, these render edge to edge where they were previously squeezed to content width. - **`@wabbit/tome-ui`:** `.grid` declares `reading-start` / `reading-end` below 768px (aliased to the content column), so blocks placed on the reading column no longer collapse to a sliver on phones. - Every pack README gains an "Install into an existing Payload project" section and a peer table that matches `package.json`; `blocks-core`'s README carries the full walkthrough.

v0.4.5patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.4patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.3patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.2patch

@wabbit/tome-blocks-core@0.16.0

@wabbit/tome-blocks-core@0.16.0

v0.4.1patch

c1f3830: Demo imagery now resolves without a network. Every org-pack image field is a plain-text URL (no Payload upload), and the demos pointed at `https://cdn.wabbit.example/…`, a domain that does not exist — so member-card, member-grid, division-card and campaign-banner rendered broken-image glyphs in any gallery preview or thumbnail capture. New `demo-media.ts` emits a self-contained SVG data URI per subject (neutral tonal field + initials; no brand colour), and `DemoContext` gains `placeholderImageUrl` so a host can substitute real imagery. Found while registering Org Blocks on wabbit.com/blocks (2026-09-05).

c1f3830: Demo imagery now resolves without a network. Every org-pack image field is a plain-text URL (no Payload upload), and the demos pointed at `https://cdn.wabbit.example/…`, a domain that does not exist — so member-card, member-grid, division-card and campaign-banner rendered broken-image glyphs in any gallery preview or thumbnail capture. New `demo-media.ts` emits a self-contained SVG data URI per subject (neutral tonal field + initials; no brand colour), and `DemoContext` gains `placeholderImageUrl` so a host can substitute real imagery. Found while registering Org Blocks on wabbit.com/blocks (2026-09-05).
Updated dependencies - @wabbit/tome-blocks-core@0.16.0

v0.4.0minor

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` (ruled 2026-09-01). The platform declared React peers in five different shapes — `>=18.0.0`, `>=18`, `^18 || ^19`, `^18.3.0 || ^19.0.0`, `^19.0.0` — while its kernel (`@wabbit/tome-core`) and five app-layer packages already required `>=19`. Any package advertising React 18 was advertising a configuration that could not be installed alongside the kernel, so the split was never a supported matrix; it was drift. One shape now, and it is the honest one. These nine version independently of the `linked` blocks family (which gets its own coordinated bump), so they are listed here: - `@wabbit/tome-admin`, `@wabbit/tome-admin-pro` — from `^18.3.0 || ^19.0.0` - `@wabbit/tome-blocks-gallery` — from `^18 || ^19`; devDeps `react`/`@types/react` `^18.0.0` → `^19.0.0` - `@wabbit/tome-blocks-org-pack` — from `>=18.0.0`; same devDep correction - `@wabbit/tome-engine`, `@wabbit/tome-motion`, `@wabbit/tome-rpg`, `@wabbit/tome-webgl` — from `>=18` - `@wabbit/tome-ui` — from `>=18.0.0` The `^18` devDependency pins on the two block-shaped packages were already fiction: the root `pnpm.overrides` pins `@types/react` to `19.2.14`, so both have been building against React 19 types regardless. Correcting them changes the manifest, not the resolved tree. Consumer impact: a React 18 consumer can no longer install these. That install was already impossible with the kernel in the graph.

b01ca1f: Raise the `react` / `react-dom` peer floor to `>=19.0.0` (ruled 2026-09-01). The platform declared React peers in five different shapes — `>=18.0.0`, `>=18`, `^18 || ^19`, `^18.3.0 || ^19.0.0`, `^19.0.0` — while its kernel (`@wabbit/tome-core`) and five app-layer packages already required `>=19`. Any package advertising React 18 was advertising a configuration that could not be installed alongside the kernel, so the split was never a supported matrix; it was drift. One shape now, and it is the honest one. These nine version independently of the `linked` blocks family (which gets its own coordinated bump), so they are listed here: - `@wabbit/tome-admin`, `@wabbit/tome-admin-pro` — from `^18.3.0 || ^19.0.0` - `@wabbit/tome-blocks-gallery` — from `^18 || ^19`; devDeps `react`/`@types/react` `^18.0.0` → `^19.0.0` - `@wabbit/tome-blocks-org-pack` — from `>=18.0.0`; same devDep correction - `@wabbit/tome-engine`, `@wabbit/tome-motion`, `@wabbit/tome-rpg`, `@wabbit/tome-webgl` — from `>=18` - `@wabbit/tome-ui` — from `>=18.0.0` The `^18` devDependency pins on the two block-shaped packages were already fiction: the root `pnpm.overrides` pins `@types/react` to `19.2.14`, so both have been building against React 19 types regardless. Correcting them changes the manifest, not the resolved tree. Consumer impact: a React 18 consumer can no longer install these. That install was already impossible with the kernel in the graph.
0836ef5: dist now raw-Node loadable: relative specifiers get explicit extensions post-build. `build` gains `&& node ../../scripts/fix-dist-extensions.mjs --strict` as its last step, joining the 13 packages that already ran it. tsup builds `bundle: false` and emits relative specifiers exactly as the TypeScript source wrote them — extensionless — which bundlers resolve and raw Node does not (ESM `ERR_MODULE_NOT_FOUND`; CJS worse, `require('./x')` finds the ESM `.js` twin and Node 22+ `require(esm)` then dies on that file's own extensionless import). Every consumer outside a bundler hit this: the payload CLI under plain node, `generate:types`, `generate:importmap`, ops scripts, codegen tools. No source changes, no API changes, and bundler consumers are unaffected — extensioned relative specifiers are universally resolvable. Two supporting changes made the wiring possible, both in repo scripts rather than package source. `fix-dist-extensions.mjs` now skips bundler-asset specifiers (`.css`, `.module.css`, `.scss`, fonts, images, shaders) by explicit extension allowlist instead of reporting them as unresolvable — that single gap is why the 13 prior adopters were exactly the 13 packages that ship no CSS, since `--strict` exited 1 on any package with a relative stylesheet import. Dotted MODULE names (`./config.meta`, `./x.variants`, `./y.demo`) are deliberately NOT treated as assets and still get `.js`/`.cjs` appended. `assert-node-loadable.mjs` gained the matching carve-outs so the new repo-wide CI gate reports real defects only: a resolution failure whose path lands under `node_modules` is a peer SKIP (next@15 has no exports map, so `next/image` fails as an absolute path), and a bundler-asset load failure is an environmental SKIP (CJS surfaces it as `SyntaxError: Unexpected token '.'` raised from inside the stylesheet). Verified before/after on four packages built one at a time: print 8 FAIL → 0, readout 22 FAIL → 0, ai 3 FAIL → 0, gamification 2 FAIL → 0 (its failure was the other signature — a `directory import` missing `/index`). cop was already clean on a fresh build, so the audit's "27 of 46 fail" figure includes at least one package whose local dist was merely stale.
73081e6: Manifest metadata: `homepage`, `bugs`, `engines`. All 46 publishable manifests were missing the three fields a consumer sees before any code (2026-09-01 sale-readiness audit §6). Metadata only — no source, no build, no runtime change. - `homepage` deep-links to that package README on GitHub (`.../tree/main/packages/<dir>#readme`). Without it a registry page links to the monorepo root and the reader has to guess which of 46 folders they want. - `bugs.url` points at the repo issue tracker, so a paying customer has a place to report a defect that is not email. - `engines.node` is `>=22`, matching the root `engines` and `.nvmrc` set the same day. This is a real floor, not decoration: CI on Node 20 could not expand the glob the block packs use for `node --test`, and a package installed on Node 20 fails at a runtime the installer cannot connect back to the version. The forcing function ships with the change: `scripts/assert-manifest-metadata.mjs` (root `pnpm assert:manifest-metadata`, wired into `platform-discipline.yml` beside `assert:license-metadata`) fails when any publishable manifest lacks `description`, `repository.directory` matching its own folder, `homepage`, `bugs`, `engines.node` equal to the repo floor, `license`, `files` or `sideEffects`. It reported 138 violations before this change and 0 after.
Updated dependencies [57875ba]
Updated dependencies [b01ca1f]
Updated dependencies [0836ef5]
Updated dependencies [73081e6]
Updated dependencies [090e984]
Updated dependencies [73081e6] - @wabbit/tome-blocks-core@0.16.0

v0.3.17patch