@dzhechkov/harness-cli 0.4.5 → 0.5.0

package/README.md

@@ -125,6 +125,140 @@ point any tool at (a skill is just Markdown). Dedicated targets are on the [road
 **❌ No target applies:** `nemoclaw` (NVIDIA agent-safety runtime — not a code editor, no rules file) ·
 `v0` (UI-only, no repo file). *(`pi` is a real coder but reads `AGENTS.md` → covered by `agents-md`.)*
 
+#### `--target` aliases and did-you-mean
+
+`--target claude` used to be rejected outright — the canonical name is `claude-code`, and the error
+just re-printed the list. All **eight** `--target`-taking commands (`init`, `verify`, `install`,
+`compose`, `setup`, `upgrade`, `parity`, `feature-adr-setup`) now resolve the value first.
+
+*(This sentence used to say "every" and name only seven: `dz parity` was missed, and shipped the
+original defect verbatim. It is now checked rather than promised — `test/target-alias-cli.test.ts`
+asserts that no command reads `--target` without reaching the resolver, and that every command whose
+`--help` advertises `--target` appears in the per-command sweep.)*
+
+**Accepted aliases** (a table, so adding one is a data edit):
+
+| You type | You get | Why it is a row |
+|----------|---------|-----------------|
+| `claude` · `cc` | `claude-code` | the tool's everyday name |
+| `agents` | `agents-md` | the everyday name of the `AGENTS.md` target |
+| `gpt` · `openai` | `codex` | the vendor name, not the CLI's |
+
+Case, padding and separators are handled **without** a row: `CLAUDE`, `Claude_Code`, `claudecode`
+and `  claude-code  ` all resolve to `claude-code`; `agentsmd` and `agents.md` resolve to `agents-md`.
+
+**A typo is SUGGESTED, never silently accepted** — installing to the wrong target on a guess is worse
+than one round-trip:
+
+```console
+$ dz init --target clade-code --preset devops > out.txt   # the refusal is on STDERR
+dz init: unknown --target "clade-code" — did you mean "claude-code"?
+  --target must be one of: agents-md, claude-code, codex, copilot, cursor, gemini, hermes, openclaude, opencode, windsurf
+$ echo $?
+1
+$ wc -c out.txt
+0 out.txt        # stdout stays a clean data channel, even on a refusal
+```
+
+**Both lines go to stderr** — the refusal, like the alias note below, is diagnosis, not data. `dz
+parity --target <bad> --json` likewise writes its structured error to stderr and leaves stdout empty,
+so `| jq` is never handed a diagnostic.
+
+An ambiguous prefix gets no guess at all (`--target co` could be `codex` or `copilot`), and neither
+does nonsense (`--target totally-bogus` prints the plain list). When an alias IS accepted, the
+substitution is announced **on stderr**, so piped stdout stays machine-readable:
+
+```console
+$ dz init --target claude --preset devops > installed.txt
+dz init: --target "claude" → claude-code (alias)
+```
+
+**When this matters:** you are following a blog post or a teammate's snippet that says `--target claude`.
+It now works, and you are told what it resolved to.
+
+### `dz list` — one broken skill never hides the rest
+
+`dz list` used to abort on the FIRST unparseable `SKILL.md`: exit 1, an error naming neither the file
+nor a count, and every other skill in the tree invisible. A pack you installed could blank your whole
+listing. Now the loadable skills are listed on **stdout** and the unloadable ones are named on
+**stderr**:
+
+```console
+$ dz list --skills-dir .claude/skills
+105 skill(s) in /home/you/proj/.claude/skills:
+
+  api-design                          Designs REST and GraphQL APIs with OpenAPI specs…
+  …103 more…
+  test-writer                         Writes focused unit and integration tests…
+$ echo $?
+1
+```
+
+…with the diagnosis kept out of the data:
+
+```console
+$ dz list --skills-dir .claude/skills 2>/dev/null   # stdout only — clean, pipeable
+105 skill(s) in …
+
+$ dz list --skills-dir .claude/skills 1>/dev/null   # stderr only — the actionable part
+dz list: 105 listed, 1 skipped in /home/you/proj/.claude/skills
+⚠ 1 skill(s) skipped (unparseable SKILL.md):
+  /home/you/proj/.claude/skills/broken-one/SKILL.md
+    SKILL.md must begin with a "---" frontmatter fence
+    (line 1: "# Broken One")
+```
+
+The full contract:
+
+| valid skills | skipped | stdout | stderr | exit |
+|--------------|---------|--------|--------|------|
+| >0 | 0 | the listing | *empty* | 0 |
+| >0 | >0 | the listing of the valid ones | named summary | 1 |
+| 0 | >0 | *nothing* | named summary (`0 listed, N skipped`) | 1 |
+| 0 | 0 | *nothing* | `dz list: no skills found in <dir>` | 1 |
+
+`dz init`, `dz install` and `dz sync` behave the same way — the good skills are installed, the bad ones
+are named, and the command exits 1.
+
+**Two failure kinds, two headers, two subjects.** A skill that will not PARSE and a skill that will not
+WRITE are different accusations, so `dz init` reports them separately:
+
+```console
+$ dz init --target claude-code --skills-dir ./skills --project ./proj
+dz init --target claude-code: 1 skill(s), 1 file(s) written, 0 skipped
+dz init: 1 installed, 1 failed to write                       # ← stderr
+✗ 1 skill(s) failed to install (compile/write error):
+  alpha
+    EEXIST: file already exists, mkdir './proj/.claude/skills/alpha'
+```
+
+The header names the **target**, not `alpha/SKILL.md` — which is perfectly valid. (It used to print
+`⚠ 1 skill(s) skipped (unparseable SKILL.md)` and quote `line 1: "---"`, a valid frontmatter fence, as
+its evidence: a failure that names the wrong artifact is worse than an anonymous one.)
+
+`dz install` renders the offending path **relative to the package**
+and says so explicitly, because a `node_modules/**` path is not something you can act on:
+
+```console
+$ dz install @someone/skills-pack
+dz install @someone/skills-pack: 12 skill(s), 24 file(s) written, 0 skipped
+dz install: @someone/skills-pack ships 1 unparseable skill(s) —
+⚠ 1 skill(s) skipped (unparseable SKILL.md):
+  skills/broken-one/SKILL.md
+    SKILL.md must begin with a "---" frontmatter fence
+This is a defect in the package, not in your project.
+Workaround: npx -y @someone/skills-pack init
+```
+
+**When this matters:** a package you installed shipped a broken skill — you still see everything else,
+you know exactly which file is at fault, and you know whose defect it is.
+
+> **`dz` requires `@dzhechkov/harness-core >= 0.4.7`.** If you ever see
+> `dz: needs @dzhechkov/harness-core >= 0.4.7, found 0.4.1`, a stale core was reused from a cache:
+> `rm -rf ~/.npm/_npx && npx @dzhechkov/harness-cli@latest --version`. That named message replaced a
+> bare `SyntaxError: … does not provide an export named 'GRADE_SUCCESS_FLOOR'` that used to kill even
+> `dz --version`.
+
 > **"Nothing installs" / "no skills found"?** Update the CLI:
 > `cd /tmp && npm i -g @dzhechkov/harness-cli@latest`. Older global installs couldn't locate their
 > own bundled packs outside the monorepo — now fixed, so `dz registry`/`dz init`/`dz setup` work
@@ -132,7 +266,7 @@ point any tool at (a skill is just Markdown). Dedicated targets are on the [road
 
 ## User Journey — from install to mastery
 
-All 66 commands (MEASURED — reproducer: `grep -c "^      case '" src/cli.ts`, the dispatch cases) mapped to a real workflow:
+All 67 commands (MEASURED — reproducer: `grep -c "^      case '" src/cli.ts`, the dispatch cases) mapped to a real workflow:
 
 ```
 DISCOVER → INSTALL → USE → CREATE → MAINTAIN → SHARE
@@ -1015,7 +1149,7 @@ green: re-sign reminder (`dz sign …` — the publish signature gate is refuse-
 before a multi-package npm release, or whenever a broken dist/bin must be impossible to ship; keep plain
 `dz publish` for routine pushes. `dz publish` itself is byte-identical whether or not release exists.
 
-### Skill Packs (23 packs · 179 skills)
+### Skill Packs (18 packs · 189 skills)
 
 Each pack is an npm package — click through for the **full per-skill documentation** (what each skill does + how to trigger it). Install a whole pack with `dz install <pkg>`, or pick skills with `dz init --select` / a `--preset`.
 
@@ -1027,7 +1161,7 @@ Each pack is an npm package — click through for the **full per-skill documenta
 | [@dzhechkov/skills-qe](https://www.npmjs.com/package/@dzhechkov/skills-qe) | 20 | Quality engineering — test-gen, coverage, chaos, defect intelligence, QCSD swarms |
 | [@dzhechkov/skills-reasoning](https://www.npmjs.com/package/@dzhechkov/skills-reasoning) | 4 | Generic reasoning & code-quality — investigate (root-cause), solid (SOLID/TDD), karpathy-guidelines, agents-md-creator |
 | [@dzhechkov/skills-ecc](https://www.npmjs.com/package/@dzhechkov/skills-ecc) | 20 | Claude-Code engineering craft — agent architecture, autonomous loops, framework patterns |
-| [@dzhechkov/skills-meta](https://www.npmjs.com/package/@dzhechkov/skills-meta) | 18 | Dev-process meta skills — explore, feature-adr, design-thinking, audit, skill-advisor |
+| [@dzhechkov/skills-meta](https://www.npmjs.com/package/@dzhechkov/skills-meta) | 19 | Dev-process meta skills — explore, feature-adr, design-thinking, audit, skill-advisor, loop-plan-author |
 | [@dzhechkov/skills-academic](https://www.npmjs.com/package/@dzhechkov/skills-academic) | 5 | Thesis-defense toolkit — dissertation review, questions, doc-check, defense eval |
 | [@dzhechkov/skills-news](https://www.npmjs.com/package/@dzhechkov/skills-news) | 3 | *dz-original* — news digests (`news-digest`) + delta watches (`news-monitor`) + bundled `goap-research-ed25519` verified-research backend (mandatory) |
 | [@dzhechkov/skills-idea2prd](https://www.npmjs.com/package/@dzhechkov/skills-idea2prd) | 1 | *dz-original* — `idea2prd-manual`: idea/problem → PRD+ADR+DDD+C4+Pseudocode+Tests+Completion (9 checkpoints); bundles the analyst trio as a sources.json-tracked vendor ([ADR-0001](https://github.com/djd1m/dz-harness-hub/blob/main/docs/adr/0001-skill-canonicalization-and-dependency-model.md)) |
@@ -1038,6 +1172,7 @@ Each pack is an npm package — click through for the **full per-skill documenta
 | [@dzhechkov/skills-taste](https://www.npmjs.com/package/@dzhechkov/skills-taste) | 1 | *imported (MIT)* — `design-taste-frontend`: anti-slop landing/portfolio/redesign framework (dials + pre-flight + GSAP skeletons); complements frontend-design (`dz init --select design-taste-frontend`) ([ADR-0002](https://github.com/djd1m/dz-harness-hub/blob/main/docs/adr/0002-product-and-design-expansion.md)) |
 | [@dzhechkov/skills-book-digitizer](https://www.npmjs.com/package/@dzhechkov/skills-book-digitizer) | 8 | *dz-original* — book → installable methodology pack: `digitize-book` (orchestrator) + ingest/extract/distill/pack/kb-index + `book-brain-register` (CP6 promote → cross-project brain) + `source-brain-ingest` (repo sibling). Verified provenance, IP-safe, resumable (`dz init --select digitize-book`) ([ADR-001](https://github.com/djd1m/dz-harness-hub/blob/main/features/book-knowledge-digitizer/03_adr/001-book-to-skillpack-pipeline.md)) |
 | [@dzhechkov/skills-12factor](https://www.npmjs.com/package/@dzhechkov/skills-12factor) | 12 | *generated by the digitizer, CC BY 4.0* — The Twelve-Factor App distilled into 12 decision-moment skills (one per factor). The first PUBLIC digitized-book pack; paraphrased (shingling-gated), routing-gated (every factor carries triggers), attributed (`NOTICE`) (`dz init --select 12factor-config-in-environment,…`) |
+| [@dzhechkov/skills-book-ai-apps](https://www.npmjs.com/package/@dzhechkov/skills-book-ai-apps) | 17 | *generated by the digitizer, CP5-published* — «Building Applications with AI Agents» (Albada, рус. пер.) distilled into 17 decision-moment skills across the whole agent-building arc: agent-fit & model choice, single-vs-multi, orchestration, tool design, knowledge & memory, context engineering, evaluation, probabilistic behaviour checks, release gates, improvement loops, drift, human-in-the-loop, agent UX, governance, security. Ships our page-anchored Knowledge Units, NOT the book text — shingling-gated at 0 uncited verbatim runs >=8 words; publication is the recorded CP5 owner decision; `trust_tier 1` (routing-gated, not human-reviewed) Since 0.2.2 it also ships `brain/ai-apps.sqlite`, the 223-KU knowledge slice: `dz brain add --from-pack @dzhechkov/skills-book-ai-apps` loads it into your `~/.dz/brain`, then `dz brain query --source ai-apps` answers in any project (`dz install @dzhechkov/skills-book-ai-apps --target claude-code`) |
 
 ### Available Presets (14)
 
@@ -1097,7 +1232,7 @@ Get the whole set with `dz init --target claude-code --preset meta`, or pick one
 
 Custom loops used to be born by copy-pasting a 1470-line workflow script; nothing deterministic
 checked the copy. The loop-designer meta-factory replaces that: a versioned typed plan
-(`loop-plan/1`), a schema-driven generator, a 17-rule lint gate, and a local trace plane.
+(`loop-plan/1`), a schema-driven generator, an 18-rule lint gate, and a local trace plane.
 
 ```bash
 # 1. Scaffold a plan (pipeline | barrier | fanout | gate), edit the TODO prompts:
@@ -1116,7 +1251,7 @@ dz workflow render triage-loop.plan.json --o triage-loop.js
 
 # 4. Gate it (generated-loop CI mode; exit 0/1/3 — inconclusive is NEVER a pass):
 dz workflow-lint triage-loop.js --plan triage-loop.plan.json --require-plan
-# → dz workflow-lint: PASS (mode=require-plan; 0 fail, 0 warn, 0 inconclusive over 17 rules)
+# → dz workflow-lint: PASS (mode=require-plan; 0 fail, 0 warn, 0 inconclusive over 18 rules)
 
 # 5. Run it via Workflow({scriptPath:'triage-loop.js', args:{traceDir:'/abs/run-dir'}}), then read
 #    the run's own trace (seq-ordered; wallTime is diagnostic only):
@@ -1207,12 +1342,46 @@ 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)
+# → dz workflow-lint: PASS (mode=require-plan; 0 fail, 1 warn, 0 inconclusive over 18 rules)
 ```
 
 `inconclusive` is never a pass, and the rendered script keeps your hand edits across re-renders
 (USER regions are preserved).
 
+#### Declare each step's tool perimeter — `LoopStep.tools`
+
+**When to use it:** any loop whose steps reach external systems (a ticket tracker, a wiki, a repo
+host) through MCP, and you want the intended perimeter written down, well-formed, and gated rather
+than living in a prompt someone will edit.
+
+```jsonc
+// in your plan.json — one array per DISPATCHING step (agent | gate)
+{"stepId":"discovery","kind":"agent","phase":"Discovery",
+ "tools":["gitlab:read","jira:read","wiki:read"],  "budget":{"maxAgents":1}},
+{"stepId":"verdict-gate","kind":"gate","phase":"Discovery","deps":["discovery"],
+ "tools":[],                                        "budget":{"maxAgents":1}}
+```
+
+`tools: []` is the **meaningful** value for a step that touches no external tool — absence is a lint
+finding, because silence is never permission:
+
+```bash
+dz workflow-lint my-loop.js --plan my-loop.plan.json --require-plan
+# → FAIL  tool-perimeter-declared: dispatching step sa declares no `tools` perimeter — absence
+#         FLAGS: silence is never permission (declare `tools: []` if the step touches no external tool)
+```
+
+A non-empty array is **enacted**, not decorative: it renders a fixed contract line into that step's
+prompt, and the lint rule cross-checks the script against the plan (so a plan edit you forgot to
+re-render fails too). Severity is staged — **WARN by default, FAIL only under `--require-plan`.**
+
+**It is a DECLARATION, not enforcement.** `agent()` exposes no tool restriction; real enforcement
+lives at the MCP server. Do not read this field as a sandbox.
+
+Worked consumer in this repo: `.claude/workflows/cfr-pipeline.js` — a 12-step, 6-gate Customer
+Feature Request pipeline with seven typed terminal exits, whose five source-touching stages each
+declare their perimeter (`features/cfr-pipeline/`).
+
 #### Step 4 — run it (Claude Code), read it back (anywhere)
 
 In **Claude Code**, paste exactly this shape:
@@ -1342,9 +1511,9 @@ only at their documented scopes (plan + step), and `fanouts[].registry` items mu
 ItemKey domain the trace plane enforces — `trace.emit` can never decide whether a valid plan runs.
 Deferred options are on the loop-designer roadmap.
 
-## All Commands (66)
+## All Commands (68)
 
-*(66 MEASURED — reproducer: `grep -c "^      case '" src/cli.ts`, the dispatch cases.)*
+*(67 MEASURED — reproducer: `grep -c "^      case '" src/cli.ts`, the dispatch cases.)*
 
 ```
 dz setup             --target <name> [--preset <name>] [--select id,id,...] [--skills-dir <dir>] [--memory agentdb] [--no-memory] [--no-hooks] [--install-driver] [--force]
@@ -1399,7 +1568,7 @@ dz feature-adr-setup [--plan] [--from-spec <f>] [--apply]   # guided project onb
 dz challenge --plan <plan.md> [--json] [--context-only] [--author <model>]   # adversarial plan-gate (behind the `challenge-panel` skill): assemble a WIDE context pack (plan + vision + testing + map + degradations) + the fixed C1-C8 "break it" brief for a FRESH adversary (≠ plan author); advisory, never blocks
 dz routing [--stage <s>] [--json]   # inspect the learned cost-optimal routing store: what `args.models.<stage>='auto-cost'` believes per (stage, complexity-tier, model) — gated attempts/successes/rate (feeds feature-adr model selection)
 dz bto-optimize --split|--plan|--select|--scope-check|--diff [--json]   # deterministic engine behind /bto-optimize: hold-out split + hard-capped budget + no-regress-on-holdout winner selection (defeats judge-gaming); prose-only, diff-confirmed, never auto-writes
-dz discrimination-check --test <f[,f]> [--base <ref>] [--name <filter>] [--runner <cmd>] [--json]   # §42 test-discrimination gate for feature-adr Step-8: run the ADR's property test in an isolated git worktree at pre-feature base — it MUST go red without the fix; a green is a false green (HIGH finding, advisory, never auto-aborts)
+dz discrimination-check --test <f[,f]> [--base <ref>] [--name <filter>] [--runner <cmd>] [--timeout <ms>] [--json]   # §42 test-discrimination gate for feature-adr Step-8: run the ADR's property test in an isolated git worktree at pre-feature base — it MUST go red without the fix. SEVEN verdicts, each gated on EXECUTION evidence: DISCRIMINATES · DISCRIMINATES_VIA_ERROR · NON_DISCRIMINATING (false green) · TEST_FILE_ABSENT · LOAD_ERROR_AT_BOTH_REVS · FAILS_AT_TIP · CANNOT_ISOLATE (+ typed reason). Advisory, never auto-aborts
 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 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
@@ -1422,10 +1591,12 @@ dz release           [--filter <name>] [--affected] [--audit-dev] [--tag] [--pub
 dz auto-canonicalize --source <github-url> --pack <skills-pack>
 dz sync-upstream     [--package <dir>] [--list] [--all]
 dz drift-check       [--all] [--json] [--project <dir>]   # CI gate: exit 1 on NEW shared-skill drift (baseline: .dz/drift-allowlist.json; --all incl .claude dogfood)
+dz agents-sync       [--check] [--json] [--project <dir>] # sync anchored bearing rules into the root AGENTS.md policy fence; exit 0 sync / 1 drift / 3 inconclusive
+dz hooks-sync        --target codex [--check] [--remove] [--json]  # install + ARM the dz veto/recall hooks in $CODEX_HOME/hooks.json; exit 0 armed+trusted / 1 not armed / 3 inconclusive
 dz sync-canonical    <skill> [--check] [--from <dir>] [--auto] [--project <dir>]   # heal every copy from skills-meta/<skill> or --from; no canonical + --check = compare copies to each other (exit 1 on drift); no canonical + write = refuse unless --auto (LOUD, picks most-complete copy); --check writes nothing
 dz scout             [--topics <list>] [--since <date>] [--deep] [--output <file>] [--diff] [--report]
 dz workflow          init --name <n> [--pattern pipeline|barrier|fanout|gate] [--o <plan.json>] | validate <plan.json> [--json] | render <plan.json> --o <script.js> [--check] [--force] | blobs [--check]   # loop-plan/1 authoring (the ADR-005 templates are retired)
-dz workflow-lint     <script.js> [--plan <plan.json>] [--require-plan|--legacy] [--json]   # 17-rule deterministic gate; exit 0/1/3 — inconclusive is never a pass
+dz workflow-lint     <script.js> [--plan <plan.json>] [--require-plan|--legacy] [--json]   # 18-rule deterministic gate; exit 0/1/3 — inconclusive is never a pass
 dz workflow-trace    <runDir|--slug <s>|--run <id>> [--invariants <plan.json>] [--html <out.html>] [--json]   # timeline + SEQ invariant runner over the loop's own trace.jsonl
 dz workflow-trace export <run> --o <file> [--include-pairs --yes] [--strict]   # one run's telemetry as ONE movable file
 dz workflow-trace import <bundle> --into <root> [--force] [--with-pairs]       # reconstruct that run; fail-closed against clobbering
@@ -1440,6 +1611,44 @@ dz import-ecc       [--local-path <dir>] [--select id,id,...] [--limit N] [--out
 dz help
 ```
 
+## Global: `dz --version` / `-v` / `dz version`
+
+```bash
+dz --version          # 0.4.8
+dz --version --json   # {"name":"dz","version":"0.4.8","node":"v22.22.0","schemas":{"loopPlan":"loop-plan/1"}}
+```
+
+One line, exit 0. Unresolvable ⇒ the literal `unknown` and exit **1** — never a fabricated number,
+and never a zero exit for "I could not tell you".
+
+This is a pre-dispatch GLOBAL FLAG, not a 67th command: the count above is unchanged, and a test
+derives it from the rendered `dz --help` command list so a reformat cannot move it silently.
+
+**Why it exists.** `dz --version` used to print the entire USAGE manual and exit 0 (MEASURED
+2026-08-17 on 0.4.5 — reproducer: `node dist/bin.js --version` before this change). Any wrapper
+guarding a version range — `@dzhechkov/loop-designer-plugin` is the first — would read exit 0 as "it
+answered me" while finding no version to parse, and then call a possibly-stale binary. Recognised
+only as the FIRST argument, so a later positional `-v` still belongs to its subcommand.
+
+## `dz skills-verify` also sees SLASH COMMANDS now
+
+```bash
+# does a plugin's skill AND its five commands actually register?
+dz skills-verify --dir /tmp/probe --plugin-dir packages/@dzhechkov/loop-designer-plugin \
+  --expect loop-designer:loop-plan-author \
+  --expect-commands loop-designer:init,loop-designer:validate,loop-designer:render,loop-designer:lint,loop-designer:trace
+```
+
+- `--plugin-dir <dir>` loads a plugin into the probe session (session-scoped, no marketplace). With
+  no `--expect-commands`, the expectation DEFAULTS to the manifest's own `commands[]`; an unreadable
+  manifest is refused rather than defaulted to an empty (vacuously passing) expectation.
+- `--expect-commands a,b` names the slash commands that must appear in the authoritative listing.
+- An **absent** `slash_commands` key is `inconclusive`, never an empty list — schema drift and "your
+  commands did not load" are different facts and must not be collapsed.
+- `--static` now also PRINTS its advisories. A `.claude-plugin/plugin.json` under `.claude/skills/`
+  previously produced `no layout problems found` and nothing else; the shape most likely to be a
+  silent non-registration was invisible in the mode CI runs. It is reported, and still never fatal.
+
 ### Grounding: three tiers + the token trade-off (`dz brain ground` / `dz brain expand`)
 
 The `dz brain ground` hook fires on **every turn**, so what it injects is a token trade-off. There are
@@ -2011,6 +2220,78 @@ dz sync-upstream --package packages/@dzhechkov/skills-devops  # check one packag
 
 Discovers all skill packs with `sources.json`, fetches SKILL.md from origin repos, reports which skills have upstream changes.
 
+### dz agents-sync — Codex starts with the repository's bearing rules
+
+Use this after changing an anchored policy clause in `CLAUDE.md` or `.claude/rules/*.md`, and run
+the check form in CI. It updates only the `dz:policies` fence in the root `AGENTS.md`; authored
+content and the independent `dz:skills` fence remain untouched.
+
+```console
+$ dz agents-sync
+dz agents-sync: wrote — 9 policy section(s), 8097 bytes (24.71% of 32768)
+
+$ dz agents-sync --check
+dz agents-sync: in sync — 9 policy section(s), 8097 bytes (24.71% of 32768)
+```
+
+Exit codes are **0** for synchronized, **1** for drift and **3** when fixed source evidence is
+missing or unreadable. `--check` never writes. Each section carries a 12-hex hash recomputed from
+its source anchor; this proves synchronization only — not that Codex read or obeyed the rule. The
+separate cold-start acceptance probe establishes runtime visibility.
+
+### dz hooks-sync — Codex runs the same veto and recall hooks Claude Code does
+
+**When to use it.** Once per machine, after `npm i -g @dzhechkov/harness-cli`, if you drive Codex as
+well as Claude Code. It installs two hooks into the **user-global** `$CODEX_HOME/hooks.json`
+(default `~/.codex/hooks.json`) and **arms** them — Codex hooks are trust-gated, and an untrusted
+entry is silently never run. Re-run it after a dz upgrade; it is byte-idempotent, so an unchanged
+install rewrites nothing and the hook keeps its trust.
+
+```console
+$ dz hooks-sync --target codex
+dz hooks-sync: codex hooks installed and ARMED (trust: trusted) — ready
+
+$ dz hooks-sync --target codex --check
+dz hooks-sync: codex hooks installed and ARMED (trust: trusted) — ready
+
+$ dz hooks-sync --target codex --remove
+dz hooks-sync: removed 2 managed entr(ies) from /root/.codex/hooks.json
+```
+
+Exit codes are **0** for armed **and** trusted, **1** for not-armed / drift / a refusal, and **3**
+when the answer is inconclusive (including "no `codex` binary on PATH", where dz writes **nothing**).
+`--check` writes nothing and is **silent** in a home that never opted in.
+
+**What the two hooks do.**
+
+| Hook | Event | Behaviour |
+|---|---|---|
+| `dz-codex-veto.cjs` | `PreToolUse` | judges the shell command against one rule, `ssh-explicit-auth-weakening` |
+| `dz-codex-recall.cjs` | `UserPromptSubmit` | injects matching learned lessons and records the use with `runtime: "codex"` |
+
+**The veto WARNS by default and never blocks.** A hit prints `DZ-VETO-WARN:` and exits 0. Enforcement
+is opt-in **per project**:
+
+```console
+$ cat .dz/config.json
+{"hooks": {"shellVeto": "block"}}     # off | warn (default) | block
+```
+
+Only then does a hit exit 2 and stop the command. The rule fires only on tokens by which the command
+*explicitly* asks for weaker ssh authentication — `sshpass`, `-o PasswordAuthentication=yes`,
+`-o PubkeyAuthentication=no`, `-o PreferredAuthentications=…password…`. A bare `ssh myhost` whose
+identity comes from `~/.ssh/config` or `ssh-agent` is **allowed**: this guard is user-global, so a
+rule that blocks the normal secure case is not a guard, it is an outage.
+
+**Radius.** Both helpers are INERT outside an opted-in dz project — the activation marker is a `.dz`
+directory, not `.git`. In a plain git checkout they take no decision, print nothing, and create
+nothing.
+
+**Removal is conservative.** `--remove` deletes only entries whose command hash is recorded in dz's
+own manifest. An entry that merely *looks* like dz's is kept and reported — dz never deletes what it
+cannot prove it wrote. Foreign entries are preserved byte-for-byte by every operation, and a
+`hooks.json.bak-<ISO>` copy (newest 3 kept) is taken before each modifying write.
+
 ### dz drift-check / dz sync-canonical — intra-monorepo skill-drift guard
 
 **What.** The same skill is physically duplicated across many packages (`packages/@dzhechkov/*/​<skill>/` + `.claude/skills/<skill>/`). These two commands make that duplication safe:
@@ -2684,23 +2965,56 @@ feature-adr Step-8 asserts the ADR's load-bearing safety property **has** a test
 false green — it may never exercise the property, so it would stay green even if the property regressed. The
 `§42` gate (learned from rUv's `cve-bench/evaluate.mjs`) proves the test **discriminates**: it runs the property
 test in a throwaway git worktree at the pre-feature base (no fix) and requires it to go **red**.
+
+**Use it when** you are about to accept "the property has a test" as evidence — in Step-8 QE, in a review of
+someone else's fix, or before trusting a regression test you did not write. Run it against `HEAD` while your
+change is still uncommitted; that is what makes `HEAD` the pre-feature base.
+
 ```bash
 # the Step-7 feature diff is uncommitted mid-pipeline, so HEAD is the pre-feature base
 dz discrimination-check --test packages/x/test/auth-property.test.ts --base HEAD --json
+
+# human output, a longer suite, and a runner that is not vitest
+dz discrimination-check --test packages/x/test/auth-property.test.ts \
+  --base HEAD --runner "node --test" --timeout 600000
 ```
 ```
 discrimination-check @ HEAD — verdict: NON_DISCRIMINATING
   ✗ packages/x/test/auth-property.test.ts: NON_DISCRIMINATING
+  measurementValid: true · primaryAction: strengthen-test
 
   [high] non-discriminating property test (false green)
-  1 property test(s) PASS at pre-feature base — they do not exercise the ADR safety property … (Advisory — the pipeline continues; the owner decides.)
+  1 property test(s) PASS at pre-feature base WITH execution evidence — they do not exercise the ADR safety
+  property and would stay green if the fix regressed … Action: strengthen-test. (Advisory — the pipeline
+  continues; the owner decides.)
 ```
-Verdicts: `DISCRIMINATES` (red by assertion — good) · `DISCRIMINATES_VIA_ERROR` (couldn't load at base, e.g. a
-brand-new module — inferred) · `NON_DISCRIMINATING` (green at base — a false green, HIGH finding) ·
-`CANNOT_ISOLATE` (no runnable property test — folds into "property untested"). It **never auto-aborts** (dz's
-rule: a false gate kills trust) — exit 0 on any verdict, exit 2 only on a usage/setup error. The worktree +
-sanitation live in tested CLI code; base ref, paths, name filter, and runner are all injection-checked, and the
-worktree is always removed. Step-8 runs this on the ADR Confirmation's `Required automated check` automatically.
+
+**Every verdict is gated on EXECUTION evidence.** The gate reads the runner's own output shape (vitest /
+node --test) and requires it to demonstrate that the *named* test actually ran. An outcome nobody can prove
+degrades loudly instead of minting trust — MEASURED before this change, `--runner false` (a command that
+executes nothing and prints nothing) returned `DISCRIMINATES`; it now returns `CANNOT_ISOLATE` with
+reason `unrecognised-runner-output`.
+
+| Verdict | Means | ✓/✗ | Action |
+|---|---|---|---|
+| `DISCRIMINATES` | assertion-red at base, execution-evidenced | ✓ | none |
+| `DISCRIMINATES_VIA_ERROR` | evidenced load error at base **and** an evidenced pass at TIP | ✓ | none (inference — note it) |
+| `NON_DISCRIMINATING` | evidenced pass at base — a proven false green | ✗ | `strengthen-test` |
+| `TEST_FILE_ABSENT` | the named check is not a regular file (stat+isFile, before any worktree) | ✗ | `create-missing-test` |
+| `LOAD_ERROR_AT_BOTH_REVS` | could not execute at EITHER rev — zero signal | ✗ | `fix-runner-invocation` |
+| `FAILS_AT_TIP` | the feature's own test is red **with** the feature present | ✗ | `fix-red-feature-test` |
+| `CANNOT_ISOLATE` | no established observation; the row carries a typed `reason` | ✗ | `map-a-test` / `fix-runner-invocation` |
+
+`--json` carries the full reading: `perTest[]` (verdict + `reason`), the per-run `evidence` rows, `findings[]`
+(**one per distinct non-clean verdict** — the scalar `aggregate` can only name the worst), `measurementValid`
+(`true | false | 'partial'` — did the instrument measure at all), `primaryAction`, and `tipTree` (the live
+tree's HEAD + dirty-file count when a tip control ran). The singular `finding` is a **deprecated** alias for
+`findings[0]`; read `findings[]`. `--timeout <ms>` (default 300000) bounds each run — a timed-out run is
+`CANNOT_ISOLATE` reason `timeout`, never a pass.
+
+It **never auto-aborts** (dz's rule: a false gate kills trust) — exit 0 on any verdict, exit 2 only on a
+usage/setup error. Base ref, paths, name filter, and runner are all injection-checked, and the worktree is
+always removed. Step-8 runs this on the ADR Confirmation's `Required automated check` automatically.
 
 ### `dz guard` — when a self-mutating operation should be refused, not regretted
 
@@ -3434,7 +3748,20 @@ npx @dzhechkov/p-replicator init
 
 ## Status
 
-`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).
+`v0.4.8` — staged (not yet published). Also available as [Claude Plugin](#claude-plugin). Part of [DZ Harness Hub](https://github.com/djd1m/dz-harness-hub).
+
+New in 0.4.8 (feature `crossrt-1-agents-md`): `dz agents-sync` ports the fixed registry of bearing
+rules into an early root-`AGENTS.md` fence, `--check` exposes source drift to CI, and both surfaces
+report the measured Codex project-doc byte budget. A live cold-start probe, not file presence,
+remains the runtime acceptance gate.
+
+New in this change (feature `dz-cli-defects`, slice A — three defects confirmed by RUNNING the CLI, then fixed):
+
+- **`dz list` skips and collects** — one unparseable `SKILL.md` no longer hides the rest; the broken files are named on stderr and the exit code stays 1. Same for `dz init` / `dz install` / `dz sync`. [Details](#dz-list--one-broken-skill-never-hides-the-rest)
+- **`--target` aliases + did-you-mean** — `--target claude` (and `cc`, `agents`, `gpt`/`openai`) resolve; typos are suggested, never silently accepted. [Details](#--target-aliases-and-did-you-mean)
+- **A named refusal instead of a `SyntaxError`** — `dz` now requires `@dzhechkov/harness-core >= 0.4.7` (was `^0.4.0`, which npm could legally resolve to a core too old to link) and says so in words, before anything is imported.
+
+Previously: the global `dz --version` / `-v` / `dz version` surface (one parseable line), and `dz skills-verify --plugin-dir` / `--expect-commands` so slash-command registration is gate-visible. Both exist for `@dzhechkov/loop-designer-plugin`, which requires `dz` in `^0.4`, verifies it at run time, and falls back to `npx -y @dzhechkov/harness-cli@^0.4` when the `dz` on PATH is stale, unparseable or missing.
 
 ## Claude Plugin
 

package/dist/bin.d.ts

@@ -1,6 +1,16 @@
 #!/usr/bin/env node
 /**
  * `dz` executable entry point.
+ *
+ * Two phases, and the split is load-bearing (feature dz-cli-defects, D5):
+ *
+ *   phase 1 — ZERO `@dzhechkov/harness-core` imports: probe the installed core version
+ *             and refuse with a NAMED message if it is below `MIN_CORE`;
+ *   phase 2 — `await import('./cli.js')`, which is where the ~100-name static graph is
+ *             linked. A STATIC import here would link that graph before any guard could
+ *             run, which is exactly how a cached lower core produced a bare
+ *             `SyntaxError: … does not provide an export named 'GRADE_SUCCESS_FLOOR'`
+ *             with nothing pointing at the cause.
  */
 export {};
 //# sourceMappingURL=bin.d.ts.map

package/dist/bin.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"bin.d.ts","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA;;GAEG"}
+{"version":3,"file":"bin.d.ts","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA;;;;;;;;;;;;GAYG"}

package/dist/bin.js

@@ -1,17 +1,50 @@
 #!/usr/bin/env node
 /**
  * `dz` executable entry point.
+ *
+ * Two phases, and the split is load-bearing (feature dz-cli-defects, D5):
+ *
+ *   phase 1 — ZERO `@dzhechkov/harness-core` imports: probe the installed core version
+ *             and refuse with a NAMED message if it is below `MIN_CORE`;
+ *   phase 2 — `await import('./cli.js')`, which is where the ~100-name static graph is
+ *             linked. A STATIC import here would link that graph before any guard could
+ *             run, which is exactly how a cached lower core produced a bare
+ *             `SyntaxError: … does not provide an export named 'GRADE_SUCCESS_FLOOR'`
+ *             with nothing pointing at the cause.
  */
-import { runCli } from './cli.js';
-const code = await runCli(process.argv.slice(2));
-// `process.exit()` here TRUNCATED large output on a pipe, silently and at exactly the
-// pipe buffer size. On a pipe (not a TTY, not a file) Node's stdout is ASYNCHRONOUS, so
-// `process.exit` discards whatever has not flushed yet: `dz recall --all --json > file`
-// wrote 122826 bytes while `dz recall --all --json | jq` got exactly 65536 and a parse
-// error. That is data loss in the documented sharing path, and silent — the exit code
-// was 0 and the JSON simply stopped mid-string.
-//
-// So: set the code and let the process end when the event loop drains, which is what
-// flushes stdout. `process.exitCode` preserves the status without the race.
-process.exitCode = code;
+import { checkCoreCompat, describeMissingExportError, resolveInstalledCoreVersion, MIN_CORE } from './core-compat.js';
+const foundCore = resolveInstalledCoreVersion(import.meta.url);
+const compat = checkCoreCompat({ found: foundCore, min: MIN_CORE });
+if (!compat.ok) {
+    // stderr, and no stack: the user needs one actionable line, not a trace.
+    console.error(compat.message);
+    process.exitCode = 1;
+}
+else {
+    let code;
+    try {
+        const { runCli } = await import('./cli.js');
+        code = await runCli(process.argv.slice(2));
+    }
+    catch (error) {
+        // The version probe fails OPEN, so a missing-binding link error can still reach us.
+        // Translate exactly that class into the named form; re-throw everything else
+        // unchanged so real bugs still surface.
+        const named = describeMissingExportError(error, foundCore);
+        if (named === null)
+            throw error;
+        console.error(named);
+        code = 1;
+    }
+    // `process.exit()` here TRUNCATED large output on a pipe, silently and at exactly the
+    // pipe buffer size. On a pipe (not a TTY, not a file) Node's stdout is ASYNCHRONOUS, so
+    // `process.exit` discards whatever has not flushed yet: `dz recall --all --json > file`
+    // wrote 122826 bytes while `dz recall --all --json | jq` got exactly 65536 and a parse
+    // error. That is data loss in the documented sharing path, and silent — the exit code
+    // was 0 and the JSON simply stopped mid-string.
+    //
+    // So: set the code and let the process end when the event loop drains, which is what
+    // flushes stdout. `process.exitCode` preserves the status without the race.
+    process.exitCode = code;
+}
 //# sourceMappingURL=bin.js.map

package/dist/bin.js.map

@@ -1 +1 @@
-{"version":3,"file":"bin.js","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA;;GAEG;AAEH,OAAO,EAAE,MAAM,EAAE,MAAM,UAAU,CAAC;AAElC,MAAM,IAAI,GAAG,MAAM,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;AAEjD,sFAAsF;AACtF,wFAAwF;AACxF,wFAAwF;AACxF,uFAAuF;AACvF,sFAAsF;AACtF,gDAAgD;AAChD,EAAE;AACF,qFAAqF;AACrF,4EAA4E;AAC5E,OAAO,CAAC,QAAQ,GAAG,IAAI,CAAC"}
+{"version":3,"file":"bin.js","sourceRoot":"","sources":["../src/bin.ts"],"names":[],"mappings":";AACA;;;;;;;;;;;;GAYG;AAEH,OAAO,EAAE,eAAe,EAAE,0BAA0B,EAAE,2BAA2B,EAAE,QAAQ,EAAE,MAAM,kBAAkB,CAAC;AAEtH,MAAM,SAAS,GAAG,2BAA2B,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;AAC/D,MAAM,MAAM,GAAG,eAAe,CAAC,EAAE,KAAK,EAAE,SAAS,EAAE,GAAG,EAAE,QAAQ,EAAE,CAAC,CAAC;AAEpE,IAAI,CAAC,MAAM,CAAC,EAAE,EAAE,CAAC;IACf,yEAAyE;IACzE,OAAO,CAAC,KAAK,CAAC,MAAM,CAAC,OAAO,CAAC,CAAC;IAC9B,OAAO,CAAC,QAAQ,GAAG,CAAC,CAAC;AACvB,CAAC;KAAM,CAAC;IACN,IAAI,IAAY,CAAC;IACjB,IAAI,CAAC;QACH,MAAM,EAAE,MAAM,EAAE,GAAG,MAAM,MAAM,CAAC,UAAU,CAAC,CAAC;QAC5C,IAAI,GAAG,MAAM,MAAM,CAAC,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,CAAC;IAC7C,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,oFAAoF;QACpF,6EAA6E;QAC7E,wCAAwC;QACxC,MAAM,KAAK,GAAG,0BAA0B,CAAC,KAAK,EAAE,SAAS,CAAC,CAAC;QAC3D,IAAI,KAAK,KAAK,IAAI;YAAE,MAAM,KAAK,CAAC;QAChC,OAAO,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC;QACrB,IAAI,GAAG,CAAC,CAAC;IACX,CAAC;IAED,sFAAsF;IACtF,wFAAwF;IACxF,wFAAwF;IACxF,uFAAuF;IACvF,sFAAsF;IACtF,gDAAgD;IAChD,EAAE;IACF,qFAAqF;IACrF,4EAA4E;IAC5E,OAAO,CAAC,QAAQ,GAAG,IAAI,CAAC;AAC1B,CAAC"}

package/dist/cli.d.ts

@@ -7,6 +7,18 @@
 export interface CliIo {
     readonly cwd?: string;
     readonly write?: (line: string) => void;
+    /**
+     * Diagnostics sink — **stderr**, defaulting to `console.error`.
+     *
+     * Before feature dz-cli-defects `CliIo` had no stderr seam at all, so every
+     * diagnostic (including the top-level error handler) landed on stdout and
+     * `dz list > skills.txt` wrote the error INTO the data file. `write` stays "data
+     * only"; `writeErr` is "diagnosis only".
+     *
+     * There is deliberately **no** fall-back to `write`: a test that wants to assert on
+     * stderr must inject `writeErr`, or the assertion would be theatre.
+     */
+    readonly writeErr?: (line: string) => void;
     /**
      * Pre-read STDIN content (injectable so `dz brain ground`'s hook path is testable without
      * an actual pipe). When omitted, the CLI reads fd 0 synchronously — but only for the one

package/dist/cli.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAocH,2EAA2E;AAC3E,MAAM,WAAW,KAAK;IACpB,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,KAAK,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IACxC;;;;OAIG;IACH,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;IACxB;;;;;OAKG;IACH,QAAQ,CAAC,aAAa,CAAC,EAAE,iBAAiB,CAAC;IAC3C;;;;;OAKG;IACH,QAAQ,CAAC,aAAa,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,KAAK,IAAI,CAAC;CACjE;AAED,yFAAyF;AACzF,MAAM,MAAM,iBAAiB,GAAG,CAC9B,GAAG,EAAE,MAAM,EACX,IAAI,EAAE;IAAE,QAAQ,CAAC,GAAG,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAA;CAAE,KACvD;IAAE,QAAQ,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE,OAAO,CAAA;CAAE,CAAC;AA0lR9E,wBAAsB,MAAM,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,GAAE,KAAU,GAAG,OAAO,CAAC,MAAM,CAAC,CAoK5E"}
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAsdH,2EAA2E;AAC3E,MAAM,WAAW,KAAK;IACpB,QAAQ,CAAC,GAAG,CAAC,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,KAAK,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IACxC;;;;;;;;;;OAUG;IACH,QAAQ,CAAC,QAAQ,CAAC,EAAE,CAAC,IAAI,EAAE,MAAM,KAAK,IAAI,CAAC;IAC3C;;;;OAIG;IACH,QAAQ,CAAC,KAAK,CAAC,EAAE,MAAM,CAAC;IACxB;;;;;OAKG;IACH,QAAQ,CAAC,aAAa,CAAC,EAAE,iBAAiB,CAAC;IAC3C;;;;;OAKG;IACH,QAAQ,CAAC,aAAa,CAAC,EAAE,CAAC,OAAO,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,KAAK,IAAI,CAAC;CACjE;AAED,yFAAyF;AACzF,MAAM,MAAM,iBAAiB,GAAG,CAC9B,GAAG,EAAE,MAAM,EACX,IAAI,EAAE;IAAE,QAAQ,CAAC,GAAG,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,SAAS,EAAE,MAAM,CAAA;CAAE,KACvD;IAAE,QAAQ,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,QAAQ,CAAC,EAAE,OAAO,CAAA;CAAE,CAAC;AAilS9E,wBAAsB,MAAM,CAAC,IAAI,EAAE,MAAM,EAAE,EAAE,EAAE,GAAE,KAAU,GAAG,OAAO,CAAC,MAAM,CAAC,CAgM5E"}