2,559 commits

This branch

This branch

All branches

Author	SHA1	Message	Date
Joshua Belke	338c988032	docs: the ignored-relay-test count is 53, and a fourth author has now got it wrong ... a9b30ea27 added two Postgres-gated tenancy tests and left the number at 51 in both the Justfile and the CI comment beside the same selection. Derived from the binary rather than from grep: 53. The Justfile comment already told the next reader to re-derive rather than trust it, and listed three authors who had not. It now lists four, including this campaign. Leaving the tally visible is the point -- a hand-maintained number that keeps being wrong is evidence the comment wants a gate, not a bigger warning. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 04:53:55 -04:00
Joshua Belke	a9b30ea276	test(relay): prove the bus tenancy binding ACCEPTS, not just that it refuses ... `meridian-f43l` closed a cross-tenant injection path by making a below-floor bus event's tenancy come from its row in the system of record rather than from the publisher-chosen key expression. Every refusal on that path was covered without infrastructure; `CommunityBinding::Bound` was covered by code inspection only, because the row it asks for cannot exist without Postgres. That is the wrong way round for a security control: a binding that refused everything would have passed the entire existing suite. Three tests, in the crate's `--lib` module because `fan_out_pubsub_event_with` — the only entry point that reaches the `Reverify` arm without a Zenoh session — is `pub(crate)`, and gated `#[ignore = "requires Postgres"]` so `just test-relay-db-run` (CI's "Relay DB/Redis gate") runs them and the infra-free suite stays infra-free: - `reverify_delivers_the_community_whose_row_binds_the_event_and_no_other`. One event, one signature, one channel UUID, two real communities. Under A, where the event's row exists carrying the routed channel scope, it is re-verified and delivered. Under B — a real community holding a real *open* channel with the same UUID and a subscriber on it, which is the shape an attacker gets for free from caller-chosen channel ids and a `(community_id, id)` primary key — the identical bytes on the identical topic are refused. Without the delivered half, "refused" would be equally consistent with a binding that refuses everything. - `a_relay_derived_channel_kind_is_bound_by_its_row_scope_and_nothing_else`. `bind_scope` answers `Silent` for reactions, deletions, gift wraps, 9007 and 44100/44101, so for those kinds the routed channel is checked in exactly one place: `stored.channel_id == routed_channel`. The stream-message pair cannot reach that arm — its refusal is decided before any lookup and its acceptance has tag and row agreeing — so this test is the one that fails when the comparison is deleted. Verified: with it deleted the pair still passes and this test fails. - `unknown_tenancy_refuses_and_withdraws_the_replay_id_that_unbound_spends`. A database error refuses rather than accepts, and is told apart from a decided `Unbound` by the replay set: `Unbound` spends the id, `Unknown` withdraws it so one Postgres blip is not a ten-minute hole. Needs no live database — `Unbound` is reached by an ephemeral kind and `Unknown` by a pool pinned at an address nothing listens on, so it runs in the default suite. The seen-set assertion is also what proves the refusal came from the tenancy check rather than from the visibility gate failing closed one step later. Mutation-verified in both directions: forcing `Bound` fails the paired refusal and the `Unknown` test; forcing `Unbound` fails the acceptance. The `--lib` pool is untouched. `test_state` still resolves through `test_config` and connects lazily; `postgres_state` is a sibling builder that resolves `meridian_test_db::disposable_url()` and connects eagerly, failing loudly rather than skipping, the same repair `api::operator` got in meridian-wxqw. Redis stays unconnectable for all three — the cross-node *receive* path publishes nothing, and a live one would pull these into meridian-h0tg's non-exiting test binary. The seeded rows are removed on the way out, because that gate's database is shared and nothing resets it. Refs: meridian-f43l Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 04:47:22 -04:00
Joshua Belke	c5afeed1c1	docs(deploy): name the enforcement point for the chart version rule ... The bullet said to bump Chart.yaml on any chart change and nothing checked it, which is the repo's own no-vocabulary-without-an-enforcement-point failure sitting inside the deployment contract. b6443a823 then shipped an entire alert group under an unbumped version, and it was caught by a human reading two files three commits later. Worth recording why it got that far: a deploy/charts-only push matched no glob in lefthook pre-push, so zero local hooks ran on it. The guard is now in just check, in CI, and in pre-push. Also records what is deliberately NOT guarded -- tests/, ci/, README.md -- because demanding a bump for a test-only edit teaches reflexive bumping, which is the same defect wearing a hat. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 04:34:11 -04:00
Joshua Belke	043361afcd	ci(charts): enforce the Chart.yaml version bump instead of asking for it ... deploy/AGENTS.md has said it plainly for a long time: "Bump `Chart.yaml` `version` on any chart change. ArgoCD tracks chart versions; an unbumped chart deploys stale templates." Nothing checked it. helm lint does not, helm unittest does not, check-alert-runbooks does not, and the failure is both silent and remote -- the chart renders, the suite passes, CI is green, and the cluster keeps serving the previous templates. Commit b6443a823 is the worked example. It added the entire meridian-relay.bus-reachability group plus MeridianBusPeersUnreachable to templates/prometheusrule.yaml and left Chart.yaml at 0.1.13, so a new alert was doubly unreachable: no promtool case proving it could fire, and a chart version that did not contain it. A human reading two files caught it three commits later (meridian-8s3s). The contract is differential -- "this changed without that changing" -- which is unusual here, because every other guard in scripts/ reads the current tree. Two diff-shaped placements were considered and rejected: - a merge-base diff inside `just check`. There is no trustworthy baseline. The root contract forbids branches, so work lands directly on a constantly-rebased `main`; a merge-base with origin/main is not a release boundary, and in a fresh or shallow checkout it does not exist at all. A guard that invents its baseline reports whatever the local ref happens to be. - a CI-only diff against the PR base. The baseline is real there, but it is only real on pull_request, and this repo pushes to main. It would also be invisible to `just ci` and to the pre-push hook, which is where this repo prefers to catch things -- and helm-chart.yml, the one workflow that already touches charts, is `paths`-filtered on pull_request, which is precisely the conditional gate that does not run when it matters. So the baseline is checked in instead, the same shape as scripts/n-minus-one-pins.json and .settings/stellar/snapshot.json: scripts/chart-version-manifest.json records, per chart, the sha256 of every file that renders into a cluster against the version they were last recorded at. Any edit to templates/, crds/, values*.yaml|json, Chart.yaml or Chart.lock moves a digest, and a moved digest without a higher `version` is a hard failure naming the file. No diff, no baseline branch, works in `just check` and in a shallow clone. Two normalizations make the guard say what it means. Chart.yaml is hashed with its top-level `version:` line removed, so a bump with no template change stays silent while an edit to `dependencies:` or `appVersion` still demands one; Chart.lock is hashed without `generated:`, which `helm dependency build` rewrites without changing what deploys. tests/, ci/, examples/ and README.md are deliberately outside the set -- none of them reach a cluster, and demanding a bump for a test-only edit teaches people to bump reflexively, which is the same failure wearing a hat. `--write` is not an escape hatch: it refuses to record a chart whose rendered files moved while `version` did not, printing the same message the check does. The only route to a green tree is the bump. Wired three ways, because a guard in one place is a guard someone skips: `just check` (via check-chart-version-bump), the ci.yml guards job, and a new lefthook pre-push entry -- before which a `deploy/charts/**`-only push matched no glob at all and ran zero local hooks, which is how b6443a823 got out. scripts/test-chart-version-bump-guard.sh is the "prove it fires" half. It asserts the exit codes rather than the prose: refused with exit 1 on a template edit and on a values.yaml edit, `--write` refusing to launder either, exit 0 on a Chart.yaml-only bump and on a tests/ edit, every chart under deploy/charts/ actually present in the manifest, and -- when history is deep enough to reach it -- b6443a823 replayed against its own parent's baseline and refused for the unbumped 0.1.13. Covers all three charts: meridian@0.1.14, meridian-control-plane@0.1.1, meridian-push-gateway@0.1.0, 50 rendered files. No file under deploy/charts/ is touched by this commit. Refs: meridian-8s3s Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 04:30:21 -04:00
Joshua Belke	610b9cac2e	docs: withdraw the >=4 KB crossover — shared memory was on for every measurement ... Both SHM keys default true in Zenoh 1.8, the eclipse-zenoh wheel IS built with the shared-memory feature, and transport_optimization's threshold is 3,072 B. So every measured payload at 4 KB and above took a POSIX-SHM fast path -- one the relay build cannot take, because shared-memory is not in its zenoh feature list -- while the Redis side had no equivalent. The error points toward Zenoh. RELAY_BUS_SCALING.md's own bullet said "Nothing about shared memory. SHM was not enabled." That was false, and nothing could have caught it: the static contract checked transport.shared_memory.enabled and was blind to the second switch beside it. This adds that check. The "Router mode prices the Docker boundary" reading goes with it. SHM works host-to-host and cannot cross into the Docker VM, so an unknown share of the peer-vs-router divergence at >=64 KB is the SHM path dropping out rather than the boundary appearing. Both readings are unlicensed until re-measured under the shipped posture. Below 4 KB stands, including the 256 B verdict that failed the >=5x gate: 256 B is well under the SHM threshold, and gossip's extra transports cost the measured process work rather than saving it. Worth stating plainly, because it is the second time: the 0A.2 result has now been invalidated twice for two unrelated reasons -- unmatched publish semantics, then transport posture -- and neither was visible in the numbers. A bus measurement is not licensed by its spread. It is licensed by its posture being pinned, read back, and stamped beside the result, which is what af4b92eba now does. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 00:54:18 -04:00
Joshua Belke	af4b92eba4	perf(bus): measure the posture the relay ships, and prove it took ... Every Zenoh figure this repo has taken was measured with `scouting/multicast/enabled: false` and nothing else set. Three keys the relay pins were left at their upstream `true`, and one of them moved numbers. `transport.shared_memory.enabled` and `transport.shared_memory.transport_optimization.enabled` BOTH default true, and the `eclipse-zenoh` wheel is built with the `shared-memory` feature. Verified on this binding: with both unset, `zenoh_transport::unicast::manager` logs `shm: Some(TransportShmConfig { .. })` and `zenoh_shm` allocates the 16 MiB pool on the first >=3 KB put; with both false it logs `shm: None`. So every peer-mode payload at or above the 3,072 B `message_size_threshold` -- 4 KB, 16 KB, 64 KB, 256 KB, which is the entire upper half of the crossover curve -- travelled through POSIX shared memory, on a path the relay build cannot take at all because `shared-memory` is not in its `zenoh` feature list. Gossip was the second: measured with one publisher and four subscribers, gossip autoconnect opened 24 transports where the shipped posture opens 8. The harness now applies the relay's embedded posture key-for-key from `bus-peer.json5`, READS EVERY KEY BACK (zenoh 1.9/1.10 accept `routing.peer.mode` and silently drop it, so a clean insert proves nothing), prints the whole posture once per run, and stamps a digest beside every table. A unit test pins the table against the fixture so the two cannot diverge again. Arms: the deployed shape is `client` against a real zenohd, so that arm runs first and `--zenoh-session-mode` defaults to `client`; peer-direct arms are labelled a transport floor rather than a routing path; `peer` + `--zenoh-connect` is refused by name as the meridian-2m45 trap. `--zenoh-posture legacy-0a2` and matrix arms J/K reproduce the old posture so the delta is measured, not argued -- the same role arm H plays for the superseded synchronous Redis publisher. The deployed router config left `transport_optimization` unset while the tested fixture pinned it false. It is fixed, along with two more drifts the new check found (`listen.exit_on_failure`, `timestamping.drop_future_timestamp`), and `daemon-config-check.sh` now runs `deploy/compose/zenoh/zenohd.json5` through the same daemon and diffs its EFFECTIVE config against the fixture's. Differences are declared with reasons; anything undeclared fails, and a declared difference that no longer exists fails too. Reverting the fix reproduces exit 1. Phase 0A.2's figures are marked, not deleted: which survive the posture change (256 B FAIL, the sub-2 KB rows, the Redis-only arms, the Zenoh-vs-Zenoh ratios) and which must be re-taken (the whole >=4 KB crossover, the express table above 4 KB, and the Docker-boundary reading of the peer-vs-router divergence). No measurement was run. Host load ~30. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 00:48:59 -04:00
Joshua Belke	445b241202	test(charts): make every bus alert prove it fires, and prove what it ignores ... Nine MeridianBus* alerts have never fired. `just check-alert-runbooks` proves an alert references a declared metric and has a runbook row; `helm unittest` proves the rule renders. Neither evaluates the expression, so an alert that can never fire passes both and reads as coverage. `tests/prometheus_rules.promtool.yml` is the only file that runs real Prometheus against a synthetic series. Two of the nine were not in it: - MeridianBusPeersUnreachable had no case at all. Its author said so when it landed: validated by the alert-to-metric guard, pinned by helm assertions, never evaluated. - MeridianBusReverifyRateHigh had only a below-threshold negative, so nothing had ever shown the expression could evaluate true. Eight cases added, and each deliberate exclusion is now asserted from the side that would survive its deletion: - The `count(max by (pod) (meridian_zenoh_session_open == 1)) > 1` clause is the one a simplification deletes first. `a single pod with no peer to reach never pages` is the two-pod firing case with the second pod removed: every per-pod conjunct satisfied, silent to 40m. Dropping the clause, or weakening it to `> 0`, pages every single-pod install continuously. - MeridianBusEventsRejected's `lane!="Q0"` was only ever asserted against a flat-zero Q0 series, which no expression could fire on. Q0 rejects now rise for twenty minutes while the events warning stays silent. - MeridianBusTenancyUnbound's `reason="community-unbound"` was only asserted silent at 4m, where its own 15m wait hid it regardless of the selector. - MeridianBusReverifySeenSaturated now also holds `cause="explicit"` above the size cause on a pod that must stay silent. The `for: 15m` over `[15m]` claim is corrected. A one-shot step is visible to `increase(...[15m])` for 13m, not 15m: Prometheus 3 range selectors are left-open, so the pre-step sample leaves the window two scrapes early. The burst therefore does not merely fail to fire at 18m — it cannot fire at any eval time, and the case sweeps to 31m to say so rather than reading as "the wait has not elapsed yet". Window and wait are coupled: widening to `[18m]` while leaving `for: 15m` would page on a healthy failover. Chart bumped 0.1.13 -> 0.1.14. The bump covers this change and repairs an omission: b6443a823 added the bus-reachability group to prometheusrule.yaml without bumping, so ArgoCD would have kept deploying templates that do not contain MeridianBusPeersUnreachable at all. Every case was mutation-tested. Eleven mutants — dropping each PeersUnreachable conjunct and the fleet gate, weakening `> 1` to `> 0`, dropping `lane!="Q0"`, `reason="community-unbound"`, `reason!="community-unbound"`, `cause="size"`, `decision="reverify"`, lowering the rate threshold, and widening the replay window to `[18m]` — were each killed by the intended case. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-21 00:32:04 -04:00
Joshua Belke	8256c6e09c	docs(relay): record the reachability split, and why it must never gate ... Two ticks ago this file learned that bus_ready() is liveness, not reachability. That was half the story: it said what the field is not, without saying where the missing signal lives. It now exists as bus.reachability, reported beside bus.ready and explicitly carrying gates_readiness: false, backed by two independent witnesses -- one on the declaration plane, one on the data plane. The load-bearing half is the prohibition. A single-pod deployment has no peer to witness it, and an_isolated_pod_is_indistinguishable_from_a_lone_one proves the discriminator does not exist at session scope at all: every observable is byte-for-byte identical between a healthy lone pod and a cut-off one. So gating readiness on reachability would hold a correct single-pod deployment closed -- worse than the overclaim it fixes. The discriminator lives one layer up, in an alert whose count(...) > 1 clause is what stops it firing on a lone pod. Written here because the next person to "tighten" readiness will read this file, not the bead. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 21:05:45 -04:00
Joshua Belke	b6443a823b	fix(bus): report Zenoh reachability separately instead of overclaiming ready ... `meridian_zenoh_ready` was 1 and `/_readiness` `bus.ready` was true on both pods for the entire period during which cross-pod delivery was completely broken (meridian-ty6l). The cause is structural: `probe()` publishes on the session's own health key and is satisfied by that same session's subscriber, which Zenoh delivers without involving the router at all (`zenoh-1.8.0/src/net/runtime/mod.rs:325`). The probe proves the session object is alive and proves nothing about reachability. The obvious fix -- require a witness for readiness -- is wrong, because a single-relay deployment has no peer to witness it and would be held closed for ever. So the signal is split rather than tightened: - `bus_ready()` / `meridian_zenoh_ready` keep exactly their conditions and are now named as liveness in code, in `/_readiness` and in the runbook. Redis and Shadow paths are untouched: Shadow still answers from Redis alone. - A separate `ZenohReachability` is reported and gates nothing. It carries two router-external witnesses that fail independently. The declaration plane is `Publisher::matching_status()` on a publisher restricted to `Locality::Remote`, which `net/runtime/mod.rs:326` answers by `matches.values().any(|dir| dir.id != face_id)` -- every face but our own, and for a client session those faces are populated only by declarations the router forwarded. The data plane is the health subscriber widened from `_health/<own-zid>` to `_health/*`: a sample keyed to an id this process does not own cannot have been delivered locally. The peer map is bounded in both directions, since its key now arrives over the bus. - `meridian_zenoh_received_total` is registered at 0 for all eleven lanes at startup, and every new series likewise. An absent series and a zero series are the same picture on a dashboard and opposite facts, and the live re-probe hit exactly that ambiguity. `MeridianBusPeersUnreachable` pages when a pod reports ready, sees no peer on either plane, and more than one pod in the namespace has an open session. That last clause is the whole design: no single session can tell "alone" from "cut off", so the discriminator is the fleet's own pod count. A one-pod deployment never trips it. Listed in `MUST_BE_ALERTED` under a second, written-down criterion -- a metric whose failure to *move* is the fault -- with a runbook section and an inventory row, in this commit rather than a later one. The reproduction test keeps asserting the absence of delivery and now also asserts that reachability reads zero on every field while it happens. Its counterpart, `an_isolated_pod_is_indistinguishable_from_a_lone_one`, stands up one relay against a real zenohd and proves it reaches readiness with no witness -- the evidence that this must not gate. Verified: `just zenoh-check` 0, `just zenoh-router-check` 0 (3/3 against a live eclipse/zenoh:1.8.0), clippy `-D warnings` with `--features zenoh` 0, `just fmt-check` 0, `just check-alert-runbooks` 0 (35 alerts / 204 metrics), `just check-unwrap-budget` 0, `cargo test -p meridian-relay --lib` 889 passed. Refs: meridian-ty6l Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 21:03:51 -04:00
Joshua Belke	051cd966b0	docs(mips): adopt MIP-RT and withdraw the on-chain payments scope ... Protocol council, 2026-08-20, parallel mode, five seats — Protocol Steward (chair), Interop Skeptic, Enforcement Auditor, plus Revocation Guardian and Second-Node Skeptic borrowed at the charter cap of two. Each seat received only its charter row, the decision sentence and the evidence. Call: approve with conditions, 5/5 concurring, no seat blocking at close. **Withdrawn, not deferred — and none of the prior call's conditions fired.** `meridian-ded` approved on-chain payments on 2026-08-02 against three reversal conditions: a competing upstream payments NIP merging, a measured fake-claim burden, and an upstream x402 Kaspa scheme. All three verified NOT fired. The reversal proceeds on different grounds and the record says so plainly: the requirement was never present, rather than refuted — no counterparty outside the issuing community, no reachable public chain from an exercise network. A scope held "deferred" on conditions that never fired is inventory with no owner or expiry, and it keeps a chain-settled second system of record alive as a live option. The chair initially **blocked** the withdrawal limb, because "withdrawn" was being chosen blind to the one trigger the prior council said would point the other way: the NIPs mirror was pinned at `8228afb5`, dated 2026-07-31 — *before* the call being reversed. Lifted only after fetching refs (working tree still pinned, confirmed by `rev-parse`) and re-running the sweep: `origin/master` = `656cecc7` (2026-08-08), delta two commits touching only `29.md` and `47.md`, zero hits tree-wide for `x402|kaspa|erc-20|eip-681|eip-3009|stablecoin`. `git ls-remote` returned the same head on 2026-08-20, so the twelve-day gap is upstream quiet, not stale data. That check also revealed it is a **weaker instrument than it looks**, which is why `docs/AGENTS.md` now carries the rule rather than the anecdote: upstream `c538775` moved NIP-47's authorization models and wallet extensions out of `nostr-protocol/nips` entirely, into `nostr-wallet-connect/nwc` — 332 of 351 changed lines — behind an open numeric `extensions` namespace that nothing here mirrors. A future payment scheme can now merge upstream without ever appearing in the grep that just cleared this decision. So a scan record must state the mirror's commit hash *and* its commit date separately from the scan date, and name the surface it actually covered; the mirror is merged-state only and cannot see an open PR. Three amendments the council made to the spec, all at DRAFT deliberately because deferring any of them forces a renumber: - **Kind `50416`, a consumer-signed spend hold**, accepted before serving. Without it `50412` is a post-hoc self-report by the party that gained the resource, and ingest rejects an overdraft only after the GPU-seconds are already gone. - **The epoch rule is rewritten.** Wire `epoch` is advisory and ignored on input; the relay assigns it per `(community, holder, class)`; it is absorbing at *any* epoch, following the MIP-MS pattern, resolved fail-closed. Without this a peer transfer at `epoch n+1` reinstates a holder reclaimed at `epoch n` — the monotonic-revocation law, live on one relay today. - **The arbiter is registered at scaling axis A1**, with `SELECT … FOR UPDATE` in the same transaction as the ledger append. MIP-RT is a **non-monetary internal resource instrument, not a payment rail**, and the support matrix now says exactly that: nine payment rows keep `Reject` with strengthened rationale, an MIP-RT row is added, and there is **no NIP-CP row** — that was the withdrawn bead's ask. The register row cites `meridian-8t6h` (Phase 1), not the closing Phase 0 bead: `just check-mips` requires a non-terminal row to name a live bead, so pointing it at `meridian-yzr6` would turn the gate red the moment that bead closed. Bead created and row repointed before closing, not after. Verified: `check-mips`, `check-architecture-map`, `check-kinds`, `check-feature-specs`, `check-external-copy` all exit 0. `check-stellar` and `check-gauntlet` exit 1, both pre-existing and provably not from this work — `check-stellar`'s findings are byte-identical to a baseline captured before any edit, and `check-gauntlet` fails on F001/F003 marked open against beads already closed in the committed export at HEAD. Beads: meridian-yzr6 (Phase 0), meridian-grxu (minutes), meridian-8t6h (Phase 1) Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 18:34:48 -04:00
Joshua Belke	7c630a61cf	feat(ci): refuse the two ReductStore Zenoh omissions that work when wrong ... From v1.19 the bytes tier joins a Zenoh network natively — a subscriber for writes, a queryable for reads — configured entirely by `RS_ZENOH_*`. Two one-token omissions in that environment each convert it into something DIAGRAM.md refuses by name, and neither goes red: - Point `RS_ZENOH_SUB_KEYEXPRS` or `RS_ZENOH_QUERY_KEYEXPRS` anywhere that overlaps `meridian/v1/**` and one string buys a second durable log AND a second read path — R2 and R3, the arrival R9 names. - Leave `mode=` out of `RS_ZENOH_CONFIG` and it inherits Zenoh's own default of `peer`, so a storage box becomes a routing peer transiting between communities — R4, where Law 2 answers "Leaves. Always." Records land and queries answer in both cases, which is why this is a gate rather than a review item, and why it lands before any Zenoh wiring exists to guard. Overlap, not string match. `**`, `meridian/**`, `meridian/*/**`, `**/k/9` and `meridian/v1` all reach the event key space without spelling it, so the core does chunk-wise keyexpr intersection over `**`/`*`/`$*`; `meridian/artifacts/**` and `meridian/v2/**` pass. `RS_ZENOH_CONFIG_PATH` is resolved and read, an unresolvable path being a finding rather than a skip, and an unreadable value (a Helm template, a `${VAR}` with no literal default) is reported as `unverifiable-value` — explicit denial, never a silent empty result. Nothing in tree sets `RS_ZENOH_*` yet, so the guard would pass vacuously. The contract test therefore pins its *reach* as well as its verdicts: the scan set still contains `docker-compose.yml`, `docker-compose.override.yml.example` and `.env.example`, still reaches `deploy/` and `REMAPPING/cicd/`, and the enumerate-read-refuse path joins up end to end in a throwaway repo. One bug found by staging rather than by running: the guard scans tracked files via `git ls-files`, and its own contract test carries both refused values inline as the assertions that give it teeth. Untracked, the test was invisible to the scan and everything passed; committed, the guard would have eaten its own test corpus and failed on first run. Excluded by exact path — not by a `scripts/` prefix, so a real config under `scripts/` is still scanned. The "default scan of the tree is clean" assertion the test already carried is what will catch this class next time; it simply could not fire before the file was tracked. Markdown is deliberately not scanned: prose legitimately names these variables while forbidding a value, so the guard is assignment-anchored and config-file-scoped. Verified: four bad fixtures exit 1 and the good fixture exits 0 individually; `node --test` core suite 41/41; contract test 22 assertions; `just check-reductstore-zenoh` exits 0 with the guard staged, so the post-commit state is what was measured. Reachable from `just ci` via `ci -> check -> check-reductstore-zenoh` (confirmed with `just --dry-run ci`, which emits all three guard lines; the full multi-minute `just ci` was not run). Bead: meridian-f26n Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 18:33:55 -04:00
Joshua Belke	c2189f19ea	feat(mobile): bundle preview-features.json as a Flutter asset (slice 0a) ... Recovered from `3725528b5`, which was stranded. `meridian-jdxp.2.1` was closed on 2026-08-18 with "Integrated 3725528b5 on conductor tree", but that commit is contained by **no branch and no remote ref** — it was reachable only from the detached worktree's HEAD at `R2D2-MERIDIAN-worktrees/client-pilot`. `git merge-base --is-ancestor 3725528b5 HEAD` exits 1 and `git branch -r --contains` is empty, so a closed bead's verified work was never on the shared branch. This is the failure the root contract names: to verify a commit landed, ask `git branch -r --contains`, not the local tree. Content is `3725528b5` verbatim — pubspec asset entry, the byte-identical `assets/preview-features.json`, the `preview_features_asset.dart` load helper and its test — with original authorship and date preserved. One conflict, in `REMAPPING/meridian-mobile/AGENTS.md`: both slices edit the `lib/shared/` ownership row. Resolved to slice 0b's line, which is a strict superset ("load helper + manifest parser" vs "load helper"). Verified after the merge, not before: the two slices' suites run together green — `flutter test --no-pub test/shared/features/` exits 0 with 35 tests, including 0a's byte-identity assertion against the current repo-root `preview-features.json`, so the bundled asset has not drifted in the two days it sat unlanded. `just mobile-check` exits 0. Bead: meridian-jdxp.2.1 (closed; work now actually on main) Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 18:33:40 -04:00
Joshua Belke	4366eb5dda	feat(mobile): pure preview-features manifest parser (slice 0b) ... Mobile had no feature-flag system at all, so `platforms: [desktop, mobile]` in `preview-features.json` was a declaration the Flutter build could not honour and Pulse and Forum rendered ungated. This is the pure parser half: no Riverpod, no widgets, no call sites. Slice 0c wires the provider. The four rules the bead names, and why they are not arbitrary: - Unknown id fails **OPEN**. The manifest lists only previews, so inside a manifest that validated, an absent id means "graduated" — a stale gate must never hide shipped UI. - Malformed manifest fails **CLOSED**, overrides included. A failed parse yields the same empty table, but there absence is an artifact of the failure and carries no information. This is desktop's `manifestParsed` fix (`manifest.ts` / `resolveWithManifest.ts`), not reintroduced in Dart. - `platforms` omitting `mobile` resolves false and outranks an override. - `override` beats `defaultEnabled` beats `false`. So the fail-open/fail-closed boundary is **the manifest, never the id**, pinned by a test asserting `feature('pulse')` is null in both a valid-but-empty and a malformed manifest while resolving true only in the first. Validation mirrors desktop's zod schema field-for-field including its strictness: one bad field invalidates the whole manifest rather than dropping one entry, because a partially-trusted table is what makes "unknown id" ambiguous in the first place. The platform gate is mobile-only new logic — desktop applies `platforms` when listing the Experiments panel, never inside its resolver. Verified rather than asserted: 33 focused tests pass, and each of the four rules was mutated in turn and shown to fail the suite (18/3/3/3 failing assertions respectively), then restored byte-identically. `just mobile-check` is clean — dart format 0 changed, analyze "No issues found". `just mobile-test` is red on three PRE-EXISTING failures in `test/features/channels/` that this change does not touch; filed separately. `just check-stellar` is likewise red on main beforehand. Bead: meridian-jdxp.2.2 Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 18:33:40 -04:00
Joshua Belke	cca4628f72	docs(settings): restore the NATO Tokens spec clobbered by 874065eeb ... `874065eeb` reverted `.settings/features/feature-payments.md` to its pre-NATO-Tokens state — 645 lines removed, 316 restored — while its commit message enumerates only the ReductStore spec, the tactical-picture spec, `local.yaml`, `.settings/AGENTS.md` and `stellar/reference-index.md`. The file is not mentioned, and the worktree copy was byte-identical to `022798eb4`, three commits before the rewrite. It was collateral, not a call. The same commit is its own evidence: it also touched `.settings/features/README.md`, which still reads "**NATO Tokens**: rationing" at :85, and `.settings/AGENTS.md:15` still indexes "the NATO Tokens compute-allocation protocol spec". Index and file disagreed, which is how the clobber surfaced — an agent sent to execute `meridian-bs9` read the reverted file as current and would have written a *withdrawn* on-chain payments decision into the normative record. Restored verbatim from `874065eeb^` (= `32b52de0b`); `git diff` against that tree is empty. That version carries the reversal front matter — MIP-RT wire vocabulary, "Council: reversal pending", and the note that `meridian-grxu` supersedes `meridian-ded` with `meridian-bs9` / `meridian-13x` / `meridian-7qt` closing as withdrawn — which is the record `meridian-yzr6` reads as its Phase 0 spec. Markdown-only restore of previously committed content; hooks skipped deliberately because several agents share this checkout and the auto-fix hooks re-stage files they touch. Refs: meridian-4o3y Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 18:33:40 -04:00
Joshua Belke	5b07d61bd0	docs(stellar): the vendored ZENOH checkout is not the release we compile ... Its Cargo.toml says 1.8.0. Its routing HATs are broker/client/peer/router, where published 1.8.0 has client/linkstate_peer/p2p_peer/router and no broker at all; it also lacks routing.peer.mode and carries a gateway.south key 1.8.0 does not have. That gap is not academic. The meridian-2m45 P0 -- peer mode delivering nothing through a router -- turns entirely on routing.peer.mode and on the failover_brokering chain in hat/router/, and diagnosing it against this checkout would have produced a confidently wrong mechanism. The agent that solved it had to notice the discrepancy first and switch to the registry copy. A reference that is close enough to look authoritative and different enough to answer differently is worse than an absent one, so this says where to read instead: the registry copy under .hermit for anything we ship, this checkout for prose, examples and design intent only. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 16:48:48 -04:00
Joshua Belke	b81fefb5da	fix(bus): the relay is a client of the router tier, not a peer of it ... meridian-2m45. Two relays in the documented default `peer` mode, both connected to a `zenohd` router, exchanged NOTHING while both reported `session_open`, `endpoints_connected 1` and `zenoh_ready 1`. Not a drop either: no drop counter on the receiver was ever created, because the sample never left the publisher. The mechanism, in the pinned tree rather than in a blog post: zenoh-1.8.0/src/net/routing/hat/router/pubsub.rs:200-222 — the router refuses to propagate a subscription declaration from one Peer face to another Peer face unless `failover_brokering(src, dst)`. A Client face is exempt; the `src_face.whatami != WhatAmI::Peer` arm short-circuits. hat/router/mod.rs:287-303 — `failover_brokering` needs `linkstatepeers_net`, and hat/router/mod.rs:373 builds it only `if peer_full_linkstate | gossip`. With `routing.peer.mode` at its `peer_to_peer` default and `scouting.gossip.enabled: false` it is `None`, so the answer is always false and the publisher never learns a remote subscriber exists. Upstream states it plainly at DEFAULT_CONFIG.json5:225-226 — "The failover brokering only works if gossip discovery is enabled". So the charter's gossip refusal and session mode `peer` are mutually incompatible through a router. Confirmed both ways on a live router: gossip on (autoconnect still empty) makes `peer` deliver; gossip off with `routing.peer.mode: "linkstate"` on BOTH ends also makes it deliver. `linkstate` was measured working and rejected anyway, unanimously (Architecture & Scale council, parallel seats, minutes in the bead): - it converts a per-pod value into a fleet-wide invariant that fails SILENTLY in both directions when the halves disagree — measured, both directions — and every rolling restart passes through that state; - eclipse/zenoh 1.9.0 and 1.10.0 ACCEPT `routing.peer.mode` and silently drop it (absent from the daemon's own `Initial conf`, router starts healthy), so the fix evaporates on a minor upgrade and this P0 returns wearing a different hat; - `endpoints` has no cardinality bound, so a second router endpoint added for availability — posture-compliant, no refusal fires — would make every relay a multihop forwarder between communities. `client` needs no cross-node agreement: verified delivering against a `peer_to_peer` router AND a `linkstate` one. `hat/client/` holds no routing Network at all, so transit is impossible by type rather than by topology. It is also the documented target shape — one pod, one regional router (feature-zenoh-transport.md § Topology) — and the only shape this repo has ever actually measured through a router (perf/run_0a2_matrix.sh:71 already passes `--zenoh-session-mode client`). `peer` stays a supported mode for a DIRECT pod-to-pod link, which is what `zenoh_bus.rs::peer_pair` tests and what the benchmark arms use. Nothing in that suite changes; all 21 still pass, because all 21 cross-connect two peers directly and none of them ever touched a router. That is why they were green through the whole defect. The reversal condition, and the whole trade, sit on `ZenohMode` where the next person to change it will be looking, not only in the tracker. New gate `just zenoh-router-check` is the live half: it starts a real `zenohd` from `deploy/compose/zenoh/zenohd.json5` with the deployed command line, routes two `ZenohEventBus` sessions through it, and pins BOTH the mode that delivers and the mode that silently does not. Proven to fail against the pre-fix default. Opt-in behind MERIDIAN_ZENOH_DAEMON_CHECK=1 and out of `just check`, same as `zenoh-config-check`, because it needs Docker and the pinned image. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 16:43:34 -04:00
Joshua Belke	128e5014a0	docs(relay): bus_ready() is liveness, not reachability — the probe proved it ... This file told the next reader that the 5s probe ticker means "a session that lost every transport stops reporting ready". A live re-probe showed meridian_zenoh_ready 1 and /_readiness bus.ready true on BOTH pods for the entire period during which cross-pod delivery was completely broken. The cause is structural, not a bug in the ticker: ZenohBus::probe publishes on health_key and is satisfied by its own session's subscriber, and Zenoh delivers a session's publication to that session's local subscribers without involving the router. The probe proves the session object is alive. It cannot prove reachability to anything. That field gates the WS upgrade, /_readiness and the admission latch, so a rolling deploy would pass every gate while the bus carried nothing. Recorded here rather than only in the bead, because this is the file someone reads before trusting it. Also records that all five bus metrics are now held by MUST_BE_ALERTED -- the first two, then the next three, each shipped counted-and-silent one commit apart, so the guard is the thing that stops a sixth. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:43:50 -04:00
Joshua Belke	d45a6fcf96	feat(observability): alert the three scope-binding counters, and stop the runbook asserting strings the binary never emits ... `f26bfe5b4` added three error-shaped, bootstrapped-to-zero counters that nothing alerted on — the exact defect `2a33c8ea0` had closed two commits earlier, and unavoidable then because the alerts slice was based on a commit where these names did not exist. Four alerts, four runbook sections and three additions to `MUST_BE_ALERTED` close it (meridian-nedw). `meridian_bus_scope_refusals_total` carries two severities under one name, split by `reason`, because its five values are not one failure mode: - MeridianBusScopeRefused (page, for 0m) — the four verdicts `bind_scope` decides purely: channel-mismatch, channel-routed-global, global-routed-channel, missing-h. A signature binds author to content and binds nothing to community, so a validly signed event republished on another tenant's key expression re-verifies perfectly; this is the check that catches it. No dependency can fail into these and no relay can publish them. The absence of a wait is deliberate: the only non-adversarial shape is a rolling upgrade where two builds disagree about which kinds are channel-scoped, and any `for:` long enough to outlive a rollout is far too long for a cross-tenant injection signal, so that correlation is the runbook's first-response step instead. - MeridianBusTenancyUnbound (warning, for 15m) — `community-unbound`, the fifth reason, which has two shapes that are not attacks: an event that is never stored (every ephemeral kind, and the fan-out-only 39005) has no row to bind it and is refused by design, and a tenancy lookup Postgres could not answer refuses under the same label. Paging here would page on the design working and add a second pager to every database incident. The runbook gives the two log lines that distinguish them. - MeridianBusReverifyReplays (warning, for 15m) — the 600s window was sized to outlive the longest redelivery a *healthy* bus produces, so a failover fills this counter legitimately. 15m over a 15m window is the shortest wait a bounded burst cannot satisfy while a sustained stream still does; promtool pins both sides of that boundary. - MeridianBusReverifySeenSaturated (warning, for 10m) — scoped to `cause="size"` alone. `expired` is every entry's normal exit and would warn forever. One size eviction already means the stated 100k bound is being hit and the advertised replay window has been shortened, so >0 rather than a rate nobody has measured. Warns because the remedy is a compiled-in constant, so a build. None of the eight bus alerts can fire under the shipped `LaneFloors::IN_DEPLOYMENT` default. The runbook now says how far that goes: `Accept` is the only arm that runs, so four of the five counters have no reachable increment at all and the fifth only ever records `decision="accept"`. Two operator-facing strings the docs asserted and the binary never emits (meridian-fwo4), both verified against source rather than repeated: - `TrustProfile::label()` is kebab-case (`trust.rs:90`) and `router.rs:479` feeds it to `/_readiness`, so the field reads `"link_profile":"p0-none"` — inside the `bus` object, not at the top level. `P0None` matches nothing on a running pod. - `ZenohConfigError::NonLocalEndpoint`'s `#[error]` string (`config.rs:150`) contains no such token; the runbook now quotes the message and says to match on `reachable beyond this host`. Also records the gotcha that sent a live probe looking for a bug: an event topic is only subscribed once `retain_topic` runs for a client `REQ`, and `decision="accept"` is deliberately not bootstrapped, so on an idle pod `meridian_bus_admission_total` is absent rather than zero. G17's prose counts re-derived in the same commit, per its own instruction: 30 -> 34 alerts (relay 18 -> 22), 194 -> 198 declared metrics. `meridian_bus_scope_binding_total` is deliberately left off `MUST_BE_ALERTED` — it records the accepting verdicts too, so its first non-zero value is the design working. Gates: `just check-alert-runbooks` 0, `helm lint` 0, `helm template` 0, promtool `test rules` 0, `just check-mips` 0, `git diff --check` 0. `helm unittest` still fails on its one pre-existing `spec.groups[2].rules[4]` alert-name mismatch, byte-identical to before (64 -> 65 passing, one new suite). Guard proven to fire: deleting each new alert yields exit 1 with "is declared but no alert expression references it". Refs: meridian-nedw, meridian-fwo4 Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:41:35 -04:00
Joshua Belke	2a9d9acb51	docs(mips): re-point six MIPs to the corrected lanes, and stop Q0 asserting a store nobody built ... MIP-QC's renumbering in 2c64794dd changed lane meanings, not just numbers: old Q2 "latest-wins track state" became "interactive control" (Block, persisted), and old Q6 "volatile hints" (Drop) became "deferred control" (Block). Six documents were left citing the old numbering, so each of them asserted something false rather than merely stale. MIP-QC section 10 recorded them instead of reconciling silently, because a re-point is a decision per document. Re-pointed (meridian-7o0n): - MIP-OF section 7 -- the movement-contract table now reads off MIP-QC section 5.1: persisted is every Block lane (Q0, Q2, Q4, Q5, Q6, Q7), volatile is Q1 plus Q3 with conflation_key = 0, conflated is Q3 with a non-zero key. The prose that called the contract "a property of the lane" no longer holds for Q3 and now says what does: the lane bounds, the key selects. - MIP-AB / MIP-TK / MIP-ML section 6 -- "Q2 latest-wins" and "Q3 compactable" both resolve to Q3 conflated, since there is now one superseding lane. The column is relabelled to MIP-QC's own vocabulary (lane + contract), and each table gains the rule that makes the row honest: Q3 is volatile by default, so conflated is earned by setting a MIP-OF conflation_key, never conferred. - MIP-AS, MIP-CT, MIP-OF -- kind_to_qos() is renamed to kind_to_lane(), which is the implemented name; kind_to_qos() exists nowhere in crates/. Q0's recovery source (meridian-d0m7): crates/meridian-core/src/qos.rs maps Lane::Q0 to RecoverySource::DurableGeneration and kind_to_lane() puts ban, unban, timeout, untimeout and the NIP-43/NIP-29 membership kinds on Q0 -- but no membership generation, ban generation or revocation epoch exists anywhere in migrations/ or the workspace. relay_members and community_bans are both mutable rows on (community_id, pubkey), the last-write-wins shape Design Law warns about. The three generation records that do exist back other lanes: the git repo state watermark (0028) belongs to a Q5 kind, the replica-fence epoch (0026) is deployment-global and per-fact for nothing, and the push lease/endpoint generations (0012, 0015) are Q6 traffic. meridian_pubsub_subscriber_generation is a transport liveness gauge. So the row was "no vocabulary without an enforcement point" failing inside the table written to enforce it. New MIP-QC section 4.1 marks durable-generation UNIMPLEMENTED for membership and standing, enumerates what exists and what does not with file paths, and says plainly that a Q0 message carrying a ban today has no generation to reconcile from. The section 3 lane row and the section 5.2 grant bullet both point at it, so no reader meets the claim without the caveat. The chair's call stands -- build the generation record, do not relabel the lane -- and section 4.1 says why relabelling to postgres-backfill would be worse than the fiction: the ban row is durable but is not REQ-addressable and nothing re-reads it on reconnect. Section 10's first open question is rewritten rather than deleted. The re-point landed, but what made it possible -- a conflated stream on a shedding lane instead of a conflated lane -- is a protocol design call that has not been through the Protocol council, and a profile that binds to Q3 conflated before it hardens would lose its per-key guarantee silently. Gates: just check-mips (0), just check-external-copy (0), git diff --check (0). Documentation only; no crate, migration or config touched. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	2a33c8ea00	feat(observability): alert and runbook the two bus-admission metrics (C6) ... `meridian_bus_admission_total` and `meridian_bus_reverify_failures_total` landed in 301820a04 counted and unalerted, which made "counted, not silent" true of the data and false of the operator. Four alerts and a runbook section close council condition C6. - MeridianBusReverifyFailures (page, for 2m) — an unverifiable message reached fan-out. The sharpest security signal the relay emits. 2m costs no detection (the 10m `increase()` window holds the expression true well past the wait) and keeps a rollout's dropped verification task off the same pager as an injection attempt, since both increment this counter. - MeridianBusControlRejected (page, for 5m) — Q0 control traffic refused. Refused control messages are never retried, so cache invalidation stops reconciling and a ban reads as applied on one pod and not another. Pages because the operator who applied it has no other signal. 5m is the shortest wait that outlives a bus failover. - MeridianBusEventsRejected (warning, for 15m) — the same refusal off Q0. Bounded loss, no authorization decision, configuration-shaped recovery. - MeridianBusReverifyRateHigh (warning, >7500/s, for 15m) — cost, not fault. Derived from the measured 34-37us verification cost: ~a quarter core, continuously. The runbook records that the repo's own published per-core band is wider (30-46us), so the number is only as tight as the bench. None of the four can fire under the shipped `LaneFloors::IN_DEPLOYMENT` default, where `admit()` answers Accept for everything. The runbook says so up front, because an operator who reads silence as health on an unwired metric is the failure this whole change is about. It also names what silence looks like when it *is* healthy: `metrics::install()` bootstraps both error-shaped series to 0 across all nine lane labels, so series-at-0 is instrumentation and no-series-at-all is a different incident. Adds the metric -> alert direction to `check-alert-runbooks` as a named short list (`MUST_BE_ALERTED`), not a rule over all 194 declared names — a blanket requirement would demand an alert per diagnostic gauge and teach operators to ignore the pager. Both existing contracts start from an alert, which is precisely why neither could see two metrics that had none. Proven to fire by removing the alert and re-running the guard. Verified with promtool against the rendered rules: the expressions evaluate, the bootstrapped zero series does not self-fire, the Q0/non-Q0 split holds, and a single re-verification failure is still pending at 4m. The G17 prose counts were already stale (25/13 against a table carrying 26/14, from an earlier alert added without touching the sentences). Corrected to the derived 30/18 and the drift recorded, since nothing guards those numbers. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	f26bfe5b43	fix(relay): bind a bus event's tenancy to its signature, not to its key expression ... `ChannelEvent.community_id` and `.topic` are read off the key expression the transport matched, and on a reachable link the publisher chooses that key. `verify_event` does not cover it: an id hash plus BIP-340 binds author to content and binds nothing to community, channel or time. So on the `Admission::Reverify` path a validly signed event lifted out of community A and republished on `meridian/v1/{B}/ch/{chan}/k/{kind}` re-verified and was delivered under B; `EventTopic::Global` on an event whose signed `h` tag names a private channel skipped the visibility/membership gate entirely, because `filter_fanout_by_access` reaches it only through `StoredEvent::channel_id`; and the stateless verify meant the same bytes re-verified forever. Three bindings, all on the `Reverify` arm: - Channel. `handlers::bus_scope::bind_scope` is a pure comparison of the topic against what the signature determines. `requires_h_channel_scope` kinds must be routed to exactly their `h` tag; `is_global_only_kind` kinds must be routed `Global`; everything else is `Silent` on purpose, because outside those two predicates the relay's own channel derivation is not a function of the signed event — reactions/deletions/gift wraps read a stored row, 9007 mints a UUID, and 44100/44101 carry an `h` tag while being published globally. Guessing there would have cut legitimate cross-pod traffic. - Community. Nothing in a NIP-01 event names one, so the only thing that can answer is the event's own row: it must exist under that community and carry the routed channel scope. The channel row is deliberately not used for this even though `filter_fanout_by_access` already resolves it fail-closed — channel UUIDs are caller-chosen via `create_channel_with_id`, the key is `(community_id, id)`, and `conformance_multitenant.rs` depends on the same UUID co-existing in two communities, so an attacker who can create a channel in B can mint A's UUID there. An event that is never stored therefore has no available binding and is refused — stated, not papered over. A DB error is `Unknown`, not `Unbound`. - Replay. `AppState::bus_reverify_seen`, a 600 s / 100k seen-id set with counted evictions. It records authenticated arrivals, not deliveries: checked before the signature check and inserted the moment `verify_event` passes, so a replay costs neither a BIP-340 verify nor a Postgres round trip, and a forged id cannot pre-empt the genuine event. `Unknown` withdraws the entry so one Postgres blip is not a ten-minute hole. A duplicate-suppression window, not an anti-replay guarantee; monotonic epochs remain the fix for grant resurrection. `Accept` is untouched: it means the link met the lane floor, which is where MIP-XP authorises transport attribution, and `extract_channel_id` allocates per tag — computing the binding there would spend per-event allocations on the relay's hottest path to observe a rule that cannot fire. Under `LaneFloors::IN_DEPLOYMENT` every floor is `P0None`, every arrival is `Accept`, and delivery is bit-identical. Pinned by `in_deployment_floors_deliver_every_shape_the_below_floor_path_refuses`, which replays the four `ChannelEvent` shapes the below-floor tests refuse — a channel-tagged message on the global topic, the same message on a foreign channel topic, an unstored ephemeral event, and a relay-authored 44100 — and asserts each still reaches its subscriber, then that the accepting arm leaves the replay set empty. Refs: meridian-f43l Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	6606e618dd	fix(bus): bind the zenohd router to loopback, as its commit title already claimed ... The council's C11 live re-probe injected a forged, invalid-signature event into the bus FROM A LAN ADDRESS and a real WebSocket client received it as authentic. The router was reachable because the "loopback-only" profile published it with a bare "${ZENOH_HOST_PORT:-7447}:7447", which Docker binds to 0.0.0.0. The NonLocalEndpoint refusal that this campaign treated as the boundary confines the relay's DIAL address. It cannot confine the router's LISTEN address, and nothing else did. So the guard's stated threat model -- "keep the endpoint on loopback", in its own error string -- was not achieved by the shipped profile, and the commit title said loopback while the port said every interface. Fixed in both places, because either alone is useless: docker-compose.yml publishes on 127.0.0.1, and run.sh's generated override does too. The generator matters more -- its block is `!override`, so it REPLACES the base ports list, and a bare mapping there would have silently undone the base fix on every machine run.sh touches. Found by live probe, not by review or by any test. The 21 zenoh_bus tests pass against the vulnerable configuration, because none of them stands up a router on a routable interface. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	6893ecfbd5	feat(bus): land the single-host loopback arm of the zenohd profile ... Phase 5.1 of `.settings/features/feature-zenoh-transport.md`, split per the Security & Identity council's chair call on meridian-nok3. The held commit 060b755c5 carried Compose *and* Helm; this lands only the arm the relay can actually boot against, and holds the rest. WHAT LANDS: the root `docker-compose.yml` `bus` profile (opt-in, default off), `deploy/compose/zenoh/zenohd.json5` as the one router config both stacks will mount read-only, `docker-compose.override.yml.example`, `.env.example`, `.env.local.example`, `run.sh` with `zenoh` added to `PORT_KEYS`, `.settings/run-profiles/local.yaml`, and the `env-doctor` bus report. Every endpoint it renders is `tcp/localhost:<port>`. WHAT IS HELD: `deploy/charts/**`, `deploy/compose/compose.yml`, `compose.dev.yml`, `deploy/compose/.env.example` and `deploy/compose/README.md`. Those render `tcp/zenohd:7447` and `tcp/<pod>.<service>:7447`, and `ZenohBusConfig::validate` refuses a reachable endpoint while no lane floor exceeds the authenticated link profile — which under the in-deployment floors is unconditional, and which `from_env` cannot raise by design. Confirmed against the binary built from this tree, not only against `a_reachable_endpoint_is_refused_while_the_link_profile_meets_every_floor`: MERIDIAN_BUS=zenoh MERIDIAN_ZENOH_ENDPOINTS=tcp/zenohd:7447 -> exit 1, "endpoint `tcp/zenohd:7447` is reachable beyond this host ... an event-injection primitive" The held chart went further and made that state the documented default: `_validate.tpl` failed the render unless endpoints were supplied whenever `bus.mode != redis`. Shipping it would have pushed operators into a guaranteed crash rather than merely allowing one. Three findings from zenohd's own source shape the router config, none visible from its documented surface. zenohd runs `config.adminspace.set_enabled(true)` and `config.plugins_loading.set_enabled(true)` unconditionally after loading the file, so the levers that hold are `--adminspace-permissions none`, `plugins_loading.search_dirs: []`, an empty `plugins: {}`, and never `-P`. Multicast scouting is force-ENABLED when the key is unset, so `--no-multicast-scouting` is what survives a config swap, while gossip has no CLI flag at all — which is why mounting the file is mandatory rather than a convenience. And `transport.shared_memory.enabled` defaults TRUE in Zenoh 1.x, so it is set explicitly false; Phase 6 is unscheduled and gated on a measured crossover plus memlock/CAP_IPC_LOCK. `run.sh`, `PORT_KEYS` and `local.yaml` move in this commit and not before: a generated `zenohd:` override block against a base file with no `zenohd` service makes `docker compose config` fail outright. The port is allocated whether or not the profile is on, so enabling it later moves nothing. Two fixes on top of the held commit. Its `.env.local` and override heredocs are unquoted and its new comments carried raw backticks, so every `./run.sh` invocation ran `bus` as a command — three `bus: command not found` lines on stderr and the word deleted from the generated comment. Backticks are escaped the way the surrounding lines already do it. And its `.env.example` block re-documented `MERIDIAN_BUS` a second time, claiming `redis` is the only shippable value and that the other modes exist "not in a deployable artifact"; that was already only half true and is now false, so the block points at the canonical one and states the real boundary, which is loopback. Also carried over: `env-doctor` exited 1 on any tree without a `.env`, because the recipe exports `COMPOSE_ENV_FILES=.env` while `.env` is gitignored — the tool you reach for BECAUSE the layers are confusing died before printing a port. It now reports what was asked for, then drops the names that do not exist. Gates, each read as an exit code rather than from its output: just compose-check 0 with COMPOSE_PROFILES=...,bus and 0 without (63 assertions, 0 failed, both ways) just env-doctor 0 both ways, including on a tree with no .env docker compose --profile bus config 0; `published: "7447"` appears once, so `ports: !override` replaced rather than appended just launcher-check 0 ./run.sh ports --fresh-ports 0, and reproduces the saved allocation exactly across three runs — every port equals its profile starting point, zenoh included just zenoh-check 0 just check-docker-context 0 Signed-off-by: Joshua Belke <admin@aipowergrid.io> Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	c99ed00692	build(image): compile the Zenoh adapter into the relay image ... `Dockerfile:70` and `REMAPPING/cicd/Dockerfile:103` built `-p meridian-relay --bin meridian-relay` with no `--features zenoh`, and the adapter sits behind `zenoh = ["meridian-pubsub/zenoh"]`, off by default. So in every image this repo can build, `bus_backend_from_str` in `crates/meridian-relay/src/config.rs` takes its `#[cfg(not(feature = "zenoh"))]` arm and answers `MERIDIAN_BUS=zenoh|shadow` with MERIDIAN_BUS=`zenoh` needs a relay built with the `zenoh` feature; this binary constructs `redis` only That is a boot failure, not a bus. Verified against both binaries built from this tree: the feature-off relay prints exactly the line above and exits 1; the feature-on relay accepts the name and moves on to demand `MERIDIAN_ZENOH_ENDPOINTS`, and its accepted set is `redis, zenoh, shadow` rather than `redis`. Found by the Provenance Auditor seat, Security & Identity council, and recorded as meridian-nok3. The flag goes on `cargo chef cook` as well as `cargo build`, because the two layers must agree. Measured with `cargo tree -e normal,build` on this lockfile: the feature takes the workspace graph the cook layer builds from 565 to 642 packages (+77) and the three-package selection from 505 to 596 (+91), and every one of those lands in the source layer — invalidated by any edit under `crates/` — if only the build line carries it. The symptom would be a build that got slow rather than one that broke, which is why it is a comment between the two lines rather than a note in a commit nobody re-reads. Package-qualified (`meridian-relay/zenoh`) because three packages are selected; a bare `--features zenoh` does not say which one it belongs to. `cargo chef` 0.1.71 — the version both Dockerfiles pin — forwards `--features` verbatim to `cargo build`, and its skeleton preserves member `[features]` tables, so the qualified name resolves there too. Both published targets derive from this stage (`runtime` via `stripped-binaries`, and `runtime-debug`), so both carry the adapter. `MERIDIAN_BUS` still defaults to `redis`: this commit makes the variable readable, not active. Gates: just zenoh-check 0, just check-docker-context 0. Signed-off-by: Joshua Belke <admin@aipowergrid.io> Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-20 12:18:25 -04:00
Joshua Belke	f4e6265aa4	test(bus): compile the Zenoh backend in a gate, and correct eleven stale claims ... Council review (Security & Identity, parallel, 2026-08-19) found that NO gate on this repo builds the Zenoh feature. `git grep zenoh -- .github` returns nothing; `just clippy` is --workspace --all-targets with no --all-features; `just test-unit` names crates without --features zenoh; tests/zenoh_bus.rs is #![cfg(feature = "zenoh")]. So ZenohEventBus, the shadow adapter, the trust-ladder integration suite, and ZenohConfigError::NonLocalEndpoint -- the single refusal standing between this build and unauthenticated federation -- were compiled and executed by nothing. A compile break in that refusal would have shipped undetected, and every "landed and tested" claim rested on an agent typing a local command in a worktree. That is the third instance of one defect this week: perf/ ran in no recipe while four documents cited its number as [MEASURED], and cargo-deny reported `licenses ok` with zenoh absent from the graph entirely. A gate that does not run is indistinguishable from one that passes. `just zenoh-check` now joins `just check`. Also corrects eleven surfaces that still asserted the >=5x gate was unrun, or published the withdrawn >=2M msg/s target -- including README.md's "Ceilings, with profiles attached" table, which is the most externally-facing claim in the repo, and the GitLab wiki pages, which still told an operator "No zenoh entry in any Cargo.toml" and "Not built". An earlier correction pass caught three surfaces and missed eleven, which is the argument for a mechanical guard rather than another manual pass. The wiki rows now carry the fact that matters operationally and was nowhere written down: neither Dockerfile builds --features zenoh, so the shipped relay image still answers MERIDIAN_BUS=zenoh with a boot error. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 17:02:03 -04:00
Joshua Belke	9bda818353	docs(stellar): record the bus readiness contract and mark non-negotiable 2 unmet ... The relay now selects its bus backend, so three docs had gone stale in ways that would mislead the next reader rather than merely lag. crates/meridian-relay/AGENTS.md gains the readiness rule the wiring forced: readiness asks PubSubManager::bus_ready(), never SubscriberHealth::all_ready(). `phase` is published only by the Redis subscriber tasks, so all_ready() holds a Zenoh-backed pod closed for ever -- a Zenoh subscriber is a declaration held for the session's life, with no loop that could reach Ready. Also records the two new bus admission metrics and why their error-shaped series are bootstrapped to zero. crates/AGENTS.md stops calling meridian-pubsub a Redis backend now that it carries Zenoh and shadow too, and records that presence moved off the bus onto the manager's state pool: Redis stops carrying events, it does not leave. The G17 observability baseline claimed 158 declared metrics while the guard counts 194. The number is prose rather than machine-checked, so nothing failed -- which is exactly why it drifted through two slices. Marks Phase 3 non-negotiable #2 (TLS/QUIC mutual authentication between pods) UNMET in the charter, and corrects the status header: the adapter does not refuse every non-loopback endpoint, it refuses a reachable one unless every lane floors strictly above the authenticated link profile. Landing the re-verification branch is not what makes a reachable endpoint safe -- under IN_DEPLOYMENT floors admit() answers Accept and the branch never runs. The coupling is the gate. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 16:53:50 -04:00
Joshua Belke	301820a042	feat(bus): wire the Zenoh backend into the relay and land cross-node re-verification ... `MERIDIAN_BUS` gains `zenoh` and `shadow`, both behind a new `meridian-relay/zenoh` feature so a variant exists only where this build has a constructor for it. `redis` stays the fresh-checkout default and the value an unset variable means; an unrecognised value is still a hard startup error. A build without the feature refuses the two new names *by name* rather than reading them as a typo — or, worse, as redis, which is how a fleet ends up believing it migrated. Configuration fails closed at the config boundary, not at `open`: `ZenohBusConfig::from_env()` is called from `Config::from_env()` whenever the selected bus needs it, so a missing `MERIDIAN_ZENOH_ENDPOINTS`, an unknown session mode, and TLS material this build compiled no link for all stop the process with the variable named. ## The manager `PubSubManager` now holds `AnyEventBus` rather than a concrete `RedisEventBus`. Its Redis-only inherent methods split by what they actually are: - Presence is Redis **state**, not bus traffic, so it moves onto a `state_pool` the manager holds for every backend. Redis stops carrying events; it does not leave. - The three subscriber loops are the Redis subscriber *topology*. They keep their names and return immediately on a backend that has no such loop — a Zenoh subscriber is a declaration held for the session's life, so there is nothing to run and nothing to reconnect. - `subscriber_health` keeps its single-writer direction intact: nothing outside the Redis subscriber tasks publishes `Ready`. A Zenoh bus gets a manager-owned registry that only ever takes the two backend-independent transitions, and the new `consumers_live()` is the half of `all_ready()` that is not about `phase`. Readiness therefore asks `bus_ready()`, not `all_ready()`: the latter would hold a healthy Zenoh pod closed for ever. It waits for **configured connects and required declarations**, never a live process — `wait_bus_ready()` at startup, a 5s `refresh_bus_health()` ticker after it, and `/_readiness` plus the WebSocket upgrade gate reading `bus_ready()`. `/_readiness` also reports the backend, the link profile, and whether re-verification is mandatory, so the two postures are distinguishable without reading the deployment's environment back. ## The re-verification branch `fan_out_pubsub_event` called no `verify_event` at all, justified by a documented assumption: "Redis only ever carries events between nodes inside the relay trust domain". That holds for a private in-cluster service and dies quietly the moment a router link reaches past it. It now drives `meridian_pubsub::trust::admit` from the bus's authenticated link profile and its negotiated per-lane floors. `Accept` is today's path; `Reverify` runs BIP-340 in `spawn_blocking` and drops on failure or on a failed task; `Reject` drops. A kind with no MIP-QC lane is judged by the strictest floor the link negotiated — closed under a raised floor, a no-op under the default, and never a delivery regression dressed up as a security control. The control lanes go through the same decision at Q0 with `PayloadProof::None`. Cache invalidation and connection control carry no signature to re-check, so a below-floor arrival is refused outright rather than vaguely re-verified: a link that cannot be trusted to assert an event must not be able to flush this pod's authorization caches or drain its sockets either. A claimed envelope profile is never trusted above the link's. `admit` applies `meet` first and nothing here compares a claim to a floor on its own. Nothing on the wire carries a claim yet, so `claimed_profile()` answers `P0None` — the bottom of the ladder and the one value that can never lift a decision — as a named function taking the envelope, so the field lands in one body when MIP-XP adds it and the forgery test already covers every value it could then carry. `filter_fanout_by_access` is untouched. The tenant boundary is receiver-side and transport-independent, and a key expression is a routing label, never an isolation boundary. Metrics: `meridian_bus_admission_total{decision,lane}` and `meridian_bus_reverify_failures_total{lane}` — string literals at the macro per the relay's metric-name contract, and both error-shaped series bootstrapped at 0 so an `increase()` alert reads the first occurrence as a rise rather than adopting it as the baseline. ## Why relaxing the endpoint refusal is safe now The adapter refused every non-loopback endpoint because this branch did not exist. Landing the branch is **not** what makes a reachable endpoint safe: under `LaneFloors::IN_DEPLOYMENT` every floor is `P0None`, `admit` answers `Accept` for everything, and the branch never runs. What makes it safe is the coupling. A reachable endpoint — connect or listen — is accepted only when EVERY lane floors strictly above the authenticated link profile, which is exactly the condition under which `link.meet(claimed) >= floor` is unsatisfiable for every claim. Each arriving message is then either re-verified against BIP-340 or refused. One lane left at the link's own profile reopens the hole for that lane's traffic, so the rule is all-or-nothing and there is a test for it. The predicate has one implementation, `meridian_pubsub:🚌:reverification_is_mandatory`, read by the config refusal, by `/_readiness` and by the tests for both. `0.0.0.0` and `::` no longer read as loopback. That was the sharpest form of the same hole: as a listen endpoint `0.0.0.0` binds every interface — the most exposed configuration available — while passing a check named for the safest. The relaxation is deliberately **not reachable from the environment**. There is no `MERIDIAN_ZENOH_LANE_FLOORS`, because the charter's other Phase 3 non-negotiable is unmet: an external link needs TLS or QUIC with mutual authentication, and this build compiles `transport_tcp` only and refuses TLS material. A floors variable today would let an operator federate over unauthenticated TCP — satisfying this coupling while violating a non-negotiable that has nothing to do with it. `ZenohBusConfig::with_trust` is the seam that opens when a mutually authenticated link exists. Known consequence, documented in `.env.example`: with floors raised on a build with no link authentication, Q0 control payloads are all refused, so cross-pod cache drops and live ban enforcement would not cross a reachable Zenoh link. Counted and logged, not silent. Also carries a one-hunk `cargo fmt` fix in `meridian-agent/src/config.rs` that predates this change; `cargo fmt --all -- --check` was red on main without it. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 16:44:12 -04:00
Joshua Belke	12e5c70e63	docs(zenoh): bring the status header up to the landed state ... The adapter is on main and the first measurement exists, so "no adapter and no runtime flag" and an un-run gate were both stale. Leads with the two facts a reader most needs: the adapter refuses a non-loopback endpoint until the re-verification branch lands, and the 256 B gate failed at 1.15-1.51x with the crossover at roughly 2 KB and 16 KB. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 16:21:20 -04:00
Joshua Belke	9673a8f7ff	docs(zenoh): record what postcard cannot encode, and stop the Q2 express cell reading as permission ... Four amendments from the ZenohEventBus slice. The Q2 row's express cell said "yes only for the latency-critical subset", which reads as permission and contradicted the landed code: Lane::express() models that lane as MeasuredSubset, and a caller with no measurement must read MeasuredSubset as Never. Phase 0A.2 measured express as a latency instrument that costs roughly half the throughput below 16 KB, so "this lane feels interactive" is not grounds to spend that. The table should not disagree with the type. Records that postcard is not self-describing and that three types in meridian-pubsub look encodable and are not -- nostr::Event, plus CacheInvalidation/ConnControl, which are internally tagged and cannot be deserialized from a non-self-describing format at all. Same family: serde implements its array traits only to length 32, so a BIP-340 signature cannot be a [u8; 64] field, and must not become a Vec<u8> either, which would admit a wrong-length signature into the decoder. Makes the non-local-endpoint refusal a written rule rather than an implementation detail: fail closed in configuration, not only in review. An adapter that can be pointed at a remote router before the re-verification branch exists has already lost the argument. Also applies rustfmt to the include_str! wrap introduced in c3733941a, which had left just fmt-check red on main. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 16:03:43 -04:00
Joshua Belke	25349f15c3	feat(bus): implement ZenohEventBus, its shadow adapter, and the trust ladder ... Phase 3 of the Zenoh transport charter. The second `EventBus` implementor, the shadow adapter that composes it with Redis, and the MIP-XP profile type the relay's cross-node re-verification branch will be written against. The default build is unchanged and proved so: `cargo tree -p meridian-pubsub` is byte-identical before and after (312 lines, same sha256). `postcard` is the only new dependency edge and it was already in `Cargo.lock` via `meridian-relay-mesh`, so no package is added to any graph. What is here, and why each piece is shaped the way it is: - **`zenoh/topic.rs`** — the key space, exactly as the charter states it. Zenoh's wildcards are `*` and `**`; `+` is a legal *literal* chunk, so an MQTT-shaped subscription declares fine and then receives silence. That is named as its own error, and asserted against Zenoh's own matcher rather than string equality. Parsing accepts only canonical spellings: `Uuid::parse_str` also takes braced, URN and unhyphenated forms and `"+9".parse::<u32>()` is `Ok(9)`, and every one of those renders a *different* key for the same logical topic. `v1` is a wire fence — `meridian/v1/**` provably does not intersect a `v2` key. - **`zenoh/codec.rs`** — postcard, and the routing attachment. The attachment carries `community`, `channel`, `kind`, `event_id` in 71 bytes, so a receiver answers "is this my own echo?" without deserializing the payload. That is charter Gap #5, and it is enforced by a signature rather than by call order: `decide_from_attachment` takes no payload, so it cannot decode the event even if a later edit wanted it to. Three types needed postcard-friendly mirrors — `nostr::Event` (self-describing `Deserialize`), and `CacheInvalidation` / `ConnControl`, which are `#[serde(tag = "op")]` and cannot be decoded from a non-self-describing format at all. A test fails if that ever stops being true. - **`zenoh/config.rs`** — one statement of the posture. `tests/fixtures/zenoh/ bus-peer.json5` is embedded with `include_str!` and `check_posture` is the only implementation of the policy check; `tests/zenoh_config.rs` now delegates to it instead of keeping a copy. Fails closed on: no endpoint, unknown mode (`router` is not a mode a relay may take), a link this build did not compile, TLS material with no TLS link, a lost pin, and **any non-loopback endpoint** — the charter requires the re-verification branch before a non-local endpoint exists, that branch is the relay slice, so until it lands this adapter refuses to be reachable from off-host. - **`zenoh/mod.rs`** — `ZenohEventBus`. One long-lived session; declared publishers and subscribers created once and cached, because the first publication of a session costs ~15.5× the steady rate. `retain_topic` / `release_topic` are now the declaration's lifetime: the retain count and the live `Subscriber` are one map entry, so "declared" and "desired" cannot drift, and there is no 500 ms debounce because undeclare is local. QoS comes from `meridian_core::qos::kind_to_lane`, translated into Zenoh's types here and nowhere else; `meridian-core` keeps no bearer dependency. `express` is taken only where a lane earned it — Q0/Q1 always, Q2 never without a measurement, because express costs about half the throughput below 16 KB. - **`zenoh/health.rs`** — readiness is configured connects **plus** required declarations **plus** a fresh application loopback, and `readiness_gap` names the first unmet condition rather than answering a bare `false`. - **`zenoh/shadow.rs`** — dual publish, Redis-authoritative delivery, per-lane parity counters. A Zenoh success never rescues a Redis failure: the caller sees the primary's error, because a shadow that could rescue the primary makes the primary's health unobservable. - **`trust.rs`** — the MIP-XP ladder, `LaneFloors`, and `admit(link, claimed, lane, floors, proof) -> Admission`. Not feature-gated: the branch it exists for compiles in every build. Effective trust is the meet of claim and link, and an unknown wire value maps to least trust. - **`bus.rs`** — `AnyEventBus`, the enum dispatcher. `EventBus` is RPITIT and not dyn-compatible; `async-trait` would put a heap allocation on the publish path of a bus built to remove per-event cost. `bridge` gets no variant, because nothing constructs one yet. The subscriber→`broadcast::Sender` adaptation needs no runner: `broadcast::Sender::send` is synchronous, so the Zenoh callback *is* the adapter. `run_broadcast_consumer` remains the only place lag is interpreted. Not in this commit, by scope: relay wiring (`config.rs`, `main.rs`, `reconcile.rs`, `metrics.rs`), the `BusBackend` variants, `.env.example` and Helm. `bridge` is unimplemented. Gates: `cargo test -p meridian-pubsub` 0; with `--features zenoh` 0 (92 lib + 21 zenoh_bus + 11 zenoh_config + 1 doc); clippy both ways 0; `cargo fmt -p meridian-pubsub -- --check` 0; `just check-unwrap-budget` 0 (no new unwrap/expect in any production path); `just check-alert-runbooks` 0; `just check-architecture-map` 0. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 15:59:59 -04:00
Joshua Belke	f6a09ab844	docs: the >=5x bus gate at 256 B has been run, and it failed ... Phase 0A.2 (meridian-ctg) produced this project's first Redis-vs-Zenoh measurement. Three documents claimed the comparison "has not been run" and one carried a target of ~10-20x at 256 B. Measured: 1.51x against Dragonfly, 1.15x [0.98-1.34] against a same-footing host-native Redis -- statistical parity with the lower bound below 1.0 -- and 0.71x with express. Crossover is ~2x at 2 KB and ~5x at 16 KB; against host-native Redis, >=5x appears nowhere in the sweep. The 10-20x target is withdrawn rather than softened, and replaced by a per-band statement, because the honest answer is not one number: <=1 KB is parity, 2-16 KB is the only band with a throughput case, and the 8.21x at 256 KB is substantially the Docker boundary (1.82x routed). Also records the failure mode that produced the first, invalid answer. The harness compared a Redis client that blocks on the reply against Zenoh's fire-and-forget batched put, and reported the difference as a property of the buses: 26.87x before matching publish semantics, 1.51x after. Dragonfly alone spans 73.3x between synchronous and pipelined publish. A bus comparison must state its publish semantics beside its payload size or it is not a comparison. Per the owner's standing call this is a claim-licensing gate, not a direction gate: it decides which lanes migrate first and what may be said, not whether to proceed. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 15:24:07 -04:00
Joshua Belke	82118b8ec7	chore(beads): record the helm/ disposition call (meridian-l1gu) ... Release & Operations blocked committing the untracked helm/ directory. Minutes, verified claims and the salvage conditions are in the bead. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 15:22:22 -04:00
Joshua Belke	5d13406839	perf(bus): the zenohd router topology is Phase 5, not Phase 4 ... `.settings/features/feature-zenoh-transport.md` places production `zenohd` routers at Phase 5 / `meridian-0ps`, both in its opening commitment and in its phase table. The harness doc and the `--mode zenoh` install hint both said Phase 4, which is the batching/QoS phase. Someone reading the hint to find out who owns starting a router would land on the wrong row. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 15:20:27 -04:00
Joshua Belke	e70a363201	perf(bus): record the first Redis-vs-Zenoh measurement, and fix the arm that made it wrong ... The Phase 0A.2 matrix, and the harness defect it had to fix first. `publish_scenario` called `RedisClient.command()`, which flushes and then blocks on the reply -- a full round trip per PUBLISH. Zenoh's batched `put` returns on enqueue. The arm was comparing a synchronous client against a fire-and-forget one and reporting the difference as a property of the two buses. Measured publisher-side at 256 B, Dragonfly does 7,072 msg/s synchronous and 518,163 msg/s pipelined -- 73x. At 256 B on the full grid the defect reads 26.87x [24.72-28.14]; matched, the same grid reads 1.51x [1.42-1.78]. `--redis-publish {pipelined,sync}` now selects the operating point, pipelined is the default, the label is stamped into every profile header, and the superseded shape is kept as a run arm so the discarded number stays reproducible. `wait_for_counts` also raised TimeoutError on a subscriber error even when the expected count had been met, hiding the real cause behind "timed out ... got 12800" of 12800. It now checks the count first and names the subscriber failure. Result, 5 repetitions, profile in the doc: the >=5x claim-licensing gate at 256 B FAILS -- 1.51x against Dragonfly-in-Docker, 1.15x [0.98-1.34] against a host-native Redis on the same loopback footing, 0.71x with `express`. Zenoh crosses 2x at 2 KB and 5x at 16 KB against Dragonfly, and never reaches 5x against the same-footing baseline. The router arm prices the Docker boundary the peer arm does not pay: 8.21x at 256 KB peer becomes 1.82x routed. Cold start measures 15.5x [14.2-27.5], replicating dora's ~16x. The machine was not quiet (load 22-31, unrelated esbuild watchers at 830-930% CPU). Absolute msg/s are published only so the ratios can be checked against them; the doc states which rows the pairing helped and which it did not. This is a Python-binding probe. It licenses no MERIDIAN throughput claim and is not the Rust adapter's capacity number. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 15:19:22 -04:00
Joshua Belke	692826927d	docs(stellar): iceoryx2 is a competitor, not a layer in our stack ... The row placed it inside the architecture — "the same-host half of the bus question", read "as evidence for" Phase 6 of the Zenoh plan. That is the same mistake as the one it had just corrected, one level up: the first version put iceoryx2 underneath Zenoh, this one put it underneath our roadmap. It is neither. iceoryx2 is a complete competing middleware with its own service discovery, config, CLI and messaging patterns. We keep the checkout to read its code, and it occupies no position here at all. The interchangeability is upstream's own framing, not an inference: ROADMAP.md 60-67 lists smoltcp, zenoh, mqtt, dds, someip, dbus and websocket as gateway backends, of which only Zenoh exists and is still marked MVP. Zenoh is a plug-in transport it reaches other hosts with — two Eclipse projects competing for the same slot and bridging at the edge. Recasts Phase 6 accordingly: not evidence for our plan, but a competitor's published answer to the same question, worth reading before designing ours. Drops the duplicated MVP bullet now that the point is made once, up top. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:52:10 -04:00
Joshua Belke	16c8dc3b90	fix(skills): bound no-ai-slop to one named draft, out of the suite tree ... The skill was dropped into `skills/` unregistered, so it had no manifest role, no routing row, and no gate. An agent found it with `ls`, could not invoke it (`Unknown skill: no-ai-slop`), read the body by hand, and applied it to the whole of `docs/ux-end-to-end-workflow.md` from the request "make it human read-able" — sweeping with `grep -nioE '<banned-words>'` and committing the result in 8a470ed8f. Nothing in the body said which files were drafts, so in a repo it meant every file with prose in it. That shape does not stop at one doc. The patterns it deletes on sight are the patterns Design Law is written in: binary contrasts, colon reveals, stated importance, and prose that tells an implementer how to weigh a rule. DIAGRAM.md carries 335 em dashes against the skill's cap of 1-2, the STELLAR chain is 40 AGENTS.md files of exactly those shapes, and the banned list contains `harness`, which is a crate name appearing in 422 tracked files and ~2,700 banned-word hits sit across 329 tracked source files. `SHRUNK_DOC_RATIO` guards AGENTS.md and nothing else, so `docs/`, `docs/mips/`, README.md and DIAGRAM.md were unguarded. The body now opens with a Scope contract that is not advisory: one named file or pasted draft per invocation, ambiguity routes to Detect rather than Edit, never sweep with a regex, prose only and not code fences or tables or marker blocks, propose a diff rather than write, stop at a quarter of the target's bytes, and require a clean baseline before any write. A refusal list names the contracts outright — AGENTS.md, DIAGRAM.md, docs/nips, docs/mips, docs/spec, migrations, gauntlet baselines, features, Beads, reference-code, CHANGELOG, LICENSE, marker blocks, skill bodies, and all source. Every "pattern to cut" gains a load-bearing exception, because a rule, invariant, refusal or silent-failure warning reads as slop precisely when it is doing its job. eval.md gains eight blocking Scope checks that run before the edit, and the frontmatter description now says what the skill is not for, so it stops matching "make this readable". Placement follows the convention skills/README.md already states: it is a generic utility, not a suite member, so it lives as identical copies in the three runtime trees beside `desktop-screenshot` and `meridian-cli` rather than in `skills/`. That also clears it from `just check-skills`, which fails any `skills/` directory without a manifest entry. The README records why it sits out there, and that it is a drafting aid and never a publication gate — `just check-external-copy` owns that boundary, and a blocklist over freeform prose fails open on the phrasing nobody predicted. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:52:10 -04:00
Joshua Belke	9af57aa511	docs(zenoh): fold the Phase 1 and Phase 4 findings back into the charter ... Ten amendments from the dependency-pin and lane-map slices. The load-bearing ones: - The pin is `=1.8.0` exact, not `^1.8`, because "1.8" resolves to 1.10.0 and a caret range silently decouples the vendored reference checkout every later phase reads from what actually gets built. - A new ledger row for zenohd itself. The daemon is not a passive reader of its own config: it re-enables adminspace and plugins_loading after loading the file, and reads an ABSENT multicast-scouting key as consent. So `enabled: false` is true for the library and false for the daemon, and Phase 1 now requires asserting the daemon's EFFECTIVE config rather than that the file was accepted. - cargo-deny resolves the default-feature graph, so an optional dependency is invisible to it. Before `[graph] all-features = true`, `licenses ok` was reported with Zenoh not in the graph at all -- vacuous green, not passing. - Shared memory and its transport optimization also default on, so omitting the keys switches on the unscheduled Phase 6. - Ban/unban/timeout ride Q0, not Q2 as the map's example said: they remove standing, and Q2's postgres-backfill recovery has nothing to recover from because they are executed and never stored. - kind_to_lane is guarded by a source-parsing test, not range tests, which cannot see a constant added inside an already-covered range. Adds `just zenoh-config-check`, deliberately outside `just check` until its Docker self-skip is proven -- a gate in `check` that has never been shown to skip cleanly is how a green CI stops meaning anything. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:40:16 -04:00
Joshua Belke	1f84d5e6bd	fix(mips): regenerate the client registry so just check-mips passes again ... check-mips has been red on main. Two copies of the generated registry existed; dd64dce6c deleted the fresh desktop/ one during the REMAPPING move, leaving the stale REMAPPING/meridian-desktop/ copy as the only one the script reads. It still carried a MIP-SA / SAPIENT row. MIP-SA has no docs/mips/MIP-SA.md and no row in docs/mips/README.md, so the generated artifact advertised a spec that does not exist -- the repo's own no-vocabulary-without-an-enforcement-point failure, in the file the desktop client reads. SAPIENT remains real planned work (meridian-6juf, characterization first); this removes only the client's claim to a MIP document, which was already marked available: false. Regenerated with the fix the gate itself prescribes. No other row moved. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:30:09 -04:00
Joshua Belke	ebb9a14780	fix(agent): repoint the effort-table fixture at its post-rebrand path ... include_str! still resolved ../../../desktop/..., which the REMAPPING move deleted, so `cargo check --workspace --all-targets` failed at meridian-agent's lib test target. Nothing caught it because the path only resolves under --all-targets. Also retires two stale crate-role claims now that the EventBus seam has landed: meridian-pubsub is a bus seam with a Redis/Dragonfly backend, not "Redis pub/sub fan-out". README additionally credited it with typing indicators, which the crate's own doc comment explicitly retracted (meridian-ki8w: no typing API, no typing key, no typing call site). Records in the transport plan that the seam is RPITIT and therefore not dyn-compatible, so Phase 3's shadow/bridge compose as an enum rather than Box<dyn EventBus> -- a boxed future per call would put a heap allocation on the publish path of a bus built to remove per-event cost. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:30:01 -04:00
Joshua Belke	24a5be5eb7	test(perf): run the bus-scaling harness in CI, and record what it was hiding ... README, TASKS and DIAGRAM all publish the 64x interest-scoping figure as [MEASURED], and DIAGRAM adds that the harness "fails below 95% of ideal, so the claim is load-bearing rather than decorative". Nothing ran it: no Justfile recipe referenced perf/ at all, so the enforcement point behind four published claims never executed. Worse, the guard did not hold even when run. assert_scaling computed reduction as old/new if new else inf, so a scoped arm delivering ZERO scored an infinite reduction and passed. RELAY_BUS_SCALING.md had named that exact trap in prose while the code did not implement it -- the repo's own no-vocabulary-without-an-enforcement-point failure, in the harness that licenses its headline numbers. just perf-check runs the harness's unit tests and joins just check. The measurement itself stays out of CI on purpose: a throughput number taken on a loaded machine is worse than no number, because it gets quoted. Also moves queue/backpressure time and reconnect loss/recovery out of Phase 0A.2, which demanded fields the harness cannot produce. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:30:01 -04:00
Joshua Belke	ebadbe19c2	docs(zenoh): record the four zenohd settings the config file cannot close ... Verified against zenohd's source and by running 1.8.0, 1.9.0 and 1.10.0. zenohd force-enables adminspace and plugin loading unconditionally, so a file that says false is echoed back as true; multicast scouting is force-enabled when the key is unset; gossip has no CLI flag at all, so a router with no mounted config gossips; and shared memory defaults to true in Zenoh 1.x, which silently activates the unscheduled Phase 6. Each of these passes an assertion made against the config file and is false in production, so Phase 5 now names the lever that actually holds. Also records that the deploy mapping is ported and held unpushed, and that run.sh/PORT_KEYS/local.yaml must move in the same commit as the service. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:30:00 -04:00
Joshua Belke	5e3735da2a	feat(pubsub): pin zenoh 1.8.0 and make its config contract executable ... Charter Phase 1 of `.settings/features/feature-zenoh-transport.md`: one exact Zenoh release for both the library and the daemon, off by default, with the configuration policy asserted by tests rather than described in prose. No adapter code, and no change to a default build. Version: `zenoh = "=1.8.0"` and `eclipse/zenoh:1.8.0` (index digest sha256:7aada0d1f86404c4c6ae3419618b7cfac3d8d261541a686da248ae90de40fa97). crates.io offers 1.10.0 (published five days ago) and 1.9.0, and multi-arch daemon images exist for all three, so the image is not the constraint. 1.8.0 is chosen because the charter's adoption ledger and the reviewed source under `.settings/reference-code/ZENOH/` are both 1.8.0. Every later phase reads that checkout as its source of truth; compiling a different release would make each of those reads quietly wrong, which is the drift this repo legislates against. The requirement is `=1.8.0`, not `^1.8`, because `"1.8"` resolves to 1.10.0 — a caret range here means the ledger silently stops describing what is built. Five months of field time and an already-published daemon image are the secondary reasons; the ledger alignment is the argument. Ledger claims re-verified against the PUBLISHED 1.8.0 crates, not the +35-commit reference checkout. All four hold: (a) `zenoh-protocol-1.8.0/src/core/mod.rs:303` — eight values, `Control = 0` reserved. `zenoh-1.8.0/src/api/publisher.rs:521` exposes seven, `RealTime = 1` .. `Background = 7`. Pinned by `seven_application_priorities_are_assignable`. (b) `zenoh-1.8.0/src/api/builders/publisher.rs:130` — `express` bypasses batching, and is NOT gated. `:154-159` and `:440-445` — `reliability` is `#[zenoh_macros::unstable]` and documented to trigger no retransmission. `unstable` is not enabled here, so `Reliability` is unreachable in this build. Nothing is lost: it is a wire marker, and every non-lossy lane needs a named recovery source regardless. (c) `zenoh-transport-1.8.0/src/unicast/manager.rs:237` — `qos && lowlatency` bails. Pinned by `rejects_qos_plus_lowlatency`, which opens a session because the file parses fine and only `zenoh::open` rejects it. (d) `zenoh-config-1.8.0/src/defaults.rs:75` and `:105` — multicast AND gossip scouting both default `true`. Four things the ledger does not yet say, each found by running the pinned artifacts rather than reading docs: - `transport.shared_memory.enabled` and `.transport_optimization.enabled` both default `true` (`zenoh-config-1.8.0/src/lib.rs:795-816`). Omitting the keys switches on charter Phase 6 — unscheduled, gated on a measured payload crossover, and needing `CAP_IPC_LOCK`. The daemon image is built with the feature even though this build is not, so it would announce SHM on a link the other end cannot honour. Both pinned off, with a negative fixture. - `zenohd/src/main.rs:136-137` unconditionally re-enables `adminspace` and `plugins_loading` after reading the config file. `enabled: false` is honest for the library and false for the daemon that ships REST and storage-manager plugins in its image root. What survives, and is now asserted against the daemon's own `Initial conf` line, is `plugins_loading.search_dirs: []`, `plugins: {}` and `adminspace.permissions.{read,write}: false`. - `zenohd/src/main.rs:203-214` reads an ABSENT multicast-scouting key as consent and force-enables it. Present-and-false takes the `(false, false)` arm and survives. The assertion is `== "false"`, not "not true", so deleting the key from a fixture fails instead of re-enabling discovery. - `zenoh-runtime-1.8.0/src/lib.rs:149` panics outright on Tokio's current-thread scheduler. Every Zenoh call site needs a multi-thread runtime. Features: `default-features = false, features = ["transport_tcp"]`. TCP is the only scheme the fixtures declare. `transport_tls` is deferred to the phase that introduces the first non-local endpoint, and the deferral is executable — a `tls/` endpoint is a negative fixture. `unstable`, `internal`, `plugins`, `shared-memory` and `stats` are all off; each is justified in the workspace manifest next to the pin. Cost: the crate is optional behind a `zenoh` cargo feature that is off by default. `cargo tree -p meridian-pubsub` is byte-identical to before (144 packages); with the feature it is 295. `Cargo.lock` grows 983 -> 1056. No workspace crate's default build gains a single dependency. deny.toml: no license needed permitting. `EPL-2.0 OR Apache-2.0` resolves to the already-allowed Apache-2.0 path for all 20 zenoh crates, and no new advisory appears. The one change is `[graph] all-features = true`, which is a widening, not a waiver: cargo-deny defaults to the DEFAULT-feature graph, so an optional dependency is invisible to every check and `cargo deny check` was reporting `licenses ok` without ever looking at Zenoh. Verified by banning `zenoh` in a throwaway edit and watching the bare `cargo deny check bans` fire. Measured to change nothing else: the same 12 pre-existing advisories (h2, nostr, nostr-relay-pool, webbrowser — identical on an untouched tree), `bans ok, licenses ok, sources ok`. MSRV: all 20 zenoh crates declare 1.75.0, under the workspace's 1.88.0 and the pinned 1.95.0 toolchain. No conflict. Tests are wrapped in `mod zenoh_config` on purpose: the documented filter `cargo test -p meridian-pubsub --features zenoh zenoh_config` matches test NAMES, and before the wrap it reported `0 passed; 11 filtered out` — exit 0 for a suite that never ran. Gates: cargo check (feature off / on) 0, clippy -D warnings 0, cargo test 0 (11 tests, incl. the Docker daemon check), just fmt-check 0, cargo deny check licenses / bans / sources 0. `cargo deny check` exits 1 on the 12 pre-existing advisories, identically to an untouched tree. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:16:42 -04:00
Joshua Belke	2e71938c24	feat(core): kind_to_lane() — the MIP-QC Q0–Q7 map, exhaustive and fail-closed ... Every kind now resolves to one of the eight MIP-QC lanes, and an unknown or unclassified kind returns `UnclassifiedKind` rather than falling into a convenient default. A default is precisely how a durable kind acquires best-effort delivery without anyone deciding it should, so the map is an explicit denial — the same law as "explicit denial, never a silent empty result". Tests were written first and were red on the whole table before the map existed. What they pin: - all 133 declared kind constants against their lane, by name and number; - lane counts per lane, so a reclassification has to move a number; - the eight lanes' priority/congestion/express/recovery against MIP-QC § 3; - that every `Block` lane names a recovery source that is not `loss-accepted` — the property that replaces the removed reliability marker; - that lane priorities are only ever 1..=7, since 0 is the bearer's reserved internal priority, and that Q5/Q6 share one so eight lanes fit seven. The merge guard is a source-parsing test rather than an extension of `just check-kinds`. `check-kinds` reads `ALL_KINDS`, but its three documented `REGISTRY_EXEMPT` constants (KIND_AUTH, KIND_NOSTR_IDENTITY_BINDING, KIND_PUSH_LEASE) are declared and deliberately absent from that list — exactly the kinds a test over `ALL_KINDS` would miss. So the test reads this file's own source between `LANE-TABLE-START`/`LANE-TABLE-END` markers and fails when a declared `KIND_*` constant has no arm. Verified by adding a throwaway constant: kind constants declared with no MIP-QC lane: KIND_GUARD_PROOF (47001). Add an arm to kind_to_lane() between the LANE-TABLE markers and a row to LANE_TABLE. See docs/mips/MIP-QC.md § 3.1. Identifier matching is whole-word, so KIND_STREAM_MESSAGE_V2 cannot satisfy the guard for KIND_STREAM_MESSAGE. No Zenoh dependency enters meridian-core. `LanePriority`/`CongestionPolicy` are MERIDIAN's own enums with a documented 1..=7 numbering; translating them to a bearer's types is the adapter's job, and lane labels are exported from this application map — a bearer-derived label would silently merge Q5 and Q6, which share `DataLow`. The lane type carries no `reliability` field, by MIP-QC § 2.4. Q1 and Q7 carry no registered kind: media frames and backfill/reindex/sweep are MIP-OF lane operations, not events. The lanes stay, and a test says so, because deleting one would push its traffic onto a lane whose contract does not fit. Assignments the charter did not name are listed under "# Judged assignments" on kind_to_lane, biased conservative — most notably 9040–9043 (ban/unban/timeout) on Q0 rather than the Q2 the charter's "moderation actions" example implies, because they remove standing and store no event to backfill from. Bead: meridian-2e9, meridian-9j8 Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:13:25 -04:00
Joshua Belke	2c64794ddb	docs(mip-qc): separate Zenoh scheduling from recovery, and stop promising retransmission ... MIP-QC listed `reliability: Reliable / BestEffort` as a lane-owned knob beside priority and congestion. That conflates Zenoh's transport marker with a delivery guarantee. In the pinned tree (Zenoh 1.8.0), the builder that sets it is `#[zenoh_macros::unstable]` and says so verbatim: "Currently `reliability` does not trigger any data retransmission on the wire. It is rather used as a marker on the wire and it may be used to select the best link available" — zenoh/src/api/builders/publisher.rs:152-159, repeated at 438-445 A spec that promises retransmission from that marker is discovered to be wrong only when a message is lost and nothing recovers it, so the knob is removed and every lane now names a recovery source instead: a store (durable generation, Postgres/REQ backfill, addressable re-read, durable source plus retry, job checkpoint) or the explicit `loss-accepted`. A lane may not be called reliable without one, and a MERIDIAN lane type may not carry a `reliability` field. Also pinned to source, because these are the claims that go stale silently: - Seven application-assignable priorities (`zenoh/src/api/publisher.rs:523-532`), not eight. `Control = 0` exists on the wire enum (`commons/zenoh-protocol/src/core/mod.rs:332-342`) and is reserved for Zenoh's internal use (`zenoh/src/api/publisher.rs:611-612`). Eight lanes therefore map onto seven priorities and Q5/Q6 deliberately share `DataLow`. - `CongestionControl` is `Drop`/`Block`; `BlockFirst` is `unstable` and is not assignable by a lane (`commons/zenoh-protocol/src/core/mod.rs:617-629`). - `transport.unicast.lowlatency` with QoS is a boot failure, not a degradation: `io/zenoh-transport/src/unicast/manager.rs:237-239` bails with "'qos' and 'lowlatency' options are incompatible". The lane table is replaced with the eight lanes of the transport charter's QoS and recovery map, which is the authoritative one. That renumbering conflicts with lane references in MIP-OF, MIP-AB, MIP-TK, MIP-ML, MIP-AS and MIP-CT; the conflict is recorded as open question 1 with a per-document table rather than silently reconciled, because it is a decision and not a rename. `kind_to_qos()` becomes `kind_to_lane()`, exhaustive over registered kinds and fail-closed on an unknown one — no convenient default lane, per "explicit denial, never a silent empty result". Bead: meridian-2e9, meridian-9j8 Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:13:25 -04:00
Joshua Belke	81dc044126	feat(pubsub): land the EventBus seam with Redis as the only backend ... Zenoh transport plan, Phase 2. Today's Redis/Dragonfly PUB/SUB body moves verbatim into `RedisEventBus`, behind an `EventBus` trait, so a later backend plugs in without touching a relay call site. `PubSubManager` keeps its exact public surface and becomes a thin dispatcher over the bus. The trait carries the three lanes the relay actually runs — events (plus the retain/release topic-interest pair), cache invalidation, connection control — and nothing else. Two deliberate exclusions: - Presence, rate limiting and NIP-98 replay are Redis *state*, not bus traffic, so they stay inherent on `RedisEventBus`. - `SubscriberHealth` stays inherent too: its lane set is this backend's subscriber topology, and readiness for another transport is a different shape. The subscribe methods return `tokio::sync::broadcast::Receiver`, not an opaque stream. All three lanes are consumed by the single shared runner in `broadcast_consumer::run_broadcast_consumer`, which owns the lag-is-not-terminal contract (record, compensate, count); an opaque receiver type would force a second copy of that loop per backend, which the relay's lane contract refuses by name. `publish_event` drops the Redis `PUBLISH` subscriber count and returns `Result<(), BusError>`. Every production call site — 11 in the relay, one in `meridian-admin` — matches on `Err` only; none read the `i64`, and a later backend has no equivalent to report. `BusError` aliases `PubSubError`, so `?` and error matching at those call sites are unchanged. `MERIDIAN_BUS` is parsed strictly in the relay config: unset and `redis` select Redis, and every other value is a hard startup error. That is a deliberate departure from `MERIDIAN_MESH`, which reads an unrecognised value as off — a feature that quietly does not run is recoverable, a relay that read `MERIDIAN_BUS=zenho` as "redis" and started healthy is how a fleet ends up believing it migrated. `zenoh`, `shadow` and `bridge` are not accepted and get no variant of their own: a name nothing constructs is vocabulary without an enforcement point. `main.rs` selects the backend through an exhaustive `match config.bus`, so a future variant cannot be added without a constructor for it. Behavior is unchanged: same topic keys, same `broadcast::channel(4096)`, same 500 ms unsubscribe debounce, same three dedicated subscriber loops and health transitions. Every existing pubsub and relay test passes with no assertion touched — the only edit inside a test module is one `use` line in `meridian-pubsub`, needed because the imports it shared with the old `PubSubManager` body moved to `bus.rs`. Gates: cargo test -p meridian-pubsub (34 pass, and 46/46 with --include-ignored against local Dragonfly); cargo test -p meridian-relay --lib (863 pass); cargo clippy -p meridian-pubsub -p meridian-relay --all-targets -D warnings; just fmt-check; just check-unwrap-budget. All exit 0. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:02:23 -04:00
Joshua Belke	dd64dce6ca	docs(stellar): correct and ground the iceoryx2 reference-index row ... The row landed in a2002e8a5 claiming iceoryx2 is "the mechanism underneath Zenoh's shared-memory transport". It is not, and the claim was load-bearing: it attributed Zenoh's `ulimit -l unlimited` / `CAP_IPC_LOCK` and 16x cold-session constraints to this checkout, so the next reader would have gone looking for them here and found nothing. `grep -rn iceoryx Cargo.toml Cargo.lock` in `.settings/reference-code/ZENOH` exits 1 — a lockfile lists every transitive dependency, so that settles it. Zenoh ships its own `commons/zenoh-shm`. The dependency runs the other way and only inside iceoryx2: `integrations/zenoh/` is an iceoryx2 gateway that uses Zenoh to reach other hosts, and `ROADMAP.md:62` still calls it MVP. Replaces it with what the source supports, each claim reproducible by grep: - Identity and scope: `main` at 2baf620bd (v0.9.0-1263), MIT OR Apache-2.0, same-host zero-copy IPC with no network transport of its own — which is Phase 6 of feature-zenoh-transport.md, not the bus displacement. - The gateway contract worth reading: `Backend<S: Service>` plus EventRelay / PublishSubscribeRelay over one shared conformance-test crate. - `integrations/zenoh/Cargo.toml:48` pins zenoh 1.9.0 — the tag Compose deploys, while the ZENOH row is a 1.8.0 checkout. - Four refusals: 2483 `unsafe` in iceoryx2-pal against this repo's no-unsafe rule; FAQ.md:361-369 rejects String/Vec/HashMap payloads, which a signed NIP-01 event is made of; its latency plots carry a benchmark profile and a different traffic class than signed ingest; brokerless but not stateless, with a 64 MB default /dev/shm that pre-allocation exceeds. Also records that the generated entry-point list truncates at 12 and hides `iceoryx2/`, `iceoryx2-pal/`, `iceoryx2-gateway/` and `integrations/` — the four directories the row is actually about. The rust-skills row from the same commit is left as-is: its claims (265 rules, edition 2024, pinned by skills-lock.json) check out. `.settings/stellar/ snapshot.json` is deliberately NOT refreshed — `just check-stellar` fails on 8 pre-existing REMAPPING losses and an orphaned `.agents/skills/rust-skills/ AGENTS.md`, none of them from this change, and accepting them here would hide another agent's in-flight work behind a documentation commit. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:01:45 -04:00
Joshua Belke	8a55ad18e8	docs(stellar): index the iceoryx2 and rust-skills checkouts with their reasons ... Both rows were regenerated with an unrecorded "why we keep it", which is the one part of a reference-index row the generator cannot supply and the only part that survives the clone going missing. - iceoryx2 is the zero-copy shared-memory IPC layer underneath Zenoh's shared-memory transport, so it is where the machine plane's operational constraints get settled rather than quoted. - rust-skills is the corpus `rust-coding` selects from, and the row records that it is read through that skill's reconciliation rather than applied directly. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:01:45 -04:00
Joshua Belke	66dd854900	chore: reflow the UX guide's tables and refresh the beads export ... `docs/ux-end-to-end-workflow.md` is separator-row realignment only — `git diff -w` is empty. `.beads/interactions.jsonl` is the passive export. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:01:44 -04:00
Joshua Belke	9c93f7d4fd	docs(intro): track MIP-CT § 6.5 in the briefing page, byte budget included ... The page said MIP-CT does not carry the APP-6 text amplifiers. It now does — § 6.5 specifies the 22-field extension, including the commonly omitted AG · Auxiliary Equipment Indicator — and what remains is the writer, validator and decoder. Those are different claims and the page should not make the stronger one. The byte budget moves with it: ≤37 B fixed core plus the empty extension-vector byte puts header plus bare payload at ≤82 B, ~76 B after postcard varints, and that figure is for a track carried without source attachment *or* populated payload extensions. Quoting it for an amplifier-bearing track would be the profile-free number the page's own rule ① forbids. The CTC profile row now says it drops both source attachment and the complete text-amplifier group. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:01:44 -04:00
Joshua Belke	874065eeba	docs(settings): add the ReductStore bytes-tier spec and settle the local ports ... `feature-reductstore-bytes-tier.md` records the owner call of 2026-08-13: ReductStore becomes the default front door for bytes, with S3 demoted from primary store to backend. It is a delivery contract rather than a description — the tier is still opt-in with zero call sites in tree — and it reaches S3 durability with an OSS server plus a sidecar, so no commercial licence sits on the path. Epic `meridian-ozru`. `feature-tactical-picture.md` no longer says the 22 APP-6 amplifiers are uncarried; they are now specified by MIP-CT § 6.5 and merely unwritten by any track writer, which is a different piece of work. The `local.yaml` port profile listed two starting points that the same file also declared reserved — `redis: 6380` (the CoCo stack's) and `health: 8082` (codebase-chat's adminer). A reserved port is never free, so both were walked on every fresh allocation and the settled values were 6381 and 8085 all along. Starting points are meant to be what this host actually settles on, so they now say so. The CoCo stack is added to `reserved` because it is not always up, and a bind probe only sees what is listening right now. `.settings/AGENTS.md` picks up `deepseek-harness/` and a corrected `.gitignore` line reference; `stellar/reference-index.md` indexes the new checkouts. Signed-off-by: Joshua Belke <joshua@innovationhub-act.org>	2026-08-19 14:01:44 -04:00