@7h3/protocol 0.4.0 → 0.5.1

package/docs/PERF_REGRESSION_POLICY.md

@@ -1,34 +0,0 @@
-# 7h3 Protocol AIP Performance Regression Policy
-
-## Purpose
-
-Prevent unreviewed regressions in throughput and tail latency.
-
-## CI gate
-
-- CI must run adaptive open-loop performance gate:
-  - `npm run bench:openloop:adaptive:ci`
-- Fail build if p99 or drop-rate exceeds configured thresholds.
-
-## Release gate
-
-For release candidates:
-
-1. Run baseline and candidate benchmark suites using `full` profiles.
-2. Compare with `npm run bench:diff -- --baseline <...> --candidate <...>`.
-3. Block release if either condition is met without explicit waiver:
-   - throughput regression beyond accepted threshold
-   - p99 regression beyond accepted threshold
-
-## Waiver process
-
-- Waiver requires:
-  - documented reason
-  - owner
-  - rollback plan
-  - follow-up due date
-
-## Reporting
-
-- Attach benchmark artifacts and diff report to release PR.
-- Record claim context with hardware profile and command set.

package/docs/PROJECT_EXAMINATION_2026-05-31.md

@@ -1,219 +0,0 @@
-# @7h3/protocol — Independent Examination (updated 2026-06-01)
-
-**Original examination:** 2026-05-31 · **Updated:** 2026-06-01 (post-extraction, post-publish)  
-**Reviewer stance:** Independent audit — claims split into **Verified** (ran it / read the code) vs **Asserted** (repo says so, unverified).  
-**Repo:** `github.com/IceMasterT/7h3-protocol-aip` · local `/media/artiq/DATA/7h3-protocol`  
-**Package:** `@7h3/protocol@0.1.0` · live on npm · MIT
-
----
-
-## 0) TL;DR
-
-AIP is a **cryptographic hardening envelope for MCP and A2A traffic** — per-message signing, TTL-bounding, and replay-checking that those protocols don't provide natively. It is now extracted, published, and public. The engineering is real. The market gap is real and publicly acknowledged. The first meaningful risk is adoption, not implementation.
-
----
-
-## 1) What shipped
-
-### Core protocol (`aip/0.1`)
-- `protocol.ts` — envelope model, deterministic canonicalization (fixed key order), HMAC-SHA256 / Ed25519 signing and verification over real WebCrypto. Key handles LRU-cached.
-- `protocolTransport.ts` — wire encode/decode (`json` / `compact` / `binary`), full receive pipeline (validate → canonicalize → verify → replay-check), batch/session transport with bounded-concurrency and telemetry hooks.
-- `protocolBinary.ts` — MessagePack binary wire codec (highest-throughput lane).
-- `protocolReplay.ts` — `InMemoryReplayCache` (`(sender, messageId, nonce)` uniqueness window + TTL); `DistributedReplayCache` wrapping any `DistributedReplayStore`.
-- `keyRotation.ts`, `protocolCapabilities.ts`, `protocolAgent.ts` — key lifecycle, capability negotiation, agent identity.
-- `runtimePolicy*.ts` + `policyEnforcer.ts` + `policyTelemetryFeedback.ts` — declarative transport/retry/safety policy with telemetry-driven feedback.
-- `mcpGateway.ts`, `frameworkAdapters.ts`, `agentAdapter.ts` — JSON-RPC gateway runtime, LangChain/LlamaIndex/JSON-RPC bridges.
-
-### Distributed stores (production gap — now closed)
-- `redisClient.ts` — `RedisLikeClient` interface (client-agnostic; no Redis npm dep) + `InMemoryRedisLikeClient` reference impl.
-- `replayStores.ts` — `createRedisReplayStore`: atomic `SET NX PX` reserve, `reserveMany` batch pipeline, `errorBehavior: 'fallback' | 'reject' | 'allow'`, `onDegraded` observability hook. Default: degrade-to-local, never silent.
-- `revocation.ts` — `InMemoryRevocationStore`; `createRedisRevocationStore` (cached reads, **fail-closed default**); `withRevocationCheck` wraps any `SignatureResolver` — one line to add fleet-wide revocation to any verify path.
-
-### MCP hardening wrapper (production gap — now closed)
-- `mcpWrapper.ts` — `wrapMcpServer` / `wrapMcpClient` / `createMcpClientCodec`. Wire message is a signed AIP envelope carrying JSON-RPC in `body.content`; handler receives plain JSON-RPC (zero app changes).
-  - **Recipient binding** — server rejects envelopes not addressed to `selfAgentId` (cross-server relay defense).
-  - **Sender binding** — client accepts responses only when `sender === peerAgentId` (response-spoof defense).
-  - **Correlation binding** — client enforces `correlationId === request messageId` (response-substitution defense).
-  - **Replay on by default** — `InMemoryReplayCache` injected if none supplied.
-- `mcpTransports.ts` — `serveMcpOverStdio` / `createStdioMcpClient` (newline-delimited, in-order sequential chain); `createHttpMcpHandler` / `createHttpMcpClient` (`node:http` + global `fetch`, `binary` mode). No new runtime dependencies.
-
-### Polyglot parity
-- Python SDK (`sdk/python`, `from aip7h3 import …`)
-- Rust SDK + gateway (`sdk/rust`, `use aip7h3::…`)
-- Shared conformance fixtures (`conformance/aip_v0_1.json`) drive byte-identical signature verification across all three runtimes.
-
-### Governance scaffolding
-`docs/`: THREAT_MODEL, KEY_MANAGEMENT_POLICY, CLOCK_SKEW_POLICY, DISTRIBUTED_REPLAY, KEY_REVOCATION, MCP_WRAPPER, TELEMETRY, PERF_REGRESSION_POLICY, VERSIONING_POLICY, MIGRATION_GUIDE, RELEASE_GATE. Benchmark harnesses, release dashboard generator, canary planner.
-
----
-
-## 2) Auditor's ledger
-
-### ✅ Verified (ran it / read the code)
-
-**123 tests pass across 22 files in ~924ms.** (`npx vitest run`, 2026-06-01). Real coverage: envelope conformance, negative/malformed corpus, fuzz/property tests, replay cache (in-memory + distributed + batch), key rotation, transport, binary codec, gateway, policy, revocation, MCP wrapper (round-trip, tamper-reject, replay-reject, recipient/sender/correlation binding), stdio transport (PassThrough streams), HTTP transport (real `http.Server` on ephemeral port).
-
-**Real cryptography.** `protocol.ts` uses `crypto.subtle` — genuine HMAC-SHA256 and Ed25519 (PKCS8/SPKI import, base64url encoding). Not hand-rolled.
-
-**Deterministic canonicalization is real.** Fixed key order (not recursive sort), explicit `body`-then-`header` layout. This is what makes cross-language parity *provable*, not just asserted.
-
-**Genuine tri-language parity.** Python `unittest` and Rust `cargo test` both driven by the same JSON fixture set. Signatures verified against the same known vectors in all three runtimes.
-
-**Redis stores work.** Live-Redis integration test (`redisIntegration.test.ts`): replay reserve via `SET NX PX` and revocation round-trip both confirmed against a real server. Test auto-skips if no server present — no false passes.
-
-**Infinite-recursion bug in fallback chain caught by TDD before shipping.** `createRedisReplayStore` with default `errorBehavior:'fallback'` initially created a fallback store that also tried to create its own fallback. Fixed by passing `{ errorBehavior: 'reject' }` to the inner store. The test suite caught this before it shipped.
-
-**MCP wrapper security bindings all independently tested.** Each binding (recipient, sender, correlation, replay-default) has its own test that verifies rejection of the specific attack it defends against.
-
-**Honest threat model.** Lists remaining open risks (see §6). That candor is a credibility asset.
-
-**Published and public.** `@7h3/protocol@0.1.0` on npm. `github.com/IceMasterT/7h3-protocol-aip` public. 12 GitHub topics set.
-
-### ⚠️ Asserted (treat as marketing until independently reproduced)
-
-- Benchmark numbers are from one dev machine with no external methodology audit. Read them as "comfortably adequate," not headline performance.
-- Python and Rust SDKs share the conformance fixture but the Python Ed25519 path requires the `cryptography` package (skipped if absent). Rust integration is straightforward but has not been published to crates.io.
-- No third-party security audit. For a cryptographic protocol, a formal audit or at minimum an external reproduction of conformance vectors is the credibility step this hasn't cleared yet.
-
-> Precedent from this workspace: a self-reported "95/100" on a separate project was independently re-scored to ~22. The discipline here is better (green suite, shared fixtures, honest risk listing), but the rule stands — believe the test run; discount self-graded readiness claims.
-
----
-
-## 3) Architecture
-
-### Receive pipeline (core)
-
-```
-wire bytes ──▶ decode (json | compact | binary)
-           ──▶ validate envelope shape + policy (version, ids, ttl, clock-skew)
-           ──▶ canonicalize (fixed key order, body→header layout)
-           ──▶ verify signature (HS256 | Ed25519) via key/secret resolver
-                   └──▶ withRevocationCheck (optional, wraps resolver)
-           ──▶ replay-cache check (sender, messageId, nonce) + TTL window
-                   └──▶ InMemoryReplayCache  (single-node)
-                   └──▶ DistributedReplayCache → RedisReplayStore (fleet-wide)
-           ──▶ accept ──▶ app handler
-```
-
-### MCP wrapper pipeline
-
-```
-JSON-RPC request
-    ──▶ createEnvelope (sender=client, recipient=server, content=json-rpc)
-    ──▶ signEnvelope
-    ──▶ [transport: stdio newline / HTTP POST]
-    ──▶ wrapMcpServer receives WireEnvelope
-    ──▶ receiveEnvelope (full pipeline above)
-    ──▶ recipient binding check (recipient === selfAgentId)
-    ──▶ handler(plain json-rpc)  ←─ zero app changes
-    ──▶ signEnvelope(response, correlationId=request.messageId)
-    ──▶ [transport]
-    ──▶ wrapMcpClient decodeResponse
-    ──▶ sender binding (sender === peerAgentId)
-    ──▶ correlation binding (correlationId === request.messageId)
-    ──▶ returns plain JSON-RPC response
-```
-
-**Envelope structure:** `header{version, messageId, timestampMs, ttlMs, sender, recipient?, nonce}` + `body{intent, content, capability?, correlationId?}` + optional `signature{alg, keyId, value}`.  
-**Intents:** `PING / PONG / CAPS / TASK / RESULT / ERROR` — a deliberately minimal verb set.
-
-This is a textbook-correct message-security design: validate → canonicalize → verify → replay → accept. Nothing exotic, everything in the right order.
-
----
-
-## 4) Performance — honest read
-
-Quick-profile benchmarks (single dev machine, 2026-05-31):
-
-| Metric | Value | Interpretation |
-|---|---|---|
-| Canonicalization | ~1.07M ops/s | Near-zero overhead |
-| Compact codec (encode+decode) | ~0.98M ops/s | Near-zero overhead |
-| Sign + verify (HMAC-SHA256) | ~38.3k ops/s | **Binding ceiling** |
-| In-process E2E | ~50k ops/s, p99 ~4.7ms (c=100) | Protocol overhead only |
-| Open-loop adaptive HTTP | ~10.2k ops/s, p99 ~13.4ms, 0% drop | Transport-bound, not protocol-bound |
-
-The crypto sign+verify path (~38k/s/core) is the binding constraint. ~10k/s sustained over HTTP is honest and production-adequate for an agent control plane. This is not a "millions of messages/second" story, and the repo doesn't claim it — it explicitly distinguishes adaptive/sustainable throughput from firehose stress numbers. Market as **"predictable, signed, replay-safe throughput,"** never as raw speed.
-
----
-
-## 5) Best use case
-
-**Lead with:** a drop-in cryptographic trust layer for MCP-mediated tool calls and multi-agent traffic — especially any flow where tool calls trigger real side effects (writes, payments, actions).
-
-AIP is at its best when:
-- 2+ agents or services are exchanging messages,
-- tool calls cause side effects that must not be replayed or tampered with,
-- you need tamper-evidence, replay-safety, and an audit trail,
-- you run a polyglot stack (TS orchestrator + Rust gateway + Python workers) and need signatures to match across all three.
-
-**Runnable entry point:** `npm run aip:mcp:wrap` — demonstrates tampered and replayed requests rejected in under 30 seconds.
-
-**Where not to use it:** single-process prototypes, no trust boundary, exploratory prompt UX. The repo says this itself.
-
----
-
-## 6) Market positioning
-
-The competitive landscape (verified 2026-05-31) strongly favors a **complement-not-compete** posture:
-
-- **MCP** (Anthropic): JSON-RPC messages sent unsigned, no replay protection. Open issues requesting per-message signing. Community spec **MCPS** proposes a signing + nonce envelope as a backward-compatible layer. ~8.5% of MCP servers use OAuth.
-- **A2A** (Google, v1.2): Signed Agent Cards authenticate the identity card for domain verification — **not** per-message task traffic.
-
-AIP implements exactly the missing layer for both. The gap is not a niche opinion — it's in NSA guidance, in public GitHub issues, and in active community proposals. The positioning writes itself:
-
-> **"The signing-and-replay layer your agent protocol forgot."**  
-> Sign, TTL-bound, and replay-protect every MCP/A2A message — with byte-identical verification across TypeScript, Python, and Rust.
-
-Do **not** position AIP as a competing agent protocol. Position it as the hardening envelope / trust middleware those protocols lack natively. The moat is "works today, polyglot, already tested, MIT."
-
-**Standardization risk:** MCPS or MCP itself may standardize this natively. That is the primary time-sensitivity argument. AIP's edge is "running in prod now," not "only possible solution."
-
----
-
-## 7) Shipped state vs original plan
-
-The original examination identified four blockers and five execution steps. Current status:
-
-| Item | Status |
-|---|---|
-| Protocol never published / `private:true` / version `0.0.0` | ✅ `@7h3/protocol@0.1.0` live on npm |
-| Esolang-branded name buries the protocol | ✅ Extracted to `7h3-protocol-aip`; npm `@7h3/protocol` |
-| In-memory replay cache insufficient for multi-node | ✅ `createRedisReplayStore` — atomic `SET NX PX`, batch pipeline, graceful degradation |
-| No revocation/expiry enforcement layer | ✅ `createRedisRevocationStore` + `withRevocationCheck` — fail-closed, cached |
-| No MCP integration artifact | ✅ `wrapMcpServer` / `wrapMcpClient` + stdio + HTTP transport adapters |
-| Repo public and discoverable | ✅ Public, 12 topics, GitHub release v0.1.0 |
-
-**What the original plan identified as gaps that were then built before launch — not retrofitted.** That sequence (design → TDD → ship) is why the shipped state is consistent.
-
----
-
-## 8) Open risks (carry forward)
-
-- **Adoption is the only live risk.** An unadopted protocol's value is ~0 regardless of implementation quality. First real users matter more than a seventh benchmark run. The MCP wrapper is the fastest path to "I protected my MCP server this afternoon."
-- **No independent security audit.** For a signing protocol, a third-party crypto review is the credential that converts skeptics. Particularly: the canonicalization algorithm (fixed-key-order scheme) and the nonce/TTL window assumptions deserve an external read.
-- **No formal fuzz campaign** on parser boundaries (wire decode, envelope validation). Reproducible fuzz corpus welcome.
-- **Distributed stores require an available Redis control plane.** Operators own HA and clock synchronization. Documented in `docs/DISTRIBUTED_REPLAY.md`; runtime degradation is observable via `onDegraded` hook.
-- **Wire version `aip/0.1` is frozen.** Any break to the envelope schema, canonicalization algorithm, or intent vocabulary is a major version bump. The TypeScript API is pre-1.0 — minor version may bring breaking changes.
-- **Python and Rust packages not yet published** (PyPI, crates.io). Polyglot claim is verifiable via the shared conformance fixture, but `pip install` and `cargo add` don't work yet.
-- **Standardization race.** MCPS or MCP native signing could absorb the niche. Speed of community adoption is the hedge.
-
----
-
-## 9) Bottom line
-
-The engineering shipped clean: 123 tests green, real cryptography, genuine tri-language parity, four MCP security bindings all independently tested, distributed stores with graceful degradation, and a live-Redis integration test confirming the round-trip. The original examination's two core diagnoses — *mis-packaged* and *mis-positioned* — have both been addressed. The protocol is now a real, installable, documented, public artifact with honest caveats.
-
-The question is no longer "is this good enough to release?" It is "can it earn enough adoption that the standardization window doesn't close first?" That is a distribution and community problem, not an engineering problem. The MCP wrapper is the lever: it gives any developer a same-afternoon path from "interesting" to "running in my stack."
-
----
-
-### Sources (competitive landscape, verified 2026-05-31)
-
-- MCP lacks per-message auth/integrity: https://github.com/google/mcp/issues/32
-- State of MCP Security 2026 (unsigned messages, no replay, MCPS proposal): https://nimblebrain.ai/blog/state-of-mcp-security-2026/
-- MCP Security Checklist 2026: https://www.networkintelligence.ai/blogs/model-context-protocol-mcp-security-checklist/
-- NSA MCP security guidance: https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI_MCP_SECURITY.pdf
-- "MCP is dead, long live MCPS" (per-message signing + nonce replay envelope): https://dev.to/razashariff/mcp-is-dead-long-live-mcps-5ddp
-- A2A Signed Agent Cards (card-level, not per-message): https://cloud.google.com/blog/products/ai-machine-learning/agent2agent-protocol-is-getting-an-upgrade
-- A2A protocol overview: https://a2a-protocol.org/latest/

