@dzhechkov/harness-cli 0.4.4 → 0.4.5

package/.dz-manifest.json

@@ -69,7 +69,7 @@
       },
       {
         "path": "package.json",
-        "sha256": "5bd26341b4a5885c116432bf621b7fdb4172b2604db47ad3c1c001deb4fe6ed4"
+        "sha256": "00a53276d145112e3c2ae5ca2950ac74877ea4b069b2b81040d49c5903eb6482"
       },
       {
         "path": "src/bin.ts",
@@ -221,5 +221,5 @@
       }
     ]
   },
-  "signature": "dzYono+I+DXsxk1h8k2DAiNYKHmdzhwaUMDvvfFjCqzVFvYZecPnJQCLgT8i5NrpkaOQl2mbwU8bd3tyxQueDg=="
+  "signature": "6IQyjN4aazsr6EyD1+y/VrZ1+bclvxc9nXsCLR3WVDomAn6AhNtlTJQWdfbvw49A4/HH+KTW+KkJlj/gFFnqCw=="
 }

package/README.md

@@ -1141,12 +1141,16 @@ host run there is nothing to read, and it says so rather than inventing a timeli
 follows from the same boundary: on a non-Claude-Code target the authoring and lint verbs work
 unchanged, and only execution is absent.
 
-### Build a loop for YOUR scenario — the end-to-end use case
+### Build a loop for YOUR scenario — the end-to-end use case (a real one)
 
-You have a repeating multi-agent job of your own — say, **a weekly competitor digest: three
-competitors researched in parallel, one synthesis, and a quality gate that sends a weak digest back
-for a redo**. Here is the whole path, with real command output. Every command below was executed
-before being written down; the outputs are captures, not sketches.
+This walkthrough is not an invented example. It is the loop that closed a real roadmap item in this
+very repo: a test pinned `34 canonical packages` while the workspace had grown past 50 directories —
+red forever, and nobody trusted a hand count. The job: produce a **verified inventory** of every
+directory under `packages/@dzhechkov` (canonical vs private vs not-a-package), too much for one
+sitting → an audit fanout: package chunks audited in parallel lanes, one synthesis, and a quality
+gate that rejects an inventory that doesn't cover every directory. Every command and output below is
+a capture from the run that actually fixed the test (MEASURED — reproducer
+`node --test tests/canonical-packages.test.mjs`: 289 pass / 0 fail after the re-pin).
 
 **Install (once):**
 
@@ -1162,8 +1166,8 @@ RUNS one. Execution belongs to a host with the `Workflow({scriptPath})` runtime,
 #### Step 1 — scaffold the plan shape closest to your scenario
 
 ```bash
-dz workflow init --name competitor-digest --pattern fanout --o digest.plan.json
-# → wrote digest.plan.json (pattern: fanout)
+dz workflow init --name pkg-inventory-audit --pattern fanout --o audit.plan.json
+# → wrote audit.plan.json (pattern: fanout)
 # → Next: edit the TODO prompts, then `dz workflow validate` + `dz workflow render`.
 ```
 
@@ -1173,14 +1177,20 @@ template you fight.
 
 #### Step 2 — make it yours (edit the JSON)
 
