A verified response from a file-selection tool can look like a finished upload. The browser receiving a file differs from the service processing it and inserting it into an article. Northstar keeps a selection receipt separate from the later outcome instead of compressing that interval into one success flag.
Narrow the wording of selection success
TaskFiles.upload compares selected filenames and sizes with actual FileList evidence. Its note explicitly identifies file selection and asks for page-result confirmation of server transfer. A verified field on this receipt describes native selection, not uploader progress or the saved document as a whole.
The broker records file identities with tab and document epoch only for a verified selection. That connects what was chosen to the document where it was chosen. Identical field names across tools do not make every verified response equivalent to business completion. The response stays small while stating the event it can actually support.
Do not infer success from an empty FileList
Some uploaders copy selected files and immediately clear the input. A later empty FileList can make a successful selection appear absent. The driver binds the chooser to the actual frame and captures names and sizes from trusted input/change events before page handlers clear them.
It reads a present FileList or the captured selection evidence if the input is empty. The empty array itself is never interpreted as success. Neither source proves that bytes reached the service. This is a limited repair of selection observability, intended to avoid sending files again merely because a later native-input read lost the transient list.
Wait on the relevant uploader state
Video waiting prefers text from the frame containing its title field. A completion message elsewhere is not adopted as proof for this upload. Completion must be observed without an in-progress message, with unique required controls, before continuing. An apparently enabled done button is insufficient on its own.
Failure text and a waiting timeout have distinct outcomes. When bounded waiting ends, the error directs the operator to inspect the existing selected file's result. An uncertain transfer is not sent again merely because a new selection might seem quicker. Reading progress and adding another external effect remain different operations.
Insertion checks the next component and its existing prefix
The editor must contain exactly one component beyond the committed prefix. The next component's kind, identity and readiness are checked together with a full expected-composition match. Only then does pending become committed blocks and get saved. Clicking done in the video uploader is not enough to record insertion into the article.
A new component alongside a changed preceding paragraph or wrong kind stops the process; someone may have edited the document. Reopening the saved service document is a later responsibility. Separating native selection, uploader processing, editor composition and server read preserves an honest account of how far verification has reached.
Resume acknowledged selection differently from uncertain selection
Pending is saved before sending media, and selected=True is saved after the selection call returns normally. A proven pre-dispatch rejection may clear pending, but an uncertain result retains it. Resuming without acknowledged selected state stops with ARTICLE_UPLOAD_OUTCOME_UNKNOWN instead of transmitting again.
When selection was acknowledged and only its result was delayed, read-only checks can adopt the next component. Existing tests require the upload count to remain one after continuation. This content task did not start the original uploader anew. It examines those tests and the actual state transitions to explain precisely which conditions prevent resubmission.
The synthetic reviewer never invents server success
The shared module compares not-ready, order and byte differences using synthetic observations. Even matching values return publication_verified=False because caller-provided data cannot authenticate a native receipt or service storage. Hiding that limitation would make a small local test look like successful remote uploading.
Operational integration likewise needs stage-specific results: selection, completed processing, insertion and retention in a reopened document. I see an agent-friendly program as one that preserves these known facts while waiting, rather than forcing the caller to guess what an undifferentiated success flag means. That precision also tells the next worker what still requires observation.