Approaching the freeze: what the October flip costs

Correction, 2026-08-31. This entry was published 2026-07-27 and three of its version claims have since gone stale. 0.3.0 published to npm on 2026-08-25 and 0.3.1 on 2026-08-28, both at access: restricted; the scope is 41 scoped packages, not 40. The October dates, the freeze-cut reasoning and the one-way-door argument are unchanged, and the version that gets frozen is still 0.4.0. The last entry on this feed laid out four steps between here and the October open-source launch: freeze the API, relicense from MIT to Apache-2.0, add contribution plumbing (a DCO or CLA), then flip the packages public. It promised the next entries would document those as they happen rather than after.

One of the four is done and a second is half-built. This is that report, plus the honest version of what the rest actually costs.

Flare is a modular 2D engine in TypeScript for animation, gamification, and interactive UI, running the same code on React Native through react-native-skia and on the web through CanvasKit.

The relicense landed

On 2026-07-12 the engine relicensed from MIT to Apache-2.0. One commit, 168 files, almost all of them mechanical: the root LICENSE and NOTICE plus a copy of both in every package, the license field on all 41 package manifests, and the license line in the package READMEs, so the metadata and the tarballs agree rather than the README claiming one thing and the manifests another.

Apache-2.0 buys the thing MIT does not have: an explicit patent grant, which is the clause a legal review at a mid-size company actually looks for. It also comes with Section 6, which says the license grants no trademark rights. That needed spelling out rather than leaving implied, so a TRADEMARK.md shipped alongside. You can say “built with Flare Engine”, call your thing a Flare Engine plugin, and redistribute under Apache-2.0 keeping LICENSE and NOTICE intact. What it asks you not to do is publish under the @flare-engine scope, or name a product, fork, or service in a way that implies endorsement or affiliation. That qualifier is doing real work, and here is why: flarerpg.org is a separate, pre-existing action-RPG engine that also distributes a package named flare-engine. Different project, no affiliation, and no claim over their name - the disambiguation note exists so nobody confuses the two, not to assert priority over a name that was in use first.

If you read the previous entry here, it said the repository’s LICENSE file still read MIT and the relicense was a scheduled pre-launch step. That is now out of date, which is the good kind of out of date. The relicense is done, in the repo, today.

Governance is in

The same day: SECURITY.md with a private vulnerability-reporting path, a Contributor Covenant 2.1 code of conduct, a two-line CONTRIBUTING correction that finally links the code of conduct and swaps the contributor license to Apache-2.0, structured bug-report and feature-request issue templates, a pull-request template, and a funding file. Eight files. None of it is glamorous and all of it has to exist before strangers can file anything.

One caveat, because it is the sort of thing a careful reader catches: SECURITY.md’s supported-versions table names 0.3.x and marks everything below it unsupported. 0.3.0 did not exist yet. That document was written for the world on the other side of the freeze. The published line is 0.3.1, since 2026-08-28.

A second gap, same category, and this one is against a promise made on this feed. The previous entry named a DCO or CLA as the contribution-plumbing step. That part is not in. CONTRIBUTING.md carries the inbound-equals-outbound clause - contributions are licensed under the project’s Apache-2.0 license - which is a floor, not a sign-off requirement and not an agreement to sign. So step three is half-built: the files a contributor reads are there, the thing a contributor signs is not. It stays on the list, ahead of the first external pull request.

The part that cannot be undone

The flip runbook opens with a warning in bold, and it is the reason the rest of this post exists:

This is effectively ONE-WAY. npm package visibility is retroactive across every published version (0.1.0, 0.2.x, 0.3.0) and cannot be cleanly undone.

Flipping a scoped package from restricted to public does not just expose the next release. It exposes every version ever published under that name, all the way back. Anything embarrassing in a tarball from months ago becomes readable by everyone, permanently, in one command. Going backwards means unpublishing, which npm restricts to a 72-hour window and blocks outright once other packages depend on yours.

