@dzhechkov/harness-cli 0.4.3 → 0.4.5

package/.dz-manifest.json

@@ -9,7 +9,7 @@
       },
       {
         "path": "README.md",
-        "sha256": "532051106b153c0d9bb7ad2abbeb71d418f88f1bc88e60a35e29cf42162af243"
+        "sha256": "2f053f11ea49780919d0557877302e70adb8f33949299b0b0637ece2809c1b67"
       },
       {
         "path": "coverage/coverage-final.json",
@@ -69,7 +69,7 @@
       },
       {
         "path": "package.json",
-        "sha256": "4a164e5ac53ceec178463c1bdab9f80c1755311d5e4202c1f6234ca22c473b37"
+        "sha256": "00a53276d145112e3c2ae5ca2950ac74877ea4b069b2b81040d49c5903eb6482"
       },
       {
         "path": "src/bin.ts",
@@ -221,5 +221,5 @@
       }
     ]
   },
-  "signature": "wIo2tChkUqPT1qEHFeLlgbuzL29rRhhpVer4yaDmeuq7CsvdMeYN2QcttC496DwlepKeZ1EE3h2sSoY5w16qAA=="
+  "signature": "6IQyjN4aazsr6EyD1+y/VrZ1+bclvxc9nXsCLR3WVDomAn6AhNtlTJQWdfbvw49A4/HH+KTW+KkJlj/gFFnqCw=="
 }

package/README.md

@@ -1141,6 +1141,137 @@ 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 (a real one)
+
+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):**
+
+```bash
+npm i -g @dzhechkov/harness-cli     # gives you the `dz` binary
+# or zero-install per call:  npx @dzhechkov/harness-cli workflow init …
+```
+
+**The division of labour, honestly stated up front:** `dz` AUTHORS, GATES and READS loops — it never
+RUNS one. Execution belongs to a host with the `Workflow({scriptPath})` runtime, which today means
+**Claude Code**. So: author anywhere (Codex included), run under Claude Code.
+
+#### Step 1 — scaffold the plan shape closest to your scenario
+
+```bash
+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`.
+```
+
+Patterns: `pipeline` (A→B→C), `barrier` (all A, then B), `fanout` (N parallel lanes + a join),
+`gate` (a checked step with a redo route). The scaffold is a REAL plan with `TODO` prompts — not a
+template you fight.
+
+#### Step 2 — make it yours (edit the JSON)
+
+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
+"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
+actually perform is REJECTED at validate time with a named `ENACT-*` diagnostic — never silently
+accepted and ignored.
+
+#### Step 3 — validate, render, lint (the three gates before any run)
+
+```bash
+dz workflow validate audit.plan.json
+# → dz workflow validate: OK (digest sha256:70992d9ddc86de15…)
+
+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 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
+(USER regions are preserved).
+
+#### Step 4 — run it (Claude Code), read it back (anywhere)
+
+In **Claude Code**, paste exactly this shape:
+
+> Запусти мой цикл: `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 the real run produced (captured verbatim; the trace lives at `.dz/loop-trace/pkg-audit-1/` in
+this repo):
+
+```
+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
+
+**In Claude Code** (it has both `dz` and the `Workflow` runtime — one message does the whole thing):
+
+> Собери мне цикл под сценарий: «<опиши свой — источники, что делает каждая полоса, как сводить,
+> какой критерий качества>». Используй `dz workflow init/validate/render/workflow-lint`, покажи мне
+> план НА СОГЛАСОВАНИЕ до рендера, потом запусти через `Workflow({scriptPath})` и дай ссылку на
+> `workflow-trace` отчёт.
+
+The "покажи план до рендера" clause matters: the plan JSON is the one artifact worth your review —
+prompts, lanes, gate criteria, budgets — and it is small.
+
+**In Codex** (or any shell-capable agent — AUTHORING only, honestly):
+
+> In this repo, run `npx @dzhechkov/harness-cli workflow init --name <x> --pattern fanout --o x.plan.json`,
+> then edit the plan for this scenario: <describe>. Run `workflow validate` and fix every diagnostic
+> it names, then `workflow render` and `workflow-lint --require-plan`. Do NOT attempt to execute the
+> generated loop — it runs under Claude Code's `Workflow({scriptPath})` runtime; hand me the green
+> plan and the rendered script.
+
+Codex is a fine plan AUTHOR — the validate/lint diagnostics are named and machine-checkable, so its
+edit loop converges. What it cannot do is run the result: the generated script calls the host's
+`agent()`/`parallel()` sandbox, which only the Claude Code Workflow runtime provides. A green lint
+from Codex + a run under Claude Code is a legitimate two-agent split.
+
 ### Move a run's telemetry to another machine (`workflow-trace export` / `import`)
 
 A run leaves traces on the machine that produced it. `export` puts one run's telemetry into a single
@@ -3303,7 +3434,7 @@ npx @dzhechkov/p-replicator init
 
 ## Status
 
-`v0.4.3` — 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.3",
+  "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

@@ -25,7 +25,7 @@
       "hashes": [
         {
           "alg": "SHA-256",
-          "content": "532051106b153c0d9bb7ad2abbeb71d418f88f1bc88e60a35e29cf42162af243"
+          "content": "2f053f11ea49780919d0557877302e70adb8f33949299b0b0637ece2809c1b67"
         }
       ]
     },
@@ -175,7 +175,7 @@
       "hashes": [
         {
           "alg": "SHA-256",
-          "content": "4a164e5ac53ceec178463c1bdab9f80c1755311d5e4202c1f6234ca22c473b37"
+          "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.