@dzhechkov/harness-cli 0.8.24 → 0.8.26

package/.dz-manifest.json

@@ -9,7 +9,7 @@
       },
       {
         "path": "README.md",
-        "sha256": "55e833687e744ffc8f067d1fe9264d1987f32a61dc35236985234f7652b066da"
+        "sha256": "61e9c0cf5c85f1a9841af35346e6ff6351b8cdb95d11aa3b5b7c0bd82d0a6a5e"
       },
       {
         "path": "dist/bin.d.ts",
@@ -45,19 +45,19 @@
       },
       {
         "path": "dist/cli.d.ts",
-        "sha256": "d68251a8d5bf76c6a91e37bb72ba10169738f9be70aa879992247387845881ce"
+        "sha256": "1452c5529edf1c4d57711ae9c6610cf37c7619a88024c3874c499060fc4d1c31"
       },
       {
         "path": "dist/cli.d.ts.map",
-        "sha256": "55791604a1965a25dff3c3e8563b72a3dc0acc0cb3df8939d398da55221b17e3"
+        "sha256": "e750aecbc3e43a94e490b21d675f12f14dd24ddc364fb40ad811edc35e98af94"
       },
       {
         "path": "dist/cli.js",
-        "sha256": "4ca1bf4b207b13bf6bc679db969a9aede9220a81874440c55715c5f0ad7a552c"
+        "sha256": "b1a441c645ff9bcbc592069eab87742744fd6f6826cfa560f7b8203117ab927f"
       },
       {
         "path": "dist/cli.js.map",
-        "sha256": "8cf4559933a2db86c202b9283b04041b8425ea50f600e12c4f738c0d73498707"
+        "sha256": "c14e8a4542ac690b6033e69b01edf22554d6b9ac4e431a39ee0910445059e319"
       },
       {
         "path": "dist/command-inventory.d.ts",
@@ -129,15 +129,15 @@
       },
       {
         "path": "dist/known-flags.d.ts.map",
-        "sha256": "4388c40ba547deb7c1cc8038faab8b34146f3abb5538d4e64b328da4fea2bb7f"
+        "sha256": "db7b4dead9a5ca4054c1e1e7df8c56eed65a9fa31771ab0b4930c67e228f326c"
       },
       {
         "path": "dist/known-flags.js",
-        "sha256": "481e990a09740a1af38213787041bf2c70f54c3539ccfb49fb045bd374bc7669"
+        "sha256": "77eac32f2c0e552e0417205a43f40d18feacb951a768b9303360f0321fd79f6b"
       },
       {
         "path": "dist/known-flags.js.map",
-        "sha256": "86d0e1be18f4bca85feafd2865b2371e77a04e202bf99b87ecda9483696e7433"
+        "sha256": "abf5332fb08f5403d244232cf7528be8163fad17de90ec48fb0d5dc5c995ec03"
       },
       {
         "path": "keys/README.md",
@@ -149,7 +149,7 @@
       },
       {
         "path": "package.json",
-        "sha256": "fb1f3f04f6937cb01e64ab6c6433fe5871d8609216dc9a176a78e70f23e782a2"
+        "sha256": "15747dd6aec74f1ea5202fb43ecc81ded2f8f1a7e7471fd26561c863b4ee3ac8"
       },
       {
         "path": "src/bin.ts",
@@ -161,7 +161,7 @@
       },
       {
         "path": "src/cli.ts",
-        "sha256": "7bf10efa88be8a65d835ed7a65a135022339b75078f8596da3135bfc00a59044"
+        "sha256": "d1140c5f8c02f9eaf912a6c75d161de0be2413d9c2eec84446f3129caec6d2b4"
       },
       {
         "path": "src/command-inventory.ts",
@@ -181,9 +181,9 @@
       },
       {
         "path": "src/known-flags.ts",
-        "sha256": "a181018a851bbc4b1a7f3a06962a50db138c451abd0e6cca3e89f5a9d1228fba"
+        "sha256": "31473bd65a04071f13b7a5994db1b0005b85494f8b8abcc4321c8f5927270fe0"
       }
     ]
   },
-  "signature": "YHA8q4XSLQRlxsnF6+57nf1hkwwfckNrrV73TEs+XQjU6TdSIAEPa9YWx3prd44hACdXgo748KjJlwieg+xDBw=="
+  "signature": "eCd/+2pUENEEaUOCGFqCLA0FRD18kvDSmNY4YNaJTSmFeT+QI+UO54LdRm7FlUvzAvUkigu+hZDx0pfdC2h1AQ=="
 }

package/README.md

