@junghanacs/entwurf 0.34.0 → 0.34.2

package/CHANGELOG.md

@@ -4,6 +4,213 @@ All notable changes to this project will be documented here. Format follows [Kee
 
 ## Unreleased
 
+## 0.34.2 - 2026-10-11
+
+### Release coordination
+
+- **A patch cut for #136.** Coordinated by the Claude Code Fable citizen `20261011T132613-9a46b6`,
+  implemented by Claude Code Opus `20261008T094901-5d295e` as sole writer on the thinkpad that
+  holds the failing installation, and independently reviewed by a pi `gpt-6.1-sol` sibling. GLG
+  authorized the commits, main and this release. This section is written at prepare time: the
+  `check:full` and exact-SHA CI results will be recorded at make time in the GitHub release and
+  #136, not claimed here.
+- **GLG waived the LIVE `release-gate --cut` for this cut** (doctor-only change, no LIVE surface
+  touched). The deterministic floor `check:full` and the exact-SHA CI body are this release's
+  evidence, and acceptance 4 (host rebind + new Claude session) is owed after publication. This is
+  not a PASS and not a standing waiver.
+- **The plugin runtime lock rides `herdr-checkout` for this window.** `certifyLockCoherence`
+  (`scripts/herdr-runtime.mjs:353-361`) refuses an npm lock whose version differs from the
+  checkout's package, so `plugins/herdr/runtime-lock.json` leaves npm 0.34.1 for the closed
+  `herdr-checkout` source from this prep until the post-publish npm 0.34.2 re-pin; the plugin
+  manifest moves with that re-pin. A host already on npm 0.34.1 is unaffected until then and
+  upgrades same-source; a host that installs the plugin from `main` inside the window gets a
+  checkout-source runtime and needs `herdr-plugin-deactivate` before the npm reinstall.
+
+### Fixed
+
+- **`doctor-meta-bridge` certifies a Herdr plugin installation (#136).** The plugin activation
+  writes Claude's MCP and statusLine as absolute commands under the stable runtime, but the doctor
+  computed its three expectations (`meta-bridge-state.py check`, `desired-statusline`,
+  `desired-mcp`) without that mode. It expected bare bins and reported correct wiring as drift, so
+  no plugin host could reach a green doctor. The doctor now learns its mode from the certified
+  activation ledger through one narrow call (`resolveDoctorPluginRuntime`,
+  `scripts/herdr-doctor-mode.mjs`). Derived plugin mode needs all four clauses:
+  - the ledger phase is `active`;
+  - `claude-code` was activated;
+  - the ledger's runtimeRoot is this host's stable root;
+  - the doctor runs from that runtime's package.
+  A flagless checkout doctor never opens the ledger. The explicit `--plugin-runtime <root>`
+  override bypasses only the repo clause and still reads and certifies the ledger, which it must
+  agree with. A refusal reports each expectation as UNKNOWN, never a bare-bin fallback, and
+  the runtime sections still run. The doctor prints the mode it used on one line.
+- **`run.sh doctor-meta-bridge` forwards its arguments.** The verb was never shifted, so it rode
+  into the doctor's argv; the override was unreachable through the operator entrypoint.
+
+### Docs
+
+- **CONTRIBUTING matches the scheduling rule.** A gate, mutant or matrix change runs only its
+  affected exact-argv groups as PARTIAL receipts; the whole qualification body runs once per cut,
+  in the prepared SHA's CI. CONTRIBUTING still told a gate-changing PR to run the body itself.
+
+### Verification
+
+- New cells: `check-herdr-activation` D1-D6 and `check-meta-doctor-oracle` P1-P3. The existing
+  clone control is unchanged (P4). Six mutants joined the `herdr-activation` lane (now 34).
+  PARTIAL receipts: herdr-activation group 33/33 and doctor-oracle group 2/2 killed, control ok.
+  No whole body ran in development.
+- **Host acceptance before publication (thinkpad, live plugin 0.34.1 wiring).** The patched
+  checkout doctor with `--plugin-runtime <stable root>` named `mode: plugin-runtime … (activation
+  ledger)`. Its only FAIL was writer-version parity, the declared non-goal of a checkout doctor on
+  a plugin host. The seven drift lines the shipped doctor printed are gone.
+- **Owed after publication.** After the plugin is re-pinned to 0.34.2 and rebound on that host, a
+  flagless runtime-absolute `doctor-meta-bridge` must exit 0 and a new Claude session must call
+  `entwurf_self`. That is what closes #136.
+
+## v2026.10.9-herdr.0.34.1 — Herdr Entwurf plugin 0.34.1
+
+A Herdr plugin snapshot, not a core release: no package version, npm artifact or core tag moves.
+
+### Herdr plugin
+
+- **Runtime re-pinned to the published 0.34.1 (#135).** `plugins/herdr/runtime-lock.json` returns
+  from the `herdr-checkout` verification carrier the 0.34.1 preparation rode to the npm production
+  source: `@junghanacs/entwurf@0.34.1` with the registry's measured sha512
+  (`sha512-AiB88Ext…GDxA==`). The manifest version moves 0.34.0 → 0.34.1; `min_herdr_version`
+  stays 0.9.0. A plugin host now receives the #135 fixes listed under 0.34.1: owner preflight
+  before acquisition, the no-ledger deactivate, and the regular-file-or-nothing ledger address.
+- **Upgrading.** A host on the npm 0.34.0 snapshot stays on the npm source, so its next
+  `herdr plugin install` is a same-source rebind under the plugin README's conditions. A host that
+  installed while the lock named `herdr-checkout` — the 0.30.1 plugin, or `main` during the 0.34.1
+  preparation window — holds a checkout-source runtime and ledger, and npm is a different
+  acquisition source, refused rather than inherited (`activation-artifact-source-drifted`). Run
+  `herdr-plugin-deactivate` by its absolute runtime path, then `herdr plugin install` again.
+- **The READMEs no longer state a current release.** The root README's hardcoded release block and
+  the plugin README's snapshot and carrier prose went stale with every version bump; they now point
+  at `runtime-lock.json`, `herdr-plugin.toml`, Releases and this file. The source-switch rules and
+  the 0.34.0 runtime's no-ledger limit stay, the latter as a historical fact.
+
+### Verification
+
+- **Registry, measured before the pin.** One scheduled observation, after a 300 s delay:
+  version 0.34.1 published at 2026-10-09T14:29:48.184Z with `latest` → 0.34.1, and the downloaded
+  tarball re-hashed to the artifact accepted as 0.34.1 (sha256 `73407ba8…`, 13587297 bytes), with
+  `dist.integrity` re-derived equal. Dist-tags before publication were not captured, so no
+  before/after claim is made about them.
+- **VERIFY's 0.34.0 public-ref row is closed with its measured receipts:** `--ref main` PASS at
+  `b5d15d8` and `8ed4d1a`, both acquiring npm 0.34.0. That is a main-ref receipt, not a tag-ref
+  or native claim.
+- No gate, mutant or matrix changed, so no qualification PARTIAL is owed. The npm-source re-proof
+  for this pin — the focused Herdr gates, a real-npm 0.34.0 → 0.34.1 swap and torn-swap recovery,
+  an installed registry consumer, the registry-file container consumer, the public `main`
+  first-user path and the exact-SHA CI run — is recorded in the GitHub release, not claimed here.
+  A `--ref <tag>` install, a citizen drawn as a ROW in a real Herdr pane, and native hosts stay
+  unmeasured.
+
+## 0.34.1 - 2026-10-09
+
+### Release coordination
+
+- **A patch cut for #135.** Coordinated by the pi-durable citizen `20261008T113104-801621` and
+  implemented by Claude Code Opus as sole writer, under the maintainer's grant through prepare and
+  make; npm publication is not part of that grant. This section is written at prepare time, before
+  the release gates run: the `check:full`, package-consumer and `release-gate --cut` results are
+  recorded in the operator handoff and the GitHub release, not claimed here. Their raw logs stay
+  under the ignored `.tmp-verify/135-install-ownership/writer/release-0341/{p4,p6,p5}/`.
+- **The published 0.34.0 does not carry these fixes.** Its registry bytes stay as accepted.
+
+### Herdr plugin
+
+- **Component owners are asked before anything is fetched (#135).** The plugin build now runs the
+  selected components' read-only owner preflights — Pi package, Pi provider, and the Claude
+  meta-bridge plan — before runtime acquisition, on the same Pi state paths the activation reads. A
+  foreign Pi owner refuses with no runtime, journal, cache or ledger written, and the refusal says
+  to release the registration from the root that owns it (its own `remove-user-scope`): a takeover
+  from the plugin's root is not a route. The check is planned against the physical prospective
+  runtime root; a landed package whose name or root differs from that plan refuses as
+  `herdr-build-artifact-drifted`. The installed activation keeps its own preflight recheck.
+- **`herdr-plugin-deactivate` without a ledger no longer reports success over leftovers.** With no
+  certified activation ledger it exits 0 only when nothing stands at the plugin's journal, runtime
+  and cache addresses; otherwise it names what it found and exits non-zero
+  (`deactivate-unattributed-leftovers`), removing nothing.
+- **Only a regular file or nothing may stand at the activation ledger address.** A symlink,
+  dangling or not, or a directory at `activation.json` refuses as `activation-ledger-uncertified`.
+- **Limits that stay.** The Claude install state records the last installer and is not root-bound.
+  Roots changed between runs, or a host changing between the early owner check and the installed
+  recheck, can still refuse after the download. The no-ledger deactivate reports leftovers and
+  neither reclaims nor reuses them. No wider Claude-root or ownership guarantee is added.
+  `docs/setup-clean-host.md` §1.1 names the four installation paths and these limits.
+- **The runtime lock rides the `herdr-checkout` verification carrier for this window.**
+  `plugins/herdr/runtime-lock.json` returns from npm 0.34.0 to the closed `herdr-checkout` source,
+  so the lock stays coherent with the 0.34.1 package version without inventing a registry
+  integrity. The plugin manifest stays 0.34.0, and this is not a plugin pair: the npm re-pin to
+  0.34.1 follows publication with its measured sha512 and its own source proof. Moving a host
+  between the published npm 0.34.0 plugin and this carrier, in either direction, needs
+  `herdr-plugin-deactivate` first.
+
+### Repository hooks
+
+- **`prepare` no longer runs husky.** It only builds the bridge. The local
+  `core.hooksPath=.husky/_` override that shadowed the configured global guard was removed on this
+  checkout, and `.husky/pre-commit` (whitespace, lint, typecheck) is reached through a global guard
+  that chains to repository-local hooks. Another existing clone may keep its local value until it
+  is unset there (unmeasured). On this checkout a real `npm pack` inside `check-pack-install` left
+  `.git/config` and `.husky/_` unchanged. The `husky` devDependency is unchanged.
+
+## v2026.10.9-herdr.0.34.0 — Herdr Entwurf plugin 0.34.0
+
+A Herdr plugin snapshot, not a core release: no package version, npm artifact or core tag moves.
+
+### Herdr plugin
+
+- **Runtime re-pinned to the published 0.34.0 (#132 B).** `plugins/herdr/runtime-lock.json`
+  returns from the `herdr-checkout` verification carrier the 0.30.1 preparation rode to the npm
+  production source: `@junghanacs/entwurf@0.34.0` with the registry's measured sha512
+  (`sha512-rUpQ…/uJ/fw==`), which is the artifact accepted and published as 0.34.0. 0.31–0.33
+  were never pinned here. The manifest version moves 0.30.1 → 0.34.0; `min_herdr_version` stays
+  0.9.0 and the measured Herdr supply stays 0.9.3.
+- **Upgrading from a 0.30.1 plugin install needs an explicit deactivate.** That install recorded a
+  `herdr-checkout` runtime and ledger, and npm is a different acquisition source, which is refused
+  rather than inherited (`activation-artifact-source-drifted`). Run `entwurf
+  herdr-plugin-deactivate`, then `herdr plugin install` again. A host with no plugin installation
+  starts fresh.
+- **The release skill's core baseline ignores Herdr snapshot tags.** `prepare` P1 took the newest
+  tag by version sort, and a `vYYYY.M.D-herdr.*` tag sorts above every `v0.x`, so it would have
+  become the next core audit baseline. P1 now excludes exactly that shape; a core `v20.1.0` is
+  still picked.
+- **Plugin docs corrected before the tag (GLG's final review).**
+  - The direct route opens six fresh-call backends, `pi-durable` among them as the managed launcher.
+    The plugin's Herdr pair stays `{pi, claude-code}`, and the manifest now says it does not widen
+    with the core list.
+  - `smoke-herdr-plugin-build-live` is described as the checkout-carrier journey it is, not as
+    registry evidence.
+  - `herdr-plugin-deactivate` is given by its absolute runtime path, because the plugin puts nothing
+    on `PATH`.
+  - The plugin tag namespace is explained.
+  - A v1 record is now described as refused by the current inverse as well. The launch-rail doc
+    separates the `0.9.0` admission floor from the single Herdr version the gates certify (the
+    supply pin, 0.9.3).
+
+### Verification
+
+- **Real-npm swap and torn-swap recovery, measured before commit.** This is the row the 0.30.0
+  pin left open. A one-shot driver ran the registry-shipped `scripts/herdr-runtime.mjs`, whose
+  sha256 equals this checkout's, against the real registry:
+  - A 0.33.0 → 0.34.0 swap.
+  - The same upgrade torn between its two renames (`torn-swap-with-candidate`), then resumed.
+    The last-good 0.33.0 tree was restored before 0.34.0 was acquired again.
+  - Both ended `runtime-ready` with observed digest
+    `sha256-e9d995ff3858ffca40fa12b4fce2a6db3802da3ee27c7b233142fc4c71f23450`, the accepted
+    artifact. Neither left a staging or backup directory behind.
+  - Each 0.34.0 runtime passed the installed-runtime check: three executable bins, the compiled
+    entry, and `check-bridge` with its exact eight verbs. The owned inverse removed cache,
+    runtime and journal.
+  - Two earlier runs stopped on defects in the driver's own verb parser, not on product behaviour.
+- The focused Herdr gates (`check-herdr-plugin`, `-plugin-profile`, `-plugin-build`,
+  `-runtime-bootstrap`, `-activation`) and `check-gate-manifests` are green on this tree. No gate,
+  mutant or matrix changed, so no qualification PARTIAL is owed.
+- The public-ref first-user path (`smoke-herdr-raw-install-live`) and the exact-SHA CI run on the
+  pushed commit. Their receipts are recorded in the GitHub release and #132, not claimed here.
+
 ## 0.34.0 - 2026-10-09
 
 ### Release coordination

package/CONTRIBUTING.md

@@ -30,7 +30,7 @@ pnpm check              # everyday core (prints wall time; <=60s on the referenc
 pnpm run check:full     # full deterministic floor — the required PR gate
 ```
 
-The deterministic floor is tiered (#70). `pnpm check` is the everyday core (biome, tsc, the vitest lanes, and the fast contract gates); `pnpm run check:full` adds the hermetic-integration and package/install tiers — including `check-gate-manifests`, the qualification HEAD (runner self-test, manifest-set validation, declared lane inventory; zero COMMITTED mutants executed — the self-test runs only its synthetic fixture mutants in tmp fixture repos — ~20s), but not the separately scheduled mutant-EXECUTING body `check-gate-qualification`, which CI runs on a branch push whose diff touched the qualification surface (and unconditionally on dispatch or the weekly schedule) and a gate-changing PR must run once itself. Exact membership is the named `check:*` scripts in `package.json`. Run `check:full` once on your frozen commit candidate — the pre-commit hook (`.husky/pre-commit`) carries only fast static checks (whitespace, lint, typecheck), not the full floor, so a green `pnpm run check:full` before commit is the evidence that your change holds (scheduling contract: AGENTS.md "Verification scheduling").
+The deterministic floor is tiered (#70). `pnpm check` is the everyday core (biome, tsc, the vitest lanes, and the fast contract gates); `pnpm run check:full` adds the hermetic-integration and package/install tiers — including `check-gate-manifests`, the qualification HEAD (runner self-test, manifest-set validation, declared lane inventory; zero COMMITTED mutants executed — the self-test runs only its synthetic fixture mutants in tmp fixture repos — ~20s), but not the separately scheduled mutant-EXECUTING body `check-gate-qualification`, which CI runs on a branch push whose diff touched the qualification surface (and unconditionally on dispatch or the weekly schedule). Development never runs that whole body: a gate, mutant or matrix change runs only its affected exact-argv groups once, as PARTIAL receipts (`./run.sh check-gate-qualification --group '<argv JSON>' --receipt <absolute path outside the repo>`), and the whole body runs once per cut, in the prepared SHA's CI. Exact membership is the named `check:*` scripts in `package.json`. Run `check:full` once on your frozen commit candidate — the pre-commit hook (`.husky/pre-commit`) carries only fast static checks (whitespace, lint, typecheck), not the full floor, so a green `pnpm run check:full` before commit is the evidence that your change holds (scheduling contract: AGENTS.md "Verification scheduling"). No install or build lifecycle script installs git hooks: a global `core.hooksPath` guard that chains to repository-local hooks runs its own checks, then delegates — to `.husky/pre-commit` here, unless an executable `.git/hooks/pre-commit` takes precedence.
 
 For changes that touch backend launch, session lifecycle, or `_meta` shape, also run
 the live ACP smokes that cover the touched rail — at minimum:

package/README.md

@@ -27,11 +27,8 @@ Claude and Cortex Code are ACP backends. Codex and Antigravity stay native so th
 retain their own tools and work context. Capabilities differ by rail: a shipped
 citizen is not a promise of every lifecycle operation.
 
-> **Current release: [0.33.0](https://github.com/junghan0611/entwurf/releases/tag/v0.33.0)**
-> ([`fea9b3d`](https://github.com/junghan0611/entwurf/commit/fea9b3dc4779ac5deb34e239abc8e0b5e3e95382)).
-> Includes the pinned Pi 1.1.0 native durable app/TUI and one explicit native-module ingress;
-> `npm` `latest` is `0.33.0`. What that cut ran and did not run is in its CHANGELOG section.
-> Release history and detailed evidence belong in [CHANGELOG](./CHANGELOG.md).
+[Releases](https://github.com/junghan0611/entwurf/releases) contain each cut's notes and acceptance
+receipts; [CHANGELOG](./CHANGELOG.md) records source history.
 
 ## Install
 
@@ -88,8 +85,8 @@ models/auth, queues, SQLite, transcripts and recovery remain upstream-owned:
 [Hard Rule 17](./AGENTS.md#hard-rules), **supply the missing surface; do not become the harness**.
 
 Optional `--native-module <absolute file>` initializes trusted ESM before runtime/TUI
-imports, then installs its default native Extension after the contact. After 0.33.0 (#134):
-`--native-module-dir <absolute directory>` loads the top-level `*.extension.mjs` files of that
+imports, then installs its default native Extension after the contact.
+`--native-module-dir <absolute directory>` (#134) loads the top-level `*.extension.mjs` files of that
 one named directory in byte-wise order instead, and the durable TUI keeps a live
 background-task badge on screen at any terminal size. No automatic module discovery or
 classic Pi API shim; guards are not a sandbox or rollback.

package/VERIFY.md

@@ -96,7 +96,7 @@ that moved out of `scripts/` and into a file beside its subject would otherwise
 
 > **The herdr rail is an on-demand axis until it has run.** `smoke-herdr-fresh-call-live` opens a real caller inside a real herdr pane, has it invoke the PUBLIC `entwurf_fresh_call`, and reads the child's nonce callback — the one axis no deterministic gate reaches, since the rail is selected from the caller's own process environment. **The release aggregate does not yet require the herdr rail**: herdr is optional (a cut on a host without it must not block), and first evidence precedes promotion — a rail whose first acceptance run is days old has not earned a place in the gate that blocks every cut. Run it directly with `LIVE=1 ./run.sh smoke-herdr-fresh-call-live` whenever a cut changes herdr rail code, and promote it to a MUST only after the axis has a run history to point at. Without `LIVE=1`, or without herdr/pi/claude on PATH, it reports protocol SKIP — never a pass.
 
-> **The plugin's FIRST USER PATH is its own on-demand axis, and an npm acquisition receipt holds only for the ref it ran on (#118 홉 1).** Every other herdr gate proves the plugin against a source this repository controls: `check-herdr-plugin-build` drives a stub, and `smoke-herdr-plugin-build-live` redirects the product remote to a local bare clone with git `insteadOf` and asserts `identity.kind === "herdr-checkout"`. npm has been the production authority class since `dd84ac0`; the 0.30.0 follow-up re-pinned `@junghanacs/entwurf@0.30.0` with its published sha512 after the candidate windows rode `herdr-checkout` (`8b92e09`). The **unpublished 0.30.1 preparation** now uses that closed verification carrier again, without inventing a registry integrity. The source re-proof has separate dated npm rows: 2026-09-23 public `main=113ca53`, plugin 0.5.0, runtime 0.25.0 (CHANGELOG 0.25.1), and the 0.30.0 re-pin accepted at public `506c46f` in the [#126 thread](https://github.com/junghan0611/entwurf/issues/126). Neither certifies a future 0.30.1 registry acquisition. After publication and a measured re-pin, that source owes its own public-ref run; checkout candidate evidence does not transfer. `LIVE=1 ./run.sh smoke-herdr-raw-install-live [--ref <REF>]` fills that row in a clean `node:24` container with no socket, config, cache or repo mounted, no `insteadOf`, the public remote spelled as a user would type it, and pi / herdr / Claude Code installed in the IMAGE BUILD as scaffolding (Hard Rule 17 — the product face begins at `herdr integration install pi`). herdr itself comes from `scripts/install-herdr-ci.sh` against `scripts/fixtures/herdr-supply.json`, so no version or digest lives here. `--ref` defaults to `main` rather than a pinned SHA because receipt (a) is defined as what a user gets today; the resolved commit is printed, so the receipt stays exact. It takes a REMOTE REF and not an arbitrary commit — measured on herdr 0.9.1, `--ref <sha>` fails as `couldn't find remote ref`, because the checkout fetches by name — so a candidate is addressed by its branch and pinned by the resolved commit the gate prints. **Its first question is a measurement, not an assumption:** herdr registers a plugin through a running server and falls back to `persist_plugin_offline` only on a connection error (`src/cli/plugin.rs:914-981,1016-1021` @ `c77af189`, 0.9.0 source), and a container has no server. The 2026-09-23 PASS installed with no server on the 0.9.1 binary `113ca53`'s `herdr-supply.json` pins, so that install path worked on 0.9.1 — inferred from the PASS, not a direct observation of the fallback branch; a later "no" on another herdr is #118 investigation output rather than a completion. `--yes` is always passed so a non-interactive exit 2 (`:189`) can never be misread as a missing server. **At a ref whose lock names `herdr-checkout` the acquisition axis reports a NAMED SKIP rather than a red, and the rest of the journey still runs.** That lock is the candidate carrier a cut legitimately sits on — 0.23.0 was tagged that way and `dd84ac0` pinned npm afterwards — so a red there would report a broken install when what is true is that the ref does not lock npm. What is asserted at BOTH lock kinds is that the runtime came from the source the ref locks, and the package name is read from the checkout manifest rather than the lock, because a `herdr-checkout` lock carries no `name` (`herdr-runtime.mjs:317-328`) and joining `undefined` throws instead of failing an assertion. **Cells [6]–[9] carry it past the install into the USE path (#118 H1-4/H1-5).** An install is not a use, so the same container then runs what those bytes became: the compiled bridge entry, the three `REQUIRED_BINS` as executables, and a real `entwurf check-bridge` printing its exact eight-verb set — the installed-runtime row below, measured rather than inferred from the bootstrap's refusal to install without them. Then the pi that this plugin WIRED is started with no `-e` and no `--no-extensions`, because the subject is the wiring and not this checkout: one `get_state` in `--mode rpc` costs zero tokens and needs no provider argument (a bogus `--provider` exits 1 before session_start; omitting the pair lets pi resolve the default the extension itself registers), and while that session is alive the cell reads its V3 record, its gardenId-keyed control socket, and the installed `entwurf peer-facts` reporting it `alive`. The plugin's own status fan is then driven with NEITHER side stubbed, in both states a user can be in: with no herdr server it must name `herdr-agent-list-failed` and go red rather than draw an empty table, and under a headless `herdr server` — scaffolding for that second read only, stopped again before the teardown — it exits 0 and COUNTS the citizen as `unobserved` instead of dropping it. Last, the shipped `entwurf herdr-plugin-deactivate` runs from the installed bin, deletes the runtime it is executing from, and the plugin reinstalls onto the host it fully left — the deactivation row, on the npm source. **What these cells still do not close:** swap / torn-swap recovery on the npm source, the package-consumer proof, and the fan drawing a citizen as a ROW — that needs `placement.kind === "herdr-pane"`, so the pi session must live in a herdr pane a session reference joins, and a headless container has no panes. **This smoke carries no test beside behavior and no mutant**, and that is a property of its class rather than an omission: it is a real-live container journey whose oracle is the container's own end state, so there is no pure seam to assert against and nothing a source mutation could kill deterministically. Like the other two herdr LIVE lanes it is **on-demand and not an aggregate MUST** — herdr is optional, a cut on a host without it must not block, and first evidence precedes promotion. Without `LIVE=1`, or without a usable Docker daemon, it reports a named SKIP; `ENTWURF_REQUIRE_DOCKER=1` turns the Docker absence red. Neither skip is a pass.
+> **The plugin's FIRST USER PATH is its own on-demand axis, and an npm acquisition receipt holds only for the ref it ran on (#118 홉 1).** Every other herdr gate proves the plugin against a source this repository controls: `check-herdr-plugin-build` drives a stub, and `smoke-herdr-plugin-build-live` redirects the product remote to a local bare clone with git `insteadOf` and asserts `identity.kind === "herdr-checkout"`. npm has been the production authority class since `dd84ac0`; the 0.30.0 follow-up re-pinned `@junghanacs/entwurf@0.30.0` with its published sha512 after the candidate windows rode `herdr-checkout` (`8b92e09`), and the 0.30.1 preparation rode that closed verification carrier again without inventing a registry integrity. The plugin snapshot `v2026.10.9-herdr.0.34.0` pinned the published `@junghanacs/entwurf@0.34.0` with its measured sha512 (#132); 0.31–0.33 were never pinned. The 0.34.1 preparation rode the closed `herdr-checkout` verification carrier again without inventing a registry integrity, and the snapshot `v2026.10.9-herdr.0.34.1` re-pins the published `@junghanacs/entwurf@0.34.1` with its measured sha512 (#135). The source re-proof has separate dated npm rows: 2026-09-23 public `main=113ca53`, plugin 0.5.0, runtime 0.25.0 (CHANGELOG 0.25.1), and the 0.30.0 re-pin accepted at public `506c46f` in the [#126 thread](https://github.com/junghan0611/entwurf/issues/126). Neither certifies the 0.34.0 registry acquisition. That pin's real-npm swap / torn-swap recovery was measured locally on 2026-10-09 by driving the registry-shipped `scripts/herdr-runtime.mjs` (byte-equal to this checkout's) with its own npm acquisition: a 0.33.0 → 0.34.0 swap, and the same upgrade torn between its two renames then resumed, where the last-good 0.33.0 tree was restored before 0.34.0 was acquired again. Both ended `runtime-ready` at observed digest `sha256-e9d995ff…`, the accepted 0.34.0 artifact. That local receipt is recorded in the [#132 thread](https://github.com/junghan0611/entwurf/issues/132); it covers runtime recovery, not this smoke's cells. This smoke's public-ref acceptance of the 0.34.0 pin was measured locally at `--ref main`: PASS at resolved `b5d15d8` and again at the docs follow-up `8ed4d1a`, each acquiring `kind=npm @junghanacs/entwurf@0.34.0` — a main-ref receipt, not a tag-ref, native or full-Herdr claim. The 0.34.1 re-pin's npm-source rows — swap / torn-swap recovery, this smoke at a public ref, and the package consumer — are its own, recorded with that pin and never inherited from 0.34.0; checkout candidate evidence does not transfer. `LIVE=1 ./run.sh smoke-herdr-raw-install-live [--ref <REF>]` fills that row in a clean `node:24` container with no socket, config, cache or repo mounted, no `insteadOf`, the public remote spelled as a user would type it, and pi / herdr / Claude Code installed in the IMAGE BUILD as scaffolding (Hard Rule 17 — the product face begins at `herdr integration install pi`). herdr itself comes from `scripts/install-herdr-ci.sh` against `scripts/fixtures/herdr-supply.json`, so no version or digest lives here. `--ref` defaults to `main` rather than a pinned SHA because receipt (a) is defined as what a user gets today; the resolved commit is printed, so the receipt stays exact. It takes a REMOTE REF and not an arbitrary commit — measured on herdr 0.9.1, `--ref <sha>` fails as `couldn't find remote ref`, because the checkout fetches by name — so a candidate is addressed by its branch and pinned by the resolved commit the gate prints. **Its first question is a measurement, not an assumption:** herdr registers a plugin through a running server and falls back to `persist_plugin_offline` only on a connection error (`src/cli/plugin.rs:914-981,1016-1021` @ `c77af189`, 0.9.0 source), and a container has no server. The 2026-09-23 PASS installed with no server on the 0.9.1 binary `113ca53`'s `herdr-supply.json` pins, so that install path worked on 0.9.1 — inferred from the PASS, not a direct observation of the fallback branch; a later "no" on another herdr is #118 investigation output rather than a completion. `--yes` is always passed so a non-interactive exit 2 (`:189`) can never be misread as a missing server. **At a ref whose lock names `herdr-checkout` the acquisition axis reports a NAMED SKIP rather than a red, and the rest of the journey still runs.** That lock is the candidate carrier a cut legitimately sits on — 0.23.0 was tagged that way and `dd84ac0` pinned npm afterwards — so a red there would report a broken install when what is true is that the ref does not lock npm. What is asserted at BOTH lock kinds is that the runtime came from the source the ref locks, and the package name is read from the checkout manifest rather than the lock, because a `herdr-checkout` lock carries no `name` (`herdr-runtime.mjs:317-328`) and joining `undefined` throws instead of failing an assertion. **Cells [6]–[9] carry it past the install into the USE path (#118 H1-4/H1-5).** An install is not a use, so the same container then runs what those bytes became: the compiled bridge entry, the three `REQUIRED_BINS` as executables, and a real `entwurf check-bridge` printing its exact eight-verb set — the installed-runtime row below, measured rather than inferred from the bootstrap's refusal to install without them. Then the pi that this plugin WIRED is started with no `-e` and no `--no-extensions`, because the subject is the wiring and not this checkout: one `get_state` in `--mode rpc` costs zero tokens and needs no provider argument (a bogus `--provider` exits 1 before session_start; omitting the pair lets pi resolve the default the extension itself registers), and while that session is alive the cell reads its V3 record, its gardenId-keyed control socket, and the installed `entwurf peer-facts` reporting it `alive`. The plugin's own status fan is then driven with NEITHER side stubbed, in both states a user can be in: with no herdr server it must name `herdr-agent-list-failed` and go red rather than draw an empty table, and under a headless `herdr server` — scaffolding for that second read only, stopped again before the teardown — it exits 0 and COUNTS the citizen as `unobserved` instead of dropping it. Last, the shipped `entwurf herdr-plugin-deactivate` runs from the installed bin, deletes the runtime it is executing from, and the plugin reinstalls onto the host it fully left — the deactivation row, on the npm source. **What these cells still do not close:** swap / torn-swap recovery on the npm source, the package-consumer proof, and the fan drawing a citizen as a ROW — that needs `placement.kind === "herdr-pane"`, so the pi session must live in a herdr pane a session reference joins, and a headless container has no panes. **This smoke carries no test beside behavior and no mutant**, and that is a property of its class rather than an omission: it is a real-live container journey whose oracle is the container's own end state, so there is no pure seam to assert against and nothing a source mutation could kill deterministically. Like the other two herdr LIVE lanes it is **on-demand and not an aggregate MUST** — herdr is optional, a cut on a host without it must not block, and first evidence precedes promotion. Without `LIVE=1`, or without a usable Docker daemon, it reports a named SKIP; `ENTWURF_REQUIRE_DOCKER=1` turns the Docker absence red. Neither skip is a pass.
 
 > **The Herdr plugin's install-time build has two axes, and one of them needs the network (#116 M3-b3).** `check-herdr-plugin-build` is deterministic and rides `check:hermetic`: the listing reaches the runner through its own spawn seam (there is no fake `herdr` binary in this repo), and the one cell that drives the REAL binary reports a named SKIP on a host without it — `ENTWURF_REQUIRE_HERDR=1` makes that absence red. What it cannot have is the real acquisition: `npm pack git+https://github.com/junghan0611/entwurf.git#<full sha>` builds the bridge through `prepare`, which installs devDependencies from the registry. So `LIVE=1 ./run.sh smoke-herdr-plugin-build-live` owns that axis, and its cells are **two kinds of evidence, labelled as such**: three are the real Herdr journey — a real `herdr plugin install` driving the real `[[build]]`, with the UNCHANGED product remote redirected to a local bare clone by git `insteadOf` (the one substitution, which is what makes an unpushed candidate testable) — covering remote-commit available, the `{pi}` → `{pi, claude-code}` reinstall with OpenCode as a zero-write negative control and exactly ONE counted vendor MCP owner entry, and the post-build Herdr-commit gap (where the ledger has already rebound to the gap commit, so the honest assertion is that transition and not unchanged bytes). The fourth cell — remote-commit **unavailable** — calls the shipped runtime leaf directly with the fixed product argv and is therefore **acquisition-leaf evidence, not a journey**; routing it through Herdr would add a second explanation for one red. Its oracle is the honest one too: active runtime, ledger and harness bytes preserved, while the journal is left as the certified `installing` retry authority the transaction deliberately writes before acquiring, and a normal install afterwards is green. Its Claude cell is where the vendor question the deterministic gates refuse to claim gets answered — whether Claude Code accepts an ABSOLUTE executable as an MCP command — and it reports a named skip on a host without `claude`, never a pass. Like the herdr fresh-call rail, this smoke is **on-demand and not an aggregate MUST**. The release aggregate does not require the plugin build smoke: herdr is optional, a cut on a host without it must not block, and first evidence precedes promotion.
 

package/docs/setup-clean-host.md

@@ -179,6 +179,24 @@ packageRoot↔installerRoot coupling mismatch and a package/provider managed-pat
 | source checkout | the checkout dir | `dev-bin` symlinks (`setup`) | `<project>/.pi/settings.json` | shared entry + owner state | `takeover-user-scope` from the new checkout | `remove` (project) / `remove-user-scope` (global, same-owner-only) | `doctor-pi-package` → `missing-owner`; normal install still refuses |
 | global npm (`npm i -g`) | the global `node_modules/@junghanacs/entwurf` | npm bin linking | same | same shared entry | same explicit action | same; a LIVE foreign owner always refuses | same |
 | project-local npm | that project's `node_modules/@junghanacs/entwurf` | `node_modules/.bin` | same | same shared entry | same explicit action | same | same; a deleted root becomes the aligned `remove-user-scope` orphan cleanup (entry + package state + provider installerRoot must all name that missing root) |
+| Herdr plugin | `$XDG_DATA_HOME/entwurf/herdr-plugin/runtime/active/node_modules/@junghanacs/entwurf` | none on PATH — Pi provider and Claude MCP/statusLine record ABSOLUTE commands under that runtime | none | same shared entry, plus the plugin's activation ledger (`$XDG_STATE_HOME/entwurf/herdr-plugin/activation.json`) | none — the plugin never takes a registration over; release it from its owner first | the runtime's own absolute `…/node_modules/.bin/entwurf herdr-plugin-deactivate` | — |
+
+The four installation paths keep separate records: Herdr's plugin registry (changed only by `herdr
+plugin install` / `unlink` / `uninstall`), the plugin's runtime journal and activation ledger, the shared Pi
+package/provider ownership above, and the Claude meta-bridge install state
+(`${CLAUDE_CONFIG_DIR:-~/.claude}/entwurf.install-state.json`). Moving between them is explicit: release the
+shared registration from its owner (`remove-user-scope`, plus `uninstall-meta-bridge` for Claude) before
+`herdr plugin install` — a foreign Pi owner refuses the plugin build before anything is fetched (#135) — and
+run the plugin's `herdr-plugin-deactivate` before going back to `setup`. Do not `takeover-user-scope` a
+registration the plugin owns, even though a refused `setup` suggests it: it splits ownership (the plugin's
+provider key becomes an unowned override while its ledger still records pi) and the plugin's deactivate
+then refuses. Limits that stay as they are: the Claude install state records the LAST installer and is not
+root-bound — an install from another root rewrites it rather than refusing; nothing covers roots (XDG,
+`PI_CODING_AGENT_DIR`, Claude config) changed between runs or a host that changes between the plugin's
+early owner check and its installed recheck, which can still refuse after the download; and the plugin's
+deactivate, finding no activation ledger, reports what is left at its addresses and neither reclaims nor
+reuses it. The 0.34.0 runtime predates that no-ledger diagnostic; a plugin host runs the runtime its
+`runtime-lock.json` pins.
 
 ## 2. Optional pi adapter / ACP plugin
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@junghanacs/entwurf",
-	"version": "0.34.0",
+	"version": "0.34.2",
 	"description": "Garden-citizen dispatch substrate and meta-bridge for pi, Claude Code, Copilot CLI, OMP, Antigravity, and Codex CLI; Claude and Snowflake Cortex Code ACP backends.",
 	"license": "MIT",
 	"author": {
@@ -119,7 +119,7 @@
 		"vitest": "4.1.9"
 	},
 	"scripts": {
-		"prepare": "husky 1>&2 || true; npm run --silent build-bridge 1>&2",
+		"prepare": "npm run --silent build-bridge 1>&2",
 		"postinstall": "node scripts/postinstall-chmod.cjs",
 		"build-bridge": "bash scripts/with-dist-lock.sh bash scripts/build-bridge.sh",
 		"prepack": "pnpm run build-bridge 1>&2",

package/run.sh

@@ -294,7 +294,7 @@ Usage:
   ./run.sh remove [project-dir]       # remove entwurf entries from project .pi/settings.json (project scope only; global user-scope citizen left intact)
   ./run.sh install-user-scope [--plugin-runtime <root>]  # #116 M3-b2 PLUGIN-ONLY forward seam: compose ONLY the global pi citizen (user-scope packages[] + provider), never a project `.pi/settings.json` — a Herdr plugin activation has no project and must not invent one. With --plugin-runtime the provider's managed command becomes the absolute bridge under that certified stable runtime (a clean host has nothing entwurf on PATH); without it every byte is the historical bare-bin install. Inverse: remove-user-scope
   ./run.sh herdr-plugin-activate <backend...>  # #116 M3-b2 public forward activation. Takes a subset of {pi, claude-code} and NOTHING else — the stable runtime root is DERIVED from XDG here and handed down, and both harness writers accept a named root only when it IS that derived one. Certifies the runtime-ready journal AND the installed tree, certifies the existing ledger and its recorded harness roots, plans ADD-ONLY (a backend absent from this request is retained, never removed), preflights every selected component before the first byte, then writes each component `pending` BEFORE mutating and checkpoints `active` the moment its writer returns — so a run that dies halfway leaves a record of how far it got. Which backends is M3-b3's question: this verb is handed the answer, it does not read Herdr's integration status
-  ./run.sh herdr-plugin-deactivate   # #116 M3-b2 public teardown of a Herdr-plugin activation. Herdr's `plugin uninstall` deletes its checkout and calls NO cleanup hook, so the harness wiring and the stable runtime are retained, not cleaned — this is the shipped verb that takes them back. Certifies the activation ledger, the resolved Pi/Claude roots and BOTH component inverses read-only first; mutates only when every preflight is green; then Claude -> Pi user scope -> runtime -> ledger LAST. A component failure stops with the runtime and ledger intact as retry authority. Static imports only: the process deletes the runtime it is running from, and a lazy import after that fails
+  ./run.sh herdr-plugin-deactivate   # #116 M3-b2 public teardown of a Herdr-plugin activation. Herdr's `plugin uninstall` deletes its checkout and calls NO cleanup hook, so the harness wiring and the stable runtime are retained, not cleaned — this is the shipped verb that takes them back. Certifies the activation ledger, the resolved Pi/Claude roots and BOTH component inverses read-only first; mutates only when every preflight is green; then Claude -> Pi user scope -> runtime -> ledger LAST. A component failure stops with the runtime and ledger intact as retry authority. With NO ledger it removes nothing: a clean host exits 0, and anything found at the plugin's journal/runtime/cache addresses is named with a non-zero exit (#135). Static imports only: the process deletes the runtime it is running from, and a lazy import after that fails
   ./run.sh remove-user-scope          # explicit GLOBAL inverse of install's user-scope citizen: drop entwurf from ~/.pi/agent/settings.json packages[] (affects ALL cwds — shared entry, not per-project). #86 C2: same-owner-only — a LIVE foreign owner refuses; a MISSING owner is removed only when package entry + package state + provider installerRoot all align (reported orphan cleanup)
   ./run.sh takeover-user-scope        # #86 C2: operator-EXPLICIT ownership move of the shared user-scope registration to THIS root (old→new reported, packages[] entry + provider installerRoot together). The only writer over another owner — normal install/setup/remove refuse instead. No --force exists
   ./run.sh doctor-pi-package          # #86 C2: package-side user-scope ownership verdict — unregistered / owned / owned-by-other(live) / legacy-no-state / mismatch / missing-owner (nonzero on defect verdicts). Provider runtime verdicts stay with doctor-pi-provider
@@ -4393,8 +4393,8 @@ _check_pack_install_impl() {
 
   # Fresh-temp install smoke. Uses pnpm because that is what this
   # repo packages with; --ignore-workspace stops it from re-attaching
-  # to our pnpm-workspace.yaml; --ignore-scripts blocks the husky
-  # prepare hook (and any future install scripts) from running inside
+  # to our pnpm-workspace.yaml; --ignore-scripts blocks
+  # prepare (and any future install scripts) from running inside
   # the consumer project. The pi SDK is pinned to the CURRENT pi release
   # baseline (the package.json exact production dependency — the pins below
   # are what check-dep-versions binds to it) so the smoke matches the same
@@ -7634,6 +7634,8 @@ case "$cmd" in
     # global plugin install, USER MCP reach, meta-record store integrity, hook log
     # no-ERROR, and actual SessionStart creation evidence. A plugin present with
     # zero claude-code meta-records is a SILENT MISS -> non-zero exit.
+    # #136: the only argument is `--plugin-runtime <root>`; shift the verb so the doctor sees it.
+    shift || true
     (cd "$REPO_DIR" && bash scripts/meta-bridge-doctor.sh "$@")
     ;;
   install-copilot-bridge)

package/scripts/check-gate-qualification.ts

@@ -3471,8 +3471,8 @@ let manifestCount: number;
 		"herdr-placement": 13,
 		"herdr-plugin": 25,
 		"herdr-plugin-profile": 14,
-		"herdr-activation": 25,
-		"herdr-plugin-build": 14,
+		"herdr-activation": 34,
+		"herdr-plugin-build": 20,
 		"herdr-runtime-bootstrap": 31,
 		"herdr-fresh-call": 38,
 		"herdr-supply": 11,