An intention reported as an observation: a launcher's own line is not the run's

Start by locating the repository's background launchers, run logs, and waiting logic, then trace how launcher output is used to report completion. Compare the three described cases and decide whether launchers need externally readable refusal status and whether completion reports must include a fact produced by the run; done requires an agreed scope rather than a single fix.

A line that says work started is repeatedly read as a line that says work ran.
It is not the same statement, nothing in the output distinguishes them, and the
failing reading is the silent one.

The shape

When a run is started in the background, what comes back is the STARTER's
account of itself, not the run's. The only fact in it is the pid. Everything
else a reader takes from it is an assumption: that the process got the
resources it needed, that it reached the work, that the work produced anything.

This is the same family as one output with two meanings, with one difference
that makes it worse. There, two meanings share a channel and can be given
disjoint ranges. Here the two meanings are in DIFFERENT places: the intention
is in the launcher's output and the observation is in the run's own output, and
the failure is that the first is read where the second belongs.

WHY READING THE LINE CANNOT CATCH IT. "submitted", "started", "queued" and
"running" are all true of the launcher at the moment it prints them. There is
no wrong word to find. The line is accurate and the conclusion drawn from it is
not, which is why it survives review and survives being read again later.

Three sightings, all within about two days

A HEAVY SUITE THAT WAS REFUSED, REPORTED AS A SUITE THAT PASSED. A gate was
launched in the background, the lock was already held, and the wrapper refused
within a second. Its log said so in full, naming the holder and how to find it.
The launcher's own line said the run had started, that line was read, and the
gate was nearly reported as evidence. The refusal and the pass both leave a log.
Only one of them has numbers in it, and nothing but opening the log tells them
apart.

A CELL RUNNER LOGGING "submitted" OVER THREE IDLE PANES. Three cells sat at
$0.00 because a large brief never reached the composer. The runner's line was
true: it had submitted. Nothing downstream asked whether anything had been
received, and the run reported itself as dispatched for as long as it sat there.

A BACKGROUNDED SUITE WAITED ON BY MATCHING COMMAND TEXT. Two waiters looped on
a pattern that matched themselves and spun long after the work they were waiting
for had finished cleanly. The waiters' own output said they were waiting, which
was true, and said nothing about what they were waiting for.

A footnote of the same family, included because it shows the boundary: writing
a test file through a shell heredoc silently consumed every apostrophe in it,
so an assertion string ended early and the closing quote was eaten several lines
down. That one was caught by the compiler within seconds. It is a footnote and
not a finding for exactly that reason: something downstream checked. The three
above had nothing downstream that checked.

What actually separates the two

The test is whether the output contains a fact the WORK produced, as opposed to
a fact the thing that started the work produced. A package name and a duration
are the work's. A pid is the launcher's. "submitted" is the launcher's. An empty
log is neither, and in particular an empty log is not evidence of a quiet run:
a test runner prints nothing mid-package and a refusal prints everything at
once, so length says nothing about which happened.

Three habits that would have caught all three sightings, in order of how cheap
they are:

1. NEVER QUOTE A BACKGROUNDED RUN UNTIL ITS OWN LOG CARRIES A LINE THE RUN
   WROTE. Not the launcher's line, not the log's existence, not its size.
2. PROBE THE RESOURCE, NOT THE PROCESS. Whether a lock is held is a question the
   lock can answer. Whether a run is alive is not a question its command text
   can answer, because the text travels with every wrapper around it.
3. A LAUNCHER THAT CAN REFUSE SHOULD MAKE THE REFUSAL IMPOSSIBLE TO MISS FROM
   THE OUTSIDE: a non-zero exit the caller can read without opening anything,
   in addition to the explanation in the log.

The third is the only one that is a code change, and it is the only one that
does not depend on whoever is reading remembering the rule. The first two are
habits, and a habit indexed under a verb fires only when somebody is already
thinking the right thought: the waiter defect happened because the rule about
not matching command text was filed under killing, and that reader was waiting.

What this is asking for

Not a single fix. A decision on whether launchers in this repository owe a
readable refusal, and whether anything that reports a run as done should be
required to carry a figure the run itself produced.