@@ -1321,6 +1321,40 @@ dz mutation-gate --json               # machine contract {baseline, results, sum
 npm run test:mutation                 # the package's own alias for the full run
 ```
 
+**Scope the gate to what a FEATURE actually touched — `--touched` / `--added-since`.** A whole-registry
+sweep does not fit a per-feature Step 8: on this repo's core package it is 358 entries, 30-40 minutes,
+and hit the timeout wall INCONCLUSIVE every time (MEASURED 2026-09-12) — yet a feature usually owns only
+the files it edited and the entries it just added. `--touched <path[,path]>` selects entries whose `file`
+matches one of the given paths — accepted in package-relative POSIX form (the plain case), with a leading
+`./`, as an ABSOLUTE path inside the package, as a REPO-relative path (package prefix stripped, so a
+Step-7 change list in repo-relative form works unmodified), or backslash-separated (a Windows-authored
+change list handed to a POSIX runner); all forms normalize to package-relative POSIX before matching
+(fix-round 1, AM-1). A path that resolves OUTSIDE the package is not silently dropped — it is counted
+and reported as `<K> outside package` in the `selected N of M` line. `--added-since <git-ref>` selects
+entries whose `id` is NOT present in the registry as `git show <ref>:<registry path>` read it: a registry
+genuinely ABSENT at that ref means every current entry counts as added, and the run says so explicitly
+(`base registry absent at <ref> — all M entries count as added`); an unresolvable ref, any OTHER git
+failure, or a base registry that is present but INVALID/malformed at that ref is a usage error (exit 2),
+never folded into "absent" (fix-round 1, AM-3 — collapsing all three used to hide real failures behind a
+silently-too-generous selection). The two selectors UNION with each other and INTERSECT with `--only`
+when both are given — same set algebra as any filter chain — and the run prints exactly how it selected.
+`--json` always carries a `selection` object (`{selected, total, touched, addedSince, base,
+outsidePackage}`) on every scoped run, not only the empty-selection case (fix-round 1, AM-4):
+
+```bash
+dz mutation-gate --touched src/cli.ts,src/mutation-gate.ts             # only entries on these two files
+dz mutation-gate --added-since HEAD                                    # only entries this run just added
+dz mutation-gate --touched src/cli.ts --added-since HEAD --only gate-touched-selector
+# → mutation-gate: selected 1 of 81 entries (touched: 1; added-since HEAD: 1)
+```
+
+An empty match is SAID, never silent, and exits 0 without spending a scratch-copy run:
+`mutation-gate: 0 entries match touched: 0 — nothing to run`. **Recommended for Step 8 of `/feature-adr`**:
+scope to `--touched <this run's file list> --added-since <base ref>` for the per-feature gate; run the
+gate WITHOUT selectors as a separate, periodic regular task (not per feature) to keep the whole registry
+honest — the scoped run proves the feature's own protections, the full sweep proves the registry hasn't
+drifted anywhere else.
+
 Expected output (abridged from a real run — MEASURED 2026-08-07, reproducer: `cd
 packages/@dzhechkov/health-advisor && dz mutation-gate`, 18 entries over a 484-test `node --test`
 suite; wall-clock 9m32s with the default per-entry re-baseline, 4m53s with `--rebaseline final` —
@@ -1358,6 +1392,36 @@ Four rules the gate itself obeys — these are what distinguish it from a green-
 4. **The gate carries its own discrimination proof**: a fixture package with a deliberately
    undefended property lives in this repo's test suite, and the gate MUST fail on it — a gate that
    cannot fail cannot pass.
+5. **A suite timeout is a VERDICT, never a fabricated exit code** (mutation-gate-timeout-verdict,
+   2026-09-14). node's `spawnSync` sets `error.code === 'ETIMEDOUT'` on a real timeout regardless of
+   whether the killed process manages to report its own numeric exit status first — MEASURED: a
+   script that traps the kill signal and calls `process.exit(1)` makes `spawnSync` report
+   `status: 1` AND `error.code: 'ETIMEDOUT'` at once. Before this fix, that numeric status silently
+   outranked the timeout flag and the gate printed `baseline suite RED (exit 1)` for a suite that
+   never actually ran to completion — indistinguishable from a real red suite. Now every ETIMEDOUT
+   is reported `INCONCLUSIVE`, naming the elapsed time, the killed child's own exit/signal, and a
+   `--timeout` suggestion (`ceil(2× elapsed)`).
+   The suite-run ceiling itself resolves **`--timeout` flag > the registry's own `timeoutMs` field >
+   the 300000ms default**, printed in the header as `mutation-gate: timeout: <ms> ms (<source>)`. A
+   package whose real baseline run is longer than the default (this repo's `harness-core`, whose
+   `test/mutation-registry.json` declares `"timeoutMs": 900000` — MEASURED ≈5–8 min baseline) needs
+   no `--timeout` flag at all: a bare `dz mutation-gate` in that package now succeeds where it used
+   to need a manually-remembered flag.
+6. **A suite runs at vitest's DEFAULT worker count (= cpu cores) unless capped, and an uncapped full
+   suite can take the machine down** (mutation-gate-baseline-honesty, 2026-09-15). MEASURED: under
+   this repo's `harness-core` embedding-daemon tests (0.7–3.5 GB/process), an 8-core/16GB box hit
+   load 62–358 and 0.4–1.8 GB free — three full overnight gate runs died. The same suite at
+   `--maxWorkers=2` passed 6909/6909. The worker ceiling resolves **`--max-workers` flag > the
+   registry's own `maxWorkers` field > `min(4, max(1, floor(cpus/2)))`**, is injected as
+   `--maxWorkers=<n>` into a `vitest run` testCommand (unless the command already names the flag —
+   never double-injected) and sets `VITEST_MAX_WORKERS=<n>` in the env unconditionally (a vitest
+   command reached indirectly through a wrapper script is still capped). Printed as
+   `mutation-gate: workers: <n> (<flag|registry|default>)`, or
+   `mutation-gate: workers: n/a — test command is not vitest` for a non-vitest command. Also
+   fixed the same session: vitest 3 prints an optional POOL LABEL between `FAIL` and the file path
+   (`FAIL  |serial| test/x.test.ts …`) — the baseline-attribution parser used to capture the label
+   itself as "the file" and report a perfectly parseable red run as `unparseable from runner
+   output`; the regex now skips the optional label.
 
 **Where the full output of a RED baseline/rebaseline line lives** (gate-stability, 2026-09-12,
 fix-round-1 2026-09-12): the bounded 3-line/20-line tail in the verdict is a teaser, and under a
@@ -1455,7 +1519,25 @@ is not a false gate; `--audit-dev` widens; an audit that *cannot run* also block
 `STALE_DIST`, never checked as-is; a package that declares a `build` script but has **no** dist JS is
 `MISSING_DIST` — an unbuilt package cannot ship), (4) smoke-boot every bin via `node <bin> --help` in a
 throwaway cwd with a timeout. Packages without a `test` script are **named skips** in the report — never
