Feat/cep8 explicit gating by 1amKhush · Pull Request #75 · ContextVM/sdk

1amKhush · 2026-06-11T11:30:10Z

Feat: CEP-8 Explicit Gating Lifecycle

Resolves: #74
Reference Spec: ContextVM/contextvm-docs#44

Description

This PR introduces full support for the Explicit Gating payment lifecycle (explicit_gating mode) in the ContextVM TypeScript SDK, as mandated by the latest CEP-8 specification updates.

Previously, the SDK only supported the default transparent notification-based payment flow. With this update, servers can now strictly gate priced capabilities by returning JSON-RPC error responses (-32042 Payment Required and -32043 Payment Pending), effectively blocking execution until a verifiable payment is made.

Key Changes & Architecture

Types & Constants:
- Introduced standard error codes -32042 and -32043.
- Added payment_interaction to negotiation tags.
- Implemented CanonicalInvocationIdentity utilizing RFC-8785 JSON canonicalization (JCS) and SHA-256 to ensure idempotent matching between paid authorizations and retried executions.
Server Middleware (createExplicitGatingMiddleware):
- Tracks paid executions using a new TTL-bounded AuthorizationStore with strict check-and-set atomicity.
- Emits -32043 with a precise mathematically computed retry_after if a request races against an active payment verification.
Transport Negotiation:
- Added capabilities to ClientSession to track both requestedPaymentInteraction and effectivePaymentInteraction.
- Transports automatically validate the payment_interaction mode and safely fallback to transparent mode to prevent injection of untyped interactions.
Client Handling (withClientPayments):
- Intercepts explicit gating error responses upstream, completely shielding the main MCP caller.
- Delegates resolution strictly to the user's onPaymentRequired handler hook.
- Supports completely autonomous auto-retry of the exact original request upon successful payment.
- Includes resilient exponential backoff for -32043 errors capped at 5 MAX_RETRIES, alongside robust memory management (timer cancellation on transport termination).

Testing

Unit Tests: Full coverage for AuthorizationStore concurrency, JCS hashing, and edge cases. (Timings have been buffered to prevent CI flakiness).
Integration/E2E Tests: A complete end-to-end flow (payments-flow.test.ts) that runs a client request → intercepts -32042 → delegates to user payment logic → auto-retries → consumes authorization → and successfully returns the result.

Notes-

The atomicity inside AuthorizationStore.trySetPending relies on in-memory Maps and is therefore strictly single-process. Extensive doc comments have been added noting that distributed environments should implement an external Redis Redlock using the CanonicalInvocationIdentity.
Backward compatibility is 100% maintained. Legacy clients not advertising the new mode will continue running through the default transparent capability.

Copilot

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds CEP-8 “explicit_gating” payment interaction mode support across Nostr client/server transports, including negotiation tags, server-side authorization gating, and client-side auto-retry behavior for -32042/-32043.

Changes:

Introduces explicit-gating server middleware with canonical invocation hashing + authorization store.
Adds client negotiation/disclosure plumbing (payment_interaction tags) and client auto-retry handling for -32042/-32043.
Refactors shared server payment utilities and adds unit + transport-level tests.

Reviewed changes

