Fix Rust compile errors and test infrastructure blocking CI

.gitignore

@@ -19,3 +19,4 @@ __MACOSX/
 ._*
 *.egg-info/
 .pytest_cache/
+rust/tritrpc_v1/target/

docs/ghost-transport-and-fixtures.md

@@ -0,0 +1,53 @@
+# Ghost transport and fixture contract
+
+## Purpose
+This note defines the minimum transport and fixture expectations for Ghost control-plane artifacts carried over TritRPC/TriTRPC.
+
+## Scope
+The Ghost transport surface currently covers:
+- semantic Ghost events (method family `semantic.*`)
+- primeER contradiction-fracture reports (method family `primeER.*`)
+- signed registry update bundles (method family `registry.*`)
+- correlated control-plane validation reports (method family `validation.*`)
+- signed Ghost event wrappers and governance attestations (cross-cutting)
+
+## Method namespace
+Recommended method families:
+- `semantic.declareCell`
+- `semantic.reportLiftedProjection`
+- `primeER.reportContradictionFracture`
+- `registry.reportUpdateBundle`
+- `validation.reportOutcome`
+
+## Fixture classes
+Every method SHOULD have fixtures for:
+- happy
+- warning
+- blocked
+- malformed
+
+Blocked means well-formed but semantically inadmissible.
+Malformed means invalid at transport/schema/canonicalization level.
+
+## Canonical event integrity
+If a payload-bearing Ghost event includes `canonical_hash`, implementations MUST verify:
+
+`sha256(jcs_rfc8785(event_without_canonical_hash))`
+
+where `event_without_canonical_hash` is the event with the top-level `canonical_hash` member removed before hashing, and `jcs_rfc8785(...)` means canonicalization according to RFC 8785 (JSON Canonicalization Scheme) over the resulting JSON value encoded as UTF-8. This RFC 8785 requirement is normative for fixtures and replay. Inputs that cannot be represented or canonicalized under RFC 8785, including duplicate object member names, MUST be treated as malformed.
+
+## Signed wrappers
+Signed wrappers MUST bind:
+- schema ref
+- subject type
+- subject ref
+- canonical hash
+- signer ref
+- key id
+- scope ref
+- issued-at
+- nonce
+- signature
+
+## Notes
+Fixtures are the interoperability contract. Runtime integrations may evolve, but fixture semantics and canonicalization rules must remain replay-stable.

docs/vnext/integration/worldclass_capture/README.md

@@ -0,0 +1,50 @@
+# Worldclass capture: TriTRPC
+
+This branch captures the TriTRPC portion of the worldclass wire/semantic control-fabric work developed in chat on 2026-04-09.
+
+## Purpose
+
+This is a preservation and landing branch. It exists so the work is captured in GitHub in the correct repository with the current public repo direction taken into account.
+
+## Current repo reality
+
+The public repo now exposes a unified-v4 integration direction. That means the correct framing for the chat work is:
+
+- not a detached parallel spec
+- not a competing beacon model
+- but a unified-v4 extension / annex / landing layer
+
+## Core TriTRPC recommendations captured here
+
+1. Keep Beacon-A/B/C as the native beacon family.
+2. Treat typed semantic deltas as the concrete realization of the repo's own stated target.
+3. Keep handle-routed inheritance and compact semantic coordinates as the hot-path rule.
+4. Add semaphore and barrier coordination semantics as first-class control-plane material.
+5. Revisit the topic codebook so temporal semantics and environment/boundary semantics are first-class rather than hidden.
+
+## Source bundles produced in chat
+
+The strongest local bundles generated during the work were:
+
+- `worldclass_outputs_v4.zip`
+- `worldclass_outputs_v5.zip`
+- `worldclass_outputs_v6.zip`
+- `worldclass_outputs_v7.zip`
+- `worldclass_outputs_v8.zip`
+
+The TriTRPC-specific patch material was organized under the local paths:
+
+- `repo_patchsets/TriTRPC/patches/0001-topic25-and-kind243.patch`
+- `repo_patchsets/TriTRPC/patches/0002-typed-beacons-fixtures-and-harness.patch`
+- `repo_patchsets/TriTRPC/patches/0003-ci-and-benchmark-capture.patch`
+
+## Immediate landing order
+
+1. Reconcile any capture material against the current unified-v4 master draft.
+2. Land integration notes and annex-grade prose first.
+3. Land codebook / kind / fixture deltas next.
+4. Only then push into native runtime parity and benchmark captures.
+
+## Important note
+
+This branch preserves the work and the landing plan. It does not claim that all captured ideas are already canonical or merged.