-silent passes; a template-only pack (no build, no artifacts, no bin) is a named `SKIP_NO_ARTIFACTS`.
+silent passes; a template-only pack (no build, no artifacts, no bin) is a named `SKIP_NO_ARTIFACTS`. The
+packed-install smoke's `pack` steps run against a **staged** `package.json` — `workspace:*` sibling
+deps rewritten to the exact sibling version, `scripts.prepublishOnly` dropped, written and restored
+atomically (temp file + rename), one package at a time — the same staging `dz publish`'s preview
+applies, so `npm install` on the resulting tarballs does not fail on a literal `workspace:*` spec. A
+restore that fails is reported as a FAILED step (the tree is left staged and says so), never as a pass.
+A red `tests`/`syntax`/`smoke` step names the failing test(s) when the output is a runner shape it
+recognises (vitest summary/FAIL/×/❯ lines, or node:test/TAP `not ok N …` + `# fail N`) — colour
+codes are stripped first, so a coloured runner is recognised too; otherwise it falls back to the
+first output line, marked `(no test-runner summary recognised)` so the difference from a parsed
+summary is visible. Beneath the reason it prints the tail **per stream**, labelled `stdout:` /
+`stderr:` — the two streams are captured independently, so their relative order (as the process
+actually interleaved them) is **not** reconstructed, only each stream's own tail order. Both
+streams appear the same way in the report, the `--json` output (a `tails: {stdout, stderr}` object
+on every executed tests/syntax/smoke/timeout failure — present with empty strings when a stream
+produced nothing), and the best-effort `gh issue`, where every tail is additionally **redacted**
+(`token`/`secret`/`password` values, `Bearer …`, `npm_…`/`ghp_…`/`sk-…`/`AKIA…` tokens, and long
+opaque base64/hex-ish blobs all become `[redacted]`) and the whole issue body is capped at 60KB,
+shrinking every tail evenly rather than dropping some whole while leaving others untouched.
 
 ```bash
 dz release --dry-run              # full gate plan, zero commands executed
@@ -2174,7 +2256,7 @@ probe that both selects the workspace build or PATH fallback and prints the sele
 dz runs               [--settle] [--stall-minutes N] [--json] [--project <dir>]   (read the run registry: live / stalled / orphaned / inconclusive / finished)
 dz runs-record        --event started|heartbeat|finished [--run-id <id>] [--kind <kind>] [--slug <slug>] [--pid <pid|host>] [--parent-run-id <id>] [--outcome <text>] [--project <dir>] [--json]   (append one run event)
 dz runs-clean         [--apply] [--retention-days N] [--project <dir>] [--json]   (plan cleanup of old clean merged worktrees and dead/finished registry histories; apply explicitly)
-dz mutation-gate [--package <dir>] [--registry <file>] [--test-cmd "<cmd>"] [--only <id[,id]>] [--timeout <ms>] [--rebaseline per-entry|final] [--keep-scratch] [--json]   # the mutation gate: for each NAMED protection in a declarative registry, copy the package to a scratch dir (shadow-repo layout, node_modules symlinked, git-initialized), verify the baseline is green, apply the entry's exact {find, replace} mutation, run the suite, REQUIRE red, restore — and require the red to be ATTRIBUTABLE to the protection: a mutated file that no longer parses is MUTATION_UNPARSEABLE, a failing count far above the entry's bound (maxFailing, default from observed) is OVER_FAILING, and a restored tree that does not reproduce green makes the entry INCONCLUSIVE (flaky suite). A mutation that does not apply, a green suite, or an inconclusive run is a FAILURE — never a skip. exit 0 all proven / 1 gate failed / 2 setup error
+dz mutation-gate [--package <dir>] [--registry <file>] [--test-cmd "<cmd>"] [--only <id[,id]>] [--touched <path[,path]>] [--added-since <git-ref>] [--timeout <ms>] [--max-workers <n>] [--rebaseline per-entry|final] [--keep-scratch] [--json]   # the mutation gate: for each NAMED protection in a declarative registry, copy the package to a scratch dir (shadow-repo layout, node_modules symlinked, git-initialized), verify the baseline is green, apply the entry's exact {find, replace} mutation, run the suite, REQUIRE red, restore — and require the red to be ATTRIBUTABLE to the protection: a mutated file that no longer parses is MUTATION_UNPARSEABLE, a failing count far above the entry's bound (maxFailing, default from observed) is OVER_FAILING, and a restored tree that does not reproduce green makes the entry INCONCLUSIVE (flaky suite). A mutation that does not apply, a green suite, or an inconclusive run is a FAILURE — never a skip. `--touched <path[,path]>` / `--added-since <ref>` scope the run to a feature's own touched files and newly added entries (they UNION with each other and INTERSECT with `--only`; an empty selection prints `selected 0 of M entries (…)` and exits 0 without running the suite — never a silent skip) — MEASURED: an unscoped sweep of 358 entries on this repo's core package took 30-40 minutes and hit the timeout wall every time. `--timeout` resolves flag > the registry's own `timeoutMs` field > a 300000ms default (printed in the header); a real ETIMEDOUT is always INCONCLUSIVE, never read as the killed child's own numeric exit code. `--max-workers` resolves flag > the registry's own `maxWorkers` field > `min(4, max(1, floor(cpus/2)))`, injects `--maxWorkers=<n>` into a `vitest run` testCommand (unless it already names the flag) and always sets `VITEST_MAX_WORKERS=<n>` in the env — printed as `mutation-gate: workers: <n> (<flag|registry|default>)`, or `n/a — test command is not vitest` when the command isn't recognised as vitest; MEASURED: an uncapped full-suite baseline (vitest's default worker count = cpu cores) hit load 62-358 and <2GB free on an 8-core/16GB box under this repo's core-package embedding-daemon tests, killing full overnight gate runs — `--maxWorkers=2` passed 6909/6909. exit 0 all proven / 1 gate failed / 2 setup error
 dz delivery-check --slug <slug> [--context-only] [--findings <f.json>] [--strict] [--author <model>] [--json]   # portable Step-10 Delivery Gate: the `manual` form that travels to every shell target — prints the 4-plane review brief (regressions ‖ security ‖ code-quality ‖ product-honesty) + artifact probes; --findings classifies a fed-back review into a fail-closed ready|blocked hand-off (only cross-validated BLOCKER/HIGH count) and writes features/<slug>/10_delivery_review.md; --strict exits 1 on blocked
 dz skills-verify     [--dir <project>] [--expect a,b] [--static] [--strict] [--timeout <s>] [--json]   # does .claude/skills/ actually REGISTER? --static = instant layout scan (CI-safe, no session): flags dirs that can never register; default also starts a real session and reads the authoritative system/init listing. exit 0 pass / 1 fail / 2 inconclusive — an unobservable registration is NEVER a pass
 dz compounding       [--project <dir>] [--json]   # honest learning-loop payoff report: pool/replay/guard instrumentation plus the monthly eligible→attempted→accepted→executions funnel. A missing source is NOT MEASURED; only a non-empty→empty named edge across three consecutive measured months is a funnel finding; text/JSON carry the same facts and no learning-health verdict
@@ -3234,16 +3316,33 @@ earlier one failed):
 
 1. **Sibling drift.** For every workspace `S` a batch package depends on (`dependencies`,
    `peerDependencies` AND `optionalDependencies` — all three pin and ship identically) that is NOT
-   itself part of the batch, the gate hashes `S`'s published inventory — `dist/**`, every path
-   named in `package.json#files`, and every `bin` target (not `dist/**` alone: a changed bin script
-   or template outside `dist/` is drift too) — plus a normalized `package.json` (version/gitHead/
-   `_*`/`imports`/`browser`/`sideEffects`/`man` compared, not just entry points) against the
-   workspace copy. A mismatch blocks; anything this gate cannot build — a fetch that fails
-   (offline, 404), an unreadable/invalid `package.json` on either side, or a `workspace:`-spec'd
-   name it does not recognize — is `unavailable` and blocks too; `unavailable` is never silently
-   treated as a pass. `--include-drifted` auto-extends the batch and RE-CHECKS the expanded batch's
-   own new edges until nothing new drifts (a fixed point over transitive drift, capped at the
-   package count) — a folded-in sibling that itself depends on a drifted sibling is not missed.
+   itself part of the batch, the gate compares `S`'s WORKSPACE copy against its published inventory,
+   naming which mechanism produced BOTH sides on every result (`inventorySource: 'pnpm-pack' |
+   'npm-pack' | 'readdir-approximation'`, never left implicit). In production the CLI packs `S`'s
+   workspace dir with `pnpm pack` — the SAME transport the live publish uses — into a per-run scratch
+   dir, unpacks it, and hands the unpacked tree to core, which hashes it with the same full recursive
+   walk it applies to the already-unpacked registry tarball: symmetric by construction, so a file the
+   transport synthesises into the tarball (pnpm copies the workspace-root LICENSE into a package whose
+   own tree has none) is on BOTH sides. MEASURED 2026-09-14 on the hub: with an `npm pack --dry-run
+   --json` path listing instead, two siblings unchanged since publication (harness-presets, scout)
+   read as "LICENSE only in the published copy" — a false drift, because npm's dry-run never lists
+   the file pnpm adds. That npm listing survives only behind a test seam (`publishNpmPackRunner`,
+   parsed by core's pure `parseNpmPackInventory`, source `'npm-pack'`) — the seam path and the
+   production path are NOT the same code, and that is named here rather than implied. Packed ONCE
+   per package directory per `dz publish` RUN (not re-run per dependent package that happens to
+   share the sibling); the scratch dir is removed after the drift loop. With no provider injected
+   (an unusual, degraded mode), both sides fall back to the same `dist`/`files`/`bin` approximation
+   — cruder, but still symmetric by construction. Both
+   inventories are hashed together with a normalized `package.json`
+   (version/gitHead/`_*`/`imports`/`browser`/`sideEffects`/`man` compared, not just entry points). A
+   mismatch blocks; anything this gate cannot build — a fetch that fails (offline, 404), a
+   failed `pnpm pack` (or a shapeless seam listing) on the workspace side, an unreadable/invalid
+   `package.json` on either side, or a `workspace:`-spec'd name it does not recognize — is
+   `unavailable` and blocks too; `unavailable` is never silently treated as a pass, and NEVER goes
+   unlogged (an `unavailable` outcome writes an audit record whether or not `--allow-sibling-drift`
+   was used). `--include-drifted` auto-extends the batch and RE-CHECKS the expanded batch's own new
+   edges until nothing new drifts (a fixed point over transitive drift, capped at the package count)
+   — a folded-in sibling that itself depends on a drifted sibling is not missed.
 2. **Packed-install smoke.** The batch's `.tgz` files are installed TOGETHER into a clean directory
    (siblings outside the batch resolve from the registry — exactly like a fresh user), then every
    declared `bin` — including one whose target file turns out NOT to exist after the install,
@@ -3251,11 +3350,31 @@ earlier one failed):
    n/a — runs `--version` and must exit 0 with non-empty stdout. On a **live** publish this gate
    packs each package's tarball exactly ONCE, right after its own version bump — the SAME bytes are
    then smoke-tested and handed to `npm publish <tgz>`; their sha256 is printed
-   (`tarball <pkg>@<ver> sha256:<hex>`) and written to `.dz/guard-audit.jsonl` alongside every
-   pass/block/override/n-a verdict, so "the smoke tested what shipped" is a checkable claim rather
-   than an architectural one. `dz release --dry-run` plans the same steps inside its `smoke` gate
-   (`smoke:packed-install:*`) and `dz release`'s own execution judges the `--version` step through
-   the identical rule — the two doors apply one rule, for real, not only on paper.
+   (`tarball <pkg>@<ver> sha256:<hex>`). `dz release --dry-run` plans the same steps inside its
+   `smoke` gate (`smoke:packed-install:*`) and `dz release`'s own execution judges the `--version`
+   step through the identical rule — the two doors apply one rule, for real, not only on paper.
+
+Both gates write to the SAME append-only, hash-chained `.dz/guard-audit.jsonl` `dz guard` reads —
+**exactly ONE JSONL record per package per rule per run**, never one record per SIBLING a package
+happens to depend on: every sibling's outcome for a package (same/drift/unavailable, overridden or
+not) is aggregated first, then written once, with a detail that names every sibling and its status
+and a verdict of `block` if any sibling stands blocked, else `warn` if the only issues were resolved
+via `--allow-sibling-drift`, else `pass` (a package with no external sibling to check still gets a
+`pass — no external siblings` record, so the rule is never silently absent for a package). Each
+note/violation names `<rule>: <pkg>@<ver> sha256:<hex> — <detail>`, with `sha256:n/a` stated
+explicitly whenever the verdict is a preview that ran before anything was packed. The write itself is
+durable: `openSync` append → a LOOP of `writeSync` calls until every byte of the record is confirmed
+written (checking the returned length on every call — a short write is resumed, not silently
+accepted) → `fsyncSync(fd)` → `closeSync`. Two FURTHER fsyncs are each REQUIRED, not best-effort, and
+each failure alone is enough to report the whole write as not logged: an `fsyncSync` of `.dz` itself
+when THIS call is the one that created the audit file (so its new directory entry survives a crash),
+and an `fsyncSync` of `.dz`'s PARENT when THIS call is the one that created `.dz` (so `.dz`'s own
+directory entry survives a crash). Every printed verdict line says so: `(logged)` appears only after
+every required fsync actually succeeded, and a failed write — the file's own fsync, either directory
+fsync, or a writer that makes no progress — prints `(audit NOT logged: <reason>)` instead, never a
+false `(logged)`. The signature gate got the matching honesty fix: a `.dz-manifest.json` that PARSES
+but is not a JSON object (`null`, an array, a bare string) is reported `unavailable` — "the manifest is
+malformed", not "the pack carries no signature", because the fix for each is different.
 
 ```bash
 dz publish --filter harness-cli               # ✓ sibling drift: none / ✓ packed install smoke, or BLOCKED with a fix-it command
@@ -3272,7 +3391,7 @@ dz publish: BLOCKED harness-cli — sibling drift: @dzhechkov/memory@0.2.20 on t
 dz publish: refusing to publish (1 sibling-drift violation(s))
 
 $ dz publish --filter harness-cli --yes
-dz publish: tarball @dzhechkov/harness-cli@0.8.24 sha256:9f2c…e10a
+dz publish: tarball @dzhechkov/harness-cli@0.8.26 sha256:9f2c…e10a
 dz publish: ✓ packed install smoke
   ✓ @dzhechkov/harness-cli                1.0.0 → 1.0.1  published (confirmed by registry after 1 probes)
       sha256:9f2c…e10a
@@ -3582,7 +3701,12 @@ Every run also prints where the backend came from, e.g. `memory backend: agentdb
 `dz doctor` cross-checks the two truths too: a new `memory hooks match config` row goes red when
 `.dz/config.json`'s `memory.backend` and the ACTUAL `SessionStart`/`SessionEnd`/`PreCompact` hooks in
 `.claude/settings.json` disagree in either direction, naming the exact fix (`run: dz setup --target
-claude-code --memory agentdb`, or the jsonl equivalent).
+claude-code --memory agentdb`, or the jsonl equivalent). When the two truths agree, the row prints an
+explicit `[OK]` naming the backend and the three events (e.g. `memory.backend=agentdb —
+SessionStart/SessionEnd/PreCompact all invoke .dz/agentdb-writer.mjs`) — it stays silent only when
+there is no `.dz/config.json` at all (never ran `dz setup`); a `.claude/settings.json` that exists
+but cannot be parsed or inspected (invalid JSON, or a malformed `hooks` shape) is reported red as
+"cannot be compared", never as a green receipt.
 
 ### The apply leg — `dz setup --memory agentdb` installs the whole loop, not two of three
 
@@ -3592,7 +3716,7 @@ Self-learning is a three-leg loop: **collect** (session hooks write into the sto
 Before this feature `dz setup` shipped the first two legs only — the apply leg's files existed
 solely in this repo's own `.claude/helpers/`, so every OTHER project that ran `dz setup --memory
 agentdb` got collection and ranking, but never automatic recall (MEASURED: a clean install wrote no
-`UserPromptSubmit` entry at all, on 0.8.10 and 0.8.24 alike, with or without `--memory agentdb`).
+`UserPromptSubmit` entry at all, on 0.8.10 and 0.8.26 alike, with or without `--memory agentdb`).
 
 `dz setup --target claude-code --memory agentdb` now installs all three, additively (a repeat run
 changes nothing; a foreign hook you wrote yourself is left exactly where it is):
@@ -3601,7 +3725,7 @@ changes nothing; a foreign hook you wrote yourself is left exactly where it is):
 |---|---|---|
 | `recall-hook.cjs` | `.claude/helpers/` | `UserPromptSubmit` hook — asks the embed daemon for relevant lessons, injects them as prompt context, silent when nothing clears the relevance floor |
 | `dz-embed-daemon.mjs` | `.claude/helpers/` | Resident embedding daemon behind a unix socket — keeps the ~1.5 s model-load cost off every single prompt |
-| `UserPromptSubmit` entry | `.claude/settings.json` | Runs the recall hook (`node ".../recall-hook.cjs" 2>/dev/null \|\| true` — a broken hook never blocks a prompt) |
+| `UserPromptSubmit` entry | `.claude/settings.json` | Runs the recall hook (`node ".../recall-hook.cjs" \|\| true` — a broken hook never blocks a prompt; stderr is NOT redirected — see "The leg never fails silently" below) |
 | `SessionStart` entry | `.claude/settings.json` | Spawns the embed daemon detached (`sh -c 'nohup node ".../dz-embed-daemon.mjs" ... & exit 0'`) |
 
 The hook resolves your harness-core installation by an ABSOLUTE PATH baked in at `dz setup` time
@@ -3610,6 +3734,38 @@ The hook resolves your harness-core installation by an ABSOLUTE PATH baked in at
 global install elsewhere). Project-local candidates (`node_modules/`, a monorepo checkout) stay as
 fallbacks after it.
 
+**Installed at `$HOME` (a common single-machine layout)? The leg now finds ITSELF, not whatever
+project the current session happens to be in.** Both generated files used to resolve their store
+from `CLAUDE_PROJECT_DIR || cwd()` — the SESSION's project. A user-level install
+(`dz setup --target claude-code --memory agentdb --project $HOME`, expecting the leg everywhere)
+silently looked up a DIFFERENT project's `.dz/` from every other session, and the `UserPromptSubmit`
+command itself broke down to `Cannot find module` (swallowed silently) whenever `project === $HOME`
+and a session's own `CLAUDE_PROJECT_DIR` pointed elsewhere (issue #2, MEASURED on 0.8.26). Fixed: the
+hook and daemon now resolve their own INSTALL location first (`path.resolve(__dirname, '..', '..')`
+for the hook — the precedent already used by the destructive-guard hook), and `dz setup` writes the
+`UserPromptSubmit`/`SessionStart` commands as an ABSOLUTE path to that install root instead of the
+old `${CLAUDE_PROJECT_DIR:-.}`-relative form. A re-`dz setup` over a pre-feature relative entry
+upgrades it in place — never a second entry. The one-line reproducer:
+
+```bash
+# temp $HOME layout, matching the owner's real one
+export HOME=$(mktemp -d) && mkdir -p "$HOME/other-checkout"
+dz setup --target claude-code --memory agentdb --project "$HOME"
+dz teach "install-root beacon lesson" --project "$HOME"
+
+# invoke the RECORDED command from a DIFFERENT checkout, CLAUDE_PROJECT_DIR pointing at it too —
+# the beacon still reaches additionalContext, because the hook found ITS OWN install, not $CLAUDE_PROJECT_DIR
+( cd "$HOME/other-checkout" && CLAUDE_PROJECT_DIR="$HOME/other-checkout" \
+  node "$HOME/.claude/helpers/recall-hook.cjs" <<< '{"prompt":"install-root beacon lesson"}' )
+# → one line of JSON, hookSpecificOutput.additionalContext containing the beacon
+```
+
+One named limit: from a foreign project's session the hook now injects the INSTALL ROOT's lessons,
+not the session project's — that is the requested one-store-per-install behavior, not a bug; a
+per-project store layered on top of a user-level one is a separate feature. The Codex host's own hook
+resolves its root from `payload.cwd`/`PWD`/`cwd()` — the SAME class of weakness — and is not fixed by
+this change; it is named in the harness-core README and the feature's own backlog entry.
+
 **On the jsonl backend** (no `--memory agentdb`) the step reports `skipped` with the reason named —
 the embed daemon needs agentdb's transitive `@huggingface/transformers`/`@xenova/transformers`
 dependency, which jsonl mode never installs. This is an honest boundary, not a missing feature: run
@@ -3677,18 +3833,128 @@ dz teach "acceptance check lesson" --allow-cold-start   # → "↳ mirrored to v
 # 5. The embed daemon comes up (spawned by SessionStart; give it up to ~20s to load the model).
 timeout 20 sh -c 'until [ -S .dz/embed.sock ]; do sleep 1; done' && echo "daemon socket is up"
 
-# 6. The recall hook actually injects context for a relevant prompt, and stays silent for one
-#    that clears no relevance floor — never a hang, never a stray print on stdout.
+# 6. The recall hook actually injects context for a relevant prompt, and STAYS SILENT ON STDOUT for
+#    one that clears no relevance floor — never a hang, never a stray print on stdout. stderr now
+#    NAMES the no-hits case (apply-leg-never-silent, FR-1) instead of staying blank.
 echo '{"prompt":"acceptance check lesson"}'   | node .claude/helpers/recall-hook.cjs   # → one line of JSON, hookSpecificOutput.additionalContext non-empty
-echo '{"prompt":"unrelated weather report"}'  | node .claude/helpers/recall-hook.cjs   # → empty stdout, exit 0
+echo '{"prompt":"unrelated weather report"}'  | node .claude/helpers/recall-hook.cjs   # → empty stdout, exit 0, stderr: [dz-recall] skipped reason=no-hits root=…
 
-# 7. Doctor confirms the leg is alive, not merely installed.
+# 7. Doctor confirms the leg is ALIVE AND ACTUALLY INJECTING, not merely installed.
 dz doctor   # → "apply-leg alive (embed daemon): embed socket present at <path> — recall injection can run"
+            # → "apply-leg injects (live probe): live probe injected its beacon lesson in <N>ms"
 ```
 
 Every step above is a REPRODUCER, not a claim: run it on a scratch project before trusting a `dz
 setup --memory agentdb` install on a new machine.
 
+#### One recall engine for the hook and the CLI (`hook-recall-hybrid-parity`, ADR-001)
+
+Before this feature the per-prompt hook and `dz recall` used TWO DIFFERENT engines: the hook's embed
+daemon ran its own brute-force cosine loop over the mirror; `dz recall` called core's `recallHybrid`
+(FTS5 lexical + semantic + reciprocal-rank-fusion). MEASURED (record 097ca040): 41.8% of taught
+lessons went unretrieved by either path over 48 days, and an exact lexical match with cosine 0.39 was
+silently dropped by the hook's cosine floor — a lexical hit `dz recall` would have surfaced.
+
+The daemon's `op: recall` now calls `recallHybrid` itself — the SAME engine, SAME store, SAME
+ranking `dz recall` uses — under a time budget (`HOOK_RECALL_BUDGET_MS`, default 500 ms, below the
+hook's own 800 ms socket timeout). Every reply now carries an honest `engine` field:
+
+- `engine: 'hybrid'` — `recallHybrid` answered inside the budget; `hits[].score` is an RRF rank
+  normalized into `[0,1]` (`score / (2 / (RRF_K + 1))`, clamped — RRF_K=60 mirrors `vector-tier.ts`'s
+  own constant).
+- `engine: 'cosine-fallback'` — the budget was exceeded, `recallHybrid`'s engine errored, or no core
+  module was resolvable; the daemon falls back to TODAY'S brute-force cosine (unchanged, byte for
+  byte) and reports `reason` alongside (e.g. `"budget exceeded (500 ms)"`).
+
+The hook prints `engine`/`reason` to **stderr only** (`[dz-recall] engine=… reason=…`) — it never
+rides into `additionalContext`, so the model reading the prompt never sees it. The relevance floor
+the hook applies also depends on `engine`: a `cosine-fallback` reply keeps today's cosine-calibrated
+`DEFAULT_RECALL_FLOORS` (`recall-hook-policy.ts`) untouched; a `hybrid` reply is judged against its
+OWN placeholder floor (`DZ_RECALL_HOOK_SCORE_FLOOR`, currently `0.01`, deliberately permissive) —
+calibrating that floor on the real 281-pattern store is tracked as a follow-up measurement, named as
+a `TODO(08, FR-5)` at the constant's definition site.
+
+**Recall-mode `'hook'` never moves the bandit's exposure counters.** The daemon calls
+`recallHybrid(PROJECT, prompt, { limit, mode: 'hook', deferExposures: true })` and never calls the
+returned `commitExposures(...)` — so a per-prompt recall (which would otherwise fire on every single
+turn) never counts as a bandit "exposure" the way an interactive `dz recall` does. `mode: 'hook'`
+itself ranks identically to `'hybrid'` (no weight change); it exists purely so the daemon's intent is
+visible end to end, alongside `deferExposures`, which is the field that actually withholds the write.
+
+**The vector engine is now cached per process** (`getOrOpenEngine`, `vector-tier.ts`, FR-3): a
+long-lived caller like the daemon no longer re-runs the native-dependency probe
+(`isPackageInstalled`/`probeNativeDep`) on every single request — the resolved engine is kept keyed
+by `(projectRoot, mtime of .dz/agentdb.db)` and re-resolved only when that mtime changes (a `dz
+teach`/`consolidate` landed between requests). A short-lived CLI invocation is unaffected — the cache
+just gets populated once and discarded with the process, byte-identical to before this feature.
+
+**`dz doctor`'s "apply-leg alive (embed daemon)" row now names the live engine** (FR-6): when the
+socket is alive it sends one `op: recall` probe (bounded at 1000 ms — comfortably above the 500 ms
+production budget default, see the honest NFR-1 discussion below) and appends `(engine: hybrid)` or
+`(engine: cosine-fallback)` to the detail line. A non-live fixture (no daemon actually listening)
+fails the probe near-instantly and the line is unchanged from before this feature.
+
+**Honest NFR-1 finding (measured, not assumed).** The target was p95 daemon-answer ≤ 500 ms over 100
+real prompts from `.dz/recall-usage.jsonl`. MEASURED on this machine against the REAL 743-pattern
+production store, under the documented DEFAULT `HOOK_RECALL_BUDGET_MS=500` (script + numbers in
+`features/hook-recall-hybrid-parity/07_code_changes/change_manifest.md`): every single reply fell
+back to `engine: 'cosine-fallback'` — `resolveAgentdbEmbedder` (agentdb-index.ts, `EmbeddingService`)
+re-initializes the transformers pipeline on EVERY call with no cross-call caching (MEASURED
+standalone: 2–3.6 s per call, no warm-up across 3 repeated calls in one process), so a cold semantic
+leg routinely costs well over the 500 ms budget — NFR-1 is **not met** by the current architecture on
+this machine. Caching that embedder lives one layer below this feature's touched files
+(`agentdb-index.ts`, out of `hook-recall-hybrid-parity`'s scope) and is named as follow-up work in the
+manifest, not silently left unmeasured.
+
+### The leg never fails silently — `dz doctor`/`dz parity` prove injection, not presence (`apply-leg-never-silent`)
+
+Issue #2's second half, MEASURED: the recall hook exited 0 with NO stderr on every early-return path
+— dead store, dead socket, unresolvable core module, an empty prompt, no relevant lesson — and `dz
+setup`'s own UserPromptSubmit command swallowed even a `Cannot find module` behind
+`2>/dev/null || true`. `dz doctor` printed three green checks (`apply-leg installed`,
+`apply-leg alive`, `memory hooks match config`) and `dz parity` printed
+`✓ Self-learning … via UserPromptSubmit hook (auto recall)` on a project where the leg injected
+nothing in every session but one — both instruments were reading FILE PRESENCE as proof of FUNCTION.
+
+**The hook now names every silent exit, on stderr, before returning:**
+
+```
+[dz-recall] skipped reason=<store-not-found|socket-absent|core-unavailable|empty-prompt|no-hits> root=<path> (<source>) session=<path>
+```
+
+Exit code stays 0 — a broken hook must never fail a prompt. `dz setup`'s UserPromptSubmit command no
+longer redirects that stream (`node ".../recall-hook.cjs" || true` — `2>/dev/null` is gone,
+`|| true` stays). **This is not for Claude Code's own transcript**: MEASURED against the real
+`claude` binary's own hook-reference table (`UserPromptSubmit`'s entry), exit 0 there is documented
+as `stdout shown to Claude` — stderr is named nowhere for that exit code, so a "verbose mode" hope of
+seeing it in-session does not hold. It is for two readers who read a spawned child's stderr directly:
+`dz doctor`/`dz parity`'s own live probe below, and a human running the hook by hand from a terminal.
+
+**`dz doctor` and `dz parity` now measure whether the leg actually injects, not whether its files
+exist.** Both call the SAME `probeApplyLeg(root)`: it spawns the REAL configured hook command (read
+back from `.claude/settings.json`, not reconstructed) from a TEMPORARY cwd with `CLAUDE_PROJECT_DIR`
+pointing at that same temp dir — the shape of a real session — asks it to recall a throwaway beacon
+lesson written into the store just for the call, and is green ONLY when the beacon's own token comes
+back inside `additionalContext`. The beacon is removed immediately after, success or failure —
+proven by a count-before == count-after test, not merely claimed.
+
+```bash
+dz setup --target claude-code --memory agentdb   # installs all three legs
+dz doctor   # → "apply-leg injects (live probe): live probe injected its beacon lesson in 143ms — the recall hook actually finds this project's store"
+dz parity --target claude-code   # → "✓ Self-learning: automatic apply-leg   via UserPromptSubmit hook (auto recall)"
+
+# now kill the daemon and re-check — files are still there, but the leg is silently dead:
+pkill -f dz-embed-daemon.mjs; rm -f .dz/embed.sock
+dz doctor   # → "apply-leg injects (live probe): installed but silent: socket-absent (probed in 4ms)" — RED, with the reason
+dz parity --target claude-code   # → "◐ Self-learning: automatic apply-leg   via manual dz recall before a task — installed but silent: socket-absent"
+```
+
+`dz doctor` and `dz parity` cannot disagree about WHY a leg is dead: both read the same `reason`
+string off the same `probeApplyLeg` result, the same discipline `applyLegReasonMessage` already
+enforces for `stale-version`/`unreadable`. `dz doctor`/`dz parity` pay one probe's worth of wall time
+(measured: well under 200 ms when the leg is dead; ~100-200 ms once warm when it is alive) whenever
+the leg is wired — named here, not hidden.
+
 ### AgentDB self-learning algorithms
 
 When using `--memory agentdb`, the following algorithms automatically tune search quality:
@@ -5124,8 +5390,38 @@ refusal as the honest answer.
 
 ## Status
 
-`harness-core v0.8.32` · `harness-cli v0.8.24` — **this release: `dz publish` refuses a broken pair, `dz setup`
-reads the memory backend from config, and the embed daemon says "ready" only with a socket that exists.**
+`harness-core v0.8.35` · `harness-cli v0.8.26` · `memory v0.2.22` — **this release (night 14→15.09, 8 features, each
+cross-family reviewed by Codex): the recall hook resolves its store from the INSTALL root, never from the session's cwd,
+and is never silent; the skill walker follows symlinks, drops build junk and names everything it skipped; one-character
+recall terms are searchable; and the mutation gate stays honest under load.**
+(a) `apply-leg-install-root` + `apply-leg-never-silent` (issue #2): the `UserPromptSubmit` recall hook computes
+`INSTALL_ROOT` from its own location and `SESSION_ROOT` from `CLAUDE_PROJECT_DIR`, settings commands are absolute and
+POSIX-quoted, a dead leg prints `[dz-recall] skipped reason=… root=…`, and `dz doctor`/`dz parity` report the leg
+green ONLY after a live injection probe (`apply-leg injects (live probe)`).
+(b) `skills-walk-symlinks-and-junk`: `walkFiles` → `{files, skipped}` — a symlink resolves via `stat`, a cycle guard
+tracks the ANCESTOR chain (aliases both walk), a symlink escaping the skill directory is skipped and named, an
+escaping `SKILL.md` refuses the whole skill in EVERY public reader, junk (`__pycache__`, `node_modules`, `.git`,
+`__MACOSX`, `.pytest_cache`, `.mypy_cache`, `*.pyc/*.pyo/*.swp/*.swo`, `.#*`, `.DS_Store`, `Thumbs.db`) is a published
+contract, and `dz install` prints `skills: skipped N junk entr(y|ies)` only when N > 0.
+(c) `recall-short-terms` (memory 0.2.22): ONE shared `tokenize()` for both backends, no length floor, diacritics folded
+for Latin script only (one combining mark — exactly FTS5 `unicode61 remove_diacritics=1`, measured), `hasSearchableTerms`
+/ `noSearchableTermsReason` re-exported through core, and `dz recall ",,"` prints `reason: no-searchable-terms`.
+(d) `mutation-gate-baseline-honesty` + `--touched/--added-since`: the attribution regex reads vitest 3's pool label
+(`FAIL  |serial| path`), `maxWorkers` lives in the registry (hub: 2) and is honoured by `--max-workers`, and a feature
+gates only its own entries. (e) `store-generation-counter`: the daemon's engine cache invalidates on a generation bump
+written under a named lock. (f) `sandbox-copy-remaining-sites` + `full-suite-flake-fixes-2`: measured budgets
+(≥ 2× p95 under load), spawn timeouts strictly below the test budget, `waitForSocketReady` for daemon tests.
+Previous release (v0.8.34 / v0.8.26): the recall hook and `dz recall` share ONE hybrid
+engine, the embedder is cached per process, and every publish-gate verdict is a durable per-package audit record.
+(0) Hook/CLI recall parity (`hook-recall-hybrid-parity`): the embed daemon answers `op: recall` through core's
+`recallHybrid` under a 500 ms budget (measured p95 100–190 ms on the real 743-pattern store, 99–100 of 100
+requests hybrid) with an honest cosine fallback labelled `engine`/`reason`, a warm-up at start, an in-flight cap,
+and an engine cache used ONLY by the hook (`dz recall` itself resolves fresh); `dz doctor` prints the engine.
+The agentdb embedder is cached per process (`agentdb-embedder-cache`: cold 2117 ms → warm 1 ms). Sibling-drift
+inventories come from `pnpm pack` — the live transport — so the LICENSE pnpm synthesises from the workspace root
+no longer reads as drift; every gate verdict is one fsync'd audit record per package with `sha256:<hex|n/a>`.
+Previous release (v0.8.33 / v0.8.26): `dz publish` refuses a broken pair, `dz setup`
+reads the memory backend from config, and the embed daemon says "ready" only with a socket that exists.
 (1) Sibling-drift gate + packed install smoke: before any live `npm publish`, every `workspace:*` sibling on
 the registry is compared with the workspace (dist/files/bin + the shipping fields of package.json); a
 drifted sibling BLOCKS the batch (`add <sibling> to the batch or publish it first`), and each package that

package/dist/cli.d.ts

@@ -32,6 +32,13 @@ export type MutationGateRunner = (command: string, options: {
     readonly timeoutMs: number;
     readonly phase: 'baseline' | 'mutation' | 'rebaseline' | 'final-rebaseline';
     readonly entryId?: string;
+    /**
+     * mutation-gate-baseline-honesty FR-3: the extra env vars the REAL executor would set on top of
+     * `process.env` for this run — currently just `VITEST_MAX_WORKERS`, set unconditionally
+     * regardless of whether the test command is recognised as vitest (a non-vitest command still
+     * gets the env var; only the command-string injection is vitest-gated).
+     */
+    readonly env: Readonly<Record<string, string>>;
 }) => MutationGateRunnerObservation;
 /** Output sink + working directory — injectable so the CLI is testable. */
 export interface CliIo {
@@ -139,6 +146,20 @@ export interface CliIo {
         timeout?: number | undefined;
         env?: NodeJS.ProcessEnv | undefined;
     }) => string;
