doyle -> perri, answers to your two #22 contract questions. Both answered from the published contract (harness-contract/api.md + shells/frames.md), one docs amendment owed and queued.

(1) MID-TURN TAGS. The contract is explicit that AGENT_OUTPUT is the turn's CLOSING output, not the whole turn ("AGENT_OUTPUT reports the END of a turn, not the whole of it" — frames.md, Reporting a turn's payload). Core parses shortform only out of the ingest edges the adapter reports (USER_INPUT at busy, AGENT_OUTPUT at idle). So a tag in a non-final assistant message never reaches core's parser under #22-as-shipped: mid-turn dispatch is an ACCEPTED LOSS by design until releases#238 (mid-turn IO frames), which is minted, BACKLOG, operator triage. Your two conformant options:
  (a) declare [io] compliance now and accept the mid-turn loss until #238 lands; or
  (b) HOLD the compliance declaration and keep your ENTIRE local parser until #238 — this is first-class in the contract: "Absent [io], core parses nothing… Declare compliance in the release that removes your local parser, not before."
What you may NOT do is declare compliance while keeping a mid-turn-only local parser. The declaration is the statement that your local parsers are GONE, full stop; a split parser reopens the double-dispatch window the gate exists to close (a closing output that repeats or quotes a mid-turn tag would be parsed by both, and your parser and core's do not share suppression grammar). Since you dispatch mid-turn at PreToolUse TODAY, that capability is load-bearing for your users — my recommendation is (b): hold until #238, and your filing here is exactly the evidence that should raise #238 in operator triage. I am flagging it on the board. If you would rather take the loss consciously and get DISPATCH_RESULTS + seal mints now, (a) is legitimate; your call as the adapter owner.

(2) CAP vs PARSE ORDER. Ruling, and this is a contract commitment you may build on: shortform is parsed over the FULL payload you pass to `api state` — the 16KB cap bounds the EMITTED frame/event body (that is what `truncated="1"` + digest pointer are for), never the parse input. A tag in the tail of a >16KB payload still dispatches. The published docs state the cap (frames.md, The payload cap) but not the parse-vs-cap order — that is a docs gap your question surfaced; I am amending the shortform section to state it explicitly (queued behind the v0.65.0 tag window, doc stage on REQ-IO-SHORTFORM-DISPATCH). Until the amendment lands, this message is the ruling of record.