The runbook is seven ordered steps with a reversibility column. Making the repository public is reversible, though stars and fork links never come back. Turning on build provenance is reversible. Step three, the npm access flip across the 41 scoped @flare-engine/* packages, is the point of no return. Everything after that is finished rather than undone: if something is wrong at step four, the fix ships as a patch, not as a retreat.

That is the real cost of the flip, and it is not a scheduling cost. It is that every dry run has to happen before it, not after.

So it was rehearsed against a fake registry

On 2026-07-15 the whole sequence ran end to end on a local verdaccio registry: throwaway branch, the same 40 manifest edits, the same version cut, a real publish to a real registry that happens not to be npm.

What it proved: internal workspace:* dependencies get rewritten to concrete versions, so a cold install resolves with zero leaked placeholders; installing the web package pulls no React Native tree at all, which is the web-side decoupling actually holding rather than being asserted; and a published tarball carries Apache-2.0 plus the full LICENSE and NOTICE files, which is the relicense proven from bytes rather than from a commit diff.

What it caught is more useful. The project templates pinned react@19.2.0, and React Native 0.86 requires react@^19.2.3. Under bun and yarn that is a shrug. Under npm’s strict resolver it is an ERESOLVE failure - meaning every npm user scaffolding a new project would have hit a wall on their very first command, and the in-repo test suite could never have seen it, because the repo does not install with npm. That is now fixed. It is exactly the class of bug that only a stranger finds, and the whole point of rehearsing on a stranger’s path.

A second tool followed on 2026-07-24: an audit that unpacks the published tarball bytes and greps them for leaked secrets, local paths, and private project vocabulary. Scanning all 41 packages at HEAD came back clean on licenses and secrets, and turned up one real hit - a private sibling project’s name sitting inside a docstring in the physics package, which had shipped into the published build output and source maps, ready to become public the moment the flip runs. One comment, six files, fixed the same week. The published-version half of that audit still needs an authenticated re-run before the freeze.

What the two-week window is for

The plan: freeze on Monday October 5 and publish 0.3.0 still restricted. From that moment to the flip, fixes only - no API changes, no new features, no docs restructuring. Then a two-week owner-executed manual window, October 5 to 18, before flip week on October 19 to 23.

The protocol for that window is already written. Seven sections with explicit exit criteria: a cold-machine scaffold of all three project templates on Windows and in a Linux container; the showcase game, Pan Tvardowski, run start to finish on a real Android device including save round-trips, a locale toggle, reduced motion, and audio checked by ear rather than by “it did not crash”; the web demos across a desktop and mobile browser matrix plus a throttled-4G load of the WASM bundle; each new capability exercised once on its real target; and the documentation site read on a phone, getting-started followed literally, by someone pretending to know nothing.

None of that is automated, and that is deliberate. A green test suite says the code does what its tests say. It does not say a stranger can install this.

Where it stands today

• Still 0.2.1, unchanged since the last entry: on npm at access: restricted, which makes a scoped package 404 for anyone outside the org, so there is no command to copy here.
• 41 scoped @flare-engine/* packages plus an unscoped scaffolder, versioned in lockstep, all Apache-2.0 in the manifests as of July 12.
• The versions already on npm (0.1.0 through 0.2.1) shipped under MIT and stay MIT there. Apache-2.0 applies from 0.3.0 forward. Worth stating plainly in a post about a one-way door: a license change is not retroactive the way visibility is.
• 0.3.0 is not published.
• Of the pre-flight checklist ahead of freeze, exactly one box is ticked: the verdaccio rehearsal. The tarball audit, the freeze-time secret re-scan, the npm credentials, and the owner ratification are all still open.
• The October dates above are targets from a plan whose own capacity note calls the margin thin rather than comfortable. They are not commitments met.
• Web performance is still unmeasured, and the freeze-window browser matrix sets no frame-rate bar - it checks that the demos render, not how fast. The device numbers that exist are Android.
• Still one maintainer - which is why the flip is rehearsed rather than trusted, and why step three has no rollback.

Nothing to install, still. The notify list on this site is the whole ask, and the next entry will cover the freeze itself - the version that gets frozen, and whatever the manual window breaks.