Copilot reviewed 27 out of 28 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
src/transport/payments-flow.test.ts	Adds a transport-level test for explicit-gating behavior and retry flow.
src/transport/nostr-server/session-store.ts	Stores requested/effective payment interaction on server sessions.
src/transport/nostr-server/outbound-response-router.ts	Discloses effective `payment_interaction` on first response (CEP-8).
src/transport/nostr-server/inbound-coordinator.ts	Parses client `payment_interaction` request and sets per-request context.
src/transport/nostr-server-transport.ts	Exposes API to configure supported payment interaction mode.
src/transport/nostr-client/server-metadata-store.ts	Persists server-disclosed effective payment interaction mode.
src/transport/nostr-client/outbound-sender.ts	Stores raw JSON-RPC request into correlation metadata for retries.
src/transport/nostr-client/inbound-coordinator.ts	Captures server-disclosed `payment_interaction` tag and passes event id to response handler.
src/transport/nostr-client/correlation-store.ts	Extends pending request state to include the raw JSON-RPC request.
src/transport/nostr-client-transport.ts	Exposes get/set API for payment interaction negotiation and forwards response context.
src/transport/middleware.ts	Extends inbound middleware context with `paymentInteraction`.
src/transport/capability-negotiator.ts	Advertises requested `payment_interaction` tag from the client.
src/payments/types.ts	Adds explicit-gating types: interaction mode, error data shapes, canonical identity.
src/payments/server-transport-payments.ts	Wires explicit-gating middleware + discovery tags into server transport.
src/payments/server-payments.ts	Refactors shared helpers into a new utils module; adds paymentInteraction option.
src/payments/server-payments-utils.ts	New module for timeout/capability matching and resolvePrice type guards.
src/payments/server-explicit-gating.ts	Implements explicit-gating server middleware returning `-32042/-32043`.
src/payments/server-explicit-gating.test.ts	Unit tests for explicit-gating server middleware.
src/payments/constants.ts	Adds explicit-gating error codes and negotiation error code constant.
src/payments/client-payments.ts	Adds client-side explicit-gating handling, auto-retry, and pending backoff.
src/payments/client-payments.test.ts	Adds tests for `-32042/-32043` handling and retry behavior.
src/payments/canonical-identity.ts	Computes canonical invocation hash/identity using JSON canonicalization + SHA-256.
src/payments/canonical-identity.test.ts	Unit tests for canonical hashing determinism and identity composition.
src/payments/authorization-store.ts	Adds LRU+TTL store for pending/granted paid authorizations.
src/payments/authorization-store.test.ts	Unit tests for authorization store behavior (TTL, pending, eviction).
src/core/constants.ts	Adds `PAYMENT_INTERACTION` to Nostr tag constants.
package.json	Adds `json-canonicalize` dependency.
bun.lock	Locks `json-canonicalize` dependency.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

1amKhush · 2026-06-13T16:17:10Z

@ContextVM-org Up for review! Lmk if the implementation need refining?

ContextVM-org · 2026-06-16T10:32:38Z

Thanks for this — it covers a lot of spec ground and the tests are thorough. I found two blocking issues, several significant ones, and a pervasive code-style violation that needs addressing across the diff.

🔴 Blocking

1. Server ignores per-session payment_interaction negotiation

withServerPayments installs only one middleware based on the global config option. createExplicitGatingMiddleware gates every priced invocation unconditionally — it never reads ctx.paymentInteraction. This means a legacy client that never opted into explicit_gating will still receive -32042 errors it cannot handle. CEP-8 is explicit that explicit gating is opt-in, and the PR claims 100% backward compatibility.

Fix: Both middlewares need an early guard:

if (ctx.paymentInteraction !== 'explicit_gating') { await forward(message); return; }

Then withServerPayments should install both middlewares so the effective session mode selects the behavior.

2. canonical-identity.ts uses Node crypto.createHash

src/payments/canonical-identity.ts:4 imports createHash from crypto. This is a public-API file and must remain browser-safe per AGENTS.md. Use the existing dependency @noble/hashes (sha256) or crypto.subtle.digest('SHA-256', …).

🟠 Significant

3. -32042 response omits instructions

CEP-8 says error.data.instructions SHOULD be present. createExplicitGatingMiddleware builds data: { payment_options: [...] } without it. Add a standard instruction string.

4. payment_interaction tag sent on every request

ClientCapabilityNegotiator.getNegotiationTags emits the tag on every outbound request. CEP-8 says clients SHOULD send it at most once, on the first direct message. Track a hasSentPaymentInteraction flag.

5. Unbounded rawRequestCache

withClientPayments stores every outgoing request in a plain Map and only cleans entries on non-explicit-gating terminal responses. Over a long-lived transport this is an unbounded memory leak. Wrap it in an LRU.

