gateable = yes in .agents/oracles/vllm.md currently sits on a pin it was never measured at.
The pin. a7c23ac96d7806e7c7e7d862eadbce5a33529b94, 0.3.0.dev267, pinned_on = 2026-09-22. It replaced e126687a9a (0.28.1rc1.dev132, pinned 2026-09-03). 1187 commits separate the two, 232 of them touching ported subtrees.
Why the record is wrong. AGENTS.md §"Pin vLLM" is explicit: "An oracle is only gateable once it demonstrably builds and runs the model. Constructing a config proves nothing." The gateable = yes was earned at e126687a9a, where the oracle was built and run on two boards. The pin then moved, and the structured field did not.
What the September 22 sync report actually records. .agents/sync/2026-09-22-a7c23ac96d.md records two gates, and both are this project's own C++:
test_scheduler 48/48- the
vllm library build
Neither is the oracle. The one PORT-NOW commit in the range (c64b15cde5, the scheduler) was ported from source reading, not from a capture. The advance was made to unblock MODEL-JEV, which needs the DiffusionGemma architecture from vllm-project/vllm#57250.
The checker does not catch this, and that is worth stating. scripts/check-oracle-pins.py:314-327 accepts gateable = yes when the evidence path exists in the tree. It checks that a document is present, not that the document records a build-and-run of the oracle. So for as long as evidence pointed at a sync report, the gate read yes on an unmeasured pin. Every other oracle in .agents/oracles/ that is not demonstrably run is already gateable = no and names its owing issue; vllm is the one that drifted.
What this issue owes. Build the pinned vLLM at a7c23ac96d and run a model through it, then set gateable back to yes with evidence that says so. The prior pin's measurements stay as historical evidence in the prose sections of the oracle file; they are measurements of e126687a9a and are labelled as such.
Related, and still owed separately. #2818 is the standing post-hoc issue for the previous pin advance, e126687a9a. This is the same class of debt for the advance that superseded it, so #2818's scope does not cover it.
Until this is discharged, gateable = no is the truthful disposition.
gateable = yesin.agents/oracles/vllm.mdcurrently sits on a pin it was never measured at.The pin.
a7c23ac96d7806e7c7e7d862eadbce5a33529b94,0.3.0.dev267,pinned_on = 2026-09-22. It replacede126687a9a(0.28.1rc1.dev132, pinned 2026-09-03). 1187 commits separate the two, 232 of them touching ported subtrees.Why the record is wrong.
AGENTS.md§"Pin vLLM" is explicit: "An oracle is only gateable once it demonstrably builds and runs the model. Constructing a config proves nothing." Thegateable = yeswas earned ate126687a9a, where the oracle was built and run on two boards. The pin then moved, and the structured field did not.What the September 22 sync report actually records.
.agents/sync/2026-09-22-a7c23ac96d.mdrecords two gates, and both are this project's own C++:test_scheduler48/48vllmlibrary buildNeither is the oracle. The one PORT-NOW commit in the range (
c64b15cde5, the scheduler) was ported from source reading, not from a capture. The advance was made to unblockMODEL-JEV, which needs the DiffusionGemma architecture from vllm-project/vllm#57250.The checker does not catch this, and that is worth stating.
scripts/check-oracle-pins.py:314-327acceptsgateable = yeswhen theevidencepath exists in the tree. It checks that a document is present, not that the document records a build-and-run of the oracle. So for as long asevidencepointed at a sync report, the gate readyeson an unmeasured pin. Every other oracle in.agents/oracles/that is not demonstrably run is alreadygateable = noand names its owing issue;vllmis the one that drifted.What this issue owes. Build the pinned vLLM at
a7c23ac96dand run a model through it, then setgateableback toyeswith evidence that says so. The prior pin's measurements stay as historical evidence in the prose sections of the oracle file; they are measurements ofe126687a9aand are labelled as such.Related, and still owed separately. #2818 is the standing post-hoc issue for the previous pin advance,
e126687a9a. This is the same class of debt for the advance that superseded it, so #2818's scope does not cover it.Until this is discharged,
gateable = nois the truthful disposition.