wowbagger 0.1.0-alpha.1 → 0.1.0-alpha.3

package/CHANGELOG.md

@@ -7,6 +7,51 @@ 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
+
+- `claim-verify` now reports `git_finalized` and `git_commit` for each successful
+  claimed publication. Reconciliation logs stay inside the configured ledger,
+  including repository-root ledgers. Items 55-57.
+- A new empty ledger now starts on schema version 2. Existing non-empty
+  schema-version-1 ledgers remain compatible until migration. Item 54.
+- The installed skill now identifies the active claim as the work-in-flight
+  signal while the item remains in `backlog`. Item 58.
+- The npm package now ships the mutation and work-claim contract documents that
+  the installed skill references. Item 59.
+- The npm package now ships the documented schema-version-2 migration
+  entrypoint for package-only consumers. Item 60.
+- The installed work-claim contract now distinguishes durable reconciliation
+  state from per-publication Git finalization. Item 61.
+
+- The Claude Code plugin manifest and marketplace metadata now use the same
+  distribution version as `package.json`. The packaging gate rejects release
+  identity drift before npm, Git, or marketplace publication. Item 48.
+- Capability help now distinguishes the core's unbound default claim profile
+  from one provisioned ledger's work-claim profile. It names
+  `contract_version` as the core version and
+  `operations.work_claim.api_version` as the work-claim API version. Items 47
+  and 51.
+- `provision --help`, README, and the shipped skill now expose the accessible
+  Git-checkout prerequisite and the pre-provision
+  `claim capabilities --ledger <dir> --json` gate. Item 50.
+- The isolated consumer dogfood runbook now creates or selects the disposable
+  worktree before agent launch and requires a session-root Git preflight before
+  installation or ledger mutation. Item 52.
+
 ## 0.1.0-alpha.1 - 2026-08-11
 
 ### Behaviour changes

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,17 @@ 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
+root. Follow the [isolated dogfood pilot runbook](docs/isolated-dogfood-pilot.md);
+do not try to drive a sibling worktree from an already-running agent session.
 
 To use the core directly from a clone instead, see
 [Core commands](#core-commands).
@@ -64,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.
@@ -88,7 +95,10 @@ whether a core supports your request.
   with release evidence). Do not assume a platform is officially supported just
   because the CLI starts.
 - **Other tooling:** `wowbagger` manages a Git-tracked Markdown ledger. It
-  needs `git` present for work-claim and namespace operations.
+  needs an accessible Git checkout for work-claim and namespace operations.
+  Before `provision`, run
+  `wowbagger claim capabilities --ledger <dir> --json` and require
+  `result.operations.work_claim.supported: true`.
 
 ### Security
 
@@ -123,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
 ```
 
@@ -135,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
 ```
 
-`contract_version` is the 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
@@ -327,11 +337,15 @@ operation. See [the work-claim contract](docs/work-claim-contract.md) for the
 request envelopes, refusal precedence, recovery rules, and the difference
 between strict fenced and merge-coordinated backends.
 
-The `contract_version` reported by `capabilities` is what an adapter or plugin
-declares it requires. A consumer pairing one with a core that reports a
-different contract version gets a refusal, not a guess. Direct checkout use —
-`./bin/wowbagger.js` from a clone — remains supported and is what this
-repository's own ledger uses.
+Core and work-claim versions use distinct negotiation fields. Read the
+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 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