--- title: "Public package readiness is a product feature." description: "npm 1.1.0, Studio 1.0.4, Homebrew 1.0.4, website 1.0.4: what it took to make four surfaces agree, and the readiness checks that moved into CI instead of living in memory." publishDate: 2026-06-07T18:00:00.000Z author: Sarvesh Chidambaram tags: ["npm", "release", "studio", "homebrew", "growth"] canonical: https://memoire.cv/blog/public-package-readiness-check --- I used to treat "released" as a boolean owned by `npm publish`. The launch weeks taught us it is a property of agreement between four surfaces, and that those surfaces disagree by default unless something forces them not to. ## The state, checked rather than felt Four claims, each one checkable in under a minute: - `@memi-design/cli@1.1.0` is npm `latest`. - Mémoire Studio `1.0.4` is the latest signed macOS release (tag v1.0.4, 2026-06-07). - The Homebrew cask at `sarveshsea/memi/memi-studio` installs that same 1.0.4. - The website download copy points at 1.0.4, with per-arch DMG URLs and a SHA256SUMS link, all generated from one file, src/lib/release.ts. That does not mean distribution is solved. It means the public version story is no longer lying to anyone, which is a lower bar than it sounds and took longer than it should have. ## Why agreement became the bar The first release week showed us how individual surfaces lie while everything looks green. DMGs went out signed but unnotarized and Gatekeeper rejected them (commit 9dcf306, 2026-05-10). The v1.0.0 updater manifest ended up listing one architecture because both arches' tarballs shared a filename and one overwrote the other (commit ccdded8, 2026-05-10). In both cases the release "existed". In both cases a user following the public path hit a wall. So readiness got redefined. The npm package has to expose the right binary, README, MCP name, and agent kits. The macOS app has to launch a stable local runtime. Homebrew has to install the same release the website advertises. The website has to link to the actual signed artifact, not an older launch build. A new user should never have to wonder which channel is the real one. ## The check that moved into CI six weeks early npm has propagation lag, and we got bitten by releases that were "done" but not yet installable. On 2026-04-25 we added manual release dispatch plus npm verification to the engine's CI (commit 300e5f37): the workflow does not consider a release finished until the registry actually serves the new version. That check predates the Studio launch by six weeks, and it is the reason "is npm actually current" is a CI question now instead of a thing someone remembers to type into a browser. The general lesson: any readiness question you ask more than twice should become a job, because the third time you will forget to ask it. ## The architecture nobody tests by hand All daily development happens on Apple silicon. The Intel build is therefore the artifact most likely to be silently broken, because no human double-clicks it before a user does. Since 2026-06-06, builds fetch both macOS runtime sidecars, aarch64 and x86_64 (commit f3bfa14). Readiness has to include the arch you never personally run. If the gate only covers the machine on your desk, the release is only ready for people who own your machine. ## Drift has a direction, and the direction matters One gap is open as I write this: local engine metadata trails the public npm `latest`, and needs syncing forward before the next publish or tag. The detail worth keeping is the word "forward". The registry is ahead of the working copy, not behind it. An earlier version of our status tooling just flagged "out of sync", and the natural reflex to that message is to publish, which in this state would push stale code over a newer registry. The tool now reports which direction the drift goes and recommends the action that matches. A sync warning without a direction is an invitation to make the exact wrong fix. ## Readiness for things that have not shipped The strangest artifact in the readiness story is docs/LICENSING_PLAN.md. It contains a complete design for a paid tier: a $9 one-time purchase through Lemon Squeezy, a 48-hour trial, the license stored in Keychain, bound to the machine's IOPlatformUUID. None of it is live. The app ships free with no license check. It sits in the repo so that flipping to paid is a contained PR instead of a re-architecture under deadline pressure. Readiness is not only "current versions agree". It is also "the next likely decision has a written path". ## The numbers, as a spot check Weekly npm downloads when I last checked: 188. Monthly: 509. Distance to a million a week: 999,812. Fine. The wrong response to small numbers is inflating them. The right response is making the first useful run obvious enough that the package earns its second install, and keeping every public pointer current so that the people who do arrive land on something real. ## The rule Every public post should point at something current and runnable. If npm, the desktop app, the cask, and the website disagree, stop writing and fix the chain first. Readiness is a feature, and like any feature, it regresses the moment nothing is testing it.