6. Retry/backoff behavior doesn't match the PR description

The description claims "exponential backoff" with a "precise mathematically computed retry_after". In practice:

retry_after is hard-capped at Math.min(2, …) — effectively always ≤ 2 seconds.
The client just sleeps for retry_after * 1000 ms with no exponential multiplier.
MAX_RETRIES is hard-coded and not configurable.

Either implement true exponential backoff or update the description.

7. Confusing handler logic in the explicit-gating path

In maybeHandlePaymentRequired the explicit -32042 branch loops over payment_options and checks handler/canHandle, but never calls handler.handle. All decision-making is on onPaymentRequired. Extract the explicit-gating path into its own function and drop the dead handler loop.

8. Long stream-of-consciousness comments

client-payments.ts contains speculative design notes ("Wait, we need to create a new ID…", "But actually we are the transport…") that should not be committed. Per AGENTS.md comments should be brief and explain "why", not document the author's thought process.

🟡 Inline `import('…').Type` pattern (forbidden)

The diff uses inline type imports extensively — for example:

// Instead of a top-level import:
import('./types.js').PaymentInteractionMode
import('../../payments/types.js').PaymentInteractionMode
import('@contextvm/mcp-sdk/types.js').JSONRPCErrorResponse

This appears across 15+ files including:

AGENTS.md says: "All relative imports must include the .js extension to ensure ESM compatibility." These import('…') expressions are ESM-incompatible dynamic imports that also add visual noise and repetition. Replace all of them with top-level import type { … } statements. This also reduces the number of lines in the diff.

🟢 Minor / Code quality

Duplicated price/processor resolution between createServerPaymentsMiddleware and createExplicitGatingMiddleware. Extract a shared helper.
Extra blank lines in server-payments.ts:80-82,122-124 and server-explicit-gating.ts:25. Run bun prettier --write src/.
Grant TTL is bound to verification timeout: authorizationStore.grant(identity, effectiveTimeoutMs) means a slow verification can exhaust most of the authorization window. Consider granting until the original payment option TTL instead.
Missing tests for backward compat: no test covers a client that did NOT request explicit_gating against a server configured with explicit_gating, nor the -32602 unsupported-mode path. Adding these would have caught issue feat: add nostr proxy server with bidirectional message routing #1.
withClientPayments is ~820 LOC, modestly over the ~700 LOC heuristic in AGENTS.md. Splitting explicit-gating handling into a separate module would improve readability.

✅ What's solid

Constants, types, and tag structures are well-aligned with CEP-8.
AuthorizationStore has clean single-process atomicity with good documentation about distributed limits.
The client wrapper correctly intercepts -32042/-32043 upstream and auto-retries transparently.
The E2E test in payments-flow.test.ts:1014 exercises the full round-trip.

Summary

The two blockers (per-session middleware selection + Node crypto usage) must be resolved before merge. The inline-import pattern should be replaced project-wide. Once those are fixed and the retry/backoff claims are reconciled with the implementation, this will be a clean PR.

ContextVM-org · 2026-06-17T12:24:01Z

The fix commits correctly resolve the two original blockers and clean up the inline-import pattern. Here's what still needs attention before merge.

🔴 Missing Tests (blocking)

No test covers either of these paths, and both touch claim of 100% backward compatibility:

Legacy transparent client vs server configured with explicit_gating — the ctx.paymentInteraction guard in both middlewares handles this now, but without a test it regresses silently
-32602 unsupported payment_interaction error — the server inbound coordinator returns this when a client requests explicit_gating but the server doesn't support it; the path is untested

🟠 Redundancy

~55 lines of price-resolution pipeline duplicated between server-payments.ts and server-explicit-gating.ts. Steps 1–7 (processor resolution → resolve price → rejection/waiver → payment creation → timeout computation) are identical; only the response format diverges at step 8. Extracting a shared resolveAndInitiatePayment() would eliminate the duplication and also fix the missing duplicate-PMI-processor warning in the explicit-gating middleware (the transparent middleware warns — the explicit one silently drops duplicates).

