Version map: carve-css 0.1.2, wp-carve 0.1.7, and three rows that were wrong Reconciled against live tags and live registry queries rather than the page. intellij-carve was listed 0.1.9 and the Marketplace serves 0.1.10; carve-latex and reveal-carve were both live on npm with no row at all, and carve-latex was still listed as awaiting a release decision. Two new release gotchas: a workflow can fail before its publish step while the release page looks complete, and an install check run straight after publishing returns notarget from propagation and then from npm's own cached packument.
Confirm the IntelliJ and VS Code marketplace listings are live Both were left partly-published pending a marketplace query. JetBrains serves 0.1.9 and both VS Code Marketplace and Open VSX serve 0.1.7, checked directly.
Refresh the version map for the 0.1.6 cycle and the 2026-09-22 release round The page had drifted three to four releases behind in the core and carried rows whose claims were no longer true, not merely stale: carve-wasm, carve-hexapdf, pdf-to-carve, mkdocs-carve, zensical-carve and jekyll-carve were all described as prepared-but-not-tagged and had shipped; carve-components and the npm static-site satellites were listed unpublished; carve-press was listed as absent from npm. Every row is reconciled against live tags and direct registry queries. Adds a 2026-09-22 gotchas section for the two structural failures found during the round: release workflows that verify a draft and then never publish it, and the release environment approval gate that parks a run in waiting with no notification. Rewrites Open release work to what is actually outstanding.
Record the 0.1.6 grammar wave and the three consumer releases
Version map: intellij-carve 0.1.8 released
docs: add carve-mcp to the ecosystem version map
docs: update the ecosystem version map for the 2026-09-09 release wave
Prefer publishing the draft over pushing the tag Publishing a draft creates its tag from target_commitish, and that tag creation fires the tag-triggered release workflow. So one action does the whole release, and it cannot leave a draft behind, because the draft is the trigger. The tag-first path is two actions that must both happen, and the second is the one people forget. That is already the "a draft release stays invisible until someone publishes it" bullet in the same section, which records it biting carve-js 0.1.0 and carve-rs 0.1.0. Measured across four carve-grammars releases rather than assumed: the workflow starts 1 to 6 seconds AFTER the release's published_at, never before it. Tag-first would show the reverse order. Also records that a green release run is not evidence the registry has the version, and names the registry metadata to read instead, and brings the carve-grammars row to 0.1.6 - it had been left at 0.1.3 through two intervening releases.
Remove repo-stored release-notes rule
rouge-carve is released; record how it had to be published
Add rouge-carve, highlightjs-carve and carve-css to the version map
Document prepared downstream release wave
Document verified 2026-08-27 releases
Document homebrew-carve 0.1.0 release
docs: prefer bare release tags
docs: record release tag naming conventions
Add the generated Dependency Map, and link it from the Version Map Who pins whom across the org, read from the manifests rather than from the Version Map's prose, with what each pin resolves to and whether that is a released tag. Generated by node tools/dependency-map.mjs in the carve repo - 55 repos, 59 edges on this run. This page stays hand-written. The narrative, the release gotchas and the why are the part no generator should own; only the re-derivable half is generated.
Home: jekyll-carve v0.1.0 is live; carve-hexapdf blocked on RubyGems MFA jekyll-carve moves from 'Gem 404, untagged' to released. The row records why it was held - a >= 0.1.0 floor resolving the pre-security-fix engine while the repo's own suite ran green against a patched git pin - and what now prevents that recurring: the gate installs the built gem, resolves carve-lang through the declared floor, and renders the srcset probe before anything publishes. carve-hexapdf's entry is rewritten because its cause changed. It was recorded as a workflow that had never run; the workflow now runs on the tag and every gate passes. What fails is 'gem push' against rubygems_mfa_required => "true", which demands an interactive OTP that CI cannot supply. It is the only org gem declaring that flag, which is exactly why carve-lang and jekyll-carve push fine with the same credential - a difference worth writing down, since the obvious reading is that the token is broken. The open-work item now names the fix (OIDC trusted publishing) rather than the stale diagnosis, and suggests adopting it for carve-lang too: that gem is the native engine every Ruby consumer compiles, and it is currently the least protected of the three.
Home: tree-sitter-carve 0.1.3 is live on npm, crates.io and PyPI Records the release and the four gotchas it cost to get there: the npm dry run ignores --provenance so that path cannot be rehearsed at all, npm verifies package.json repository.url against the signed attestation, id-token is never granted implicitly, and crates.io answers 403 rather than 401 for a correctly-scoped publish token so a validity check built on /api/v1/me fails the least-privilege shape it should encourage. Also replaces the carve-hexapdf line with both half-released repos, since carve-press has no release workflow at all.
Mark WordPress 0.1.3 live
Update LSP and WordPress release status
Version map: carve-rb v0.1.1 is live on RubyGems Both vulnerable registries are now clear, which unblocks jekyll-carve. Records that RubyGems' versions and gems endpoints index at different speeds - the gems endpoint still reported 0.1.0 as latest after versions already listed 0.1.1, so reading one endpoint looks exactly like a failed push.
Version map: the downstream round carve-py v0.1.1 live on PyPI, carve-rb v0.1.1 tagged with the gem push still in flight, laravel 0.1.5 and symfony 0.1.4 live on Packagist. Records the gate-design failure that half-released carve-py: a release gate checking out spec main holds the artifact to a corpus newer than the release it gates, so it cannot pass once the spec moves. Plus how a half-released tag was recovered, and why a gate that passes on a clean tree cannot be validated by that tree.
Version map: the 0.1.x core round is released spec 0.1.3, carve-js 0.1.4, carve-rs 0.1.3, carve-php 0.1.5 - tagged at their release-time main and verified live on npm, crates.io and Packagist by direct registry query rather than by workflow status. A security release: the §25 list-valued URL attribute probe, where srcset vouched for a whole value from its leading scheme. Records four new release gotchas, the sharpest being that a PATCH to a DRAFT release which omits tag_name silently replaces the tag with an untagged-<sha> placeholder - which would have published four tags under generated names.
Version map: pandoc-carve released 0.1.0 to npm Tag e0993527, npm gitHead verified against the registry, install checked from a clean directory through both the library and the CLI. The repo had no release path at all - no workflow triggered on a tag, nothing ran npm publish, and a scoped package defaults to restricted - so publishing the draft would have cut a tag and left npm empty. The release added the guarded workflow (tag/version and changelog guards, pandoc installed so the release gate matches the CI gate), publishConfig.access, and a cut changelog. Tag glob is the bare numeric form, matching carve-js/carve-rs/carve-php rather than the v-prefixed satellites.
Record the Python release round Two first releases landed: pdf-to-carve 0.1.0 and carve-lang 0.1.0, both verified by installing from PyPI rather than by reading a green workflow. The carve-py row carries the failure worth remembering. Its first tag published nothing: the macOS wheel job died on 'mapfile: command not found' - a bash 4 builtin, and macOS ships 3.2 - and the publish job needs all three wheel jobs. CI here ran ubuntu-only, so a guard script exercised on one OS was never guarding the other two; that is why a release was the first thing to notice. The extension-drift item is closed on two of four bindings: carve-rs has a registry now and carve-py reads it, taking Python from 19 exposed extensions to 31. carve-wasm and carve-rb still re-type their lists and remain unaudited, which is why the item stays open rather than being struck out.
Record the carve-py release-readiness work and the binding extension gap The carve-py row said only that PyPI has nothing. What changed today matters for the next release round: the engine pin moved 40 commits and cleared the five corpus divergences that had main red, the publish job takes a token or OIDC, and the repo now has RELEASING and CHANGELOG files. What is left is environment, credential, tag. The extension gap gets its own open item because it is not a carve-py bug. No engine exposes a name-to-extension registry, so each binding re-types the list and nothing fails when one falls behind - carve-py is ten extensions behind, and carve-wasm and carve-rb are unaudited.
Add pdf-to-carve to the version map The repo landed its PyPI release workflow today, so the map now carries the row a release round reads from: dist name, tag glob, and what still blocks the first publish. Two facts are worth stating loudly in the row. The tag glob is v*, so the tag is v0.1.0 - the map already documents that this prefix is per-repo and that pushing the wrong one fires nothing. And the name pdf-to-carve is free on PyPI, so this is not another carve-lang collision case; nothing has to be renamed.
Update editor release and registry status
Clarify Go documentation indexing