docs/vnext/integration/worldclass_capture/TriTRPC_artifact_inventory.md

@@ -0,0 +1,13 @@
+# TriTRPC artifact inventory
+
+This file is retained as a TriTRPC-specific entry point for discoverability.
+
+The canonical inventory for these worldclass capture artifacts now lives in
+[`docs/vnext/integration/worldclass_capture/artifact_inventory.md`](./artifact_inventory.md).
+
+Please update the canonical inventory instead of duplicating changes here.
+
+TriTRPC-specific local bundle patch material referenced by that inventory includes:
+- `repo_patchsets/TriTRPC/patches/0001-topic25-and-kind243.patch`
+- `repo_patchsets/TriTRPC/patches/0002-typed-beacons-fixtures-and-harness.patch`
+- `repo_patchsets/TriTRPC/patches/0003-ci-and-benchmark-capture.patch`

docs/vnext/integration/worldclass_capture/artifact_inventory.md

@@ -0,0 +1,55 @@
+# Artifact inventory: TriTRPC (worldclass capture)
+
+This is the canonical inventory for the TriTRPC-relevant artifacts produced in the local worldclass bundles during the 2026-04-09 chat work.
+
+See [`TriTRPC_artifact_inventory.md`](./TriTRPC_artifact_inventory.md) for the TriTRPC-specific entry point.
+
+## Core TriTRPC material identified for this repo
+
+### Unified-v4 integration / narrative material
+- unified integration rebase note
+- current public repo reconciliation note
+- topic25 vs topic26 follow-up note
+- typed beacons and semaphores addendum
+- full updated spec and apply playbook (for extraction of repo-specific sections)
+
+### Codebook and kind extensions
+- topic25/topic26-oriented codebook evolution notes
+- KIND243 extension proposals for additional beacon / semaphore / barrier kinds
+
+### Fixtures and sequence artifacts
+- semantic beacon sequence fixture
+- artifact commit boundary sequence fixture
+- semaphore barrier sequence fixture
+
+### Benchmark and harness material
+- benchmark matrix
+- agentic coordination scenario
+- scoring rubric
+- harness input and capture templates
+- comparison helper
+
+### Patch material
+Local bundles organized TriTRPC patch material as:
+- `repo_patchsets/TriTRPC/patches/0001-topic25-and-kind243.patch`
+- `repo_patchsets/TriTRPC/patches/0002-typed-beacons-fixtures-and-harness.patch`
+- `repo_patchsets/TriTRPC/patches/0003-ci-and-benchmark-capture.patch`
+
+## Current public repo alignment
+
+The public repo now exposes a unified-v4 integration direction. Therefore the material above should be interpreted as:
+
+- unified-v4 extension material
+- annex-grade typed semantic delta / semaphore / barrier material
+- fixture and benchmark harness additions
+- follow-on runtime parity work
+
+It should not be treated as a detached competing spec line.
+
+## Recommended landing strategy
+
+1. Land integration notes and annex-grade prose first.
+2. Land codebook and kind extensions second.
+3. Land fixtures and benchmark harness third.
+4. Land native runtime parity work after the above are reviewable.
+

docs/vnext/integration/worldclass_capture/benchmarks/agentic_coordination_scenario.md

@@ -0,0 +1,14 @@
+# Agentic Coordination Scenario
+
+Measure a shared-context, multi-agent flow with:
+
+1. environment capability beacon
+2. route/context handle establishment
+3. typed semantic intent beacon
+4. semaphore request/grant
+5. stream data reuse under inherited semantics
+6. barrier release for review/freeze
+7. artifact commit with manifest/hash refs
+
+Baselines should approximate the same scenario using gRPC+Proto, Thrift Compact,
+and Avro RPC plus application-level metadata/control conventions.

docs/vnext/integration/worldclass_capture/current_public_repo_reconciliation.md

