@davidorex/pi-context-cli 0.30.0 → 0.31.0

package/CHANGELOG.md

@@ -4,6 +4,43 @@ All notable changes to this package are documented here. Format follows [Keep a
 
 ## [Unreleased]
 
+## [0.31.0] - 2026-06-13
+
+### Changed
+- The CLI auto-supplied params (`writer`, `arrayKey` — filled after parse so a caller need not pass them) are now described by one internal source that drives all of: their exemption from the missing-required check, their bracketed-optional rendering in the per-op synopsis, and their `autoSupplied` annotation in the `--help` Flags block. Observable behavior is unchanged — these params remain optional to pass and auto-filled.
+
+### Added
+- `pi-context context-install [--update]` reflects the new `context-install` op, listed under the top-level help's Substrate lifecycle group (after `context-accept-all`). It materializes the schemas + starter blocks declared in `config.json`'s `installed_schemas` / `installed_blocks` from the package samples catalog and records the install baseline (`config.installed_from`). Default skip-if-exists; `--update` re-syncs existing installed schemas (migration-aware) and replaces empty blocks with the catalog starter, while populated block data is preserved. `authGated` (confirm or `--yes`/`--force`). The install ceremony was previously reachable only as the `/context install` slash command.
+- `pi-context read-catalog-schema --kind <canonical_id>` reflects the new read-only op, listed under the top-level help's Read & query group. It fetches and prints the verbatim bundled catalog `*.schema.json` body for a named block kind (the raw JSON Schema — `properties` / `definitions` / `$id`, not the `read-samples-catalog` projection), so the body is diffable locally against the installed `<substrate>/schemas/<name>.schema.json` without hunting through `node_modules`. Under `--json` the raw schema text rides the op-result envelope as a string; on the default text surface it prints the bytes as-is. Package-intrinsic (reads the extension's bundled catalog, independent of any substrate); an unknown kind is a non-zero exit.
+- `pi-context context-check-status` reflects the new read-only drift-report op, listed under the top-level help's Read & query group. It reports each installed schema's installed-vs-catalog drift state and, for each schema behind the catalog (`catalog-ahead` / `both-diverged`), which schema is behind and by what version gap — the baseline → catalog version pair under `version_delta` (a declared version bump) or a content-only basis when the catalog body moved with the version string unchanged. Under `--json` the structured `CheckStatusReport` (`perAsset` + `summary`) rides in the op-result envelope; writes nothing.
+- `pi-context update`'s text surface now reports, on a schema blocked by items failing the catalog schema, that git-style failure markers were written INTO the block file(s) — the blocked report header and trailing guidance tell the operator to open each block file, fix the items between the `<<<<<<< BLOCKED …` / `>>>>>>> target: …` markers, then run `pi-context resolve-blocked --schemaName <name> --yes`. `pi-context resolve-blocked` strips the markers before re-validating the corrected block against the pinned target.
+- `pi-context resolve-blocked --schemaName <name>` — the CLI now reflects the new `resolve-blocked` op, the commit step that resolves a schema `update` blocked. After `update` blocks a catalog-ahead resync (and persists a pending-blocked record), the calling agent fixes the block's failing items (or widens the local schema) and runs `resolve-blocked` to re-validate the corrected block against the pinned target and, on pass, write the target schema + advance the merge base so a subsequent `update` converges (in-sync) instead of re-blocking; on fail it reports the remaining per-item failures and writes nothing. Listed under the top-level help's Schema & config group; `authGated` (confirm or `--yes`/`--force`). The blocked-resync report `update` prints on the text surface now ends with the matching guidance line (fix the named items → `resolve-blocked --schemaName <name> --yes`).
+- `pi-context update` now surfaces the per-schema blocked-resync diagnostic on its default text surface: when a catalog-ahead resync is refused, the CLI renders a readable report below the op's own output — a `blocked: <name> (<from> -> <to>)` header per blocked schema, then either a `no migration chain reaches <to> from <from>` line or, for a validation failure, one line per failing item naming the item id (or its `instancePath` when no id resolved), the field, and the constraint. Under `--json` the structured `blockedDetail` already rides in the op-result envelope — the report is not double-emitted there. An `update` with no blocked schemas, or any other op, is unaffected.
+- `pi-context validate-block-items --block <name>` reflects the new read-only diagnostic op: it validates a block's items against the catalog schema version (forward-migrating in memory when the block lags the catalog version) and returns `{ block, from?, to?, valid, failures[] }` — each failure naming the item id, field, and constraint — without writing. An unknown block or a missing installed block file is a non-zero exit. Listed under the top-level help's Read & query group.
+- `pi-context context-lens-view --lensId <id>` projects a config-declared lens (`config.lenses[]`) as a binned item-view. Without `--bin` it returns a bin→count summary (the count of items in each declared bin plus `uncategorized` and `total`, always under the read cap); with `--bin <name>` it returns that bin's items paged by `--offset`/`--limit` (`{ items, total, hasMore }`). Serves target, composition, and hand-curated lenses. An unknown lens id or an undeclared bin is a non-zero exit.
+- Per-op `pi-context <op> --help` now renders a structured page: a one-line summary, a `SYNOPSIS` line (`pi-context <op>` with required flags first and optional flags bracketed — auto-injected `writer`/`arrayKey` shown bracketed-optional), the per-field `Flags` block (type tag, enum choices, required/optional, description; JSON-valued flags shown as `<json | @file>`), an `EXAMPLES` section of copy-pasteable invocations for that op, a `RELATED` section listing the sibling commands in the same help group, and a footer pointing to `pi-context --help` and the machine-readable form. **`pi-context <op> --help --format json`** (or `--help --json`) emits that same help as a machine-readable JSON model (`{ name, synopsis, summary, flags[], examples[], related[] }`).
+- The top-level `pi-context --help` (and bare `pi-context`) is now grouped and scannable: the surfaced ops are partitioned into seven command classes — Read & query, Block writes, Relations, Schema & config, Substrate lifecycle, Workflow, and a Process modes section (`pi-bound`) — rendered read-before-mutate, alphabetically within each class, each row showing the op's short reflection summary truncated to a uniform width. The classification is derived from the reflected op set, so a newly surfaced op appears under its class automatically. A new **`pi-context --version`** (alias `-v`) prints the package version and exits.
+- An ergonomic-affordance layer adds three CLI-side conveniences, leaving every in-pi op byte-unchanged: (1) **`--show-schema`** previews a block-mutation op's contract — array key, required-field set, every field with its type (and enum values when declared), and the id pattern — and exits before any write (read through the installed schema; exits `3` when the block's schema is absent). (2) **`append-block-item --dry-run`** (alias `--dryRun`) validates the prospective whole file (`{...existing, <arrayKey>: [...items, newItem]}` against the block schema — exactly what a real append validates) and writes nothing, replicating the op's `--autoId` allocation and reporting the id that would be allocated (`[dry-run] PASS — would append <id>`); it never invokes the append op, so the op stays frozen. The flag is a global flag (matched on both kebab and camel forms) only for an op that declares no `dryRun` param; ops with their own `dryRun` param keep their existing semantics. (3) **Granular exit codes** distinguish error classes: `0` success, `1` runtime error / declined authorization, `2` usage error, `3` schema-absent, `4` id-allocation failure, `5` schema validation. A validation failure that previously exited `1` now exits `5`.
+- An output + error-shaping layer adds three CLI-side affordances at the emit/catch boundary, leaving every in-pi op byte-unchanged: (1) **`--format text|json|table`** selects the render — `text` (default) reproduces each op's prior human output, `json` is the existing `{ ok, op, output }` envelope (`--json` is now its exact alias), and `table` projects a renderable row array (a read whose body is a collection, or a data op returning an array) as a compact markdown table (`id`-first, ≤4 columns, cells one-lined + 80-char-capped); a result that is not a complete tabular collection (prose, a non-array value, or an over-cap read) falls back to `text` so a degenerate table never replaces the real output; an unknown `--format` value is a usage error (exit 2). (2) **Field-named validation guidance** — a schema-validation failure now surfaces which field and what constraint (e.g. `` `/gaps/0`: missing required field `description` ``, `expected string`, `must be one of …`, `unexpected property …`) on both the text and `--json` surfaces, instead of the raw validator phrasing. (3) **Whole-subtree addressed reads** — `read-schema --schemaName <name> --path <dotted.path>` and `read-config --registry <name> [--id <id>]` return the complete node at that address (all children included), 50KB-capped, instead of a paged slice of one of the node's arrays. The whole-subtree behavior is now sourced from the in-pi op itself (the op passes `whole: true` on the addressed read); the earlier CLI-side recompute that produced the same envelope is retired.
+- A pre-call input layer adds four additive flag affordances over the schema-derived surface (the in-pi op schemas + handlers are unchanged — the ops still receive + require their declared params; the CLI normalizes/supplies them, and every schema-exact form keeps working): (1) **kebab-case flags** resolve to their camelCase op-schema keys (`--dry-run` → `--dryRun`); (2) **`--id`** aliases an op's single id-shaped param (`itemId`/`parentId`/`taskId`/`unitId`/…), rejecting as ambiguous when an op declares two (e.g. `complete-task`, `rename-canonical-id`); (3) **`--arrayKey` is derived** from `config.block_kinds[].array_key` for the seven block-mutation ops, so a caller passes only `--block <name>` (an explicit `--arrayKey` overrides); (4) three shorthands — **`--writer kind:id`** (`human:you@example.com` → `{"kind":"human","user":"you@example.com"}`, `agent:`→`agent_id`, `monitor:`→`monitor_name`, `workflow:`→`workflow_step_id`), **`--where field:op:value`** for the filter predicate (split on the first two colons; the value may contain colons), and **CSV `--op in`** (a comma-separated `--value a,b,c` becomes `["a","b","c"]`, argv-order-independent).
+- `pi-context resolve-conflict --schemaName <name> [--schema <reconciled>]` — the CLI now reflects the new `resolve-conflict` op, the commit step that completes the caller-as-reconciler conflict path. After `update` surfaces a conflict and the calling agent reconciles it, `resolve-conflict` writes the reconciled body AND advances the merge base for that schema to the catalog, so a subsequent `update` converges (the schema reads as `locally-modified` and its merge takes the reconciled body) instead of re-reporting the same conflict — which a bare `write-schema` (not advancing the base) would do. Omit `--schema` to treat the current on-disk body as already reconciled and only advance the base. `authGated` (confirm or `--yes`/`--force`).
+- `pi-context update` surfaces the irreconcilable 3-way-merge conflicts it produces (`UpdateResult.conflicts`) to the **calling agent** rather than spawning a subordinate session. Under `--json` the structured conflict set (per schema, each `{ path, base, ours, theirs }`) rides in the op-result envelope; on the default text surface the CLI additionally renders a readable per-schema conflict report ending with a reconcile-guidance line (reconcile the conflicting paths into a schema → `resolve-conflict --schemaName <name> --schema <reconciled>`). Because the CLI is an agent-invoked surface, the caller — already an interactive, credentialed agent holding the conflict set and the operator's authority — reconciles and commits via `resolve-conflict`; the CLI spawns nothing. The `update` op's own output is unchanged and still printed first; an `update` with no conflicts, or any other op, is unaffected.
+- `pi-context pi-bound [--grant <id>]... [...pi flags]` — a CLI process mode that launches an interactive `pi` coding-agent session whose tool surface is constrained to the canonical bounded set: the static tools derived from the installed packages' generated `SKILL.md` files, plus pi's built-in read-only tools (`read`/`ls`/`grep`/`find`), plus the active substrate's declared bounded composites (`config.tool_operations[]`). Repeated `--grant <canonical_id>` scopes the composite surface to a subset (default: all declared); every other token passes through to `pi`. Runs from the target dir; re-derives the full allowlist and runs `pi install -l` on every launch, including `--continue`/`-c` resumes. Replaces the `scripts/launch-constrained-pi.sh` entrypoint.
+- `pi-context update [--dryRun]` — a reflected op that brings the installed substrate model toward the current catalog: it consults the per-schema drift classification, resyncs `in-sync`/`catalog-ahead` schemas, and **refuses to overwrite** a `locally-modified`/`both-diverged` schema, reporting it instead (a user's schema edits are never silently clobbered). `--dryRun` previews the per-schema action plan and writes nothing.
+
+### Removed
+- The CLI-side addressed-read override (the post-`op.run` block that re-addressed the node off a fresh source load and re-wrapped it with `whole: true` for `read-schema --path` / `read-config --registry [--id]`) is retired. The in-pi op now returns the whole addressed subtree itself, so both surfaces — the op and the CLI — produce the whole-subtree envelope from the single op source; the CLI no longer recomputes it. The now-unused `addressInto` / `structureForRead` imports were dropped.
+- `resolveConflicts` and the `resolve-conflicts` module (the subordinate-spawn conflict mergetool) are removed; `pi-context update` surfaces the conflict set to the calling agent instead.
+
+### Fixed
+- The `read-catalog-schema` `verbatimText` text-surface test and the two trailing-newline comments (the test's doc-comment and the `cli.ts` emit-branch comment) are corrected to the verified fact that the bundled catalog `*.schema.json` files end with their own trailing newline (last bytes `}\n`). The prior text encoded a false premise — that the files end with `}` and carry no trailing newline. The verbatimText emit reproduces the file's own bytes byte-exact (its single trailing newline included) and does not append a second one; the defect it addresses was the CLI appending an extra newline (doubling `}\n` to `}\n\n`), which a `read-catalog-schema --kind <k> | diff <installed> -` surfaced as a phantom trailing-empty-line. The byte-exact behavior of `read-catalog-schema` is unchanged.
+- Per-op `--help` now reconciles its `Flags` block with its `SYNOPSIS` for CLI-auto-supplied params (`writer`, `arrayKey`). The `Flags` block keeps the schema-truth `(required)` tag but appends the param's provenance — `--arrayKey <string>  (required; auto-derived from --block)` and `--writer <json | @file>  (required; auto-injected)` — so a reader no longer sees a bare `(required)` for a param the synopsis brackets as optional and the CLI fills automatically. The `--help --format json` model carries the same provenance on each such flag (`autoSupplied`). A genuinely-required param the caller must pass keeps a plain `(required)` with no provenance marker.
+- `--dryRun`/`--dry-run` on an op that does not support a dry run now errors as an unknown flag (exit 2) instead of being silently swallowed and the real operation running. The global `--dry-run` capture is now scoped to `append-block-item` — the only op whose dry run the CLI performs client-side; for every other op that declares no `dryRun` param (`update-block-item`, `remove-block-item`, and the other no-`dryRun` mutation ops) the flag is rejected rather than dropped, so a caller's dry-run intent can no longer turn into a real write. Ops that declare their own `dryRun` param (`upsert-block-item`, `update`, the relation ops, …) are unaffected — the flag still reaches their own preview semantics.
+- A schema-absent failure surfaced through id allocation now classifies to exit `3` (schema-absent) instead of `4` (id-allocation failure). When an `--autoId` append targets a block whose schema file is missing, the id allocator's "schema not found" throw was matching the id-allocation exit-code pattern first; the catch classifier now tests schema-not-found ahead of id-allocation, so the exit code names the true cause. Genuine id-allocation failures (no id pattern, or an unparseable pattern) still exit `4`.
+- The `--id` alias no longer binds to a boolean flag whose name happens to end in `Id`. The alias identifies an op's id-param(s) by name (`id` or `…Id`); it now additionally requires the matched param to be string-typed, so `append-block-item`'s `autoId` (a boolean auto-allocation flag, not an identity selector) is excluded. Previously `autoId` was that op's sole `…Id` match, so `--id` silently resolved to it — `append-block-item --id SOME-123` swallowed the value into `autoId` and `--id true` silently enabled auto-allocation on a write. With the guard, `append-block-item` declares zero id-params, so `--id` correctly falls through to the unknown-flag error; `--autoId` as the boolean presence flag is unaffected.
+- `pi-context update` no longer leaves an irreconcilable schema conflict unresolvable from the CLI. The prior route dispatched a subordinate `pi-bound` mergetool via `pi -p`, which runs headless (`hasUI=false`) so the spawned agent's `write-schema` was auth-gate-refused and its reconciliation was never applied — the spawned agent could only print a proposal. The conflict set is now returned to the calling agent — the interactive, credentialed actor that invoked the CLI — which reconciles it and commits via `resolve-conflict` (which writes the reconciled body AND advances the merge base to the catalog, so a subsequent `update` converges instead of re-reporting the conflict).
+- `pi-bound` pre-launch setup-step failures now abort before the `pi` launch with an attributed `pi-context pi-bound: …` stderr line and a deterministic exit code, restoring the `set -e` parity of the `scripts/launch-constrained-pi.sh` entrypoint it ports: a non-resolvable package returns 1 (was a raw `Cannot find module` throw surfaced as a generic error); a non-zero `pi install -l` exit propagates the install's own code and aborts (was discarded, proceeding to a broken launch); a `pi install`/launch spawn failure (pi un-runnable) returns 1 (was a bare reject). The success path still returns the launch's exit code unchanged.
+
 ## [0.30.0] - 2026-06-04
 
 ### Added

package/README.md

@@ -15,8 +15,10 @@ This provides a `pi-context` binary.
 ## Usage
 
 ```bash
-pi-context --help                 # list every surfaced op + global flags
-pi-context <op> --help            # per-op help: declared flags with TYPE tags
+pi-context --help                 # grouped op index (by command class) + global flags
+pi-context --version              # print the package version (alias -v)
+pi-context <op> --help            # per-op help: synopsis + flags + examples + related commands
+pi-context <op> --help --format json  # the same help as a machine-readable JSON model
 pi-context <op> [flags]           # run an op
 ```
 
@@ -31,15 +33,128 @@ Example:
 pi-context read-block --block tasks
 pi-context append-block-item --block issues --arrayKey issues --item @new-issue.json --autoId
 pi-context read-block-page --block framework-gaps --offset 0 --limit 50
+pi-context update --dryRun
+```
+
+## Input affordances
+
+On top of the schema-derived flags, the CLI accepts a set of input conveniences. Each is additive — the schema-exact form (camelCase flags, explicit `--arrayKey`, a JSON `--writer`, separate `--field`/`--op`/`--value`) keeps working unchanged.
+
+- **kebab-case flags** are accepted alongside the camelCase op-schema keys. `--dry-run` resolves to `--dryRun`; any conventional kebab form resolves when its camelCase key exists. An unrecognized flag (kebab or otherwise) is still rejected.
+- **`--id` aliases the op's single id-param.** When an op declares exactly one id-shaped parameter (`itemId` / `parentId` / `taskId` / `unitId` / …), `--id <value>` resolves to it. An op that already declares a literal `id` parameter takes `--id` directly. An op with two id-params (e.g. `complete-task`, `rename-canonical-id`) rejects `--id` as ambiguous — name the explicit flag.
+- **`--arrayKey` is derived from config** for the block-mutation ops (`append-block-item`, `update-block-item`, `upsert-block-item`, `remove-block-item`, and the nested variants). Pass only `--block <name>`; the array key is read from that block's `config.block_kinds[].array_key`. An explicit `--arrayKey` overrides the derivation.
+- **`--writer kind:id` shorthand.** `--writer human:you@example.com` expands to `{"kind":"human","user":"you@example.com"}`; `--writer agent:claude` to `{"kind":"agent","agent_id":"claude"}` (`monitor:`→`monitor_name`, `workflow:`→`workflow_step_id`). The first colon delimits the kind; the identifier may itself contain colons.
+- **`--where field:op:value` shorthand** for the filter predicate: `--where status:eq:done` sets `--field status --op eq --value done`. Split on the first two colons only, so the value may contain colons.
+- **CSV `--op in`.** When the comparison operator is `in`, a comma-separated `--value a,b,c` is split into the array `["a","b","c"]`. Order-independent — `--op in --value a,b,c` and `--value a,b,c --op in` are equivalent.
+
+```bash
+pi-context append-block-item --block framework-gaps --item @gap.json        # arrayKey derived from config
+pi-context find-references --id TASK-1                                       # --id → itemId
+pi-context append-block-item --block tasks --item @t.json --writer human:you@example.com
+pi-context filter-block-items --block tasks --where status:eq:done          # field/op/value from one token
+pi-context filter-block-items --block tasks --field tag --op in --value a,b,c
+```
+
+## Contract preview + dry-run
+
+For the block-mutation ops the CLI offers two pre-write affordances:
+
+- **`--show-schema`** previews a block op's contract and exits before any write — the array key, the required-field set, every field with its type (and enum values when declared), and the id pattern. Pass it with the op and `--block <name>`; no `--item` is needed.
+- **`append-block-item --dry-run`** (or `--dryRun`) validates the prospective whole file — `{...existing, <arrayKey>: [...items, newItem]}` against the block schema, exactly what a real append validates — and writes nothing. With `--autoId` it reports the id that would be allocated. The output is `[dry-run] PASS` (or `[dry-run] PASS — would append <id>`); a schema-invalid item surfaces the field-named validation error.
+
+```bash
+pi-context append-block-item --block framework-gaps --show-schema     # contract preview, no write
+pi-context append-block-item --block tasks --item @t.json --dry-run    # validate the prospective file, no write
+pi-context append-block-item --block tasks --item @t.json --dry-run --autoId   # also reports the allocated id
+```
+
+## Output rendering
+
+`--format text|json|table` selects how an op's result is rendered. `--json` is the exact alias of `--format json`.
+
+- **`text`** (default) — each op's human render: prose, a JSON.stringify'd value, or a read body with its paging footer.
+- **`json`** — the `{ ok, op, output }` envelope (`{ ok: false, op, error }` on failure). `output` is the un-stringified value (single-parse), read-capped at 50KB.
+- **`table`** — a compact markdown table of a renderable row array (a read whose body is a collection, or a data op that returns an array). The projection is best-effort terse: `id` first when present, then up to three more fields (≤4 columns), cells one-lined and capped at 80 chars. A result that is not a complete tabular collection (prose, a non-array value, or an over-cap read) renders as `text` instead — a degenerate table is never substituted for the real output.
+
+```bash
+pi-context read-block --block tasks --format table       # markdown table of the tasks
+pi-context filter-block-items --block tasks --where status:eq:open --format table
+pi-context read-block --block tasks --json               # ≡ --format json
+```
+
+Schema-validation failures surface **field-named guidance** — which field and what constraint (e.g. `` `/gaps/0`: missing required field `description` ``) — rather than the raw validator phrasing, on both the text and `--json` surfaces.
+
+Addressed reads return the **whole addressed subtree** (50KB-capped): `read-schema --schemaName <name> --path <dotted.path>` and `read-config --registry <name> [--id <id>]` return the complete node at that address — including all of its children — not a paged slice of one of its arrays.
+
+## `pi-context pi-bound` — constrained pi session
+
+```bash
+pi-context pi-bound [--grant <id>]... [...pi-args]
+```
+
+`pi-bound` is a CLI **process mode** (not a substrate op): it launches a `pi` coding-agent session restricted to the composed pi-extension tool surface. On every launch it:
+
+1. runs `pi install -l <@davidorex/pi-project-workflows root>` to register the extensions into the target dir's `.pi/`
+2. derives the static tool allowlist from the installed packages' generated `skills/*/SKILL.md` (`@davidorex/pi-context` + `@davidorex/pi-project-workflows`)
+3. always adds the built-in read-only tools `read`, `ls`, `grep`, `find`
+4. appends the bounded composites declared in the active substrate's `config.tool_operations[]`
+5. launches `pi --tools <union> ...pi-args`
+
+It runs from the process cwd and reads that dir's `.pi-context.json` for composites (warns, non-fatally, if absent).
+
+**Flags:**
+
+- `--grant <id>` (repeatable) — scope the bounded composites to only the named ids. Default: all declared composites.
+- any other token — passed through verbatim to `pi` (e.g. `--continue` / `-c` to resume a session).
+
+```bash
+pi-context pi-bound                          # launch with the full composed tool surface
+pi-context pi-bound --grant grep-paths       # restrict composites to a single named op
+pi-context pi-bound -c                        # pass -c through to pi to resume
+```
+
+This process mode replaces the former `scripts/launch-constrained-pi.sh` launch script.
+
+## `pi-context update` — drift-aware model update + conflict surfacing
+
+```bash
+pi-context update [--dryRun]
+```
+
+`update` brings the installed schema model current with the packaged catalog. Per installed schema it consults the drift classification and routes by state: an `in-sync` schema is a no-op; a `catalog-ahead` schema re-syncs through the migration-aware path; a `locally-modified` / `both-diverged` schema is reconciled by a deterministic 3-way merge of base (the as-installed schema body in the object store, keyed by the recorded baseline `content_hash`) × ours (the installed schema) × theirs (the catalog schema). Disjoint edits auto-merge so both the user's and the catalog's changes survive (`required` / `enum` / array-valued `type` nodes merge as sets).
+
+A schema whose per-path edits cannot be reconciled is left unmodified, and the conflict is SURFACED to the calling agent — `update` does not spawn a subordinate resolver. The conflict set is returned in the op output (the `conflicts` array, printed under `--json`) alongside a readable per-schema report on the default text surface. The report ends with a guidance line; the calling agent reconciles each conflicting schema and commits the reconciliation with `pi-context resolve-conflict`:
+
+```bash
+pi-context read-schema --schemaName <name>     # inspect the current installed body
+# resolve the conflicting paths into a reconciled draft-07 schema, then commit it:
+pi-context resolve-conflict --schemaName <name> --schema '<reconciled-json>'
+```
+
+`resolve-conflict` writes the reconciled body AND advances the merge base for that schema to the catalog, so the next `update` sees the schema as `locally-modified` and its deterministic merge takes the reconciled body (base === theirs → ours) — converging with zero conflicts and preserving the resolution. A bare `write-schema` does not advance the base, so `update` would re-report the same conflict on every run. Omit `--schema` to treat the current on-disk body as already reconciled and only advance the base.
+
+`update` also additively propagates catalog-new config-registry entries (`relation_types` / `invariants` / `block_kinds` / `lenses`) absent from the substrate config, preserving every user-authored entry and any locally-diverged body of an existing entry (additive-only — present entries are never overwritten; the added ids are reported under `registryAdditions`).
+
+A `catalog-ahead` schema whose resync is refused (`blocked`) carries its diagnostic under `blockedDetail` (one entry per blocked schema): the refusal reason — `no-migration-chain` (no shipped chain reaches the catalog version) vs `validation-failed` (the forward-migrated items fail the catalog schema) — the installed→catalog version pair, and for a validation failure the per-item failures naming the failing item id, field, and constraint. Under `--json` the `blockedDetail` array rides in the op-result envelope; on the default text surface the CLI renders a readable per-schema report below the op output (`blocked: <name> (<from> -> <to>)` then the no-chain line or the per-item failure lines), ending with a guidance line. A live blocked `update` also persists a pending-blocked record pinning the target catalog schema, and — for a `validation-failed` block — writes git-style failure markers INTO the block file at the offending items (full-line `<<<<<<< BLOCKED …` / `>>>>>>> target: …` sentinels), pinning the pre-marker bytes (the schema and `migrations.json` stay byte-unchanged). The resolution loop is: open the block file, fix the items between the markers (or widen the local schema) → `pi-context resolve-blocked --schemaName <name>`, which strips the markers, re-validates the corrected block against the pinned target and, on pass, writes the target schema + advances the merge base so a subsequent `update` converges (in-sync) instead of re-blocking. The standalone `pi-context validate-block-items --block <name>` runs the same per-item check on demand (read-only, returns `{ block, from?, to?, valid, failures[] }`).
+
+`--dryRun` predicts the precise per-schema outcome (resync / migrate / block / merge / conflict) by running the forward-migration and re-validation in memory, alongside the per-blocked-schema diagnostic detail and the config-registry entries that would be added, and writes nothing.
+
+```bash
+pi-context update --dryRun                   # predict the precise per-schema outcome (in-memory migrate + re-validate) + config-registry additions
+pi-context update                            # apply: resync + auto-merge; conflicts → surfaced (op output + report) for the caller to reconcile + commit via resolve-conflict
 ```
 
 ## Global flags
 
 - `--cwd <dir>` — substrate root (default: current working directory; relative paths resolve against it)
-- `--json` — emit a `{ ok, op, output }` envelope on success (`{ ok: false, op, error }` on failure) instead of raw output
+- `--json` — emit a `{ ok, op, output }` envelope on success (`{ ok: false, op, error }` on failure) instead of raw output (≡ `--format json`)
+- `--format <text|json|table>` — select the output render (default `text`, or `json` with `--json`); see [Output rendering](#output-rendering)
 - `--yes`, `--force` — pre-authorize an auth-gated op in a non-interactive context
 - `--writer <json>` — override the auto-resolved writer identity
-- `--help`, `-h` — top-level help, or per-op help after an op name
+- `--show-schema` — preview a block op's contract (array key / required fields / field types / id pattern) and exit; see [Contract preview + dry-run](#contract-preview--dry-run)
+- `--dry-run`, `--dryRun` — for `append-block-item`, validate the prospective file and write nothing; see [Contract preview + dry-run](#contract-preview--dry-run)
+- `--version`, `-v` — print the package version and exit
+- `--help`, `-h` — grouped top-level help (ops by command class + a Process modes section), or per-op help after an op name
 
 ## Writer identity
 
@@ -59,6 +174,11 @@ Ops marked `authGated` (writes that mutate config / schemas / migrations) requir
 
 ## Exit codes
 
-- `0` — success
-- `1` — op/runtime error, or declined authorization
-- `2` — usage error (unknown op, unknown flag, missing required field)
+| Code | Meaning |
+| --- | --- |
+| `0` | success |
+| `1` | op/runtime error, or declined authorization |
+| `2` | usage error (unknown op, unknown flag, missing required field) |
+| `3` | schema absent (the block's schema is not installed) |
+| `4` | id-allocation failure (`--autoId` could not allocate the next id) |
+| `5` | schema validation failure |

package/dist/cli.d.ts

@@ -6,6 +6,16 @@ import { type OpDefinition } from "@davidorex/pi-context/ops";
  * is excluded here by the partition, never by name.
  */
 export declare const useOps: OpDefinition[];
+/**
+ * The pi-context-cli package version, read ONCE at module load from the shipped
+ * package.json. Resolved RELATIVE to this module's URL (mirrors pi-bound.ts's
+ * createRequire(import.meta.url) pattern) so it works from the BUILT bin: from
+ * `dist/cli.js`, `../package.json` is the package root (npm always ships
+ * package.json in a published tarball). A plain `import pkg from "../package.json"`
+ * is deliberately avoided — tsconfig.build's rootDir:"./src" / include:["src/**"]
+ * would make that compile path a hazard. `--version`/`-v` prints this value.
+ */
+export declare const PKG_VERSION: string;
 /** Field-type tag rendered in help and used to pick a coercion strategy. */
 export type FieldType = "string" | "number" | "boolean" | "json";
 interface FieldSchema {
@@ -59,6 +69,17 @@ export interface ParsedArgs {
     json: boolean;
     yes: boolean;
     help: boolean;
+    /** --show-schema (FGAP-022): print the block contract and exit before any write. */
+    showSchema?: boolean;
+    /**
+     * --dryRun / --dry-run (FGAP-024): for append-block-item, validate the prospective
+     * whole file and write nothing. Parsed as a global flag — never injected into
+     * `params` — because the frozen append op declares no `dryRun` param and would
+     * reject it as an unknown flag.
+     */
+    dryRun?: boolean;
+    /** Selected output render (FGAP-021). Unset → resolved from `json` at emit time. */
+    format?: "text" | "json" | "table";
     explicitWriter?: unknown;
     params: Record<string, unknown>;
 }
@@ -77,6 +98,18 @@ export declare function parseOpArgs(op: OpDefinition, argv: string[], cwdBase?:
  * identity (falling back to "operator"). Mutates and returns `params`.
  */
 export declare function injectWriter(op: OpDefinition, params: Record<string, unknown>, identity: string | null): Record<string, unknown>;
+/**
+ * Schema- + config-driven arrayKey injection (FGAP-019), mirroring injectWriter.
+ * The 7 block-mutation ops still DECLARE `arrayKey` required (their in-pi schema +
+ * handler are byte-unchanged and still receive + require it) — the CLI supplies it
+ * pre-call so a caller passes only `--block`. When the op declares `arrayKey`, none
+ * was passed, and a string `block` is present, derive the array_key from the
+ * config block_kinds entry whose canonical_id matches `block` (canonical_id ≠
+ * array_key in real data, e.g. framework-gaps → gaps, so the derivation is genuinely
+ * needed). Best-effort: no substrate, no config, or an unknown block leaves arrayKey
+ * unset — the op then throws its own missing-param error. Mutates and returns params.
+ */
+export declare function injectArrayKey(op: OpDefinition, params: Record<string, unknown>, cwd: string): Record<string, unknown>;
 /**
  * Build the DispatchContext threaded into `op.run` as its 3rd arg so every CLI
  * write op stamps attestation (created_by / created_at) on schemas that declare
@@ -112,9 +145,92 @@ export declare function authDecision(op: OpDefinition, opts: {
     yes: boolean;
     interactive: boolean;
 }): AuthDecision;
-/** Per-op help text: description + one line per declared field. */
+/**
+ * One flag descriptor in the machine-readable help model (CHANGE 3 / TASK-042).
+ * `type` is the enum-join (`eq|neq|in|matches`) for string-enum fields, else the
+ * coarse FieldType tag. `required` reflects the op's declared schema `required` set
+ * verbatim (writer/arrayKey ARE marked required here — schema-truth). `autoSupplied`
+ * carries the AUTO_SUPPLIED provenance phrase when the CLI fills the param after
+ * parse (writer / arrayKey), else omitted — the Flags block + json help render it as
+ * `(required; <autoSupplied>)` so a schema-required-but-CLI-supplied param is not
+ * mistaken for one the caller must pass.
+ */
+export interface HelpFlag {
+    name: string;
+    type: string;
+    required: boolean;
+    description?: string;
+    autoSupplied?: string;
+}
+/**
+ * Structured per-op help model — the single source both the text template
+ * (deriveHelp) and the `--help --format json` machine help render from.
+ *
+ * `synopsis` treats `writer` and `arrayKey` as OPTIONAL even when the schema lists
+ * them required, because both are auto-injected after parse (writer from the
+ * resolved operator identity; arrayKey from config.block_kinds[].array_key) — the
+ * same exemption parseOpArgs applies to its required-field check. So a flag is
+ * synopsis-required iff it is schema-required AND not writer/arrayKey.
+ *
+ * `related` is the sibling use-ops sharing this op's top-level help group
+ * (groupForOp — the single grouping source the top-level help uses), name-sorted,
+ * self excluded. pi-bound modes are not useOps, so they never appear.
+ */
+export interface HelpModel {
+    name: string;
+    synopsis: string;
+    summary: string;
+    flags: HelpFlag[];
+    examples: string[];
+    related: string[];
+}
+/**
+ * Single source for the CLI's auto-supplied params: a field declared `required`
+ * by the op schema that the CLI fills after parse, so the caller never passes it.
+ * Maps the param name to its provenance phrase. This map is the ONE source for
+ * both the synopsis exemption (bracketed-optional, `isSynopsisRequired`) and the
+ * per-flag `autoSupplied` annotation surfaced in the Flags block + json help —
+ * reconciling the Flags `(required)` schema-truth with the optional synopsis so
+ * neither surface contradicts the other (TASK-042 iterate-to-zero finding):
+ *   - writer:   injectWriter fills it from the resolved operator identity
+ *   - arrayKey: injectArrayKey derives it from config.block_kinds[].array_key
+ */
+export declare const AUTO_SUPPLIED: Record<string, string>;
+/**
+ * Build the structured per-op help model from the op's typebox parameters +
+ * the registry `examples` + the help-group siblings. Pure — no I/O.
+ */
+export declare function buildHelpModel(op: OpDefinition): HelpModel;
+/**
+ * Best-of-breed per-op help text (TASK-042): `<name> — <description>` → SYNOPSIS →
+ * Flags (per-field, enum joins + required/optional + desc; json fields show
+ * `<json | @file>`) → EXAMPLES → RELATED (omitted when empty) → footer →
+ * the Global flags trailer. Plain text.
+ */
 export declare function deriveHelp(op: OpDefinition): string;
-/** Top-level help: one line per surfaced op + global flag notes. */
+/**
+ * Classify a use-op into its top-level help group LABEL (first-match-wins over the
+ * ordered HELP_GROUPS). Throws when a use-op matches no group — a new op that slips
+ * past every rule fails loudly here rather than silently vanishing from the help.
+ * The drift-guard test asserts every `useOps` name maps to exactly one group.
+ */
+export declare function groupForOp(name: string): string;
+/**
+ * One-liner for an op row: prefer `promptSnippet` (the terse reflection summary),
+ * fall back to `description`. Collapse to a single line, then truncate uniformly to
+ * ~HELP_ONELINER_WIDTH at the last word boundary, appending an ellipsis when cut.
+ * Applied to EVERY row identically — no per-op special-casing, and the ops-registry
+ * text itself is never edited.
+ */
+export declare function helpOneLiner(op: OpDefinition): string;
+/**
+ * Grouped, scannable top-level help. Sections appear in HELP_GROUPS order (only
+ * groups with ≥1 op), ops sorted alphabetically within a group, each row a name
+ * padded to the group's own max-name width followed by the truncated one-liner.
+ * A static Process modes section surfaces `pi-bound` (a process mode, not a
+ * substrate op). The Global flags block is retained verbatim plus `--version`.
+ * Plain text only.
+ */
 export declare function deriveTopHelp(): string;
 export declare function main(argv: string[]): Promise<number>;
 export {};

package/dist/cli.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AA6BA,OAAO,KAAK,EAAE,eAAe,EAAkB,MAAM,wCAAwC,CAAC;AAC9F,OAAO,EAEN,KAAK,YAAY,EAIjB,MAAM,2BAA2B,CAAC;AAEnC;;;;GAIG;AACH,eAAO,MAAM,MAAM,EAAE,YAAY,EAA2C,CAAC;AAE7E,4EAA4E;AAC5E,MAAM,MAAM,SAAS,GAAG,QAAQ,GAAG,QAAQ,GAAG,SAAS,GAAG,MAAM,CAAC;AAEjE,UAAU,WAAW;IACpB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,KAAK,CAAC,EAAE,KAAK,CAAC;QAAE,IAAI,CAAC,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,OAAO,CAAC;QAAC,IAAI,CAAC,EAAE,OAAO,EAAE,CAAA;KAAE,CAAC,CAAC;CACpE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,WAAW,GAAG,MAAM,EAAE,GAAG,IAAI,CAmBpE;AAYD;;;;GAIG;AACH,wBAAgB,SAAS,CAAC,KAAK,EAAE,WAAW,GAAG,SAAS,CAgBvD;AAED,gFAAgF;AAChF,wBAAgB,SAAS,CAAC,IAAI,EAAE,MAAM,GAAG,YAAY,GAAG,SAAS,CAEhE;AAED,oFAAoF;AACpF,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAErD;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAAC,IAAI,CAAC,EAAE;IACtC,QAAQ,CAAC,EAAE,MAAM,MAAM,GAAG,IAAI,CAAC;IAC/B,OAAO,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CAC7B,GAAG,MAAM,GAAG,IAAI,CAmBhB;AAED,MAAM,WAAW,UAAU;IAC1B,GAAG,EAAE,MAAM,CAAC;IACZ,IAAI,EAAE,OAAO,CAAC;IACd,GAAG,EAAE,OAAO,CAAC;IACb,IAAI,EAAE,OAAO,CAAC;IACd,cAAc,CAAC,EAAE,OAAO,CAAC;IACzB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CAChC;AAED,qBAAa,UAAW,SAAQ,KAAK;CAAG;AAExC;;;;;GAKG;AACH,wBAAgB,WAAW,CAAC,EAAE,EAAE,YAAY,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,OAAO,SAAgB,GAAG,UAAU,CAwGjG;AAED;;;;GAIG;AACH,wBAAgB,YAAY,CAC3B,EAAE,EAAE,YAAY,EAChB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC/B,QAAQ,EAAE,MAAM,GAAG,IAAI,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAMzB;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,uBAAuB,CAAC,cAAc,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,GAAG,IAAI,GAAG,eAAe,CASzG;AA+BD,MAAM,MAAM,YAAY,GAAG;IAAE,KAAK,EAAE,IAAI,CAAA;CAAE,GAAG;IAAE,KAAK,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,OAAO,CAAA;CAAE,CAAC;AAEpG;;;;;;GAMG;AACH,wBAAgB,YAAY,CAAC,EAAE,EAAE,YAAY,EAAE,IAAI,EAAE;IAAE,GAAG,EAAE,OAAO,CAAC;IAAC,WAAW,EAAE,OAAO,CAAA;CAAE,GAAG,YAAY,CASzG;AAED,mEAAmE;AACnE,wBAAgB,UAAU,CAAC,EAAE,EAAE,YAAY,GAAG,MAAM,CAoBnD;AAED,oEAAoE;AACpE,wBAAgB,aAAa,IAAI,MAAM,CAgBtC;AAcD,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CAqF1D"}
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":"AAkCA,OAAO,KAAK,EAAE,eAAe,EAAkB,MAAM,wCAAwC,CAAC;AAC9F,OAAO,EAEN,KAAK,YAAY,EAIjB,MAAM,2BAA2B,CAAC;AAMnC;;;;GAIG;AACH,eAAO,MAAM,MAAM,EAAE,YAAY,EAA2C,CAAC;AAE7E;;;;;;;;GAQG;AACH,eAAO,MAAM,WAAW,EAAE,MAEjB,CAAC;AAEV,4EAA4E;AAC5E,MAAM,MAAM,SAAS,GAAG,QAAQ,GAAG,QAAQ,GAAG,SAAS,GAAG,MAAM,CAAC;AAEjE,UAAU,WAAW;IACpB,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,KAAK,CAAC,EAAE,KAAK,CAAC;QAAE,IAAI,CAAC,EAAE,MAAM,CAAC;QAAC,KAAK,CAAC,EAAE,OAAO,CAAC;QAAC,IAAI,CAAC,EAAE,OAAO,EAAE,CAAA;KAAE,CAAC,CAAC;CACpE;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,gBAAgB,CAAC,KAAK,EAAE,WAAW,GAAG,MAAM,EAAE,GAAG,IAAI,CAmBpE;AAYD;;;;GAIG;AACH,wBAAgB,SAAS,CAAC,KAAK,EAAE,WAAW,GAAG,SAAS,CAgBvD;AAED,gFAAgF;AAChF,wBAAgB,SAAS,CAAC,IAAI,EAAE,MAAM,GAAG,YAAY,GAAG,SAAS,CAEhE;AAED,oFAAoF;AACpF,wBAAgB,eAAe,CAAC,IAAI,EAAE,MAAM,GAAG,OAAO,CAErD;AAED;;;;;;;;GAQG;AACH,wBAAgB,eAAe,CAAC,IAAI,CAAC,EAAE;IACtC,QAAQ,CAAC,EAAE,MAAM,MAAM,GAAG,IAAI,CAAC;IAC/B,OAAO,CAAC,EAAE,MAAM,GAAG,SAAS,CAAC;CAC7B,GAAG,MAAM,GAAG,IAAI,CAmBhB;AAED,MAAM,WAAW,UAAU;IAC1B,GAAG,EAAE,MAAM,CAAC;IACZ,IAAI,EAAE,OAAO,CAAC;IACd,GAAG,EAAE,OAAO,CAAC;IACb,IAAI,EAAE,OAAO,CAAC;IACd,oFAAoF;IACpF,UAAU,CAAC,EAAE,OAAO,CAAC;IACrB;;;;;OAKG;IACH,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,oFAAoF;IACpF,MAAM,CAAC,EAAE,MAAM,GAAG,MAAM,GAAG,OAAO,CAAC;IACnC,cAAc,CAAC,EAAE,OAAO,CAAC;IACzB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAAC;CAChC;AAED,qBAAa,UAAW,SAAQ,KAAK;CAAG;AAExC;;;;;GAKG;AACH,wBAAgB,WAAW,CAAC,EAAE,EAAE,YAAY,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,OAAO,SAAgB,GAAG,UAAU,CAyOjG;AAED;;;;GAIG;AACH,wBAAgB,YAAY,CAC3B,EAAE,EAAE,YAAY,EAChB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC/B,QAAQ,EAAE,MAAM,GAAG,IAAI,GACrB,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAMzB;AAED;;;;;;;;;;GAUG;AACH,wBAAgB,cAAc,CAC7B,EAAE,EAAE,YAAY,EAChB,MAAM,EAAE,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,EAC/B,GAAG,EAAE,MAAM,GACT,MAAM,CAAC,MAAM,EAAE,OAAO,CAAC,CAazB;AAED;;;;;;;;;;;;;;;GAeG;AACH,wBAAgB,uBAAuB,CAAC,cAAc,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,GAAG,IAAI,GAAG,eAAe,CASzG;AA+BD,MAAM,MAAM,YAAY,GAAG;IAAE,KAAK,EAAE,IAAI,CAAA;CAAE,GAAG;IAAE,KAAK,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,WAAW,EAAE,OAAO,CAAA;CAAE,CAAC;AAEpG;;;;;;GAMG;AACH,wBAAgB,YAAY,CAAC,EAAE,EAAE,YAAY,EAAE,IAAI,EAAE;IAAE,GAAG,EAAE,OAAO,CAAC;IAAC,WAAW,EAAE,OAAO,CAAA;CAAE,GAAG,YAAY,CASzG;AAED;;;;;;;;;GASG;AACH,MAAM,WAAW,QAAQ;IACxB,IAAI,EAAE,MAAM,CAAC;IACb,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,OAAO,CAAC;IAClB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,YAAY,CAAC,EAAE,MAAM,CAAC;CACtB;AAED;;;;;;;;;;;;;GAaG;AACH,MAAM,WAAW,SAAS;IACzB,IAAI,EAAE,MAAM,CAAC;IACb,QAAQ,EAAE,MAAM,CAAC;IACjB,OAAO,EAAE,MAAM,CAAC;IAChB,KAAK,EAAE,QAAQ,EAAE,CAAC;IAClB,QAAQ,EAAE,MAAM,EAAE,CAAC;IACnB,OAAO,EAAE,MAAM,EAAE,CAAC;CAClB;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,aAAa,EAAE,MAAM,CAAC,MAAM,EAAE,MAAM,CAGhD,CAAC;AAaF;;;GAGG;AACH,wBAAgB,cAAc,CAAC,EAAE,EAAE,YAAY,GAAG,SAAS,CAyC1D;AAED;;;;;GAKG;AACH,wBAAgB,UAAU,CAAC,EAAE,EAAE,YAAY,GAAG,MAAM,CAmCnD;AAuGD;;;;;GAKG;AACH,wBAAgB,UAAU,CAAC,IAAI,EAAE,MAAM,GAAG,MAAM,CAM/C;AAKD;;;;;;GAMG;AACH,wBAAgB,YAAY,CAAC,EAAE,EAAE,YAAY,GAAG,MAAM,CAOrD;AAED;;;;;;;GAOG;AACH,wBAAgB,aAAa,IAAI,MAAM,CAiCtC;AAyCD,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CAmR1D"}