wowbagger 0.1.0-alpha.7 → 0.1.0-alpha.8

package/CHANGELOG.md

@@ -7,6 +7,160 @@ consolidation. The first tagged release inherits this file.
 
 ## Unreleased
 
+## 0.1.0-alpha.8 - 2026-08-23
+
+### Added
+
+- **A published launch seam for a host that cannot run a shell.** The package
+  now declares `exports`, and its main entry `wowbagger` exposes
+  `CORE_SCRIPT_PATH`, `MINIMUM_NODE_MAJOR`, and `resolveCoreLaunch(argv)`, which
+  returns the exact process tuple a direct-core host needs: an absolute Node
+  executable, an argument array whose first element is the absolute
+  `bin/wowbagger.js`, and `shell: false`. A host that resolves its own runtime
+  gets `resolveCoreLaunch(argv, { nodeExecutable })`, and a relative or bare
+  executable name is refused rather than left for PATH to answer. The script
+  path is also resolvable on its own as `wowbagger/wowbagger.js` for a host that
+  wants the path without importing anything. Deep imports that already worked —
+  `wowbagger/src/limits.js` and every other published path — keep resolving
+  through an explicit `"./*"` subpath. No command accepts, refuses, emits, or
+  writes anything different.
+
+- **The machine contract ships as JSON Schema, not only as prose and fixtures.**
+  Seventeen JSON Schema 2020-12 documents under `schemas/` are published with
+  the package and resolvable as `wowbagger/schemas/<file>.json`, with
+  `schemas/index.json` naming each one's response domain and that domain's
+  version. They cover the core envelope and its four exact root shapes, the
+  capabilities envelope with every advertised limit as a constant, the two bare
+  results, the list query and its page and refusals, the default and workbench
+  inspect projections, the transition request, success, and every documented
+  refusal with its mutation state, the `ledger-mutation` fence refusals, report
+  configuration versions 1 and 2, and the report responses including a named
+  view. Every schema fixes its root members exactly and pins the version of its
+  own domain, so a core envelope refuses a namespaced refusal, a version 4
+  envelope, or an extra root member, and a version 1 report configuration
+  refuses a version 2 one. Exactness reaches the members too: an item core must
+  carry both relation lists, because the core view always emits them, and a
+  refusal raised before a commit is established pins its state to `unchanged`
+  rather than admitting the indeterminate state that only an interrupted write
+  can report. The validator is a test-only dependency; the runtime still has
+  exactly one dependency.
+
+### Documentation
+
+- **`docs/host-contract.md` publishes the direct-core host boundary.** One
+  document now states what a UI plugin or other non-agent consumer needs and
+  what it must supply itself: the package resolution seam and the four-part
+  launch — Node.js 20 or later, an absolute Node executable, the absolute
+  `wowbagger.js`, an argument array, and `shell: false`; bounded stdin or a
+  host-created request file, never shell source and never inline unbounded argv
+  JSON; captured stdout and stderr; the owning-host path rule for a worktree, a
+  plain folder, direct SSH, and WSL, with no cross-runtime path guessing;
+  namespace-first response dispatch and the exit table; every advertised limit
+  with its exact value; the once-only dispatch sequence for a lost response; and
+  the seventeen packaged JSON Schemas by domain. It states that a missing
+  executable is a host-level result rather than malformed Wowbagger JSON, that
+  the host owns executable discovery, working directory, timeout, cancellation,
+  process-tree containment, stream caps, and routing, and that Wowbagger will
+  not add automatic transitions, mirrored ledger state, operation identity,
+  remote routing, or a daemon. The full `inspect` read is documented as
+  deliberately unbounded, with the reason. The README, the installed skill, and
+  `SPEC.md` section 10 point at it, and it ships in the npm package.
+- **The public version and lifecycle vocabulary agrees with the runtime.**
+  `SPEC.md` section 10 said core mutation contracts 1 and 2 were defined and
+  that the runtime emitted version 2; it now says 1 through 5 and version 5. The
+  mutation contract's status line said versions 1, 2, and 3 with the runtime on
+  3; it now says 1 through 5 and version 5. `deferred` has been a real status
+  since it shipped, but `SPEC.md` omitted it from the status field, the
+  lifecycle table, the transition table, the terminal-date invariants, the
+  decision-action list, and the terminal-decision table, and the mutation
+  contract omitted the `deferred` date from the lossless core view; all seven
+  now name it, along with the `resolve`, `defer`, and `undefer` decision actions
+  the validator has always accepted. No behaviour changed: these were prose
+  omissions, and the tests that guard them read the vocabularies from
+  `src/lifecycle.js` and `src/validate.js` rather than retyping them.
+- **Response loss is a named contract instead of folklore.** The mutation
+  contract, the adapter contract, the README, and the installed skill now carry
+  the same sequence for a mutation whose response never arrived: dispatch once,
+  never replay, invalidate the inspected revision, reconnect, then re-read the
+  ledger. The mutation contract's new section 10 table separates the outcomes a
+  caller may act on — committed success, proven non-write, committed recovery,
+  unknown publication — from the two that establish nothing, a signalled or
+  timed-out transport and a missing envelope, and states that a later item state
+  never proves that the lost dispatch caused it. Adapter contract section 6.2
+  documents the `mutation_outcome: "unknown"` envelope and its per-command
+  `recovery` object exactly as the adapter emits them, and states that exit 4
+  `revision-conflict` is a proven non-write that is never relabelled response
+  loss. There is no operation ID, durable outcome store, or replay endpoint;
+  adding correlation requires a new contract decision. No command accepts,
+  refuses, emits, or writes anything different. Two conformance vectors now pin
+  the core's own exit-6 `write-outcome-unknown` and `post-commit-recovery-required`
+  envelopes at the adapter's process-outcome seam, taking the adapter vector set
+  to 212 assertions.
+- **The exit tables state where `report` actually lands.** Both contracts filed
+  exit 1 as a bare-result-only condition and exit 3 as every invalid ledger,
+  while `report` answers an invalid ledger, an unreadable input, and a failed
+  publication at exit 1. The mutation contract now carries an exit 1 row naming
+  those codes, lists `report-config-invalid` and `report-view-not-found` in its
+  exit 2 row, and scopes exit 3 to every command except `report`; the host
+  contract's exit 1 and exit 3 conditions say the same. Two guards assert the
+  rows against the codes the runtime emits.
+
+### Changed
+
+- **The report filters by facet groups instead of one value at a time.** The
+  drill-down's single-value mapped-field selects and its All/Ready/Blocked/
+  Ineligible buttons are gone. In their place is one group of checkbox chips per
+  dimension of the open set — Readiness, Status, Kind, and every configured
+  mapped field, so a mapped `class: bug` is a chip rather than a value hidden in
+  a dropdown. Values inside a group are alternatives, groups narrow each other,
+  and the search box is one more condition; every chip states the count it would
+  leave, measured against the search and the other groups but never against its
+  own, so two selections in one group cannot make their siblings read zero. A
+  visible result count, per-chip selected state, and `Clear filters` are new, and
+  opening a Work next or Attention row still clears whatever detached its card,
+  facets included.
+- **The ledger graph filters by lifecycle status.** One chip group above the
+  stage carries the statuses the ledger holds, all selected, with `Select all`
+  and `Clear`. Deselecting a status drops its nodes, every link incident to one,
+  and their labels, reheats the layout in place, and takes a hidden node off the
+  hover card; the roster and node count follow the same selection, and an empty
+  selection draws an empty graph that says so. The legend, the WebGL-less
+  roster, camera interaction, and the no-fetch contract are unchanged, and
+  nothing here reads or writes the ledger.
+
+### Fixed
+
+- **A report failure before publication says so, and never arrives causeless.**
+  An output path the filesystem cannot resolve — a `--out` under a regular
+  file, an unreadable directory on the way to it — was a raw runtime error
+  escaping into the command's catch-all, answered as `report-write-failed` with
+  empty `details` even though nothing had been rendered or replaced. It is now
+  `report-read-failed` with `details.operation` naming which resolution failed,
+  `details.path` naming the path the caller configured or passed, and
+  `details.cause` naming the filesystem's own code. An error no report path
+  throws on purpose still answers `report-write-failed`, because nothing
+  reached the output path, but it now carries `{operation, cause}` instead of
+  `{}`. Every `details.cause` is a bounded token — an error code, or the
+  error's kind when the runtime gave no code — so a publication failure no
+  longer republishes a runtime message, and the paths, credentials, and
+  run-specific values a message carries stay out of the envelope. Atomic
+  publication is unchanged: a report already at the selected path survives
+  every one of these refusals.
+- **An empty named view stops blaming the reader.** A view whose criteria
+  matched nothing rendered the drill-down's `No items match these filters.` and
+  the graph's `No status is selected`, sending a reader to controls that could
+  not bring an item back. A named artifact with no items now states
+  `No ledger item matches this view's criteria.` and, in the graph, that it has
+  nothing to draw — visibly, without waiting for scripting. A report that holds
+  items keeps the filter and status copy, which is the honest answer when the
+  reader is the one who narrowed it, and the base report's bytes are unchanged.
+- **`core-report-response.json` named a member the report never emitted.** The
+  published `ledger-invalid` refusal required `details.validation_errors`,
+  which is the mutation commands' member name; `report` has always emitted
+  `details.errors`. A consumer validating a real refusal against the shipped
+  schema failed on the runtime's own bytes. The schema now states `errors`, and
+  a live invalid-ledger report run is validated against it.
+
 ## 0.1.0-alpha.7 - 2026-08-18
 
 ### Changed
