Release 1.9.0

[lorant-one]

Release proposal per RELEASING.md step 2. Moves [Unreleased] under a dated 1.9.0 heading and states the classification rationale. package.json was already at 1.9.0 from #129.

Nothing is published by this PR. Per RELEASING.md step 4, releases are proposals until the maintainer runs npm publish.

⚠️ This branch has drifted past the release

c97b438 is the release. The other four commits are contributor-environment fixes for failures reported while this PR sat open — they accumulated here because this is the designated working branch, not because they belong to the release.

None of them touches the published artifact: every file they change lives outside packages/core, so none can enter the tarball (re-packed to confirm — 0 matches for turbo.json).

I'd suggest splitting them onto their own PR so this one is a single-commit release you can review and publish cleanly. Say the word and I'll move them.

Classification: minor

The trigger is the shared-internals change — core no longer imports next/* at runtime, and the build emits foundations' SCSS/CSS into dist as deprecated compat entries. Both are intended as improvements that keep observable behavior identical, and RELEASING.md puts that class in a minor so it appears in release notes rather than being buried in a patch. Everything else is additive or internal.

Consumers change nothing. No component, prop, export, token, or CSS class is removed or renamed; no type union narrows; no peer-dependency floor moves.

What's in the release

Added — @once-ui-system/foundations (RFC Phase 1) and the package-contract/boundary test infrastructure (RFC Phase 0): check:package, exports integrity, framework-boundary guard, CSS API-surface and token snapshots, seed interaction tests.

Changed — core no longer imports next/* at runtime; Next.js users keep identical behavior through installed defaults.

Fixed — the ThemeInit ReferenceError that fired on every page load in every consumer app, and the packaging bug that would have made npm install fail. Both are detailed in the changelog entry.

One correction landed here

Two lines described @once-ui-system/foundations as a package consumers can adopt today. It is not published to npm and is not a dependency of this release — the packaging fix made core self-contained. The release notes now say that plainly rather than implying an install path that does not exist. Publishing foundations stays a separate decision on its own timeline; nothing in 1.9.0 depends on it happening.

Verification (RELEASING.md step 3)

• pnpm typecheck — clean
• pnpm build — clean
• pnpm test — 124 passed across 12 files
• ai/manifest.json and ai/spec.json stamped 1.9.0, matching the package version (the AI-consumer rule; ai-manifest-sync.test.ts enforces it)
• pnpm pack — 7 dependencies, no workspace-protocol or pre-release ranges in the tarball
• dependencies and peerDependencies diffed against the published 1.8.3 on npm: byte-identical, so consumers install the same set they do today

Reach

^1.8.x resolves to this release, so the ThemeInit fix reaches existing projects on their next install with no version bump. Checked across the fleet: magic, motion and magic-convert are on ^1.8.2, studio on ^1.7.9 — all satisfied by 1.9.0.

Also in this branch — environment fixes, not release content

Two failures were reported on a fresh Windows clone while this PR was open. Fixing each surfaced the next.

commit	fixes
9db0f57	pnpm dev never built core, so every app failed to resolve @once-ui-system/core/next. The turbo dev task had no dependsOn — unlike build, test and start — and @once-ui-system/docs#dev had zero dependencies in the task graph. dev now depends on ^build, and dev:core / dev:docs / dev:dev route through turbo with ... instead of bypassing it via pnpm --filter.
04ca501	With that fixed, the build reached foundations and died on Node 21.7.1 with ERR_REQUIRE_ESM from inside Sass. Nothing is mis-resolved: sass@1.102.0 wants chokidar@^5, chokidar 5 is ESM-only, and Sass require()s it — which needs Node ≥22.12.0. The repo declared >=20.x, which 21.7.1 satisfies, so nothing warned. Adds .nvmrc and a CONTRIBUTING Requirements section.
3d0669a	That range still allowed Node 20, which reached end of life 2026-04-30 (verified against the node-releases schedule) and which Vercel stops building from 2026-10-01. Tightened to >=22.12.0.
450ec75	engines is only advisory — pnpm does not enforce it — so the Sass trace still appeared. scripts/check-node.mjs now fails with the version found, why the floor exists, and platform-specific fix commands. Wired at root preinstall and foundations prebuild; verified pnpm runs pre-scripts here rather than assuming. Also corrects the CONTRIBUTING instructions, which were wrong on Windows — nvm-windows does not read .nvmrc.

Deliberately avoided: engine-strict=true in .npmrc (pnpm applies it to every transitive package's engines, so it can fail installs for unrelated reasons), and packages/core's own engines field (consumer-facing, and not something to slip into a release PR).

After the publish, not before

Two follow-ups deliberately excluded, because landing them earlier would advertise a version that is not on the registry yet:

1. The 1.9.0 entry on the docs changelog page (apps/docs/src/resources/changelog.jsx).
2. The downstream notification to repos pinning the package, per RELEASING.md step 5.

I'll do both once you've published — just say when.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UsN93NU2Vp5axBdT3nLrZA

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
core-docs	Ignored		Aug 27, 2026 2:43pm

[lorant-one]

Heads-up: 9db0f57 adds a repo-tooling fix to this branch, so the release PR is no longer a single-file diff. Flagging it because this PR is the publish proposal and you may want it kept pure.

It does not touch the published artifact. turbo.json and the root package.json both live outside packages/core, so they can't be in the tarball — re-packed to confirm (0 matches for turbo.json). The npm output is byte-identical to what was verified above.

What it fixes: pnpm dev on a fresh clone failed with

Module not found: Can't resolve '@once-ui-system/core/next'
./apps/docs/src/product/Providers.tsx

apps/docs resolves @once-ui-system/core to the workspace package, whose exports map points into dist/ — so core must be built before any app can resolve it. The turbo dev task had no dependsOn, unlike build (^build), test (build) and start (build). The task graph confirmed @once-ui-system/docs#dev had zero dependencies.

dev now depends on ^build, and the dev:core / dev:docs / dev:dev scripts route through turbo with the ... suffix instead of calling pnpm --filter directly (they bypassed turbo entirely, so they'd have kept failing even with the graph fixed). This matches the build:docs / build:dev pattern already in use.

Verified by wiping packages/core/dist entirely — the docs build then rebuilt foundations → core → docs, 3/3 successful. The original error was reproduced first by removing only dist/next, which produced the reported message byte for byte.

Happy to split it onto its own PR if you'd rather this one stay scoped to the changelog move — say the word and I'll move it.

---

Generated by Claude Code