🟡 Consistency Gaps

markDiscoveryTagsSent() now manages two unrelated flags — hasSentDiscoveryTags (conditional set) and hasSentPaymentInteraction (unconditional set). The method name doesn't describe its expanded responsibility. Moving hasSentPaymentInteraction = true into getNegotiationTags() (set-on-read) would keep each concern self-contained.
Oversized transfer paths skip mark-as-sent/disclosed calls — outbound-sender.ts:164 and outbound-response-router.ts:182 have early returns that bypass markDiscoveryTagsSent() and maybeAppendPaymentInteractionDisclosure(). Low risk in practice (oversized triggers only for large payloads, negotiation happens early with small messages), but worth a comment or a follow-up issue.
Grant TTL uses Math.min(verifyTimeoutMs, paymentTtlMs) — a slow verification can exhaust most of the authorization window. Consider using the original payment option TTL instead.

🟢 Formatting

Two regressions from commit 61173bf:

outbound-sender.ts:4: JSONRPCRequest } → missing type keyword, bad indent
correlation-store.ts:2: JSONRPCResponse , JSONRPCRequest → space before comma

ContextVM-org · 2026-06-19T16:10:32Z

🔴 Blocker — Branch is 8 commits / 2 days behind master

master is not an ancestor of HEAD (merge base is 4f4ab2c from Jun 12; branch tip is Jun 17; master tip is Jun 19). Merging this PR as-is regresses real, shipped fixes:

Reverted master fix	File
`fix(transport): handle encryption size limits in chunk sizing` (`c71d556`)	`base-nostr-transport.ts` — the try/catch around `measurePublishedMcpMessageSize` is gone
`fix(transport): attach open-stream writer for oversized (CEP-22) requests` (`6398966`)	`nostr-server/inbound-coordinator.ts`, `open-stream-factory.ts`
`fix(transport): resolve open-stream and progress token conflicts` (`e81d76c`)	transport open-stream paths
`fix: forward progress notifications for oversized transfer timeout` (`d80850c`)	transport oversized paths

Also: package.json version 0.12.4 → 0.12.0, CHANGELOG loses the 0.12.1–0.12.4 entries, and 5 test files added on master (inbound-notification-dispatcher.test.ts, outbound-sender.test.ts, open-stream-factory.test.ts, three open-stream/oversized e2e tests) vanish from the diff.

Action: rebase onto current master (or merge master in). Expect conflicts in nostr-server/inbound-coordinator.ts (both branches edit the payment-interaction vs. open-stream-writer regions) and open-stream-factory.ts. Re-run the full suite after.

🟠 New regression — set-on-read `getNegotiationTags()` eats the `payment_interaction` tag in the oversized measurement path

This was introduced by adopting the previous review's suggestion to move hasSentPaymentInteraction = true into the getter (capability-negotiator.ts:272). Trace in outbound-sender.ts:

For any request carrying a _meta.progressToken, line 77 calls buildOutboundTags({ includeDiscovery: true }) purely to measure size.
That calls getNegotiationTags(), which appends ['payment_interaction', ...] and sets hasSentPaymentInteraction = true as a side effect.
The measured tags are discarded.
The real send at line 109 calls buildOutboundTags again — but now the flag suppresses the tag, so it never reaches the wire.

Blast radius is narrow because initialize (the spec-mandated first direct message) has no progress token, so the standard handshake emits the tag correctly at line 109 and the measurement path is skipped. The bug only bites when the first wire send is a request with a progress token — most importantly stateless mode, where initialize is emulated locally (emulateInitializeResponse) and never goes through the outbound sender, leaving hasSentPaymentInteraction = false. A stateless client requesting explicit_gating whose first real tools/call has a progress token will silently lose the tag, the server will treat the session as transparent, and the explicit-gating contract is violated without any error.

Fix options (either is fine):

