token-harness 0.1.2 → 0.1.3

package/README.md

@@ -90,13 +90,14 @@ HarnessTrim, or a coding agent.
 ### Managed compatibility rows
 
 Token Harness changes a harness configuration only when a reviewed compatibility row covers the
-exact provider version, harness version, platform, and configuration schema. Two rows ship, and each
+exact provider version, harness version, platform, and configuration schema. Three rows ship, and each
 names the recording it stands on:
 
 | Provider | Harness | Platform | Tested versions | Tier |
 | --- | --- | --- | --- | --- |
 | RTK | Claude Code | Windows | rtk 0.44.0, Claude Code 2.1.220 | `canary` |
 | HarnessTrim | Claude Code | Windows | harnesstrim 0.1.0, Claude Code 2.1.220 | `config-only` |
+| HarnessTrim | Codex | Windows | harnesstrim 0.1.0, Codex 0.146.0 | `config-only` |
 
 Everything else is refused, and that is the design rather than a gap: `doctor` detects and reports on
 every supported platform, and only the *mutation* is narrower. An uncovered combination exits 9 and
@@ -107,9 +108,18 @@ What is not covered today, and why:
 - **macOS and Linux.** No row on either. The recordings a row needs are states of a real machine, and
   a fixture cannot be written from a machine nobody ran. On those platforms `plan` and `apply` refuse;
   install the provider with its own installer and Token Harness will detect, verify, and measure it.
-- **Codex and OpenCode.** Both providers are detected and adopted there, and neither is written:
-  RTK's plan builder produces a Claude-shaped hook list, and HarnessTrim's reviewed write set covers
-  Claude only. A row would admit a mutation that nothing proposes.
+- **OpenCode, and permanently rather than pending.** Both providers are detected, adopted, verified
+  and measured there, and neither is written. RTK reaches OpenCode through a plugin module its own
+  installer places globally, which this build has no action for. HarnessTrim's OpenCode installer
+  writes a plugin wrapper *and runs an npm install*, so a containment boundary covering what it wrote
+  would hold a `node_modules` tree — and that is not a decision deferred for want of a fixture. A
+  dependency tree is not configuration, so it cannot be a reviewed write set; snapshotting it on
+  every apply to keep the rollback honest would be slow and would be restoring upstream's install
+  rather than our change; and excluding it would leave a transaction claiming a reversibility it does
+  not have. So the assignment is not producible, and RFC 0003 is explicit about what that means: a
+  capability the provider has but cannot be asked for is not an assignable capability. OpenCode stays
+  adoption-only by decision.
+- **RTK on Codex.** Not managed, and no row: RTK writes a Claude-shaped hook list and nothing else.
 - **A newer Claude Code.** The range is a single observed version. `2.1.221` reads `unknown-newer` and
   refuses rather than assuming it behaves like `2.1.220`.
 
@@ -122,21 +132,35 @@ There are three separate layers. Installing one does not automatically provide t
 
 | Layer | Examples | Who installs it? |
 | --- | --- | --- |
-| Coding agent (harness) | Claude Code, Codex, OpenCode | You, using the agent's official installer |
+| Coding agent (harness) | Claude Code, Codex, OpenCode, Hermes, Pi | You, using the agent's official installer |
 | Token Harness | `token-harness` | You, from npm or this repository |
 | Optimization provider | RTK, HarnessTrim | Both can be installed by Token Harness where a compatibility row covers the combination; otherwise install them with their own installers and Token Harness detects and measures them |
 
-Token Harness does not install Claude Code, Codex, or OpenCode. Install and run at least one of
+Token Harness does not install Claude Code, Codex, OpenCode, Hermes, or Pi. Install and run at least one of
 them first so that `token-harness doctor` can detect it.
 
-| Provider | Claude Code | Codex | OpenCode | Installed by Token Harness |
-| --- | --- | --- | --- | --- |
-| RTK | Configure, verify, and measure | Not managed | Detect, adopt, verify, and measure | **Yes**, for the supported Claude Code path |
-| HarnessTrim | Claude skills only; no reducer hook or reduce-pipe instruction | Detect, adopt, verify, and measure | Detect, adopt, verify, and measure | **Yes**, on a covered row — see above |
+| Provider | Claude Code | Codex | OpenCode | Hermes | Pi | Installed by Token Harness |
+| --- | --- | --- | --- | --- | --- | --- |
+| RTK | Configure, verify, and measure | Not managed | Detect, adopt, verify, and measure | Not managed | Not managed | **Yes**, for the supported Claude Code path |
+| HarnessTrim | Claude skills only; no reducer hook or reduce-pipe instruction | Detect, adopt, verify, and measure | Detect, adopt, verify, and measure | Detect, verify, and measure | Detect, verify, and measure | **Yes**, on a covered row — see above |
 
 "Not managed" does not mean the upstream tool cannot support that agent. It means this release
 does not claim ownership of that integration and will not modify it.
 
+Hermes is read-only in both directions: the adapter finds the HarnessTrim plugin, reads whether it
+is enabled, and imports the telemetry it writes to `~/.hermes/harnesstrim-metrics.jsonl`, but nothing
+here enables the plugin or restarts the gateway. Enabling it is
+`hermes plugins enable harnesstrim`, and that stays your command to run. No compatibility row ships
+for Hermes because a row is the precondition for a *mutation*, and none is proposed.
+
+Pi is read-only in both directions too: the adapter finds the HarnessTrim extension module in the
+directories Pi auto-loads (`~/.pi/agent/extensions/` and `<project>/.pi/extensions/`) and verifies
+the configuration, but nothing here installs it, and nothing here can say which mode it runs in —
+the extension defaults to `dryrun` and only `HARNESSTRIM_MODE=active` in Pi's environment makes it
+reduce. Installing it is `harnesstrim install pi --apply`, and that stays your command to run. No
+compatibility row ships for Pi because a row is the precondition for a *mutation*, and none is
+proposed.
+
 RTK on OpenCode is detected and verified, not written: `rtk init -g --opencode` installs a plugin
 module at `~/.config/opencode/plugins/rtk.ts`, and Token Harness reads that file rather than
 producing it. Note that the plugin is inert under OpenCode Desktop — see

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "token-harness",
-  "version": "0.1.2",
+  "version": "0.1.3",
   "description": "One control plane for token-efficient coding agents.",
   "license": "Apache-2.0",
   "type": "module",

package/sbom.json

@@ -7,7 +7,7 @@
       "type": "application",
       "bom-ref": "token-harness",
       "name": "token-harness",
-      "version": "0.1.2",
+      "version": "0.1.3",
       "description": "One control plane for token-efficient coding agents.",
       "licenses": [
         {
@@ -19,7 +19,7 @@
       "hashes": [
         {
           "alg": "SHA-256",
-          "content": "8e2f96efbb15fd8aec72a98ae3b62d128265abd779e9f911c8c0d4bf024adfb2"
+          "content": "d28d7044c0215e3471e990732b14275cca61e57a823e7a04a505748be73613c8"
         }
       ]
     },