The package is published as framework, at 0.7.0 (#1635)

[suleimansh]

🤖 automated

Draft on purpose — this must not merge until 0.7.0 is on npm.

The moment README.md says npm i -g framework, that command resolves. Today it resolves to Mikeal Rogers' 2011 package at 0.6.0, which is not us. So: publish first, merge this whenever after. I've left fix #1635 out of the commit for the same reason, and because the bin question below is still open.

The rename

	before	after
name	@gemstack/the-framework	framework
version	0.0.0	0.7.0
homepage / bugs / repository	gemstack-land/the-framework	framework/the-framework

Confirmed against the registry rather than from the issue: framework's maintainers are brillout and suleimansh, and its latest is 0.6.0. 0.7.0 publishes cleanly and takes latest.

The version was doing real damage

version was 0.0.0 while the CLI reads its own package.json at runtime (cli.ts:116) and then asks the registry about @gemstack/the-framework, whose latest is 1.5.0. So every run of the version footer told the user an update was available, for a package they were not running. Verified on the built binary:

$ node packages/the-framework/dist/bin.js --version
0.7.0
$ grep -o "PACKAGE_NAME = '[^']*'" packages/the-framework/dist/update-check.js
PACKAGE_NAME = 'framework'

0.7.0 against framework's 0.6.0 now reports up to date.

Where the name was load-bearing, not decorative

The issue's checklist covers package.json and the READMEs. Three more places would have broken quietly:

• src/update-check.ts:9 — PACKAGE_NAME is the registry key the check GETs, and the string in the npm i -g … line it prints.
• src/layout.ts:71 — an error telling a user to update the package when their build predates a repo-side rename. It named the old package.
• dashboard/README.md:41,53 — pnpm --filter @gemstack/the-framework resolves by package name; both lines would have stopped working for contributors.

Plus the website, which the checklist didn't mention and which is a user-facing install surface: Hero.tsx (all eight npm/pnpm/bun/yarn commands), ui.tsx (NPM_URL, GITHUB_URL — the latter still pointed at gemstack-land), and the press page's package chip.

Two things I deliberately did not do

Three comments still say node_modules/@gemstack/the-framework/prompts/*.md — in system-prompt.ts:80, tickets.ts:20, system-prompt.test.ts:140. They describe the path that a fixed bug (#1163) actually used. Renaming it there would name a path that never existed, so the history stays accurate.

The gemstack-land strings in test fixtures stay. github.test.ts, queue-entry.test.ts, agent-driver.test.ts and closing-keywords.test.ts use it as an arbitrary owner/repo. That's the repo rename, not the package rename, and it's a separate sweep if you want one.

A pre-existing docs bug this turned up — and it bears on the open question

packages/the-framework/README.md told users to run framework, in both the quickstart and the CLI options block. The bin is and always has been the-framework. So the package README has been documenting a command that does not exist.

I fixed it to match the bin. That is a docs-match-reality fix, not an answer to the A/B — but it is evidence: someone writing that README reached for framework twice without noticing, which is the argument for Option B.

Still your call on #1635:

• Option A — keep the command the-framework. What the CLI, FEATURES-SPEC.md, the root README and the website all say today. npx framework would not work.
• Option B — rename the command to framework so package and command match.

If B, it is a one-line bin change plus a docs pass; say so and I'll add it here rather than opening a second PR.

Changesets

The eleven .changeset/*.md files are deleted. a745e2e3 removed the tooling — there is no config.json, no @changesets/cli dependency, no release workflow — but agents kept writing them from training and nothing has read one since. Confirmed no consumer before deleting.

Verification

pnpm build, pnpm typecheck (both packages), pnpm test — 1536 node tests + 792 vitest, all passing. dist-test cleared before the run so it wasn't the other branch's compiled tests.

The update-check tests reference PACKAGE_NAME as a constant, so they'd have passed either way — which is why I checked the built output and the live registry instead.

Also here

One line in the root MEMORY.md, recording your 0.7.0 answer where human decisions live (the #1334 convention):

The version line stays in 0.x. The releases are experimental, and while the major is 0 a minor bump is allowed to break — so no experiment ever costs a major.

The number itself isn't in there — package.json records that now.