Ship the renderer-independent Components 4 foundation

[woksin]

Summary

Components 4 replaces the PrimeReact-backed Components 3 foundation with Cratis-owned React APIs, semantic markup, typed parts, state attributes, and design tokens while preserving the established component catalog.

React Aria supplies selected interaction primitives internally; it is not part of the public prop, DOM, styling, provider, or type contract. Native semantic HTML and Components-owned implementations remain the default where they are simpler.

This is a major release. Applications should follow the Components 3 to 4 migration guide.

Added

• Add Components-owned typed parts, stable data-cratis-part values, canonical state attributes, provider messages, strict public declarations, and standalone Common controls. (Complete TSDoc coverage for intentional public exports #173)
• Add semantic Button variant, tone, and shape props and value-first ChangeHandler<T> callbacks.
• Add the stable nine-slot stable-presentation/v1 renderer profile for Button, IconButton, TextInput, TextArea, Checkbox, Radio, Switch, ProgressBar, and Surface.
• Add @cratis/components.mui, @cratis/components.primereact, and @cratis/components.primereact10 as optional presentation adapters. (Library Agnostic components #191, Support MUI #192)
• Add @cratis/components.conformance, a development-only verification harness for renderer adapter authors covering behavior, parts, state, SSR, and accessibility. Ordinary applications do not install it.
• Add @cratis/components.migrator, an optional development CLI for upgrading Components 3 source imports, Button appearance props, and value-first callbacks. It uses syntax-aware codemods internally and is not an application runtime dependency.
• Add a Components ESLint configuration that prevents deprecated root imports and protects renderer-independent boundaries.
• Add a generated Components 3/4 compatibility manifest used by migration tooling and release validation.
• Add the explicit @cratis/components/Chat subpath with sidebar, topic, conversation, message-body, action, mention, emoji, and observable-query surfaces.
• Add Canvas region auto-membership, optional Arc messenger notifications, Canvas controls, and Canvas minimap support.
• Add ItemAddedToRegion, ItemRemovedFromRegion, NoteTextChanged, and ChatMessageAdded messaging contracts.
• Add renderer coexistence, primitive adaptation, custom composition, licensing, migration, capability-profile, Chat, and Canvas messaging documentation.

Changed

• Make the package root setup-only; import components from explicit @cratis/components/* subpaths. (Components has no UI-kit-free entry point: the Arc binding surface only ships inside the PrimeReact package #162)
• Replace PrimeReact provider/theme/pass-through contracts with Components-owned configuration, tokens, typed parts, and semantic state. (CratisComponentsConfig is Partial<PrimeReactProps>, so every consumer's root wiring is typed by a commercial third-party package #163, Replace the mandatory PrimeReact foundation with Cratis-owned React Aria components #170)
• Keep React Aria as an internal dependency behind Components-owned public contracts.
• Move pixi.js to an optional peer used only by Canvas and PivotViewer.
• Rebuild ChatSidebar without PrimeReact dependencies or public PrimeReact contracts.
• Move the generic Pixi-free Chat Kit to @cratis/components/Chat while retaining Canvas ChatBubble compatibility exports.
• Define loaded-page table search, filtering, and sorting separately from server-side complete-result behavior.
• Use one shared repository release version for Core, ESLint, Migrator, Conformance, MUI, PrimeReact 11, and PrimeReact 10 packages.
• Keep renderer ABI major 1 separate from the repository package version.
• Preserve zero-configuration built-in rendering while allowing one optional presentation adapter through CratisComponentsProvider.
• Keep dialogs, dropdowns, date pickers, tooltips, paginator behavior, focus management, overlays, and complex Components composites owned by Core.
• Commit a reproducible dependency lockfile and use immutable installation throughout CI. (Dependency integrity is disabled end to end: no committed lockfile, checksums auto-updated, CI cache keyed on package.json #130)

Fixed

• Keep built-in AutoCommandForm field providers available after aggressive production tree shaking.
• Handle malformed and non-JSON-representable SchemaEditor input without crashing, and recover when valid input returns.
• Keep nested SchemaEditor required-property state consistent across rename, deletion, and type changes.
• Restrict SchemaEditor names and DataTable/Pivot property paths to explicit own data instead of inherited or reserved prototype keys.
• Keep id-less Canvas items available to minimap and fit-to-content without leaking generated React IDs into region membership messages.
• Preserve Canvas registry metadata transitions and provider-fed asynchronous Chat mention candidates.
• Give Chat topic lists semantic list/button markup and readable light/dark token contrast.
• Make DatePicker Today respect date and date-time bounds and preserve provider-owned accessible labels.
• Prevent DataTable date filters from mutating caller-owned dates and preserve loaded-page row indices after filtering and sorting.
• Make query-backed DataTable containers scroll correctly and keep sticky headers attached to the actual scrolling ancestor. (DataTableForQuery doesn't freeze its header / fill its container the way DataTableForObservableQuery does #195, DataTableForObservableQuery's internal table-container never actually becomes scrollable (max-height:100% resolves to none) #196)
• Let Dialog titles wrap instead of overflowing. (Dialog title hardcodes whitespace-nowrap, causing long titles to overflow instead of wrapping #198)
• Keep FilterPanel clear actions outside disclosure buttons and clamp portaled panels within the viewport. (FilterPanel nests a <button> inside its own trigger <button> when a facet has active selections #199, FilterPanel dropdown does not clamp to the viewport - opens off-screen when its trigger sits near the right edge #200)
• Prevent PivotViewer filter, grouping, search, worker-correlation, stale-result, and selection-identity regressions.
• Localize Toolbar's default accessible name through CratisComponentsProvider. (Expand typed provider messages across Components-owned labels #174)
• Document the deprecated clientFiltering prop as a no-op; complete-result behavior belongs to explicit server query arguments. (clientFiltering is declared on DataTableForQuery, DataTableForObservableQuery and DataPage, forwarded by DataPage, and never read by any implementation #159)
• Render string-valued Tag icons as consumer-owned CSS classes instead of literal text. (Tag's icon prop renders a string literally instead of as an icon (Button already handles this) #220)
• Preserve packed TSDoc and @deprecated guidance without shipping declaration-only prose in runtime JavaScript.
• Reject inherited and reserved renderer metadata keys consistently across Core, Conformance, and adapter discovery.

Removed

• Remove PrimeReact, PrimeIcons, PrimeUI, and Prime theme dependencies and peers from @cratis/components.
• Remove renderer-specific styled, compatibility, and primereact-v10-palette exports.
• Remove root component-family namespace exports in favor of explicit subpaths.
• Remove accidental implementation exports that were not intended public contracts.
• Remove unused renderer-specific prop-extension declarations that no component implemented.

[woksin]

@woksin @einari — this comment records why this major takes this direction, why now, what was proven, and what we are deliberately not claiming yet.

Why this is not merely a renderer swap

Components 3 placed Cratis application behavior behind PrimeReact runtime, provider configuration, public types, pass-through slots, theme variables, DOM assumptions, and licensing. PrimeUI's published terms explicitly say that an internal wrapper/design system does not remove developer-seat requirements, and SDK/framework-style redistribution is OEM territory requiring separate clarification.

That meant the commercial renderer was not actually an implementation detail. It was an invisible condition of using Arc-bound dialogs, fields, tables, pages, and notifications.

The technical cost matched the licensing cost:

• renderer types leaked into every product provider and pt contract;
• products translated their tokens through Prime presets/variables before Components could use them;
• exact renderer DOM and slot changes made deep consumer customization brittle;
• accessibility improvements depended on another product's composition/release decisions;
• consumers with their own design system still installed and licensed a UI kit they were replacing.

We shipped Components 3 stabilization first (#169, #171, #172 → v3.5.0) so correctness and accessibility were not held hostage by this major migration.

The long-lived boundary

Components 4 now owns:

• React props, events, markup, and product behavior;
• semantic --cratis-* tokens;
• typed pt parts;
• stable data-cratis-part and state attributes;
• accessibility composition and regression specs;
• a maintained baseline appearance and Storybook.

React Aria remains internal for focus, overlays, collections, keyboard behavior, and internationalized dates. It is Apache-2.0 and style-free, but its types/classes/DOM are not the consumer contract. Native HTML is used when simpler.

Arc and @cratis/arc.react continue to own command/query state and generated bindings. Components owns visual policy. This avoids moving UI choices into Arc and preserves the right future seam.

Why no TanStack or compatibility package now

TanStack Table is a good headless engine, but current Components tables do not yet need enough grouping/pinning/faceting complexity to justify another abstraction. #109 should extract query/table state into Arc React only after a second renderer or real consumer proves the contract.

A Prime compatibility package is not published without written licensing/OEM clarity. Components 3 is the compatibility line while consumers migrate.

Baseline appearance and styling

The default UI is intentionally familiar to Components 2/3 users rather than looking like an unrelated redesign:

• Lara-adjacent blue actions and neutral surfaces;
• familiar 6px radii, control density, overlays, tables, and light/dark depth;
• default Button remains the expected primary action.

We intentionally differ where exact Lara reproduction would retain weaker contrast or semantics. Actions/statuses, focus rings, control boundaries, disabled state, forced colors, and reduced motion are stronger.

The stylesheet contract is now real rather than aspirational:

• tokens — semantic seam with conservative light defaults;
• styles — prefixed internal utilities and layered structure, with no Tailwind Preflight/reset or token duplication;
• theme — optional explicit/automatic dark/light, forced colors, and subtree behavior.

Products can override unlayered CSS without specificity wars. Mixed Prime products receive explicit Cratis z-index controls while configuring Prime independently.

Consumer evidence

Custom-token design system

A representative custom-token design system maps its canonical tokens directly to --cratis-*, including actions, controls, statuses, elevation, and focus. Strict provider typing caught a stale attempted migration that still passed Prime-era global pt/unstyled/ripple; correcting it produced a passing representative compile.

Its locale-aware Prime InputNumber remains an honest bounded Prime island until #175 supplies proven parity. We do not claim this archetype is fully migrated.

Deeply customized canvas/compositor host

Representative Dialog, CommandDialog, Stepper, Toolbar, and stable-part usage compiles. Stable parts, state attributes, and product-owned compositor markers preserve deep customization without making product vocabulary part of the Components contract.

Broad direct Prime and local canvas usage make this a staged migration, with existing obligations retained while those surfaces remain.

Components 2/PrimeReact 10 application

This archetype can move directly to Components 4 while retaining PrimeReact 10 as a bounded direct-use island. It does not need an intermediate PrimeReact 11 migration.

Components 3/PrimeReact 11 multi-entry application with an advanced table adapter

This archetype can start baseline-first with Components light/dark while retaining its separate PrimeReact 11 provider and application-owned advanced table adapter. Components does not force canvas-specific Toolbar composition onto ordinary page actions or claim that its default table implements advanced server state.

Verification

The exact candidate has:

• 262 test files / 795 tests passing;
• 25/25 export subpaths loading;
• Prime-free emitted JS/declarations;
• valid source maps and extension-complete ESM;
• prefixed/no-Preflight CSS gates;
• complete MIT/OFL notices and asset verification;
• Storybook production build plus a11y addon and representative light/dark/product/mobile visual review;
• automated axe foundation scan;
• npm Arc 20.3.1 / 21.19.4 / 22.1.0, pnpm, and Yarn PnP exact-artifact validation;
• representative compile evidence for the custom-token design system and deeply customized canvas/compositor host;
• 404 KB tarball, SHA-256 1d769e97283d4f57ce70aa2a9ce85952d9e96c182d3d045026b2cfe8e0d71fe2.

What remains deliberately open

• Prove a renderer-neutral Arc React query/table state seam #109 — Arc React query/table state seam, after real proof
• clientFiltering is declared on DataTableForQuery, DataTableForObservableQuery and DataPage, forwarded by DataPage, and never read by any implementation #159 — complete-result server filtering/sorting before paging
• Complete TSDoc coverage for intentional public exports #173 — intentional export/TSDoc/API reference audit; no silent 4.x removals
• Expand typed provider messages across Components-owned labels #174 — remaining provider-localized labels
• Add a locale-aware renderer-independent number input #175 — locale-aware number input
• Track strict TypeScript validation for Pixi and upstream declarations #176 — strict TypeScript validation for Pixi/@webgpu/upstream declarations
• Full RC runtime/visual pilots for the custom-token design-system and multi-entry advanced-table archetypes before stable release

A future Vue/Svelte frontend should use Arc transport/generated-client contracts and framework-native state/components. We should extract cross-framework contracts only after another implementation proves them, not pre-abstract React details today.

Requested review focus

1. Public API ergonomics and named behavior versus pt precedence.
2. Keyboard/focus/SSR/hydration behavior.
3. Baseline light/dark familiarity and accessibility.
4. Custom-token ownership and deeply customized canvas/compositor seams.
5. Arc/Arc React versus Components ownership.
6. Migration honesty around direct Prime and advanced tables.
7. Storybook usefulness as the maintained visual contract.

Please treat renderer leakage, inaccessible behavior, undocumented migration edits, misleading compatibility, or a custom-design-system dead end as blockers. This PR should remain unmerged until you are both comfortable with the major and the RC pilot plan.

[woksin]

Final review update: all latest checks on 3d340d6 are green, including aggregate CodeQL, JavaScript build, 25 exports, Arc 20/21/22, pnpm, Yarn PnP, semver label, Markdown, and the truthful local-link gate (101 docs files / 107 local links / 0 broken). The two earlier CodeQL threads are outdated and resolved after replacing the vulnerable regex/sanitizer with deterministic parsing and adversarial self-tests. No human review has arrived. This major remains intentionally unmerged for @woksin and @einari plus RC-pilot review.

[woksin]

Additional licensing research — independent verification of the PrimeReact 11 consumer impact

We have done additional research to be certain about what PrimeReact 11 means for Components 3 consumers, prompted by downstream reports that apps on Components 3 show a license notice. Everything below was verified against primary sources: the published @primereact/core@11.1.0 and @primeui/license-manager@1.0.0 npm artifacts (code inspected directly), PrimeReact 11's bundled LICENSE.md, and the primeui.dev license/pricing pages.

Verified findings

1. The downstream reports are accurate. PrimeReactProvider verifies a license key in a useEffect on mount with no condition on unstyled, theme, or NODE_ENV. Without a valid key it emits a console warning and calls showInvalidLicenseBanner() — a fixed-position, bottom-right, z-index: 2147483647, closed shadow DOM red badge reading "Invalid PrimeUI License", in development and production. Every Components 3 app reaches this through CratisComponentsProvider, on every styling path — including fully unstyled and including the MIT @cratis/components/theme CSS. (This matches what Correct the licensing documentation for PrimeReact 11 #140 documented; we re-verified it against the shipped artifact rather than trusting our own docs.)
2. A key must be obtained from a PrimeUI account in all cases. The free Community tier is eligibility-limited (org: <$1M revenue and <5 developers and <10 employees and <$3M outside funding; individuals/students/non-profits/non-commercial OSS also qualify), supports up to 4 developers, and requires annual renewal. The license-manager code enforces key expiry with a 30-day grace period for community keys, after which the banner returns. Commercial keys are per-developer, perpetual, with the key checked against the installed version's embedded releaseDate (2026-08-05 for 11.1.0).
3. Verification is offline — an ed25519 signature check against an embedded public key, no telemetry, no remote connection. Confirmed in the code; matches LICENSE.md.
4. The upstream primefaces/primereact repository is archived. All future PrimeReact development happens under the PrimeUI commercial model. Existing MIT versions (≤10) stay MIT.
5. The OEM exposure is real and priced: PrimeStore lists OEM licensing as a flat-annual-fee add-on for "redistributing PrimeUI to your customers", and the license restrictions clause requires it for redistribution as a component library or development tool. This validates the PR's position of publishing no Prime compatibility package without written PrimeTek clarification.

What this means

• Components 3.x is a transitional line, not a steady state. Every 3.x consumer either holds and annually renews a PrimeUI key (paid for any org above the small-team thresholds) or ships with a permanent red banner in production. Components 2.x (PrimeReact 10, MIT) is the only fully MIT-safe prior line.
• This PR is the escape hatch, and the research hardens the case for it. We verified the packed Components 4 artifact is Prime-free in runtime deps, peers, emitted JS, and declarations, and that React Aria (Apache-2.0, Adobe-maintained, actively released) does not leak into the public API — so the foundation swap is real, not cosmetic.

Recommended path forward

1. Proceed with Components 4 as designed — renderer independence is the correct long-term posture for both the product and the library; no architectural change requested.
2. Publish an explicit Components 3.x support-horizon statement (in migration.md and the release notes): what class of fixes 3.x receives and for how long after 4.0 stable. "Temporary compatibility line" is currently undated, and the license-renewal treadmill makes parking on 3.x costlier than it looks.
3. Docs: state the cost of staying on 3 inside the 3→4 guide. Documentation/migration.md says Components 3 "remains the compatibility line" but the banner/key/renewal facts live only in migration-from-2.md. Add a short "What staying on Components 3 means" note (key required on every styling path, banner without one, community-key annual renewal + 30-day grace) so a reader of only the 3→4 guide understands the ongoing obligation.
4. Docs: strengthen ui-foundation.md § "Why PrimeReact is no longer the default" with the two objective facts it currently omits: runtime license enforcement on all styling paths (verified in the shipped artifact), and the archived upstream repository. Both are verifiable and make the rationale self-evident.
5. Docs (minor, migration-from-2.md): add that keys are obtained from a PrimeUI account, note the 30-day community grace period and the releaseDate coverage check, and — a genuinely positive fact for consumers' compliance reviews — that verification is offline with no telemetry.

None of this blocks the PR; items 2–5 are documentation-scoped and could land as a follow-up commit on this branch or a fast-follow. The standing disclaimer applies: this summarizes public terms and shipped code behavior for architectural transparency; it is not legal advice.

[woksin]

Owner review summary — Components 4 final candidate

Candidate: febb5665dd9c5e9870fed889b4723b7d0254fd91

The PR body is intentionally limited to consumer-facing release notes. This comment is the short owner/reviewer entry point; the detailed certification record is in #177 (comment).

What Components 4 changes

• Replaces mandatory PrimeReact-backed Core with Cratis-owned public contracts and a zero-configuration built-in renderer.
• Keeps React Aria internal; Cratis owns props, events, semantic markup, accessibility, stable parts/state attributes, and tokens.
• Makes the package root setup-only; components are imported from explicit subpaths.
• Adds the stable nine-slot stable-presentation/v1 renderer profile while keeping interaction-heavy/atomic composition unstable.
• Ships optional MUI, PrimeReact 11, and PrimeReact 10 adapters without making any adapter a Core dependency.
• Adds Conformance, the Components Migrator, an ESLint migration ratchet, isolated renderer Storybook, and fail-closed release evidence.

Shared release scope

All seven public packages use the repository/GitHub release version 4.0.0:

1. @cratis/components
2. @cratis/eslint-plugin-components
3. @cratis/components.migrator
4. @cratis/components.conformance
5. @cratis/components.mui
6. @cratis/components.primereact
7. @cratis/components.primereact10

Renderer ABI major 1 is a separate protocol version, not an independent npm version. Plain DOM and Storybook are private evidence and are never published.

Stable renderer boundary

The stable profile contains exactly:

button, iconButton, textInput, textArea, checkbox, radio, switch, progress, and surface.

Dialogs, Dropdown, DatePicker, Tooltip, paginator, atomic behavior, mixed-renderer islands, discovery, and lazy preload remain Core-owned and/or explicitly unstable.

Important migration decisions

• Components 3 root namespaces move to explicit subpaths.
• Prime-shaped Button props move to variant / tone / shape with compatibility shims and the optional Migrator CLI.
• Components-owned callbacks become value-first.
• CratisComponentsConfig is no longer Partial<PrimeReactProps>.
• Product CSS should target Cratis tokens, typed pt parts, and stable data-cratis-* state—not renderer internals.
• Adapters provide primitive presentation, not full vendor-catalog replacement.

Final verification

• 43/43 hosted checks green on exact candidate
• Source: 386 files / 1,374 tests
• Storybook: 4 renderers × 277 stories × 2 appearances = 2,216 interaction/axe cases, zero exclusions
• Adapter matrix: 18/18 minimum/current × npm/strict-pnpm/Yarn-PnP profiles, using pack-once immutable artifacts
• Strict TypeScript 6: all 24 public JS subpaths
• Arc consumer matrix: 20.3.1, 21.19.4, and 22.6.2
• Production dependency audit: no suggestions
• Tracked-source secret scan: zero findings
• Seven 4.0.0 archives + seven CycloneDX SBOMs independently regenerated byte-identically
• Independent GPT package-documentation and documentation-completeness audits approved
• All seven npm packages published at 4.0.0 with SLSA provenance and verified registry integrity

What reviewers should decide

Please focus review on:

1. The seven-package shared-version release scope.
2. The Cratis-owned/React-Aria-internal architecture.
3. The stable nine-slot renderer boundary.
4. The documented Components 3→4 breaking changes and migration path.
5. Acceptance of the explicitly tracked post-GA limits (cross-browser/manual AT, mixed renderer islands, discovery/preload, theme bridges, slim distribution, API snapshots/evidence inventories, and performance budgets).
6. The fail-closed release policy in release.md.

A line-by-line review of the entire 317-commit branch should not be necessary; this review summary, the technical certification comment, the migration guide, release policy, and ADRs are the decision record.

Current stop point

Components 4.0.0 is merged and published. All seven public packages use latest: 4.0.0, carry npm provenance attestations, and are represented by Release v4.0.0. Publication issue #207 is closed.

[woksin]

Technical certification record — Components 4 final candidate

This comment retains implementation, evidence, limitations, and merge/publication details that do not belong in the consumer-facing release note.

Exact source state

• Candidate: febb5665dd9c5e9870fed889b4723b7d0254fd91
• Published from current main: febb5665dd9c5e9870fed889b4723b7d0254fd91
• Authorized publish workflow: 33336889665, green
• GitHub tag target: 6573b1364a552778d029e479f738deaa07d7a0ce; registry publication ran from febb5665dd9c5e9870fed889b4723b7d0254fd91. The intervening commits changed only publication workflow recovery; package source bytes were unchanged.
• PR Ship the renderer-independent Components 4 foundation #177 merged with a real merge commit; publisher recovery merged through Restore label-driven Components publishing #222, Fix Components 4 publish recovery #224, and Prepare Core before publishing Components #226
• Hosted checks: 43/43 green
• Release-note body: 6,282 bytes; SHA-256 eeee8f9a8b88c588a7c1b572741343ab24f71b2b653a17220cc8758fb46e4ca1

Repository-wide package version

All public packages are 4.0.0; compatibility generation rejects any mismatch or cratisIndependentVersion opt-out:

• @cratis/components
• @cratis/eslint-plugin-components
• @cratis/components.migrator
• @cratis/components.conformance
• @cratis/components.mui
• @cratis/components.primereact
• @cratis/components.primereact10

Renderer ABI major 1 and stable-presentation/v1 are separate protocol identifiers. Plain DOM and Storybook remain private and unpublished.

Verification evidence

• Immutable integrated CI: Source 386 files / 1,374 tests; ESLint 120; Migrator 103; Conformance 20; PrimeReact 10 11; PrimeReact 11 9; MUI 8; Storybook preflight 9; zero warnings.
• Storybook on Arc 22.6.2: 4 renderers × 277 stories × 2 appearances = 2,216 interaction/axe cases, zero story/renderer exclusions.
• Adapter matrix: 18/18 minimum/current × npm/strict-pnpm/Yarn-PnP profiles.
• Matrix artifacts are pack-once: one immutable Core archive and one archive per selected adapter are reused by every profile.
• Arc consumer matrix: 20.3.1, 21.19.4, and 22.6.2.
• Strict TypeScript 6: all 24 public JavaScript subpaths under Bundler and NodeNext; exact upstream exceptions fail stale.
• Package graph: 24 subpaths / 34 React- and DOM-free kernel modules; Prime absent from Core; Pixi reachable only from Canvas/PivotViewer.
• Production dependency audit: no suggestions.
• Tracked-source gitleaks: zero findings.
• Markdown and repository-local links: zero issues.
• Independent GPT package-documentation and completeness audits: approved after source-backed corrections.
• Code, performance, and security reviews found no introduced release blocker.

Reproducible release evidence

All seven registry tarballs were downloaded after publication, matched their npm integrity metadata and package identities, and carry SLSA provenance attestations. Prepublication archives, CycloneDX 1.6 SBOMs, and checksum manifests remain retained as release evidence.

Core archive:

• 513,313 compressed bytes
• 2,284,728 unpacked bytes
• 1,028 files
• SHA-256 84a7f1418a9d52de2c7d9552d4974c2e5de2ecd9d625e5188f160a64c0527a1c
• SHA-512 75d9316414588fe93316191bbc37daad9cbe97b7a33f4614b3c00f9a17009e1739066c9923e4206e3518a7a0e405544f5441b3fde8fd3904b590c5c0cb79e721

Other archive SHA-256 values:

• ESLint 98ebf014d2cb115b47f6497f3d381284cfdc1a41f9df338b38c281f3bc8f281c
• Migrator 0369d3378092ce7717fa718548fae7edfb95aff490e8a76ece51881a2a8927ea
• Conformance e1eca97654a1224de29f037b4189e2375a47f8be70d83cdd51837fed6037814c
• MUI 7875121138c757ac077b3cb77695f6bca4d89b731d74a3ae021069fec98bf554
• PrimeReact 11 e3c04fc72c92cac3907b57ce8f275c03c7566d573f5f2563b3ee1a157b06ba06
• PrimeReact 10 b1b210e834dfd96041d4a7c4de623fe11c71440f1d32361b25a33d9962774275
• Root lockfile 9fe6721ed3cbe3ab4dbd6009ec67a7f7f96873600678db88855ec615df406347

Decision records to review

• DOM/React contract: Documentation/decisions/0001-dom-coupled-contract.md
• Component classification: Documentation/decisions/0002-component-classification.md
• Kernel boundary: Documentation/decisions/0003-kernel-boundary.md
• Stable presentation profile: Documentation/decisions/0004-stable-presentation-renderer-profile.md
• Migration: Documentation/Migration/3-to-4.md
• Release controls: release.md
• Generated compatibility contract: compat-manifest.json

Explicitly tracked limitations

• Track strict TypeScript validation for Pixi and upstream declarations #176 upstream strict declaration defects
• Prove and promote atomic renderer slots and mixed-renderer islands #208 atomic slots and mixed-renderer islands
• Publish schema-driven renderer discovery tooling #209 public renderer discovery
• Design lazy renderer preload for streaming SSR #210 streaming SSR preload
• Add cross-browser and assistive-technology renderer certification #211 Firefox/WebKit/manual assistive-technology certification
• Ship CSS theme bridges and vendor portal-interop recipes #212 theme and portal interop bridges
• Preserve source maps through ESM specifier rewriting #213 source maps through specifier rewriting
• Measure and evaluate a renderer-exclusive slim distribution #214 renderer-exclusive slim distribution
• Restore dependency updates through reviewed pull requests #215 PR-based dependency updates
• Add packed public API snapshots and semver surface diffs #216 packed API snapshots and semver diffs
• Generate reviewable evidence inventories instead of hardcoded counts #217 generated evidence inventories
• Add renderer bundle and runtime performance regression budgets #218 renderer performance budgets
• Harden reusable workflow trust and checkout credentials #219 reusable workflow trust and checkout-credential hardening

Issue auto-close plan

GitHub permits at most ten manually linked closing issues per pull request. PR #177 is manually linked to #130, #159, #162, #163, #170, #173, #174, #191, #192, and #195; those will close automatically when the PR is merged into the default branch.

The authorized real merge commit body must carry these remaining closing references:

Closes #196
Closes #198
Closes #199
Closes #200
Closes #220

After merge, all fifteen issue states must be re-read and verified closed. Merely closing the PR without merging closes none of them.

Merge and publication controls

• Components 4.0.0 is published for all seven public packages; every latest dist-tag is 4.0.0.
• All seven packages expose npm SLSA provenance attestations.
• GitHub release: https://github.com/Cratis/Components/releases/tag/v4.0.0
• Publication issue Prepare owner-authorized Components 4 publication #207 and all fifteen resolved Components 4 issues are closed and verified.