Revert to setting the flag in markDiscoveryTagsSent() (post-send), which is where it was before and was correct. The "two unrelated flags" complaint from last round can be solved instead by renaming or splitting the method.
Or pass a dryRun/consume flag through buildOutboundTags → getNegotiationTags so the measurement call doesn't mutate state.

A regression test should accompany the fix: stateless client + setPaymentInteraction('explicit_gating') + first request with a progress token → assert the outbound event carries ['payment_interaction','explicit_gating'].

✅ Resolved from the previous review

Prior item	Status
Redundant ~55-line price-resolution pipeline	✅ Extracted to `resolveAndInitiatePayment()` in `server-payments-utils.ts`, used by both middlewares
Explicit-gating middleware silently dropped duplicate PMI processors	✅ Now warns (matches transparent middleware)
`-32602` unsupported `payment_interaction` untested	✅ Integration test added in `nostr-server-transport.test.ts`
Legacy transparent client vs `explicit_gating` server untested	✅ Unit test added (`server-explicit-gating.test.ts:109`); full e2e not added but the guard is simple and unit-covered
`markDiscoveryTagsSent()` managing two unrelated flags	✅ Flag moved into `getNegotiationTags()` — but see the regression above
Oversized paths skip mark-as-sent/disclosed	✅ Documented with explicit comments at `outbound-sender.ts:101` and `outbound-response-router.ts:182`
Grant TTL `Math.min(verifyTimeoutMs, paymentTtlMs)`	✅ Now uses `paymentRequired.ttl * 1000 ?? paymentTtlMs`
Formatting regressions (`outbound-sender.ts:4`, `correlation-store.ts:2`)	✅ Both fixed

All 64 payment tests + 44 transport/payment-flow tests pass; tsc --noEmit is clean.

🟡 Minor / cleanup

Dead constant. NOSTR_TAGS.PAYMENT_INTERACTION (core/constants.ts:126) is defined but never referenced — every call site uses the string literal 'payment_interaction' directly (6 occurrences). Either use it or drop it. Prefeer use it to avoid magic strings
Convoluted retry_after. server-explicit-gating.ts:100-106 — Math.min(2, Math.ceil(remaining/1000)) || 2 always reduces to 1 or 2 (and the || 2 only fires when remaining is 0). If the intent is "suggest 2 s, or less if the pending window is about to expire", the current expression already does that, but the trailing || 2 is dead in practice. Simplify to Math.min(2, Math.max(1, Math.ceil(remaining/1000))) or just a constant with a comment.
MAX_RETRIES = 5 for -32043 is hardcoded and tight. With retry_after=2 and 1.5^n backoff capped at 10 s, the client gives up after ~26 s of cumulative wait. Server-side verification can legitimately run up to min(verifyTimeoutMs, paymentTtlMs) (default 300 s). A slow-but-successful verification that takes >26 s surfaces a -32043 error to the caller even though a paid authorization lands moments later. Consider exposing maxPendingRetries / pendingRetryBackoff on ClientPaymentsOptions, or raising the default.
No e2e for the -32043 race. The pending path is unit-tested on both sides, but there's no end-to-end test exercising: client pays → server verification slow → client retry hits -32043 → backoff → eventual success. The happy-path -32042 e2e exists; the pending-race e2e would lock in the interaction between AuthorizationStore.trySetPending, the async verifyPayment, and the client's backoff loop. Nice-to-have, not blocking.

Recommended next steps

Rebase onto master and resolve conflicts (the blocker). Re-run bun test — the master test files will start running and may surface issues against the new payment code.
Decide on the getNegotiationTags set-on-read issue — I'd revert to post-send flagging and solve the naming concern separately; add the stateless regression test.
Sweep the minor items (dead constant, retry_after simplification, configurable retry budget).
After rebase, this should be ready to merge.

Resolves ContextVM#74 by adding full support for the explicit gating payment lifecycle in the ContextVM TypeScript SDK. Includes server middleware for tracking authorization states, client support for auto-retrying intercepted -32042/-32043 errors, and transport modifications to negotiate payment modes.

