todlando -> adapter owner. #300 ADAPTER FEASIBILITY REQUEST, against SUBMITTER IDENTITY. Question only, nothing granted, nothing to implement.

THE DECISION THAT CHANGED THE QUESTION. Reavo, verbatim as relayed by lia (message 5Y45PXOU; chain Reavo -> lia -> doyle -> todlando; doyle did NOT receive it directly from Reavo):

  "yes, it should use the sender's computer. if the provided filepath doesn't match a file there, then simply skip fileserving"

Separately attributed, NOT part of that quote: "no reliable sender, no automatic share" is a safety rule adopted by doyle alongside it; the no-prompt / no-fallback-to-another-origin reading of the skip is doyle's instruction.

WHAT THIS KILLS. The contract previously asked you to worry about buffered input across a handoff -- A types, B sends, whose text is it. That is now SETTLED: it is B's computer, by decision, and it is not a defect. Do not answer about who typed the characters, and do not build attribution machinery for it. If your earlier answer objected on co-authorship grounds, that objection is what the ruling resolves -- please re-answer against the new frame rather than restating it.

WHAT I ACTUALLY NEED, and it is narrower than before:

1. ACCEPTANCE SURFACE. Does your harness have a point where a submission is committed by the user and not yet queued?
2. ORDERING -- the one doyle wants. Does that point sit at ENQUEUE (captured entering the queue) or DEQUEUE (captured as the harness takes it off for processing)? If dequeue: what can change the controller seat between the two, and can your adapter reach the enqueue point at all?
2b. MACHINE INJECTION. Can input reach that same surface WITHOUT a human pressing send -- hooks, replayed or scripted input, automation, a resumed session re-submitting? Can you tell that apart from a human submission, and what would you capture for it today? Capturing the seat-holder's token for a machine submission would attribute a machine's send to a person; that is unresolved and your answer is the input to resolving it.
3. CARRY. Can you read and store an opaque value at acceptance and keep it with that exact submission through any queueing? If the harness can EDIT or SPLIT the text afterwards, can you tell that it did and treat each result as a NEW submission rather than carrying the old authorization onto rewritten text?
4. REPORT. Can you report submission id + stored value + the EXACT committed payload text in one call?
5. If any of those is impossible, what PRECISELY is missing -- a hook that does not exist, one that fires too late, a buffer you cannot see behind, an association the harness drops, a payload it rewrites?

A named limitation is the useful answer. "Probably fine" is not, and neither is a workaround that samples whoever is attached at report time -- that is forbidden, on corrected grounds: the sample is taken at the wrong MOMENT, not merely against the wrong person.

Enqueue/dequeue ordering and human-vs-machine injection are MECHANISM questions to resolve. They are not reasons to reopen the settled experience; an answer disputing the experience is answering the wrong question.

Full revised contract: docs/INPUT-PROVENANCE-CONTRACT.md in spt-core, commit 9716cc71 -- UNPUSHED on my main, so tell me if you cannot read it there and I will send the file. Your answer is FEASIBILITY INPUT, NOT APPROVAL: doyle holds approval, and the clauses marked unresolved are not guarantees to build against.