Publish the 2.0.0 crates and SDKs: the workspace is on 2.0.0 but crates.io still serves 1.0.0

[macanderson]

PR #87 bumped the workspace to 2.0.0 for the open-FrameKind break (ADR 0011, #92). The version now exists only in the repository: crates.io still serves 1.0.0, npm still serves the 1.0.0 TypeScript SDK, and PyPI still serves contextgraph-sdk 1.0.0.

Until the publish happens, the ecosystem is in a state the docs now describe but the registries contradict:

• docs/stability.md tells consumers to depend on contextgraph-types = "2". That requirement does not resolve.
• MIGRATION.md §5 tells them to take the bump. They cannot.
• create-contextgraph-provider now scaffolds against ^2.0.0 / contextgraph-sdk>=2.0.0. A scaffold run outside CI (which overrides both pins with local paths) will fail to install.

What to publish

• Crates: contextgraph-types, contextgraph-host, contextgraph-conformance, contextgraph-trace at 2.0.0. Order matters — types first, then host, then the two that depend on both, because the >=2.0.0 floors cannot resolve until the dependency is up.
• npm: @contextgraph/sdk and create-contextgraph-provider at 2.0.0.
• PyPI: contextgraph-sdk at 2.0.0.

Related

Distinct from #84, which is about the 1.0 publish and the canary that went red because crates.io served 1.0-draft. This is the same class of gap one major later, and #84's remedy should be checked for whether it generalises rather than being repeated by hand.

Worth deciding as part of this: whether the release pipeline should refuse a merge that changes workspace.package.version without a matching publish, since this is now the second time the repository and the registries have disagreed.

[macanderson]

Registry state re-checked 2026-08-29 — the gap is wider than this issue says

Every registry was queried directly. Three of the four premises in the issue body are wrong, and in the direction that makes the work bigger:

Package	Issue says	Actually serves
contextgraph-types (crates.io)	1.0.0	0.1.2 (published 2026-08-01; 0.1.1 yanked, 0.1.0 live)
contextgraph-host (crates.io)	1.0.0	0.1.2
contextgraph-conformance (crates.io)	1.0.0	0.1.2
contextgraph-trace (crates.io)	1.0.0	0.1.2
@contextgraph/sdk (npm)	1.0.0	404 — never published
create-contextgraph-provider (npm)	implied published	404 — never published
contextgraph-sdk (PyPI)	1.0.0	0.1.0

The workspace is on 2.0.0.

What this changes

• The 1.0 publish never happened. Publish the frozen contextgraph 1.0 crates: the downstream canary is red because crates.io still serves 1.0-draft #84 and P1: Release: pick the version and publish the three crates to crates.io #16 both assume it did. crates.io went 0.1.0 → 0.1.1 (yanked) → 0.1.2 on 2026-08-01 and has not moved since. So this is not "the same class of gap one major later" — it is the first publish gap, still open, now two majors deep.
• Two packages have no publish history at all. @contextgraph/sdk and create-contextgraph-provider are not "behind", they are absent. A 2.0.0 publish for those is a first publish: name availability, npm scope ownership, and the publishConfig access setting all need checking before the runbook will work.
• docs/stability.md telling consumers to depend on contextgraph-types = "2" resolves to nothing, and neither would = "1". The nearest resolvable requirement today is 0.1.

Evidence

curl -sS https://crates.io/api/v1/crates/contextgraph-types   # max_version 0.1.2
curl -sS https://registry.npmjs.org/@contextgraph%2Fsdk       # {"error":"Not found"}
curl -sS https://pypi.org/pypi/contextgraph-sdk/json          # info.version 0.1.0

Suggested re-scope

Fold #16 and #84 into this issue rather than tracking three publishes that are all the same blocked publish. The ordering constraint in the body still holds (types → host → the two that depend on both), and the npm packages need a first-publish pre-flight added to it.

Also worth noting for the "should the pipeline refuse a merge that changes workspace.package.version without a matching publish" question at the end of the body: the answer this data argues for is yes, because the repository and the registries have now disagreed continuously since 2026-08-01, not twice.

[macanderson]

Closing as a duplicate of #102, which tracks the same 2.0.0 publish and is the better handoff: it names the three human repo-Settings steps (crates-io environment, CARGO_REGISTRY_TOKEN, push a contextgraph-v2.0.0 tag and approve) and carries a definition of done.

The registry survey posted on this issue is the part worth keeping, so restating it on #102 rather than losing it:

Package	This issue assumed	Actually serves
the four contextgraph-* crates	1.0.0	0.1.2 (2026-08-01; 0.1.1 yanked)
@contextgraph/sdk (npm)	1.0.0	404 — never published
create-contextgraph-provider (npm)	implied published	404 — never published
contextgraph-sdk (PyPI)	1.0.0	0.1.0

Two consequences that change #102's scope and are now noted there:

• The 1.0 publish never happened, so this is not "the same gap one major later" — it is the first publish gap, still open, now two majors deep. P1: Release: pick the version and publish the three crates to crates.io #16 and Publish the frozen contextgraph 1.0 crates: the downstream canary is red because crates.io still serves 1.0-draft #84 both assumed otherwise.
• Two of the packages have no publish history at all, so their 2.0.0 would be a first publish: npm scope ownership, name availability and publishConfig.access all need a pre-flight the runbook does not currently describe.

The open question at the end of this issue's body — whether the pipeline should refuse a merge that changes workspace.package.version without a matching publish — is worth keeping alive. The data argues yes more strongly than the issue did: the repository and the registries have disagreed continuously since 2026-08-01, not twice.

Closing as not planned, since the work moves to #102 rather than having been done here.