- Fix integration test failure: remove getPendingRequestForEventId() guard from -32042/-32043 handlers. resolveResponse() consumes the correlation entry before the payment wrapper reads it, so the lookup always returned undefined. Use rawRequestCache as the authoritative source for retry requests instead. - Fix TS2769/TS2339 typecheck errors in client-payments.test.ts - Fix TS6133 unused parameter errors in server-explicit-gating.test.ts - Remove as any cast in server-transport-payments.ts - Wire -32602 error in inbound-coordinator.ts for unsupported modes - Delete accidental package-lock.json (project uses bun.lock)

…eraction learning - Server inbound-coordinator: set effectivePaymentInteraction = 'transparent' before early return when rejecting unsupported explicit_gating. Prevents inconsistent session state (requestedPaymentInteraction set but effectivePaymentInteraction undefined). - Client inbound-coordinator: move payment_interaction tag parsing before the initialize-event early return. The server sends this tag once on its first response, which was previously unreachable because the first event triggers setInitializeEvent() + return before the tag parsing code.

…tvm/mcp-sdk

…erage Spec compliance: - -32602 (unsupported payment_interaction) now carries data: { requested, supported } - -32042/-32043 instructions emphasize retrying with the same method and params - Client effective-mode guard: declines transparent payment_required when the server did not accept explicit_gating for the session Behavior-preserving refactor: - AuthorizationStore simplified to single-use grants (dropped count/remaining/ hasPending); surface confirmed internal-only - Extracted shared buildProcessorsByPmi so the duplicate-PMI warning fires once and the registry is built once across both server middlewares - Split maybeHandlePaymentRequired into explicit-gating + transparent handlers behind a slim classifier - Extracted synthesizePaymentError / dispatchAndForward; consolidated all client-side decline-error synthesis through the single helper Tests (+12 pass): - Explicit-gating e2e: server disclosure, -32043 pending race, user-decline, handler-error, verify-fail-fresh-invoice, -32602 negotiation - Transparent e2e: resolvePrice rejection -> -32000 - Unit: middleware lifecycle, verify-failure fresh -32042, onPaymentRequired reject contract, -32043 retry exhaustion 429 -> 441 pass / 0 fail / 5 skip; tsc clean. docs/: cep-8-update.md (spec reference), pr-improvements.md (review + decisions)

ContextVM-org · 2026-06-20T13:34:52Z

Summary of changes since last review — closes the remaining CEP-8 spec gaps, simplifies internal state, and locks the explicit-gating flow with integration tests. All behavior-preserving refactors verified against the existing suite (429 → 441 pass / 0 fail / 5 skip, tsc clean).

Spec compliance (correctness)

-32602 carries data (inbound-coordinator.ts): { requested, supported: ['transparent'] } per the CEP-8 effective-mode-disclosure requirement.
-32042/-32043 instructions (server-explicit-gating.ts): now emphasize retrying with the same method and params.
Client effective-mode guard (client-payments.ts): a client that requested explicit_gating no longer auto-satisfies a transparent payment_required when the server did not accept it for the session — synthesizes a -32000 decline instead. Implements the "SHOULD NOT auto-satisfy" rule.

Behavior-preserving refactor

AuthorizationStore → single-use grants: dropped count/remaining/hasPending and the LRU refresh (surface confirmed internal-only; no production caller used the removed surface).
Shared buildProcessorsByPmi: built once in withServerPayments, injected into both middlewares — the duplicate-PMI warning now fires once.
Split maybeHandlePaymentRequired into focused handleExplicitPaymentError / handleTransparentPaymentRequired behind a slim classifier; extracted synthesizePaymentError / dispatchAndForward and routed all client-side decline-error synthesis through the single helper (removed redundant casts).

Test coverage (+12 passing)

Explicit-gating e2e (payments-flow.test.ts) — every client-visible outcome, all via the mock-relay harness (no network):