package/docs/RELEASE_BENCHMARK_REPORT_2026-05-15.md

@@ -1,135 +0,0 @@
-# Release Benchmark Report (2026-05-15)
-
-## 1) Metadata
-
-- Report ID: `gluv-release-bench-2026-05-15`
-- Date/Time (UTC): 2026-05-15 (updated 2026-05-18)
-- Branch/Commit: `bbcd960` (Fix inFlight counter leak in HTTP batch bench server handler)
-- Runtime: Node.js `v24.10.0`
-- Machine: local benchmark host (same environment used for prior release-gate runs)
-
-## 2) Scope
-
-- Profile: `full` (segmented mode-by-mode to avoid timeout)
-- Modes tested:
-  - `ws`, `ws-batch`, `ws-binary`, `ws-binary-batch`
-  - `http-binary`
-  - `http-batch` (concurrency 10 lanes complete; concurrency 100 unstable/timeout)
-  - `http-binary-batch` (concurrency 10 lanes complete; concurrency 100 incomplete)
-- Payload sizes: `256`, `1024`, `4096` bytes
-- Concurrency levels targeted: `10`, `100`
-
-## 3) Security Configuration Matrix
-
-| Check | Full Secure Protocol |
-|---|---:|
-| Signature verification | enabled |
-| Canonicalization | enabled |
-| Replay defense | enabled |
-| TTL/clock-skew enforcement | enabled |
-| Policy checks/guardrails | enabled |
-
-Notes:
-- Guardrail for unsafe plain `http` high-concurrency was enforced.
-- No benchmark run in this report used invariant-bypass settings.
-
-## 4) Commands Executed (Representative)
-
-```bash
-npx tsx scripts/bench-protocol-openloop.ts --profile full --ci --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes ws
-npx tsx scripts/bench-protocol-openloop.ts --profile full --ci --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes ws-batch
-npx tsx scripts/bench-protocol-openloop.ts --profile full --ci --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes ws-binary
-npx tsx scripts/bench-protocol-openloop.ts --profile full --ci --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes ws-binary-batch
-npx tsx scripts/bench-protocol-openloop.ts --profile full --ci --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes http-binary
-npx tsx scripts/bench-protocol-openloop.ts --profile full --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes http-batch --payloads 256,1024,4096 --concurrency 10
-npx tsx scripts/bench-protocol-openloop.ts --profile full --adaptive --p99-threshold 250 --drop-threshold-pct 2 --adaptive-max-doublings 6 --adaptive-binary-steps 8 --modes http-binary-batch --payloads 256,1024,4096 --concurrency 10
-```
-
-## 5) Results Summary (Best observed per lane)
-
-### Full Secure Protocol (authoritative)
-
-| Mode | Payload | Concurrency | Ops/s | Drop % | p99 ms | Sustainable |
-|---|---:|---:|---:|---:|---:|---|
-| ws | 256 | 100 | 6548.375 | 0.000 | 49.669 | yes |
-| ws | 1024 | 100 | 5887.500 | 0.000 | 53.772 | yes |
-| ws | 4096 | 100 | 3887.500 | 0.000 | 66.011 | yes |
-| ws-batch | 256 | 100 | 7649.000 | 0.000 | 30.971 | yes |
-| ws-batch | 1024 | 100 | 6749.500 | 0.000 | 37.306 | yes |
-| ws-batch | 4096 | 100 | 3850.000 | 0.000 | 49.455 | yes |
-| ws-binary | 256 | 100 | 7261.000 | 0.000 | 53.193 | yes |
-| ws-binary | 1024 | 100 | 5087.375 | 0.000 | 73.307 | yes |
-| ws-binary | 4096 | 100 | 3662.500 | 0.000 | 77.854 | yes |
-| ws-binary-batch | 256 | 100 | 5750.000 | 0.000 | 36.134 | yes |
-| ws-binary-batch | 1024 | 100 | 6499.000 | 0.000 | 35.508 | yes |
-| ws-binary-batch | 4096 | 100 | 4246.000 | 0.000 | 63.565 | yes |
-| http-binary | 256 | 100 | 2699.875 | 0.000 | 129.755 | yes |
-| http-binary | 1024 | 100 | 2385.000 | 0.000 | 119.438 | yes |
-| http-binary | 4096 | 100 | 11993.750 | 0.000 | 17.647 | yes |
-| http-batch | 256 | 10 | 399.125 | 1.359 | 0.867 | yes |
-| http-batch | 1024 | 10 | 291.625 | 1.686 | 0.939 | yes |
-| http-batch | 4096 | 10 | 320.500 | 1.536 | 1.259 | yes |
-| http-binary-batch | 256 | 10 | 276.000 | 1.779 | 0.979 | yes |
-| http-binary-batch | 1024 | 10 | 260.000 | 1.887 | 0.983 | yes |
-| http-binary-batch | 4096 | 10 | 447.500 | 1.214 | 1.260 | yes |
-
-### Updated results after bug fix (2026-05-18, commit `bbcd960`)
-
-Root cause identified and fixed: the `inFlight` counter in the HTTP batch bench server handler was never decremented for batch requests, causing it to accumulate until the server began 503-ing all traffic. Fix: added `finally { this.inFlight -= 1 }` to the batch path.
-
-| Mode | Payload | Concurrency | Ops/s | Drop % | p99 ms | Sustainable |
-|---|---:|---:|---:|---:|---:|---|
-| http-batch | 256 | 100 | 34940.000 | 0.000 | 7.877 | yes |
-| http-batch | 1024 | 100 | 21460.000 | 0.000 | 11.470 | yes |
-| http-batch | 4096 | 100 | 17886.667 | 0.000 | 13.683 | yes |
-| http-binary-batch | 256 | 100 | 28238.000 | 0.000 | 8.551 | yes |
-| http-binary-batch | 1024 | 100 | 19056.000 | 0.000 | 22.214 | yes |
-| http-binary-batch | 4096 | 100 | 11096.000 | 0.000 | 20.675 | yes |
-
-Evidence: `dist/bench/protocol-openloop.quick.2026-05-18T09-23-51-852Z.json`
-
-## 6) SLO Gate Status
-
-Defined gates used in this closure cycle:
-
-- Interactive lanes: `p99 <= 25ms`, `drop <= 2%`
-- High-throughput lanes: `p99 <= 250ms`, `drop <= 2%`
-
-Current status:
-
-- WS lanes (`ws*`): PASS on completed lanes.
-- `http-binary`: PASS on completed lanes.
-- `http-batch` and `http-binary-batch`: PASS at concurrency `100` after `bbcd960` bug fix (0% drop, all p99 within gate).
-
-Overall decision: `GO (all lanes pass SLO gates as of 2026-05-18)`
-
-## 7) Reliability Hardening Applied During Benchmarking
-
-- Added HTTP/2 server stream `error` handling in bench harness.
-- Added HTTP/2 client session `error` handling in bench harness.
-- These are benchmark resilience fixes and do not alter protocol invariants.
-
-## 8) Evidence Artifacts
-
-- `dist/bench/protocol-openloop.full.2026-05-15T08-33-35-118Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T08-48-39-773Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T09-03-28-317Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T09-18-35-320Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T09-33-32-306Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T10-48-40-452Z.json`
-- `dist/bench/protocol-openloop.full.2026-05-15T11-18-47-746Z.json`
-
-## 9) Security Review Checklist
-
-- [x] Signature verification enabled
-- [x] Replay defense enabled
-- [x] TTL/clock-skew checks enabled
-- [x] Canonicalization enabled
-- [x] Policy validation run (`npm run policy:validate`)
-- [x] Release gate re-run after harness changes (`npm run release:gate`)
-
-## 10) Next Actions for Full Closure
-
-- ~~Rework HTTP batch transport path before re-qualification at concurrency `100`.~~ Resolved by `bbcd960`.
-- All transport modes qualified. No further bench gate blockers.
-- Proceed with `@7h3/protocol` publish from `dist/npm-aip/` via release automation.

