Asking for an internal file identity after someone names an image makes writing cumbersome. Taking the first matching filename can upload the wrong picture instead. Following the simpler publication entrance, I examined the two stages that connect a readable media name with a file actually selected for the current work.
A body marker names selected material rather than a path
PublicationInputs flushes accumulated paragraph text when it meets a standalone image or video marker, then finds that name in selected files. Anything other than exactly one match raises PUBLICATION_SELECTED_FILE_REQUIRED. Duplicate names do not justify choosing the first candidate. Supplying a path is not an entrance for reading a newly invented file outside the selected set.
This entrance checks an extension appropriate to the marker kind and the digest's format. An extension check is not complete file-content analysis, however. It connects the requested marker to a supported input shape; selected scope and actual byte metadata are separate responsibilities. The short request remains understandable because those checks have named owners behind it.
Retain filename and digest together in the plan
A media block in the converted ArticlePlan carries fileName and sha256. It remains possible to read which file belongs in which position and to compare bytes behind an unchanged name during execution. Users need not memorize handles, but a display name alone does not finish identity resolution.
The rich entrance can also accept an already structured plan. Its fileFor requires exactly one metadata item matching both name and digest. That differs from the simple marker entrance refusing name ambiguity before conversion. The two boundaries have different conditions; describing every path as an identical filename rule would lose information needed when adapting or debugging the system.
Find a late missing file before the first body block
The article fill path describes selected identities, then applies fileFor to every media block before beginning the first body block. This reduces partial progress where early paragraphs and images are inserted before a missing final video is discovered. Preparation needs to account for material at the end of the article as well as its beginning.
This is not a guarantee that no screen value has changed beforehand. The parent procedure can verify or fill the article title before entering media-body preparation. The precise boundary is whole-plan media binding before first body-block input. Title work, body assembly and external transfer should not be compressed into an inaccurate claim of zero prior changes.
Read metadata again from currently allowed files
TaskFiles.describe checks that each requested identity is allowed and belongs to the profile. Before and after reading bytes for SHA-256, it compares ordinary-file status, size and modification time with the selection record. It returns needed name, size and digest rather than embedding a local path or authentication material in article input.
This is not a guarantee against every malicious filesystem race. Additional checks immediately before upload revalidate handles and file state without necessarily hashing all bytes again in the same way. Timing and trust in the storage environment still matter. Explaining which data was read at which moment lets a reader judge the actual strength of the check.
Test when a correct-looking name still needs refusal
Existing publication tests reject absent or duplicate names, path markers and incompatible media kinds. File tests reject another profile's handle and a file changed after selection. I compared those tests with current functions without modifying original operating files or performing fresh external file selection.
The shared module actually distinguishes same-name different-byte metadata and refuses two same-name same-digest matches. It tests preservation of the caller's article when a later file is missing. It handles only supplied synthetic metadata, rather than reproducing TaskFiles reading real operating bytes. That boundary is included alongside the reusable implementation.
Keep readable names and exact internal binding together
The user decides which picture belongs near a paragraph. The program binds that name to a selected file, its bytes and its present availability. A simple entrance works better when precise internal identity remains where it is needed, rather than being removed altogether.
Hiding file IDs should not hide provenance or selection. Duplicate names or changed bytes need a clear stop and a way to resolve the necessary choice. In writing automation, convenience is more than minimizing the number of questions. It includes an inspectable connection showing which material will actually be used, before that material reaches an external service.