ANSWERS FROM THE PUBLIC HARNESS INTERFACE. No implementation, no core-source read, no new experiment; existing measurements cited with their limits. Q1 - CAN I RETAIN A CORE-ISSUED VALUE ALREADY ASSOCIATED WITH THE SUBMITTING ATTACHMENT, AT THE ACCEPTANCE POINT, ALONGSIDE THE SUBMISSION ID AND EXACT COMMITTED TEXT, BEFORE QUEUEING? NO. And the reason is narrower than "the timing is wrong" - the timing is fine; THE CARRIER DOES NOT EXIST. What the acceptance event actually hands me: the UserPromptSubmit hook receives one fixed-schema JSON object on stdin, authored by the harness - the prompt text, session_id, transcript_path, cwd, hook_event_name, permission_mode. There is NO attachment identity, NO controller identity, NO token, and NO per-submission metadata of any kind. Nothing on that event is associated with the submitting attachment. So "retain a value already associated with the submission" is not something I can do, because no such value ARRIVES. The only ways to obtain one at that instant are: (a) read it off the hook payload - there is no field, and I cannot add one; (b) call out to core at hook time (spt api driven-by, endpoint-info) - which is EXACTLY the later lookup of the current controller you just ruled insufficient. Same hook invocation or not, it is a fetch of who is attached NOW, not a value that travelled with the text; (c) read an environment variable - session-scoped, captured when Claude Code was launched, therefore stale across a handoff by construction and not per-submission at all. Three of the four elements ARE available at that point, and it is worth being exact about which one is not: - submission id: available, mine to mint. The harness supplies none. - exact committed text: available. Measured - the raw typed bytes reach the hook; claude-spt parses /sptc: out of that field in the field today. - before queueing: established. UserPromptSubmit fires at ENQUEUE - measured n=3 at +0.5/+0.9/+1.0s after Enter with the prior turn still executing, exactly one fire per submission. - a value bound to the submitting attachment: ABSENT. That is the only one of the four carrying provenance, and it is the one the harness does not provide. THE MISSING CAPABILITY, NAMED: CLAUDE CODE HAS NO PER-SUBMISSION CARRIER. There is no field, header or side-channel on the acceptance event into which an external party could place a value that then travels with THAT submission. For a core-issued token to ride a submission, either the harness must expose a per-submission metadata slot the transport can populate, or the transport must reach the adapter by a path bound to the submission rather than to the session or the process. Neither exists. A citable asymmetry that sharpens it: PreToolUse DOES carry a harness-minted per-event identifier (tool_use_id). UserPromptSubmit carries no equivalent. So the harness demonstrably can mint per-event identity, and does not do so for submissions. Q2 - CAN THE ACCEPTANCE EVENT DISTINGUISH AN AUTHENTICATED CONTROLLER SUBMISSION FROM MACHINE-INJECTED, REPLAYED OR RESUMED INPUT, WITHOUT PAYLOAD-SHAPE HEURISTICS? NO. There is no available signal, and I want to be exact that this is an ABSENCE rather than a gap I have not looked into. Every field on that event: prompt, session_id, transcript_path, cwd, hook_event_name, permission_mode. None describes origin. permission_mode is the only one that varies with invocation context, and it describes permissions, not who or what produced the input. MEASURED: machine-injected input is INDISTINGUISHABLE at this surface, not merely undocumented. My enqueue measurement was machine-injected end to end - core PTY-typed the text and pressed Enter, no human - and UserPromptSubmit fired identically to a human submission. Separately, the granted precheck spawn was a machine-launched print-mode submission, and its UserPromptSubmit fired identically again (attributed transcript artifacts). Two different machine origins, the same acceptance event, no discriminating field. Everything claude-spt uses today to tell them apart IS the payload-shape heuristic you exclude - recognising spt's own stub shapes. That is recognition of my own transport's bytes, not authentication, and it does not extend to a shape nobody has told me about. REPLAYED / RESUMED: I have NO measurement, and I will not reason my way to one. The granted precheck established D2 as TRANSCRIPT PERSISTENCE ONLY, with the window unestablished and resumability explicitly NOT established, so I have observed nothing about how resumed input presents at the acceptance surface. From the interface alone: no field marks a submission as a replay, and session_id identifies a session rather than the provenance of a particular submission within it. MISSING CAPABILITY, NAMED: the acceptance event carries NO ORIGIN OR AUTHENTICITY DISCRIMINATOR. Answering this without heuristics needs either the harness to stamp the event with the origin of the input - interactive terminal versus programmatic or PTY-injected versus harness re-submission - or a core channel that does not route through the shared input box at all. Today a human keystroke and a machine-typed one enter the same buffer and produce the same event. LIMITS ON WHAT I CITED: the enqueue result is n=3, machine-typed, and the step from machine-typed to human-typed is a generalisation I am naming rather than hiding. D1 is one print-mode submission on this host in this configuration, not a universal hook guarantee. The Stop-to-next-turn window is unmeasured. And the trace cannot attribute a hook fire to a submission at all - the transcript is what carried attribution - with the precheck's missing trace entry still unexplained and no cause offered. NET, for the contract: claude-spt can satisfy capture-at-acceptance-before-queue, one-call reporting of id plus exact committed text, never-substitute, and report-once. It CANNOT hold a value bound to the submitting attachment, because none is delivered to it, and it CANNOT authenticate the origin of an acceptance without heuristics. Both are harness-interface absences rather than adapter choices, so neither is closable on my side.