@@ -157,6 +311,44 @@ consolidation. The first tagged release inherits this file.
 
 ### Added
 
+- **`inspect` answers a bounded per-item lifecycle affordance projection.**
+  `inspect --ledger <dir> (--id <id> | --number <n>) --workbench --as-of
+  YYYY-MM-DD --json` returns, from one complete validated ledger snapshot,
+  `result.workbench`: the projection version, the as-of date, the ledger
+  snapshot witness, an `observation` member, a bounded item summary, and one
+  `transition_options` entry for every lifecycle target the native edge table
+  allows out of that item's kind and status. Each option names its target
+  status, its generated decision action or `null`, whether a caller-supplied
+  summary and rationale are required, the minimum legal transition date
+  `max(created, updated)`, its observed enabled state, and the observed
+  precondition issues and multi-item blockers in the exact `transition`
+  vocabulary. A workbench can now show a person which transitions an item can
+  take without duplicating lifecycle logic and without submitting a mutating
+  probe.
+
+  The read is an observation, not a lease, and says so in the response:
+  `observation.authority` is `observed-snapshot` and `observation.rechecked_by`
+  names what a later `transition` rechecks under lock — revision, lock, claim
+  fence, reconciliation, and candidate validation. It writes no item, lock,
+  claim journal, reconciliation log, or Git state, and it takes no lock.
+  `transition` and the projection share one lifecycle definition
+  (`src/lifecycle.js`), and a differential guard dispatches every projected
+  option and every unadvertised target through the real mutation, so an
+  advertised affordance cannot drift from what the mutation does.
+
+  Every variable-size field is bounded and says what it left out: the projected
+  title, the relation lists, each option's issues and blockers, and the related
+  IDs inside an issue. `--workbench` requires `--as-of`, an unpaired `--as-of`
+  is refused rather than ignored, and an `inspect` invocation without
+  `--workbench` is byte-identical to before. `capabilities` advertises
+  `operations.inspect.workbench` and the three exact bounds
+  `max_workbench_title_characters`, `max_workbench_collection_entries`, and
+  `max_workbench_response_bytes`; the core contract version stays 5, and the
+  projection is negotiated by its own `projection_version`. An invalid ledger is
+  `ledger-invalid` at exit 3 with no projection attached, and a projection that
+  would exceed its response bound is refused whole with
+  `workbench-response-too-large` at exit 2.
+
 - **The conformance suite now measures real core outcomes end to end.** A new
   equivalence case, `16-core-outcome-e2e`, carries nine hand-authored scenarios
   that each run the direct real core in one isolated temporary workspace and,
