sync(UPSTREAM-SYNC-HEADPIN): step6-c1a credits the version read to a job whose own read returned 1

Row: UPSTREAM-SYNC-HEADPIN

.agents/sync/2026-09-05-e126687-step6-c1a.md credits the importlib.metadata
version read to job 8c4f639c-0ebb-44de-b5e4-0e192143f7c3 (step A). That
job's own read failed. The reading in /workspace/step6-c1a-2818/versions.txt
was written by the OTHER job of the same wave,
d7908816-96a3-40ed-8024-c3ad0cc34d77 (step35.sh), which re-does the read at
its step35.sh:51.

The record is right about the FINDING and wrong about WHO took it. R1's
conclusion -- the oracle matches the pin, metadata_vllm equals
runtime_vllm___version__ equals 0.28.1rc1.dev132+ge126687a9 -- stands
unchanged on d7908816's reading. Only the attribution is false.

What step A's own log says

/workspace/step6-c1a-2818/stepA.log:1117-1126 (stepA.sh,
VENV=/tmp/oracle-e126687):

+ cd /
+ /tmp/oracle-e126687/bin/python -
+ echo VERSION_READ_RC=1
VERSION_READ_RC=1
+ cat /workspace/step6-c1a-2818/versions.txt      <- produced nothing
+ echo '--- versions.err ---'
--- versions.err ---
+ cat /workspace/step6-c1a-2818/versions.err
Traceback (most recent call last):
  File "<stdin>", line 11, in <module>
ModuleNotFoundError: No module named 'vllm'

Step A's venv never got vLLM: its wheel install at stepA.log:69 fell over on
instanttensor's C++ extension (stepA.log:887-901), so the interpreter that
ran the read had no vllm to read.

What d7908816's log says

/workspace/step6-c1a-2818/step35.log:70-82 (step35.sh,
VENV=/root/step6/venv):

+ cd /
+ /root/step6/venv/bin/python -
+ echo VERSION_READ_RC=0
VERSION_READ_RC=0
+ cat /workspace/step6-c1a-2818/versions.txt
metadata_vllm='0.28.1rc1.dev132+ge126687a9'
...

Three corroborations

1. versions.txt mtime is 2026-09-05 22:42:39Z. rc jobs -n 200 --device dgx:gpu0 -o json gives d7908816 the window 22:33:48Z-23:08:22Z and gives
   8c4f639c 22:15:59Z-22:33:48Z. The file was written inside d7908816's
   window and AFTER 8c4f639c had finished.
2. versions.txt carries
   vllm___file__='/root/step6/venv/lib/python3.12/site-packages/vllm/__init__.py'.
   That is step35's venv. Step A's is /tmp/oracle-e126687.
3. Step A's own cat of the file is empty in its log, so at 22:33:48Z the
   file did not yet exist.

The lesson this is an instance of

The corroboration relied on was state=succeeded, exit_code=0. Both jobs carry
it. 8c4f639c exited 0 while the step inside it returned 1 -- stepA.sh echoes
VERSION_READ_RC=$? and does not propagate it. An exit code is a statement about
the job, never about a step inside it. Where a record rests on what a job
measured, read the step.

Fix

Three sites in .agents/sync/2026-09-05-e126687-step6-c1a.md:

• :19 -- the Device used row names 8c4f639c as the job.
• :116 -- the job table maps 8c4f639c to "the literal version read (§5.1)".
• :279-281 -- "Two jobs ran: 8c4f639c (step A, the version read) ... Step A
  PASSED".

rc logs for both jobs returns nothing today (positive control: the same client
still returns 316 lines for 7386f034-246a-4af5-9a04-f98aafffce54), so the share
artifacts under /workspace/step6-c1a-2818/ are the only record and the
correction should quote them rather than re-derive from rc.

Found while repairing PR #2977, which carried the same misattribution forward
from this file and has corrected it in .agents/upstream-sync.md,
.agents/oracles/vllm.md and .agents/sync/2026-09-05-e126687-pingate.md. This
issue owns the repair of the originating record, which belongs to another wave.

Start with .agents/sync/2026-09-05-e126687-step6-c1a.md at lines 19, 116, and 279-281, then read the cited stepA.log and step35.log excerpts plus the workspace artifact evidence. Correct the job attribution to d7908816 while preserving the existing version finding, and ensure the record no longer says Step A performed or passed the read.