-Fill the `TODO` prompts, name your lanes in `fanouts[].registry` (`["acme","globex","initech"]`),
-and add the quality gate with a redo route:
+Fill the `TODO` prompts, name your work units in `fanouts[].registry`, and add the quality gate
+with a redo route. The real plan's shape (abridged from
+`features/pkg-inventory-audit/audit.plan.json` in this repo):
 
 ```json
-"steps": [ …, { "stepId": "check", "kind": "gate", "phase": "Gate", "deps": ["synthesize"],
-                "prompt": "…answer strictly GATE: PASS or GATE: FAIL as the last line",
-                "budget": { "maxAgents": 2 } } ],
-"gates": [ { "stepId": "check", "kind": "quality", "failRoute": "synthesize", "maxRedos": 1 } ]
+"fanouts": [ { "stage": "fan", "chain": ["lane"], "maxFanout": 3,
+               "registry": ["chunk-1","chunk-2","chunk-3","chunk-4","chunk-5","chunk-6"] } ],
+"joins":   [ { "stage": "jn", "forStage": "fan", "joinPolicy": "all-activated",
+               "onInvalid": "named-failure" } ],
+"steps":   [ …lanes…, { "stepId": "synthesize", "kind": "agent", "deps": ["jn"],
+                        "prompt": "Merge the lane JSONs into one inventory. Return STRICT JSON…" },
+             { "stepId": "check", "kind": "gate", "deps": ["synthesize"],
+               "prompt": "…counts.total must equal 52… answer GATE: PASS or GATE: FAIL" } ],
+"gates":   [ { "stepId": "check", "kind": "quality", "failRoute": "synthesize", "maxRedos": 1 } ]
 ```
 
 The plan surface is deliberately NARROW and fully enacted: anything the generated loop would not
@@ -1190,14 +1200,14 @@ accepted and ignored.
 #### Step 3 — validate, render, lint (the three gates before any run)
 
 ```bash
-dz workflow validate digest.plan.json
-# → dz workflow validate: OK (digest sha256:6b6e92fc31b781fa…)
+dz workflow validate audit.plan.json
+# → dz workflow validate: OK (digest sha256:70992d9ddc86de15…)
 
-dz workflow render digest.plan.json --o digest.loop.js
-# → wrote digest.loop.plan.json then digest.loop.js (exec-fp sha256:a095d12e…, blobs: trace)
+dz workflow render audit.plan.json --o audit.loop.js
+# → wrote audit.loop.plan.json then audit.loop.js (exec-fp sha256:49feb8a2c1e17038…, blobs: trace)
 
-dz workflow-lint digest.loop.js --plan digest.loop.plan.json --require-plan
-# → dz workflow-lint: PASS (0 fail, 1 warn, 0 inconclusive over 17 rules)
+dz workflow-lint audit.loop.js --plan audit.loop.plan.json --require-plan
+# → dz workflow-lint: PASS (mode=require-plan; 0 fail, 1 warn, 0 inconclusive over 17 rules)
 ```
 
 `inconclusive` is never a pass, and the rendered script keeps your hand edits across re-renders
@@ -1205,18 +1215,37 @@ dz workflow-lint digest.loop.js --plan digest.loop.plan.json --require-plan
 
 #### Step 4 — run it (Claude Code), read it back (anywhere)
 
-In **Claude Code**, paste exactly this:
+In **Claude Code**, paste exactly this shape:
 
-> Запусти мой цикл: `Workflow({ scriptPath: 'digest.loop.js', args: { items: ["acme","globex","initech"], traceDir: '<run dir>', runId: 'digest-2026-08-18' } })` — и когда закончит, покажи `dz workflow-trace` по этому прогону.
+> Запусти мой цикл: `Workflow({ scriptPath: 'audit.loop.js', args: { traceDir: '.dz/loop-trace/pkg-audit-1', runId: 'pkg-audit-1' } })` — и когда закончит, покажи `dz workflow-trace --run pkg-audit-1`.
 
-What a real run of THIS plan looks like (captured from an offline harness run of the rendered
-script): `lane:acme, lane:globex, lane:initech` in parallel → `synthesize` → `check` answers
-`GATE: FAIL` → the redo route re-runs `synthesize` → `check` answers `GATE: PASS` → `COMPLETED`.
-13 agent calls, one ledger row, the trace flushed at every settle. Then:
+What the real run produced (captured verbatim; the trace lives at `.dz/loop-trace/pkg-audit-1/` in
+this repo):
 
-```bash
-dz workflow-trace <runDir> --html report.html   # timeline + SEQ invariants over the loop's own trace
 ```