@@ -570,7 +762,7 @@ consolidation. The first tagged release inherits this file.
   every read and every guarded mutation on that ledger, including ones that
   never touch the misplaced item, so the refusal has to say where the item
   belongs. The claim fence is not involved: `claim-verify` reports no finding
-  on such a ledger, refuting the PropertyCompass2 PR #2184 claim that a
+  on such a ledger, refuting an earlier consumer report that a
   root-misplaced item makes the fence report `stale-write-detected` with
   `actual_revision: null`. Fixtures pin both configuration orders — layout
   bound first, and layout bound after the item was already committed at the

package/README.md

@@ -20,8 +20,8 @@ agent to use those guarantees instead of hand-editing your Markdown.
 
 **Start here:** [install the core and set up a ledger](#start-here).
 
-> **Status: alpha, published, and self-hosted.** `0.1.0-alpha.7` is on npm under
-> the `next` tag and on this repository's `v0.1.0-alpha.7` tag. It is the
+> **Status: alpha, published, and self-hosted.** `0.1.0-alpha.8` is on npm under
+> the `next` tag and on this repository's `v0.1.0-alpha.8` tag. It is the
 > version this repository runs its own backlog on. The API is not frozen and the
 > version will move before a stable release.
 >
@@ -39,7 +39,7 @@ agent to use those guarantees instead of hand-editing your Markdown.
 > version is **3**. Three adapter packages ship — Claude Code, Codex, and
 > OpenCode — on one shared engine at adapter contract version 2. Only the Claude
 > Code adapter declares a `supported` platform, Darwin, from a native run of all
-> 210 conformance assertions across all 16 cases. Every other adapter and
+> 212 conformance assertions across all 16 cases. Every other adapter and
 > platform declaration is `unverified`; do not infer support because the CLI
 > starts.
 >
@@ -60,8 +60,8 @@ Install the core CLI, then verify it:
 ```sh
 npm install -g wowbagger@next   # public npm registry
 # or, from this release's Git tag:
-# npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.7
-wowbagger --version         # 0.1.0-alpha.7
+# npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.8
+wowbagger --version         # 0.1.0-alpha.8
 wowbagger capabilities --json
 ```
 
@@ -75,7 +75,7 @@ In Claude Code, add the plugin:
 The plugin drives the installed core rather than bundling one, so a mismatch is
 detectable instead of silent. Its skill reads `wowbagger --version` and
 `capabilities`; it requires the same distribution version as the plugin and core
-`contract_version: 4`. It refuses an absent or incompatible core. It will not
+`contract_version: 5`. It refuses an absent or incompatible core. It will not
 fall back to editing ledger files by hand, because that would bypass validation
 and atomic publication.
 
@@ -253,7 +253,7 @@ two supported install routes:
   registry requires a `latest` tag), so a bare install resolves to the same
   bytes.
 - **git tag** —
