wowbagger 0.1.0-alpha.2 → 0.1.0-alpha.3

package/CHANGELOG.md

@@ -7,6 +7,18 @@ consolidation. The first tagged release inherits this file.
 
 ## Unreleased
 
+## 0.1.0-alpha.3 - 2026-08-12
+
+### Fixed
+
+- Published install and upgrade guidance now names this release's immutable Git
+  tag and uses the prerelease `next` npm channel instead of the older `latest`
+  artifact. Item 62.
+- The installed plugin skill now requires the exact core distribution version
+  that shipped with it, in addition to core contract version 2. This detects an
+  older core that shares the contract number but lacks behavior required by the
+  newer skill. Item 64; item 63 records the rejected capability-schema change.
+
 ## 0.1.0-alpha.2 - 2026-08-12
 
 ### Fixed

package/README.md

@@ -34,7 +34,7 @@ Install the core CLI, then verify it:
 ```sh
 npm install -g wowbagger@next   # public npm prerelease
 # or, from this release's Git tag:
-# npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.1
+# npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.3
 wowbagger capabilities --json
 ```
 
@@ -45,11 +45,12 @@ In Claude Code, add the plugin:
 /plugin install wowbagger@wowbagger
 ```
 
-The plugin drives the installed core rather than bundling one, so a version
-mismatch is detectable instead of silent: it reads `contract_version` from
-`capabilities` and refuses when the core is absent or reports anything it does
-not support. It will not fall back to editing ledger files by hand, because that
-would bypass validation and atomic publication.
+The plugin drives the installed core rather than bundling one, so a mismatch is
+detectable instead of silent. Its skill reads `wowbagger --version` and
+`capabilities`; it requires the same distribution version as the plugin and
+core contract version 2. It refuses an absent or incompatible core. It will not
+fall back to editing ledger files by hand, because that would bypass validation
+and atomic publication.
 
 For an isolated consumer pilot, create or select the disposable worktree before
 the agent starts. Then launch a new session with that worktree as its project
@@ -69,22 +70,23 @@ two supported install routes:
 - **npm registry** — `npm install -g wowbagger@next` installs the current
   prerelease.
 - **git tag** —
-  `npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.1` installs this
+  `npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.3` installs this
   release. Installing at a ref installs the core and every adapter that ref
   carries.
 
 Either route installs the core and the `wowbagger` command. The Claude Code
 plugin is a separate artifact (see [Start here](#start-here)); the core and the
-plugin are installed and versioned independently, and a mismatch is refused by
-`contract_version` rather than guessed.
+plugin are installed independently. Install their matching distribution
+versions.
 
 ### Compatibility
 
-The behavioural version is `contract_version`, reported by
+The contract version is top-level `contract_version`, reported by
 `wowbagger capabilities --json`. Contracts change it; refactors do not. The
-distribution version is the npm/git version, which names bytes, not behaviour.
-Match on `contract_version` — never on the package version — when you decide
-whether a core supports your request.
+npm/Git distribution version names release bytes. General API consumers
+negotiate the contract version. The shipped plugin skill additionally requires
+the exact core distribution version that shipped with it, because its
+instructions can depend on additive behavior from that release.
 
 - **Node.js:** 20 and later. The adapter conformance vectors run against Node
   20 and the current runtime before each release.
@@ -131,8 +133,8 @@ wowbagger core, this is how you move forward safely.
 Upgrade the pieces you installed:
 
 ```sh
-npm install -g wowbagger@latest                # public npm registry
-npm install -g github:lstutzman/wowbagger      # or: a direct git-tag install
+npm install -g wowbagger@next                  # public npm registry
+npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.3  # immutable Git release
 git pull && npm ci                            # or: a direct checkout
 ```
 
@@ -143,15 +145,15 @@ In Claude Code, update the plugin the same way it was installed:
 /plugin update wowbagger@wowbagger
 ```
 
-Then verify, exactly as on first install:
-
 ```sh
+wowbagger --version
 wowbagger capabilities --json
 ```
 
-The top-level `contract_version` is the core compatibility gate. The plugin
-and adapter refuse a core that reports a version they do not support; if you
-automate against the core directly, do the same rather than guessing.
+The plugin requires its exact core distribution version and top-level core
+`contract_version: 2`. Direct API consumers must check the contract version
+they support; installed plugin users must also keep the plugin and core
+distribution versions equal.
 
 The shipped adapter selects only adapter contract version 2 and requires core
 contract version 2. A v1-only consumer receives
@@ -340,8 +342,9 @@ top-level `contract_version` from core `capabilities`. Read
 `result.operations.work_claim.api_version` from
 `claim capabilities --ledger <dir> --json`. A claim response's top-level
 `contract_version` is the legacy claim-envelope marker; do not compare it with
-the core version. A consumer that receives an unsupported version refuses
-rather than guessing. Direct checkout use—`./bin/wowbagger.js` from a
+the core version. A contract consumer that receives an unsupported version
+refuses rather than guessing. The shipped plugin skill also requires its exact
+core distribution version. Direct checkout use—`./bin/wowbagger.js` from a
 clone—remains supported and is what this repository's own ledger uses.
 
 ## Verify a checkout

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wowbagger",
-  "version": "0.1.0-alpha.2",
+  "version": "0.1.0-alpha.3",
   "description": "Plain-Markdown, Git-native work ledger for coordinating agents — validate, ready-select, and mutate a task ledger from the CLI.",
   "type": "module",
   "license": "MIT",

package/skills/wowbagger/SKILL.md

@@ -15,23 +15,29 @@ This skill does **not** bundle the wowbagger core. It drives an installed one,
 so a version mismatch is detectable rather than silent.
 
 ```sh
+wowbagger --version
 wowbagger capabilities --json
 ```
 
-Read the top-level `contract_version` from this core response. **This skill
-requires core `contract_version: 2`.**
+Read the plain distribution version from the first command and the top-level
+`contract_version` from the second. **This skill requires distribution version
+`0.1.0-alpha.3` and core `contract_version: 2`.**
 
 - Command not found → the core is not installed. Tell the user, point them at
   <https://github.com/lstutzman/wowbagger>, and stop. Do not fall back to
   editing ledger files by hand — hand-edits bypass validation and atomic
   publication, which is the whole point of the tool.
+- If the distribution version is missing or is different, stop and report the
+  installed and required versions. An older core can share contract version 2
+  while still lacking behavior this skill requires. Do not guess from the
+  contract version alone.
 - `contract_version` is anything other than `2` → stop and say so plainly. A
   core reporting `1` predates schema version 2, where `depends_on` records
   declared prerequisites rather than only live blockers; an older or newer core
   may have changed the request or response shape. Do not guess.
 
-Run this once per session before the first ledger command, not before every
-command.
+Run both commands once per session before the first ledger command, not before
+every command.
 
 ## Reading