server discloses payment_interaction=explicit_gating (the spec MUST, previously untested)
-32043 pending race resolves (pay → slow verify → backoff → grant → success; no double-create)
user-declined payment → -32042 { reason }, no retry
onPaymentRequired throwing → -32042 { type: 'payment_handler_error' }
verify failure → fresh invoice (double-charge window; client pays twice, tool runs once)
transparent-only server rejects initialize with -32602 (negotiation MUST, locks the new data shape)

Transparent e2e: resolvePrice rejection → -32000 to caller (full wire path, previously unit-only).

Unit: middleware lifecycle (verify→grant→claim→forward), verify-failure/timeout → fresh -32042, onPaymentRequired reject contract, -32043 retry exhaustion.

1amKhush · 2026-06-20T14:07:39Z

@ContextVM-org Reviewed and ran the newly added test along with corresponding checks, seems great! We can merge it.

Copilot AI review requested due to automatic review settings June 11, 2026 11:30

Copilot AI reviewed Jun 11, 2026

View reviewed changes

1amKhush added 12 commits June 19, 2026 22:12

fix: address code review findings for explicit gating

0f3b082

fix: address PR feedback for explicit gating

26acaf1

fix(sdk): resolve explicit gating bugs and stabilize tests

670867e

Reseolve minor issue findings

89ff84b

Fix final review findings for CEP-8 explicit gating

b2471f0

Fix lint issue in canonical-identity.test.ts

c3be163

Fix final consistency gaps and test coverage for CEP-8 explicit gating

723c520

Export PaymentRequired type to fix build error

3095ed3

chore: cleanup explicit gating after rebase

eabfc69

1amKhush force-pushed the feat/cep8-explicit-gating branch from 785e86a to eabfc69 Compare June 19, 2026 17:26

1amKhush and others added 4 commits June 19, 2026 23:12

chore: add regression test for getNegotiationTags and fix imports

27b9d34

fix: replace remaining @modelcontextprotocol SDK imports with @contex…

c106bbf

…tvm/mcp-sdk

refactor: un-export internal helpers to clean up API surface

39eae38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Feat/cep8 explicit gating#75

Feat/cep8 explicit gating#75
1amKhush wants to merge 16 commits into
ContextVM:masterfrom
1amKhush:feat/cep8-explicit-gating

1amKhush commented Jun 11, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

1amKhush commented Jun 13, 2026

Uh oh!

ContextVM-org commented Jun 16, 2026

Uh oh!

ContextVM-org commented Jun 17, 2026

Uh oh!

ContextVM-org commented Jun 19, 2026

Uh oh!

ContextVM-org commented Jun 20, 2026

Uh oh!

1amKhush commented Jun 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

1amKhush commented Jun 11, 2026

Feat: CEP-8 Explicit Gating Lifecycle

Description

Key Changes & Architecture

Testing

Notes-

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

1amKhush commented Jun 13, 2026

Uh oh!

ContextVM-org commented Jun 16, 2026

🔴 Blocking

🟠 Significant

🟡 Inline import('…').Type pattern (forbidden)

🟢 Minor / Code quality

✅ What's solid

Summary

Uh oh!

ContextVM-org commented Jun 17, 2026

🔴 Missing Tests (blocking)

🟠 Redundancy

🟡 Consistency Gaps

🟢 Formatting

Uh oh!

ContextVM-org commented Jun 19, 2026

🔴 Blocker — Branch is 8 commits / 2 days behind master

🟠 New regression — set-on-read getNegotiationTags() eats the payment_interaction tag in the oversized measurement path

✅ Resolved from the previous review

🟡 Minor / cleanup

Recommended next steps

Uh oh!

ContextVM-org commented Jun 20, 2026

Spec compliance (correctness)

Behavior-preserving refactor

Test coverage (+12 passing)

Uh oh!

1amKhush commented Jun 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

🟡 Inline `import('…').Type` pattern (forbidden)

🟠 New regression — set-on-read `getNegotiationTags()` eats the `payment_interaction` tag in the oversized measurement path