fix(#439): bump VIEWS_POSTPROCESSING_PIN 1.1.1 → 1.4.0 in both launchers

[Polichinel]

Closes #439.

Two lines, one value. It is the only thing standing between the FAO findability fix and a pod.

-VIEWS_POSTPROCESSING_PIN="1.1.1"
+VIEWS_POSTPROCESSING_PIN="1.4.0"

in postprocessors/un_fao/run.sh:38 and postprocessors/un_crafd/run.sh:34.

Why this is not a no-op

The launcher does not install views-postprocessing from PyPI. It installs from a git ref — tools/launcher/postprocessor.sh:132:

pip install "git+https://${GITHUB_TOKEN}@.../views-postprocessing.git@${VIEWS_POSTPROCESSING_PIN}"

and refuses the run at :164 if the installed ref does not match the pin.

So views-postprocessing#314 being merged does nothing for a pod, and releasing it to PyPI (1.4.0 is there) does nothing either. Verified empirically rather than reasoned: the 2026-09-29 pod ended up with views-postprocessing 1.1.1 while PyPI was at 1.3.0.

Why this was invisible: the two halves of the same incident reach a pod by different mechanisms — views-pipeline-core transitively from PyPI through views-hydranet's dependency range, views-postprocessing from a git tag by exact pin. "Is the fix released?" therefore has two different correct answers depending on which half you mean, and nothing states that anywhere. views-postprocessing#310 is the same family.

What 1.4.0 carries

• fix(un_fao): the registry is the only source of coordinates, and its absence is fatal (#308, #309) #314 — the C-94 findability guard that verifies every artefact by name rather than trusting a returned file id. This is the defect that let the 2026-09-29 delivery log Postprocessor Run Completed and fire a success alert while being unservable.
• feat: bootstrap.sh + one writer for the Appwrite environment (#309, #311) #315 — a guard deriving the port's documented datastore contract from source, so the prose cannot drift from the code.

Verified before committing, not assumed

• tag 1.4.0 resolves on the remote the launcher actually pulls from — 8db8c9fbff181a0858737724d8bf5a68634c725d
• no other reference to 1.1.1 remains in the repo outside historical reports
• the ref-vs-pin guard at postprocessor.sh:164 still reads the same variable
• bash -n clean on both files

Both launchers, deliberately

un_crafd carries the identical pin and the identical exposure. Leaving CRAF'd on 1.1.1 would fix one partner delivery and silently leave the other on the version with the defect.

Not pinned to development

That would have been the lazy choice and it is worse than a moving target here: the :164 guard compares the installed ref against the pin string, so a branch name satisfies the check designed to catch staleness while installing whatever landed most recently. It would pass the guard and still be unreproducible for a partner-visible delivery.

Expect a behaviour change

A delivery that previously completed can now stop. 1.4.0 adds two refusal situations and no new exception types. A DeliveryNotFindableError names every object that does not resolve and states explicitly when nothing in the run is servable.

Process note

Edited under an explicit lift of the standing "do not modify run.sh" rule, granted by the maintainer for this change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GG2cY2HaqmUMpwUyR5V82K