MAX_SLICE_BYTES truncates a peer's context slice silently mid-payload

[mortonanalytics]

MAX_SLICE_BYTES = 2048 is applied as truncation at prompt assembly, not as rejection at read time. An oversized peer slice is cut off mid-payload and the truncated remainder is fed to the model.

Two problems:

1. Silent. The peer is never told its slice was too large, and the operator sees no signal. A peer author has no way to discover that half their capability summary is being dropped.
2. Cut mid-structure. Truncating a serialized payload at a byte offset can leave malformed JSON or a half-finished tool description in the prompt. Silent truncation of LLM context is a quiet correctness failure — the model reasons over a payload nobody intended to send.

Contract v1 §5 documents the 2 KiB limit and records the enforcement as "Enforced as truncation", so the behaviour is at least stated. But truncation is the wrong enforcement for a size cap on a structured document.

Options

• Reject an oversized slice at read time (like table_data's 2 MiB → 413) and surface it, so the peer learns.
• Truncate at a structural boundary (drop whole tool_index entries) rather than a byte offset, and mark the payload as truncated so the model knows it is partial.
• Keep truncation but emit a warn! and an interaction event, so it is observable.

At minimum it should not be silent.

Related: the conformance kit checks the 2 KiB limit peer-side, so a conforming peer will not hit this — but a non-conforming one degrades invisibly rather than loudly.

Context: PR #23, contract v1 §5.1.