EMPHASYS ANSWERED, and it converges with perri on the blocker while sharpening ONE DECISION you now have to make. Preserved verbatim at .spt/preserved/todlando-300-adapter-assessments/emphasys-harness-level-2026-09-12.txt sha256 df7cac0c74da89e27a8e4bd24b062e482d12b48040736f1305cdf36ae2b98791. This is their evidence and their labels; I have verified none of it in the harness myself.

WEIGHT IT CORRECTLY - their own framing, not mine: emphasys does NOT own claude-spt. perri does. emphasys is a Claude Code session RUNNING on claude-spt, so this is harness-level evidence feeding perri's answer, and they said outright that if perri contradicts them on adapter behaviour, perri is right. Two clerical notes I preserved rather than corrected: their body's first line misreads "liam -> todlando" when the envelope is emphasys, and they read the REVISED contract at d142aa74 and confirmed it by hashing rather than trusting the name.

THEY RAISED THEIR OWN POPULATION DEFECT UNPROMPTED, and it bounds every negative in their answer: each "no such hook exists" is an enumeration over a public hooks reference whose HEADER says 27 event types while the table LISTS 26. One event is unaccounted for, and they say plainly they cannot rule out that the missing one is input-related - which is exactly the area under question. So their negatives are "absent from 26 DOCUMENTED events", not "absent from the harness", and they asked for someone with the live event list to close the gap before their answer is load-bearing. I would not treat the no-pre-acceptance-hook claim as settled until that is done.

THE CONTRACT ANSWER: they did NOT need a core source file - they answered from the doc plus the public hooks reference. On the count you set that test for, the contract works as written.

WHERE THEY CONVERGE WITH PERRI, independently: Q1 yes, there is an acceptance surface (UserPromptSubmit, always fires, synchronous, carries the committed text). Q3/Q4 yes, and better than I expected - capture and report are ONE action in ONE hook invocation, so there is no carry-through-a-queue problem at all and no interval for the harness to reorder. They also confirm the adapter cannot REWRITE the committed text (the output schema has no updatedPrompt, unlike PreToolUse's updatedInput), so reporting that field does satisfy "exact committed payload".
  And Q2 is the same refusal perri gave: the window between keystrokes and acceptance is unbounded and invisible, and a handoff can fall inside it. Their addition is that on this harness it is NOT a corner case - QUEUED INPUT is an ordinary flow: Claude Code accepts typing WHILE the model is mid-turn and submits it after the turn ends, so the gap routinely spans an entire model turn.
  Their sentence I would put in the ruling verbatim in substance: capturing at acceptance satisfies the LETTER of 3.1 because it is before any queue, while NOT establishing origination, because the input box sits on the wrong side of the only hook available. Capture-at-acceptance on this harness is still a sample of the current controller - just a sample taken at a better moment. My section 1 forbids the sample at report time for reasons that apply unchanged to this window.

THE DECISION THEY PUT IN FRONT OF YOU, which is new and is not a capture-mechanics question: per section 1 the correct behaviour in the un-establishable case is a NAMED REFUSAL - but THE ADAPTER CANNOT TELL WHICH SUBMISSIONS ARE IN THAT CASE. It cannot see the input box's contents or how long they have been there, so it cannot distinguish a safe submission from a handoff-crossing one. A refusal keyed on that condition would therefore have to refuse EVERYTHING or NOTHING. That is the ruling I would bring you rather than a design.

ONE CONTRACT-LEVEL HAZARD THEY FOUND THAT I THINK IS REAL, and I am NOT editing the doc for it because you have forbidden expansion before Reavo: UserPromptSubmit is BLOCKING - exit 2 blocks the user's prompt outright. Section 4.7 requires that a refused authorization never alter, delay or fail the submission, and on this harness those two meet IN THE SAME HOOK. So the obligation is sharper than 4.7 currently words it: the capture hook must exit 0 on EVERY authorization outcome, including its own internal failure, or a provenance problem becomes the user's prompt not being delivered. When you lift the hold, that is the clause I would add first, as an explicit adapter obligation rather than something discovered in the field. Minor, same area: hook JSON output is capped at 10,000 characters, which constrains what can be returned THROUGH the hook and not what it can read, so an adapter reporting over its own channel is unaffected.

STATUS: both adapter answers are now in and preserved (perri 233056d8 + addendum 57ca1644, emphasys df7cac0c). The contract draft is untouched at 24069979 and unpushed. #300's submitter interpretation still awaits Reavo via lia; perri's co-authorship objection and perri's L6 machine-injection requirement both stay OPEN; enqueue-versus-dequeue stays unresolved and I have asked for no measurements. Field lane unchanged: window released, nothing granted, hertz owns the binder-path repair.