+run pkg-audit-1; sources: trace, ledger
+      1  run.opened  plan=70992d9ddc86 exec-fp=49feb8a2c1e1
+      2  dispatch lane:chunk-1#1  phase=Lanes
+      3  dispatch lane:chunk-2#1  phase=Lanes
+      4  dispatch lane:chunk-3#1  phase=Lanes
+      5..7  settle lane:chunk-{1,2,3}  outcome=ok
+      8  dispatch synthesize#1  phase=Synthesize
+      9  settle synthesize#4  outcome=ok
+     10  dispatch check#1  phase=Gate causedBy=[9]
+     11  settle check#5  outcome=ok        ← GATE: PASS
+     12  run.closed  {"dispatched":5,"settled":5}
+```
+
+The gate passed, the inventory (52 directories = 49 canonical + 2 private + 1 non-package) was
+cross-checked deterministically against the filesystem, and the stale test was re-pinned to it.
+
+**And the run surfaced a real defect — kept here on purpose.** Read the trace again: the registry
+names six chunks, but only `chunk-1..3` ever dispatched — `maxFanout: 3` **silently truncated** the
+other three lanes, and the run stayed green only because the synthesize agent noticed the gap and
+audited the missing chunks with its own tools. That is exactly what the trace is for: it shows what
+your loop *did*, not what the plan promised. (Filed in this repo's backlog: over-registry items must
+become a named failure or a loud trace event, never a silent drop. Until then: keep
+`fanouts[].registry.length ≤ maxFanout`, and read the trace after the first run of any new plan.)
 
 #### How to phrase the ASK — Claude Code vs Codex
 
@@ -3405,7 +3434,7 @@ npx @dzhechkov/p-replicator init
 
 ## Status
 
-`v0.4.4` — published on npm. Also available as [Claude Plugin](#claude-plugin). Part of [DZ Harness Hub](https://github.com/djd1m/dz-harness-hub).
+`v0.4.5` — published on npm. Also available as [Claude Plugin](#claude-plugin). Part of [DZ Harness Hub](https://github.com/djd1m/dz-harness-hub).
 
 ## Claude Plugin
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dzhechkov/harness-cli",
-  "version": "0.4.4",
+  "version": "0.4.5",
   "description": "The dz CLI — install AI skills for Claude Code, Codex, OpenCode, Hermes, OpenClaude, GitHub Copilot. 35 commands, 13 presets, 6 platform targets.",
   "type": "module",
   "license": "MIT",
@@ -40,6 +40,13 @@
     ".dz-manifest.json",
     "sbom.json"
   ],
+  "scripts": {
+    "build": "tsc -p tsconfig.json",
+    "test": "vitest run",
+    "test:watch": "vitest",
+    "typecheck": "tsc -p tsconfig.json --noEmit",
+    "lint": "tsc -p tsconfig.json --noEmit"
+  },
   "dependencies": {
     "@dzhechkov/harness-core": "^0.4.0",
     "@dzhechkov/harness-presets": "^0.5.0",
@@ -75,12 +82,5 @@
     "url": "https://github.com/djd1m/dz-harness-hub.git",
     "directory": "packages/@dzhechkov/harness-cli"
   },
-  "homepage": "https://github.com/djd1m/dz-harness-hub/tree/main/packages/@dzhechkov/harness-cli#readme",
-  "scripts": {
-    "build": "tsc -p tsconfig.json",
-    "test": "vitest run",
-    "test:watch": "vitest",
-    "typecheck": "tsc -p tsconfig.json --noEmit",
-    "lint": "tsc -p tsconfig.json --noEmit"
-  }
-}
+  "homepage": "https://github.com/djd1m/dz-harness-hub/tree/main/packages/@dzhechkov/harness-cli#readme"
+}

package/sbom.json

@@ -175,7 +175,7 @@
       "hashes": [
         {
           "alg": "SHA-256",
-          "content": "5bd26341b4a5885c116432bf621b7fdb4172b2604db47ad3c1c001deb4fe6ed4"
+          "content": "00a53276d145112e3c2ae5ca2950ac74877ea4b069b2b81040d49c5903eb6482"
         }
       ]
     },

package/LICENSE

@@ -1,21 +0,0 @@
-MIT License
-
-Copyright (c) 2026 dzhechko
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.