Challenge 3: Identify a Jobs-vs-Steps Mistake — Possible Solution
====================================================================

WHY THE DEPLOY JOB FAILS WITH "FILE NOT FOUND"
---------------------------------------------------
The build job and the deploy job are TWO SEPARATE JOBS, and per this
chapter's core distinction, each job typically runs on its own fresh,
isolated runner/container with no automatic file sharing between them.
The compiled binary at ./dist/app exists only on the FILESYSTEM OF THE
MACHINE THE BUILD JOB RAN ON — the moment that job finishes and its
runner is torn down, that file (and that entire filesystem) is gone.

When the deploy job starts, it spins up on a COMPLETELY DIFFERENT,
brand-new machine that has never seen the build job's filesystem at
all. It has no idea ./dist/app was ever created, because from its own
isolated perspective, nothing has ever been built there — hence "file
not found" is not a bug or a fluke, it's the expected, correct behavior
of two independent, isolated jobs.

WHY THIS CONTRADICTS THE BUILD JOB'S REPORTED SUCCESS
-----------------------------------------------------------
This is exactly the confusing experience this chapter's tip box
describes: the build job legitimately DID succeed — it really did
compile ./dist/app, on ITS OWN machine. The deploy job's failure has
nothing to do with whether the build actually worked; it's entirely
about the fact that the deploy job's environment never received a copy
of that output at all. The two facts (build succeeded; deploy can't
find the file) aren't in tension once the job-isolation model is
understood — they're both true, for entirely separate reasons.

THE FIX
--------
The build job needs to explicitly UPLOAD ./dist/app as an artifact
before it finishes, and the deploy job needs to explicitly DOWNLOAD
that same artifact as one of its own early steps, before attempting to
copy it anywhere. This is the "explicitly passed as an 'artifact'"
mechanism the chapter names directly — data doesn't move between jobs
on its own; it has to be deliberately handed off using the CI
platform's artifact upload/download feature (or an equivalent, like
pushing the build output somewhere both jobs can independently reach,
such as a registry or shared storage).