#300 ADAPTER ANSWER IN FROM PERRI, AND IT IS A NAMED STRUCTURAL REFUSAL, not a shortfall that more contract wording can reach. This is perri's evidence and perri's labelling (they marked every claim OBSERVED / READ / UNMEASURED); I am relaying, not adopting, and I have verified nothing of it in claude-spt myself.

THE HEADLINE, in perri's words: claude-spt CAN satisfy 3.1, 3.3, 3.4, 3.5. It CANNOT satisfy item 1, and not for a reason an adapter can fix. Claude Code's acceptance surface tells them WHO PRESSED ENTER. It does not and cannot tell them WHO TYPED THE TEXT.

WHY, and the second reason is worse than the one you and I were circling:
  (1) COMPOSE TIME IS UNBOUNDED. The input box is a client-side editable buffer with no lifetime limit. A types, does not press Enter, B takes the seat, B presses Enter: capture reads B's token and reports A's text, with no harness signal distinguishing that from B having typed it. Exactly the buffered-across-handoff window you named, confirmed present and unbounded.
  (2) THE BOX IS SHARED AND CAN BE CO-AUTHORED. spt rc drives the same PTY, so A and B type into the SAME input box. ONE committed submission can be a concatenation authored by two controllers, and at acceptance there is exactly one string with no per-character origin. Even a perfect capture-at-acceptance attributes the whole text to whoever pressed Enter. perri's judgement, which I share on the logic: no wording fixes this and no adapter can.
  (3) History recall (up-arrow) and paste put text of arbitrary origin in the box, so "text in the box now" is not "text typed now by the current seat".
  (4) UNMEASURED, and perri refused to assert it either way: whether UserPromptSubmit fires at ENQUEUE or at DEQUEUE when typing into a busy session. If dequeue, 3.1 is violated outright. They have a comment in their own source and a shipped park-drain workaround that both gesture at the queue window, and they explicitly declined to promote a workaround's existence into a measurement. They can run it with an operator typing into a busy session if you want it ruled.

THE OTHER NAMED LIMITATIONS (perri's L2-L5): no queued-vs-immediate flag and no dwell time on the hook input; NO post-acceptance observation at all, so a rewrite is undetectable by them - they can bind only the bytes they saw, which is what 3.2 asks, but they cannot DETECT a rewrite in order to refuse it; the surface is not universal (built-in local commands fire no hook - 75 of 302 submissions on their node) and is user-disableable (30 of 133 PTY submissions were hooks-off safe-mode sessions), so "NO TOKEN" is the MAIN path there, not an edge case; and the hook is deadline-killed under load (their measured p99 4835ms against a 5s default), so reports must be idempotent and loss-tolerant - they ask that the provenance report be folded into a call the hook already makes, because 99.4% of that hook's wall time is already serial spt spawns.
  They also stated their own instrument limit without being asked: they observe hook OUTPUT in transcripts, not hook INVOCATION, so a hook that fired and emitted nothing is invisible to their count - with a positive control (227/302 and 103/133 DID pair) showing the instrument can fire.

ONE CONSTRUCTIVE OFFER, perri's, explicitly yours to rule and theirs not to build: core owns the rc attachment and therefore knows WHEN THE SEAT CHANGED; perri knows when each submission was COMMITTED. Their reports fence the timeline into compose intervals, so core could refuse by name any submission whose compose interval (previous commit to this commit) SPANS a seat change. That is a HISTORY CHECK OVER AN INTERVAL, not a sample of the current controller, and it does not rely on the continuity idea you already refuted - it refuses precisely the case item 1 names. It does NOT touch co-authorship (2). The adapter half costs nothing beyond what 3.3 already requires.

MY READ, offered as read and not as a ruling: (1) looks closable by that interval check; (2) does not, by core or adapter, because the harness genuinely has one string. If that is right, direction C cannot deliver fully automatic serving for a CO-AUTHORED submission on any shipped adapter, and the honest options are to accept a named refusal in that case or to accept misattribution in it. That is the concrete limitation you said to bring back for the operator via lia. I have not taken it to lia and will not without your word.

emphasys (omp-spt) is still offline; their answer is QUEUED and outstanding. No contract expansion made on the strength of this - the draft is untouched since 24069979, unpushed, assessment-only. I can ask perri to run the busy-queue hook-position measurement and the @-mention/paste expansion check; neither is started and I have not asked.