+    /**
+     * Test seam for `dz publish`'s gate-audit writer (feature `publish-gate-audit-durable`, FR-2):
+     * overrides the fs primitives `appendPublishGateAudit` uses for its durable append (production
+     * leaves it unset → the real `node:fs` functions). Lets a test make `fsyncSync` throw to prove
+     * `(audit NOT logged: …)` is printed and the write is reported as failed, without touching any
+     * other seam's filesystem.
+     */
+    readonly publishGateAuditFsLayer?: PublishGateAuditFsLayer;
+    /**
+     * AM-5 (feature publish-gate-audit-durable): test seam for the sibling-drift gate's `npm pack
+     * --dry-run --json` call (production leaves it unset → real `execFileSync`). Takes the package
+     * dir, returns raw stdout, or throws to simulate a real `npm` failure without spawning anything.
+     */
+    readonly publishNpmPackRunner?: (dir: string) => string;
     /**
      * Test seam for `dz install`: overrides the `npm install` subprocess (production leaves
      * it unset → real `execSync`, stdio piped). A stub runner that pre-stages a fixture
@@ -246,6 +267,29 @@ export declare function codexHooksSummary(report: CodexHooksSyncReport, label?:
 export declare function deliverCodexHooks(input: CodexHooksSyncInput, sync?: (options: Parameters<typeof runSyncCodexHooks>[0]) => CodexHooksSyncReport, label?: string): CodexHooksSummary & {
     readonly report: CodexHooksSyncReport;
 };
+/**
+ * fs primitives `appendPublishGateAudit` needs for its durable write (FR-2), injectable so a test
+ * can make `fsyncSync` throw without touching the real filesystem underneath every OTHER seam this
+ * function shares with production. Left unset in production → the real `node:fs` functions above.
+ */
+interface PublishGateAuditFsLayer {
+    readonly existsSync: (path: string) => boolean;
+    readonly mkdirSync: (path: string, opts: {
+        recursive: boolean;
+    }) => void;
+    readonly openSync: (path: string, flags: number) => number;
+    /**
+     * AM-2 (Codex round-1 review, finding 2, high): `Buffer`, not `string` — a SHORT write must
+     * resume at the exact BYTE it stopped at, and a string-based API cannot express that safely once
+     * the data contains any multi-byte UTF-8 character (re-encoding a slice of an already-partial
+     * string can silently produce different bytes than the ones actually pending). The real
+     * `node:fs.writeSync` accepts a `Buffer` directly (no re-encoding), so this changes nothing about
+     * what production writes.
+     */
+    readonly writeSync: (fd: number, data: Buffer) => number;
+    readonly fsyncSync: (fd: number) => void;
+    readonly closeSync: (fd: number) => void;
+}
 export declare function boundedMutationGateOutputTail(output: string): string | undefined;
 /** Test seam for the chokepoint: NEW-C4's proof needs to call it with a hostile pid. */
 export declare function __wfSignalChildTestSeam(child: unknown, signal: string, detached: boolean): boolean;