-  `npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.7` installs this
+  `npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.8` installs this
   release. Installing at a ref installs the core and every adapter that ref
   carries.
 
@@ -325,7 +325,7 @@ Upgrade the pieces you installed:
 
 ```sh
 npm install -g wowbagger@next                  # public npm registry
-npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.7  # immutable Git release
+npm install -g github:lstutzman/wowbagger#v0.1.0-alpha.8  # immutable Git release
 git pull && npm ci                            # or: a direct checkout
 ```
 
@@ -342,12 +342,12 @@ wowbagger capabilities --json
 ```
 
 The plugin requires its exact core distribution version and top-level core
-`contract_version: 4`. Direct API consumers must check the contract version
+`contract_version: 5`. Direct API consumers must check the contract version
 they support; installed plugin users must also keep the plugin and core
 distribution versions equal.
 
 The shipped adapter selects only adapter contract version 2 and requires core
-contract version 4. The adapter contract and the core contract are separate
+contract version 5. The adapter contract and the core contract are separate
 version domains: the adapter stays at 2 while the core moves to 4. A v1-only
 consumer receives `unsupported-adapter-contract-version`; it does not receive v2
 behavior. The schema-2 transport is available. Ledger migration remains a
@@ -463,8 +463,8 @@ TMPDIR=/tmp node spec/run-adapter-implementation.js --target codex
 TMPDIR=/tmp node spec/run-adapter-implementation.js --target opencode
 ```
 
-The native Darwin and Linux Claude Code reports each pass all 210 assertions across all 16
-cases and report `"status": "pass"`. Codex and OpenCode execute the same 210
+The native Darwin and Linux Claude Code reports each pass all 212 assertions across all 16
+cases and report `"status": "pass"`. Codex and OpenCode execute the same 212
 assertions through the same engine, but both target reports remain `"fail"`
 pending target-specific evidence, and every platform declaration on those two
 manifests stays `unverified`. The Kimi and OpenAI-compatible harness adapters
@@ -705,6 +705,35 @@ Repeating it creates no second commit, so a lost response and a failed commit
 recover the same way. [docs/mutation-contract.md](docs/mutation-contract.md)
 section 13 is the full contract.
 
