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

One primitive for the JSON-RPC error dialect: send_json/2 sends a JSON-RPC envelope as-is — every enveloped answer flows through it, and it preserves any previously-set HTTP status — and halts the connection after sending.

Beside it, send_accepted/1 sends the acceptance — HTTP 202 with no body and so no envelope — to every notification wymcp takes: Wymcp.Plugs.Dispatch answers each one with it, whatever its body.

Above them sits send_rejection/5, the shared rejection sender: it assembles the -32600 envelope every wire check answers with, so a check states a status and a message once and never builds an envelope of its own. 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 one whose bullet says why it does not — the malformed-JSON arm has no parsed body to read a rule from — so it does not bypass that rule either:

• Wymcp.Plugs.Validate's schema arm — the distilled one-liner as the envelope's message, the locations under data.errors. Its other arm, the client-sent response, carries no data and speaks the shared sender.
• 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, 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 and, where the request offered one, data.requested for a version wymcp does not serve — the answer an initialize from an earlier revision meets.
• Wymcp.Plugs.HeaderBinding — three answers 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 method — Wymcp.Methods.Unknown builds the :method_not_found body — the table's own message, no data — with its id read through rejection_id/1, and the plug sets the 404 that makes the answer a rejection. Only a request reaches that arm: a notification is answered with the acceptance ahead of it, and Wymcp.Plugs.Validate refuses a body it cannot classify — so the read is the rule's one door rather than a live branch, and stays right if a kind is ever added ahead of it.

A null-id envelope is what JSON-RPC and the MCP spec allow on input the server cannot accept — the body "MAY comprise a JSON-RPC error response that has no id" — which is why the 400s ahead of classification carry one.

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 stalled read, and a connection broken mid-body, leave no complete body to refuse and usually no client to answer, so they escape the mount as an exception the host answers — the adapter's own transport error, or the Plug.TimeoutError Plug raises for the stalled read the parse step's reader reports; Wymcp.Plugs.Pipeline states the rule.

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.