@@ -0,0 +1,37 @@
+# Current public repo reconciliation summary
+
+This note records how the worldclass chat work should be interpreted against the current public `TriTRPC` repository snapshot.
+
+## Public snapshot findings
+
+The public repository now exposes a unified integration lane under `docs/vnext/integration/`, with a unified-v4 master draft acting as the working canonical spine while the workstreams are reconciled.
+
+The public materials also continue to state that:
+
+- Beacon-A/B/C remain the native beacon family
+- typed semantic deltas are still a target that needs to be realized
+- native Go/Rust parity for newer semantic carriage is still unfinished
+- authoritative codebooks still need freezing
+- benchmark capture still needs native execution evidence
+
+## Reconciliation rule
+
+Interpret the captured worldclass work as:
+
+- unified-v4 extension material
+- annex-grade typed semantic delta and semaphore/barrier semantics
+- codebook evolution guidance
+- benchmark and fixture scaffolding
+
+Do **not** interpret it as a detached competing protocol line.
+
+## Practical consequence
+
+The safest landing order is:
+
+1. integration notes and annex prose
+2. codebook and kind extensions
+3. fixtures and benchmark harness
+4. native runtime parity work
+
+That order minimizes semantic drift against the current public repo direction.

docs/vnext/integration/worldclass_capture/fixtures/fixture_boundary_artifact_commit_sequence.json

@@ -0,0 +1,22 @@
+{
+  "sequence_id": "seq-artifact-commit-001",
+  "events": [
+    {
+      "kind": "env-cap",
+      "epoch_id": "env-epoch-001",
+      "artifact_root": "/mnt/data"
+    },
+    {
+      "kind": "beacon-boundary-delta",
+      "action": "copy-to-artifact",
+      "source": "/home/user/.config",
+      "result": "staged-selected-file-only"
+    },
+    {
+      "kind": "artifact-commit",
+      "bundle_id": "acb-001",
+      "manifest_ref": "artifact:manifest-001",
+      "hash_ref": "sha256:archive-001"
+    }
+  ]
+}

docs/vnext/integration/worldclass_capture/fixtures/fixture_semantic_beacon_sequence.json

@@ -0,0 +1,32 @@
+{
+  "sequence_id": "seq-semantic-beacon-001",
+  "events": [
+    {
+      "kind": "stream-open",
+      "route_h": "rh:precursor-evidence-stream",
+      "context_h": "ch:ce1002-prep-window",
+      "defaults": {
+        "braid": "str.sch",
+        "state": "verified-review-local"
+      }
+    },
+    {
+      "kind": "beacon-intent",
+      "bundle_h": "bh:intent-ce1002-v1",
+      "semantic_refs": [
+        "cell-kairos-ce-001",
+        "tcell-chrono-001"
+      ]
+    },
+    {
+      "kind": "stream-data",
+      "stream_id": 1,
+      "payload_ref": "artifact:evidence-chunk-001"
+    },
+    {
+      "kind": "beacon-commit",
+      "bundle_h": "bh:commit-ce1002-v1",
+      "result": "promoted"
+    }
+  ]
+}

docs/vnext/integration/worldclass_capture/topic26_followup_note.md

@@ -0,0 +1,51 @@
+# Topic26 follow-up note
+
+## Why topic25 was proposed
+
+The earlier chat work moved from `topic23.proposed.v1` to a proposed `topic25` because two missing first-class lanes were repeatedly encountered:
+
+1. temporal / CHRONOS-style semantics
+2. environment / toolchain / boundary semantics
+
+The move to 25 was a conservative minimum-change correction, not a wire-budget constraint.
+
+## Why 26 may be better
+
+Later work sharpened an important distinction:
+
+- environment / toolchain capability is not the same as boundary / artifact / export control
+
+Those two concerns have different cadence, ownership, and control semantics.
+
+### Environment / toolchain capability
+Examples:
+- runtime feature surface
+- browser/control availability
+- renderer availability
+- SDK / generated type surface
+- helper stack availability
+
+This is mostly macrobeat material.
+
+### Boundary / artifact / export control
+Examples:
+- artifact root
+- runtime-private state
+- scaffold visibility without exportability
+- export-deny posture
+- manifest and audit requirements
+- replay-sensitive commit behavior
+
+This is mostly async and commit-plane material.
+
+## Recommendation
+
+Treat `topic25` as the conservative correction and `topic26` as the stronger mature direction.
+
+The likely extra topic should be a first-class boundary / artifact / admissibility lane, separate from environment / toolchain.
+
+That preserves one-byte braid viability while improving semantic clarity.
+
+## Why this note exists
+
+This is captured here so the later topic26 reasoning is not lost just because earlier pack artifacts were built around topic25.