Sends wire responses over the Plug connection — the lowest-level output module in the pipeline — and records every rejection wymcp sends.

Two primitives, one per structured error dialect: send_json/2 sends a JSON-RPC envelope as-is — every JSON-RPC-enveloped POST answer flows through it, and it preserves any previously-set HTTP status — and send_plain_error/3 sends the plain-JSON dialect's flat %{error: message} object, the rejection body of the GET/DELETE routes. Both halt the connection after sending. The plain-JSON dialect is legacy-only: it exists for the GET and DELETE rejection bodies, and it goes with those routes at the legacy decommission.

Beside them, send_accepted/1 sends the acceptance — HTTP 202 with no body and so no envelope — to every notification and every client-delivered JSON-RPC response wymcp takes, on both lanes: Wymcp.Plugs.Dispatch answers a notification with it on each lane, and on the legacy lane so do Wymcp.Methods.Initialized on a completed handshake, Wymcp.Methods.Cancelled, and Wymcp.Methods.DeliverResponse on the server-request round trip. One taken notification still answers otherwise — notifications/initialized under a server refusal, named in send_accepted/1's @doc. The sender is era-neutral; its legacy-lane callers go at the legacy decommission.

Above them sits send_rejection/6, the shared rejection sender: it takes the dialect as a parameter and assembles the -32600 envelope or the flat object accordingly. That is what lets a wire check — each of the plugs Wymcp.Router's wire-check invariant names runs on both POST and the GET/DELETE routes — state a status and a message once rather than carry a private dialect switch. rejection_id/1 holds the rule for what id such an envelope echoes, and the sender applies it — no call site passes an id, so none can choose otherwise.

Beneath both sits record_rejection/5, which every rejection passes through whether or not it uses the shared sender: it writes the rejection mark and emits [:wymcp, :wire, :reject]. It names the rejecter and a rejection reason, and accepts only a pair the rejection table carries. rejection/1 reads the mark back — the consumer's second door onto which rejecter refused a request and why, beside the event.

Every rejection ahead of Wymcp.Plugs.Classify carries a nil id, because no message kind is known yet. Wymcp.Plugs.Pipeline's malformed-JSON arm hardcodes it — no body parsed. Wymcp.Plugs.OriginCheck on POST, which that chain runs ahead of the parse step, and the parse step's other arms get it from the rejection-id rule, which has no kind to read — so the origin check's 403 carries a null id even for a well-formed request that does have one on the wire.

The call sites listed below assemble their rejection bodies themselves, each answer carrying a different meaning rather than merely a different shape — absorbing them would need the sender to take an error type and structured data from its caller, leaving it with no opinion at all. Every one of them still calls record_rejection/5 first, so bypassing the sender bypasses neither the mark nor the event; each reads rejection_id/1 itself except the two whose bullets say why they do not — the malformed-JSON arm has no parsed body to read a rule from, and the unknown modern method echoes an id only a request can reach it with — so it does not bypass that rule either:

• Wymcp.Plugs.Session's session_terminated/2 — error type :session_not_found and no data map, matching the TypeScript SDK byte-for-byte; it branches on the rule rather than passing it a value, sending an envelope exactly when the rule yields an id. This site is legacy-only: sessions exist only on the legacy lane, and it goes at the legacy decommission.
• Wymcp.Plugs.Validate — the distilled one-liner as the envelope's message, the locations under data.errors.
• Wymcp.Plugs.Pipeline's malformed-JSON arm of the parse step — error type :parse_error, no data. The one site that hardcodes nil: it runs when no body parsed, so there is nothing to read a rule from. The step's other arms use the shared sender.
• Wymcp.Plugs.ProtocolFields — two answers on the modern lane, each with its own error type: :invalid_params naming the missing or wrong-typed protocol field in its message and carrying no data, and :unsupported_protocol_version with data.supported + data.requested for a version no era serves.
• Wymcp.Plugs.HeaderBinding — three answers on the modern lane sharing one error type, :header_mismatch (-32020), which the shared sender cannot speak at all: data.header names the mirrored header, data.expected the body's value, and data.received the header's, omitted where there is none to report. Its message names the header and the condition, so it varies by row and by reason, as Wymcp.JsonRpc's contract asks of every envelope.
• Wymcp.Plugs.Dispatch's unknown modern method — Wymcp.Methods.Unknown builds the :method_not_found body both eras share — the table's own message, no data — echoing the request's own id, and the plug alone sets the 404 that makes the modern lane's answer a rejection where the legacy lane's 200 is not. Echoing the body's id directly is safe there because only a request reaches that arm: Wymcp.Plugs.Dispatch delivers a response message before it branches on era, and Wymcp.Plugs.Validate refuses a body it cannot classify — so the raw id and rejection_id/1's answer coincide.

One POST answer carries no envelope and uses no sender: the bare 404 answering an unrecognized session on a message the rejection-id rule gives no id for (Wymcp.Plugs.Session). The rule's reason reaches here too — what JSON-RPC forbids is an id-bearing reply to a response message, a second answer to a request still outstanding — and an id-less error body would be no reply to anything; the MCP spec even names it: on input the server cannot accept, the body "MAY comprise a JSON-RPC error response that has no id". So the 400s legitimately carry a null-id envelope; the 404 stays empty for a different reason — a client receiving it must start a new session, so the status is the whole signal and a diagnostic string would name no next action. The answer is legacy-only: it answers an unrecognized session, which exists only on the legacy lane, and it goes at the legacy decommission.

The rejection invariant

Every rejection sets the rejection mark and emits [:wymcp, :wire, :reject] exactly once, and rejection_table/0, rejection_reason/0 and Wymcp.RejectionInvariantTest's scenarios name the same pairs.

The table is what closes it: record_rejection/5 refuses a pair no row names, so a new rejecting arm cannot answer the wire until it has a row, and the sweep derives one scenario per row, so a row cannot exist without a request that trips it. What neither reaches is a rejection sent past the helper entirely — a bare send_resp(400, …) marking nothing and emitting nothing — which review catches and no gate here does.

The invariant holds for what reaches the mount unparsed; a parser ahead of the mount owns what it raises. A host whose own parser reads the body before forwarding answers what that parser refuses, in its own way, and no rejection is recorded — which is why README's Create your mount module step tells a host to leave the body unread. Two failures of the parse step's own body read are no rejection either: a read stalled past its timeout, and a connection broken mid-body, leave no complete body to refuse and usually no client to answer, so they escape the mount as the adapter's own transport errors, which the host answers.

The mark's writer and readers live in this module because every check depends on it at run time and nothing here depends on a check, so the pair adds no compile edge; a check reading a key owned by Wymcp.Router would close a compile cycle through Wymcp.Plugs.Pipeline, which initializes the checks at its own compile. The table's rows keep that property by naming their modules as fully-qualified atoms rather than aliases: an alias here — in a module attribute or a function body alike — draws this module into that cycle, which mix xref graph --label compile-connected reports and nothing else would. The cost is that the compiler no longer checks those names, which is why the sweep asserts each one resolves to a loaded module.

Renamed from Vancouver's Method module for clarity: this module's only job is sending the HTTP response, it has nothing to do with JSON-RPC methods.