+### When the response is lost
+
+A mutation you dispatched can lose its response: the process is signalled or
+times out, a stream arrives truncated, or the transport to the machine that owns
+the ledger drops. None of that observes the ledger, so none of it says whether
+the write applied.
+
+Only a complete observed result establishes an outcome. Exit 0 with state
+`committed` is a success; a complete refusal with state `unchanged` is a proven
+non-write; exit 6 `post-commit-recovery-required` says the item is published and
+cleanup remains; exit 6 `write-outcome-unknown` says publication was attempted
+and the visible bytes are indeterminate. Anything else — signal, timeout,
+truncated output, no envelope, no response at all — is unresolved.
+
+Unresolved is answered by one sequence, never a retry: Dispatch once, never
+replay, invalidate the inspected revision, reconnect, then re-read the ledger.
+Re-reading is `validate` plus `inspect` of the ID you already know, compared
+against what you observed before you dispatched. What you read back is current
+ledger state; it never proves that the lost dispatch caused it. A person reviews
+that comparison before any new mutation, and the new mutation is built on the
+current revision, not resent.
+
+Exit 4 is not response loss. A `revision-conflict` proves the write did not run;
+re-inspect and decide again.
+
+There is no operation ID and no replay endpoint, because nothing replays.
+[docs/mutation-contract.md](docs/mutation-contract.md) section 10 is the full
+contract.
+
 ### When the item was changed outside the protocol
 
 An `unauthorized-revision` finding means someone edited the item without going
@@ -771,6 +800,18 @@ graph**. State counts, item cards, filters, grouping, detail levels, terminal
 history, and area-diverse ready batches all remain, demoted below that decision
 surface.
 
+The drill-down filters are **facet groups**: Readiness, Status, Kind, and one
+group for every configured mapped field, each a fieldset of checkbox chips.
+Values inside a group are alternatives and groups narrow each other, so
+`ready` or `blocked` in Readiness plus `bug` in Class means ready-or-blocked
+bugs; the search box is one more condition on the same answer. Every chip
+carries the count it would leave, measured against the search and the other
+groups but never against its own, so two selections in one group cannot make
+their siblings read zero. The result count states how much of the open set is
+showing, and **Clear filters** gives every selection back. A Work next or
+Attention row still reaches its card: opening one clears the facets and the
+search first, because a row that names an item promises the item can be seen.
+
 The evidence layer is inline SVG, drawn at generation time and embedded in the
 file: an aging heatmap, weekly arrivals against completions, throughput with a
 four-week mean, a cumulative flow area, accept-to-complete cycle time, and a
@@ -789,6 +830,14 @@ arrowed, a `parent` edge is curved and unarrowed. Hovering or clicking a node
 opens a card with its number, title, status, age, leverage, and the same
 reasons line the ranked list prints for it.
 