package/docs/RELEASE_GATE.md

@@ -1,25 +0,0 @@
-# GLUV Release Gate
-
-Run this gate before publishing protocol performance claims or changing transport defaults.
-
-```bash
-npm run release:gate
-```
-
-The gate runs tests, AIP build, lint, wire benchmarks, and adaptive open-loop CI checks. For release candidates, also run:
-
-```bash
-npm run bench:wire:full
-npm run bench:replay:full
-npm run bench:openloop:full
-npm run conformance:binary
-npm run conformance:python
-npm run conformance:rust
-```
-
-## Rollout Rules
-
-- Compact JSON remains the default wire format for `aip/0.1` compatibility.
-- Binary wire and binary WebSocket modes are opt-in until negotiated through `CAPS`.
-- Signature verification, replay defense, TTL validation, and canonicalization must stay enabled in all benchmark claims.
-- README performance numbers must come from fresh benchmark artifacts committed or attached to the release.

package/docs/RELEASE_NOTES_v0.1.0.md

@@ -1,54 +0,0 @@
-# v0.1.0 — First public release
-
-> **The signing-and-replay layer your agent protocol forgot.**
-
-MCP sends JSON-RPC unsigned. A2A signs the identity card, not the traffic.  
-`@7h3/protocol` puts a signed, TTL-bounded, replay-checked AIP envelope around every message — without touching your handler.
-
-## What's included
-
-**Core AIP (`aip/0.1`)**  
-Real WebCrypto HMAC-SHA256 + Ed25519 over a deterministic canonical form. Byte-identical signatures in TypeScript, Python, and Rust via a shared conformance fixture.
-
-**Distributed replay protection**  
-Redis-backed `SET NX PX` atomic reserve. Client-agnostic (`RedisLikeClient`) — works with ioredis, node-redis, or any adapter. Graceful degradation to local store on Redis outage; `onDegraded` hook for observability.
-
-**Fleet-wide key revocation**  
-Cached reads, fail-closed default. Wraps any `SignatureResolver` — one line to add revocation to an existing verify path.
-
-**MCP hardening wrapper**  
-Drop `wrapMcpServer` around your handler. Add `wrapMcpClient` on the caller. Four threat bindings enforced out of the box:
-
-| Binding | Defends against |
-|---|---|
-| Recipient | Cross-server replay |
-| Sender | Response spoofing |
-| Correlation | Response substitution |
-| Replay (default on) | Duplicate execution |
-
-**Transport adapters**  
-`serveMcpOverStdio` + `createHttpMcpHandler` — real transports, no new npm deps.
-
-## Install
-
-```bash
-npm install @7h3/protocol
-```
-
-## Quick demo
-
-```bash
-git clone https://github.com/IceMasterT/7h3-protocol-aip
-cd 7h3-protocol-aip && npm install
-npm run aip:mcp:wrap   # proves tamper + replay rejection
-```
-
-## Honest caveats
-
-- No independent security audit yet — reproductions and findings welcome.
-- Distributed stores require a Redis (or equivalent) control plane; operators own HA and clock sync.
-- Wire version `aip/0.1` is stable; the TypeScript API is pre-1.0 (minor version may bring breaking changes).
-
-## License
-
-MIT.

