Found while planning how to get current code onto a server (2026-09-19). Recording rather than fixing; the register should take it at the next /register-risk.
The gap
views-models/tools/launcher/postprocessor.sh:57 installs this package with pip install git+https://…@<tag>. pip resolves dependencies live from pyproject.toml's ranges at install time. poetry.lock is never read on that path.
CI does the opposite: poetry install from the lock, then the suite. So the environment CI proves and the environment a server runs are built by different resolvers from different inputs, and agree only when the newest-within-range happens to equal the locked version.
Measured
|
lock (what CI tested) |
fresh pip install from tag (what a server got) |
| until 2026-09-19 |
views-pipeline-core 3.0.1 |
3.1.1, then 3.3.0 — newest within <4.0.0 |
| 2026-09-19 |
3.3.0 |
3.3.0 |
They coincide today by timing, not by mechanism. The next pipeline-core release re-opens the gap on the same day it publishes.
The 2026-08 production env on the developer machine held pipeline-core 3.1.1 while the lock said 3.0.1 — that divergence was already visible and read as venv drift (C-104). It was this.
Why it matters
The manager class cannot be instantiated in tests (#18), so its behaviour under a given pipeline-core is exercised only by a real run. That means the one place a pipeline-core bump is proven is a server, on whatever version pip chose that day — not CI.
What would close it, and the cost
Either the launcher installs from the lock (pip install of an exported requirements.txt, or poetry install in the launcher env), or CI adds a job that installs the way the launcher does and runs the suite against that. The second is honest about the two-environment reality; the first collapses it. Both touch views-models' launcher — two repositories changing together, so the choice is not made here.
Family: C-104 (a stale venv turns the suite red), C-112 (nothing here sees what production runs). This is the third member: nothing here tests what production runs.
Found while planning how to get current code onto a server (2026-09-19). Recording rather than fixing; the register should take it at the next
/register-risk.The gap
views-models/tools/launcher/postprocessor.sh:57installs this package withpip install git+https://…@<tag>. pip resolves dependencies live frompyproject.toml's ranges at install time.poetry.lockis never read on that path.CI does the opposite:
poetry installfrom the lock, then the suite. So the environment CI proves and the environment a server runs are built by different resolvers from different inputs, and agree only when the newest-within-range happens to equal the locked version.Measured
pip installfrom tag (what a server got)<4.0.0They coincide today by timing, not by mechanism. The next pipeline-core release re-opens the gap on the same day it publishes.
The 2026-08 production env on the developer machine held pipeline-core 3.1.1 while the lock said 3.0.1 — that divergence was already visible and read as venv drift (C-104). It was this.
Why it matters
The manager class cannot be instantiated in tests (#18), so its behaviour under a given pipeline-core is exercised only by a real run. That means the one place a pipeline-core bump is proven is a server, on whatever version pip chose that day — not CI.
What would close it, and the cost
Either the launcher installs from the lock (
pip installof an exportedrequirements.txt, orpoetry installin the launcher env), or CI adds a job that installs the way the launcher does and runs the suite against that. The second is honest about the two-environment reality; the first collapses it. Both touch views-models' launcher — two repositories changing together, so the choice is not made here.Family: C-104 (a stale venv turns the suite red), C-112 (nothing here sees what production runs). This is the third member: nothing here tests what production runs.