+Above the stage sits one chip group of the lifecycle statuses the ledger holds,
+all selected, with **Select all** and **Clear**. Deselecting a status drops its
+nodes, every link that touched one of them, and their labels together, then
+reheats the layout in place: nothing is reloaded and the ledger is never
+touched. The roster and the node count follow the same selection, and clearing
+every status draws an empty graph that says it is empty rather than quietly
+showing the last one.
+
 The renderer is [`3d-force-graph`](https://github.com/vasturiano/3d-force-graph)
 over Three.js, vendored into `vendor/3d-force-graph/` at a pinned version
 `1.80.0` with its upstream SHA-256 recorded in
@@ -827,6 +876,134 @@ validates them. `complexity` weighs `xs`/`s`/`small` as 1, `m`/`medium` as 2,
 `l`/`large` as 3, and `xl`/`extra-large` as 5; any other value carries no
 weight and is shown as written.
 
+### Named custom report views
+
+A named custom view is a second self-contained report generated from the same
+complete ledger. Every section of it — statistics, **Work next**, **Attention**,
+the evidence layer, the graph, the open-item drill-down, terminal history, and
+the swarm batches — describes one configured subset, so the file is honest to
+share as a scoped report. Excluded items are absent from the bytes rather than
+hidden by a stylesheet. The base report stays available and unchanged.
+
+Report configuration `report_version: 2` accepts every version 1 member and adds
+one more, `views`. A version 1 configuration keeps generating its base report
+unchanged, and a version 2 configuration with no view selected publishes the
+same base report from its inherited base members:
+
+```json
+{
+  "report_version": 2,
+  "repository": { "name": "Example repository" },
+  "title": "Ledger report",
+  "output": "../../ledger-report.html",
+  "fields": {
+    "area": "/priority_area",
+    "complexity": "/complexity",
+    "class": "/class",
+    "security": "/security"
+  },
+  "views": {
+    "security-blockers": {
+      "title": "Security blockers",
+      "output": "../../reports/security-blockers.html",
+      "filters": {
+        "readiness": ["blocked"],
+        "status": ["backlog", "in-progress"],
+        "kind": ["task"],
+        "fields": {
+          "class": ["bug"],
+          "security": ["high", "critical"]
+        }
+      }
+    }
+  }
+}
+```
+
+Generate one view by name:
+
+```sh
+wowbagger report --ledger <dir> --view <name> --as-of YYYY-MM-DD --json
+```
+
+One invocation generates one artifact; no flag generates them all. `--out <file>`
+overrides the selected output for that invocation, view or base alike, and the
+configured paths are still validated when it is present.
+
+A view name is a portable identifier matching `^[a-z][a-z0-9-]{0,63}$`. Names are
+case-sensitive and `views` holds at most 64 views. Each view takes exactly
+`title`, `output`, and `filters`. Unknown members fail closed.
+
+`filters` takes exactly `readiness`, `status`, `kind`, and `fields`, and at least
+one of `readiness`, `status`, `kind`, or `fields` must be present. The semantics
+are the drill-down's: **OR within one filter group; AND across groups**, so
+`readiness: ["blocked"]` with `class: ["bug"]` means blocked bugs. `readiness`
+takes `ready`, `blocked`, or `ineligible`; `status` takes `triage`, `backlog`,
+`in-progress`, `done`, `killed`, `archived`, or `deferred`; `kind` takes `task`
+or `epic`.
+
+A `fields` key must also be a configured report field. Each field filter is a
+non-empty array of unique JSON strings, finite numbers, or booleans, and matching
+preserves JSON scalar type and value: stringification is not equality, so a
+mapped `2` does not answer a filter for `"2"`. An item carrying no mapped value
+for a field matches no value selected for that field. No title-text inference,
+regular expression, arbitrary JSON pointer, or body search belongs in a view
+filter.
+
+Wowbagger validates the complete ledger and computes readiness against the
+complete ledger before it filters, so excluding a blocker never makes blocked
+work read as ready. What a view derives from its retained set does change:
+statistics, ranking leverage, epic enablement, evidence, attention, graph
+membership, and the swarm batches are all view-scoped, so the same item can
+report smaller numbers here than in the base report. That is why the artifact
+names its view and its fixed criteria at the top. A retained item that names an
+excluded dependency, parent, blocker, or related item still prints that item's
+number instead of a raw ULID, and the excluded item gets no row, no graph node,
+no history entry, and no hidden payload.
+
+Inside the file, the interactive facets and the graph status chips narrow the
+retained subset further and can never reveal an excluded item. **Clear filters**
+restores the complete custom-view subset, never the base ledger.
+
+The base output and every view output must be pairwise distinct after path
+resolution, and each must resolve outside the ledger under the same no-follow
+containment rule the base output already obeys. A colliding or contained output
+is `report-config-invalid` before anything is rendered, `--out` present or not.
+
+A named success adds exactly one member to the existing report result,
+`result.view`, and its `item_count` and `ready_count` describe the filtered
+subset. A base report's result gains no `view` member:
+
+```json
+{
+  "ok": true,
+  "command": "report",
+  "contract_version": 5,
+  "result": {
+    "report_version": 2,
+    "as_of": "2026-08-21",
+    "output": "/absolute/reports/security-blockers.html",
+    "item_count": 12,
+    "ready_count": 0,
+    "view": "security-blockers"
+  }
+}
+```
+
+`--view` requires `report_version: 2`. A missing or unknown name is
+`report-view-not-found` at exit 2 and leaves every existing output untouched. An
+invalid filter value, an unmapped `fields` key, and a colliding output are
+`report-config-invalid` at exit 2. An empty matched subset is not a failure: it
+publishes a valid report with zero items and explicit empty-state copy. Failed
+publication preserves the prior artifact, so never read an existing output as
+fresh. `wowbagger capabilities --json` advertises the whole surface at
+`result.operations.report`, so no consumer has to probe by generating a file.
+
+A custom view is scoped output and **not a security boundary**: it applies no
+redaction and no access control, and the artifact states plainly that it is a
+filtered subset of the named repository ledger. Automation reads the JSON result,
+never the generated HTML and never human output.
+
 This repository keeps its report configuration in
 `ledger/.wowbagger/report.json`. Generate the ignored local report with the
 current UTC date:
@@ -846,6 +1023,7 @@ they disagree with anything above:
 | [docs/mutation-contract.md](docs/mutation-contract.md) | Response domains and dispatch, capabilities, inspect, create, transition, patch, the extension declaration, the frontmatter ownership table, errors and recovery, and commit-per-mutation. |
 | [docs/work-claim-contract.md](docs/work-claim-contract.md) | Provisioning, claim CAS rules, claimed publication, reconciliation, revision adoption, and the difference between strict fenced and merge-coordinated backends. |
 | [docs/adapter-contract.md](docs/adapter-contract.md) | The harness adapter boundary: negotiation, forwarding, guards, approval, and honest outcome mapping. |
+| [docs/host-contract.md](docs/host-contract.md) | The direct-core host boundary: package resolution, the shell-free process tuple, bounded transport, owning-host paths, response dispatch, advertised limits, and the packaged JSON Schemas. |
 | [docs/openai-compatible-integration.md](docs/openai-compatible-integration.md) | What an OpenAI-compatible host can do today, and what a compatibility claim would require. |
 | [docs/schema-2-migration.md](docs/schema-2-migration.md) | The quiesced schema version 1 to 2 migration runbook. |
 | [skills/wowbagger/SKILL.md](skills/wowbagger/SKILL.md) | The shipped agent instructions. |
@@ -1011,10 +1189,10 @@ It is the durable work ledger beneath those systems.
   **Shipped: the policy-input contract and the report's mapped fields keep
   consumer vocabulary out of the schema.**
 - Stabilize the machine-readable command contract and compatibility evidence.
-  **In progress at core contract version 4; the version is not frozen.**
+  **In progress at core contract version 5; the version is not frozen.**
 - Ship Claude Code and Codex adapters. **Claude Code, Codex, and OpenCode
   packages share the version 2 engine; the Claude Code manifest declares Darwin
-  `supported` after passing all 210 native assertions. Other adapter targets and
+  `supported` after passing all 212 native assertions. Other adapter targets and
   platform declarations remain unverified.**
 - Document the generic tool contract for other agent harnesses. **Shipped as the
   adapter contract and the OpenAI-compatible integration guide.**
@@ -1023,8 +1201,8 @@ It is the durable work ledger beneath those systems.
   publication, Git reconciliation, and explicit revision adoption. It
   deliberately reports `safe_exclusive_dispatch: false`; direct writes and other
   uncoordinated paths remain bypasses.**
-- Treat any PropertyCompass adoption as a later, separately-scoped consumer
-  project. **Recorded as its own ledger item; not a wowbagger deliverable.**
+- Keep consumer-specific adoption and migration outside the core Wowbagger
+  project. **They are not Wowbagger deliverables.**
 
 ## License
 

package/adapters/claude-code/wowbagger-adapter.json

@@ -4,7 +4,7 @@
   "adapter_version": "0.1.0",
   "adapter_contract_versions": [2],
   "bootstrap_wire_version": 1,
-  "required_core_contract_version": 4,
+  "required_core_contract_version": 5,
   "entrypoints": {
     "describe": {
       "kind": "command",

package/adapters/codex/wowbagger-adapter.json

@@ -4,7 +4,7 @@
   "adapter_version": "0.1.0",
   "adapter_contract_versions": [2],
   "bootstrap_wire_version": 1,
-  "required_core_contract_version": 4,
+  "required_core_contract_version": 5,
   "entrypoints": {
     "describe": {
       "kind": "command",

package/adapters/opencode/wowbagger-adapter.json

@@ -4,7 +4,7 @@
   "adapter_version": "0.1.0",
   "adapter_contract_versions": [2],
   "bootstrap_wire_version": 1,
-  "required_core_contract_version": 4,
+  "required_core_contract_version": 5,
   "entrypoints": {
     "describe": {
       "kind": "command",