package/docs/SECURITY_REVIEW_2026-06-05.md

@@ -1,165 +0,0 @@
-# Internal Security Review — AIP v0.1.2
-
-**Date:** 2026-06-05  
-**Reviewer:** Claude Code (AI-assisted internal review)  
-**Scope:** `@7h3/protocol` v0.1.2 — TypeScript sources, Python SDK, Rust SDK  
-**Status:** ⚠️ NOT an independent third-party audit. This review was performed by the same AI assistant that co-developed parts of the codebase. It is published for transparency; it does not substitute for an independent cryptographic audit.
-
----
-
-## Summary
-
-The core cryptographic choices are sound: WebCrypto primitives for both HMAC-SHA256 and Ed25519, constant-time verification, algorithm-confusion guards, and fail-closed revocation. Two real bugs were found and fixed in this review pass. No signature-forgery or authentication-bypass paths were identified.
-
-| Finding | Severity | Status |
-|---|---|---|
-| Replay key collision via unescaped `\|` separator | Medium | **Fixed** — `encodeURIComponent` applied |
-| Empty nonce not rejected by `validateEnvelope` | Low | **Fixed** — error diagnostic added |
-| Rust cargo-fuzz targets uncompiled (README overclaim) | Low | **Corrected in README** |
-| `recipient: null` vs `undefined` — cross-language parity gap | Low | Documented accepted risk |
-| Revocation key space-separator (minor variant of #1) | Low | Documented accepted risk |
-
----
-
-## Finding 1 — Replay Key Collision (Medium, Fixed)
-
-**File:** `src/protocolReplay.ts` — `InMemoryReplayCache.makeKey` and `DistributedReplayCache.makeKey`
-
-**Before:**
-```ts
-return `${envelope.header.sender}|${envelope.header.messageId}|${envelope.header.nonce}`
-```
-
-**Problem:** The `|` separator is unescaped. A sender named `"a|b"` with messageId `"c"` produces the same composite key as sender `"a"` with messageId `"b|c"`. If an attacker controls their own agent ID and can observe or predict a target agent's messageId, they can send a message first that "claims" the target's replay key, causing the legitimate message to be rejected as a replay.
-
-**Security impact:** This is a **false-rejection DoS**, not a forgery or auth bypass. Signatures still cover the full, unencoded field values — an attacker cannot craft a message that validates under a victim's key. The worst they can achieve is having a legitimate message silently dropped.
-
-**Fix applied:**
-```ts
-return `${encodeURIComponent(envelope.header.sender)}|${encodeURIComponent(envelope.header.messageId)}|${encodeURIComponent(envelope.header.nonce)}`
-```
-
-`encodeURIComponent` maps `|` → `%7C`, making cross-boundary collisions impossible. For typical agent IDs containing only word characters and hyphens, the output is byte-identical to the old format — no Redis key migration required for standard deployments.
-
-**Note on deployed keys:** If your Redis instance already contains replay keys with agent IDs containing `|`, `%`, or other URI-reserved characters, those keys will have a different format after this fix. Existing entries will expire naturally via their TTL; no manual migration is needed.
-
----
-
-## Finding 2 — Empty Nonce Not Validated (Low, Fixed)
-
-**File:** `src/protocol.ts` — `validateEnvelope`
-
-**Problem:** `validateEnvelope` checked `messageId`, `sender`, `ttlMs`, `timestampMs`, and `content` but did not validate `nonce`. A missing or empty nonce produces a replay key of the form `sender||messageId`. While this doesn't defeat replay protection outright (the composite key still covers sender + messageId), it eliminates the entropy contribution of the nonce and allows any two messages with identical sender + messageId to collide in the replay cache, regardless of time.
-
-**Fix applied:** Added `if (!nonce.trim()) diagnostics.push({ level: 'error', message: 'Missing nonce — replay protection requires a unique nonce per message' })`.
-
----
-
-## Finding 3 — Rust cargo-fuzz Targets Uncompiled (Low, Corrected)
-
-**File:** `sdk/rust/fuzz/`, `README.md` status table
-
-**Problem:** `cargo-fuzz` is not installed in the development environment. The Rust fuzz targets (`fuzz_decode.rs`, `fuzz_canonicalize.rs`) were authored and reviewed but have never been compiled or run. The prior README entry claimed "✅ cargo-fuzz targets" without this qualification.
-
-**Correction:** The README status now reads: "TypeScript harnesses run clean (50k/20k rounds); Rust targets authored, not yet executed (`cargo-fuzz` not installed)."
-
-The targets themselves look structurally correct:
-- `fuzz_decode`: feeds arbitrary bytes through `decode_envelope` under a no-panic invariant — correct
-- `fuzz_canonicalize`: constructs `ProtocolEnvelope` from fuzz bytes, asserts `canonicalize_envelope` is idempotent — correct
-
-To run:
-```bash
-rustup toolchain install nightly
-cargo install cargo-fuzz
-cargo +nightly fuzz run fuzz_decode --manifest-path sdk/rust/fuzz/Cargo.toml
-cargo +nightly fuzz run fuzz_canonicalize --manifest-path sdk/rust/fuzz/Cargo.toml
-```
-
----
-
-## Finding 4 — `recipient: null` vs Absent (Low, Accepted Risk)
-
-**File:** `src/protocol.ts` — `serializeHeaderCanonical`
-
-```ts
-if (header.recipient !== undefined) {
-  parts.push(`"recipient":${JSON.stringify(header.recipient)}`)
-}
-```
-
-If a JSON message arrives with `"recipient": null`, JavaScript parses this as `null`, which passes the `!== undefined` check. `JSON.stringify(null)` produces `"null"`, so the canonical form includes `"recipient":null` — different from a message where `recipient` is absent entirely.
-
-In the TypeScript type system, `ProtocolHeader.recipient` is typed as `string | undefined`. A `null` value is a type violation but not rejected at runtime.
-
-**Cross-language risk:** The Rust SDK uses `Option<String>` for `recipient`, which serializes `None` as absent (the field is skipped). If a TS caller writes `recipient: null` and the Rust verifier receives it, the canonical forms diverge → signature mismatch.
-
-**Status:** Accepted risk. The correct mitigation is to normalise `null` → `undefined` in the wire decoder. This is tracked as a future improvement. In practice, `null` recipients do not appear in protocol-generated envelopes (`createEnvelope` leaves `recipient` undefined when not supplied).
-
----
-
-## Finding 5 — Revocation Key Space Separator (Low, Accepted Risk)
-
-**File:** `src/revocation.ts` — `InMemoryRevocationStore.makeKey` and `createRedisRevocationStore`
-
-The revocation key format `"${sender} ${keyId}"` uses a space as separator. If a sender ID contains a space (e.g., `"agent one"`) and a keyId starts with something that continues the pattern, a collision is theoretically possible. However:
-
-1. Key IDs in practice are short tokens like `"k1"`, `"prod-key-2026"` — not containing spaces
-2. Agent IDs with spaces are unusual enough to warrant operator documentation
-3. The collision would cause a revocation miss (treating a non-revoked key as revoked, or vice versa) — not an auth bypass
-
-**Status:** Accepted risk. Documented in this review. Consider changing to `${encodeURIComponent(sender)}:${encodeURIComponent(keyId)}` in a future patch.
-
----
-
-## Positive Findings
-
-### Constant-time HMAC verification
-
-`hmacVerify` delegates to `crypto.subtle.verify` (WebCrypto), which is specified to run in constant time. There is no string `===` comparison of signature bytes anywhere on the verify hot path.
-
-### Algorithm confusion rejected
-
-`verifyEnvelopeSignature` checks `signature.alg !== material.alg` before dispatching. An envelope signed with Ed25519 cannot be verified with HMAC material and vice versa — the check is at the dispatch level, before any cryptographic operation.
-
-`verifyEnvelopeHmac` checks `envelope.signature.alg !== 'HS256'` explicitly before calling `hmacVerify`. Same for `verifyEnvelopeEd25519` / `'ED25519'`. Downgrade attacks via algorithm confusion are blocked at two independent points.
-
-### Revocation fail-closed
-
-`createRedisRevocationStore` defaults to `errorBehavior: 'reject'`. A Redis outage causes the store to treat the key as revoked. Cached stale-revoked entries serve during brief outages without allowing a previously-revoked key through.
-
-### MCP wrapper — all four bindings present
-
-Code review confirms all four claimed bindings in `src/mcpWrapper.ts`:
-
-| Binding | Code location | Enforcement |
-|---|---|---|
-| Recipient | line 120: `envelope.header.recipient !== options.selfAgentId` | Returns 32600 error; handler does not run |
-| Sender | line 176: `received.envelope.header.sender !== options.peerAgentId` | Throws; response discarded |
-| Correlation | line 181: `body.correlationId !== decodeOptions.expectCorrelationId` | Throws; response discarded |
-| Replay | `InMemoryReplayCache` injected by default in `wrapMcpServer` | Replay → `consume()` returns `{ok: false}` |
-
-### Cross-language parity (within tested scope)
-
-The three conformance vectors in `conformance/aip_v0_1.json` produce byte-identical signatures in TypeScript, Python, and Rust. The canonicalization format is simple string concatenation with fixed key order; there is no runtime type ambiguity within the tested input set.
-
-**Caveat:** Three vectors are a narrow coverage set. Cross-language divergence on edge cases (very large integers, Unicode normalization, `NaN`/`Infinity` in numeric fields) is not covered by the current conformance suite.
-
----
-
-## Scope Not Covered
-
-| Area | Reason not covered |
-|---|---|
-| WebCrypto Ed25519 implementation | Browser/Node built-in; outside reviewable scope |
-| Binary wire format (protocolBinary.ts) | Not reviewed in this pass — fuzz coverage via `protocolFuzz.advanced.test.ts` exists |
-| Framework adapters (LangChain, LlamaIndex) | Translation adapters; lower security surface |
-| Policy enforcer | Logic review only; not cryptographic |
-| Python pure-Ed25519 implementation | Correctness verified against conformance vector; not audited for side channels |
-
----
-
-## Conclusion
-
-The cryptographic architecture is well-chosen: standard primitives, no custom crypto, constant-time comparison, fail-closed defaults. The two bugs fixed in this review (replay key collision, empty nonce) were low-to-medium severity and have been patched. No authentication bypass, signature forgery, or replay-protection bypass paths were found.
-
-**This review does not substitute for an independent third-party audit by a qualified cryptographer.** The parsing, canonicalization, and replay-cache logic remain unaudited by an external reviewer. Treat accordingly for high-stakes deployments.