# 📦 WP-159 — `release: v0.7.0 augmentation engine upstream`

> Engineering log · [Phase 14 — Augmentation upstreaming to `fuse`, v0.7.0](https://borda.github.io/lucid-YOLO/engineering/phase-14-augmentation-upstreaming/)
>
> 🔗 Depends on [WP-158](https://borda.github.io/lucid-YOLO/work_packages/wp-158/) · Needed by [WP-160](https://borda.github.io/lucid-YOLO/work_packages/wp-160/)
>
> ⬅️ [WP-158](https://borda.github.io/lucid-YOLO/work_packages/wp-158/) · [Roadmap](https://borda.github.io/lucid-YOLO/ROADMAP/) · [WP-160](https://borda.github.io/lucid-YOLO/work_packages/wp-160/) ➡️


## WP-159 — the release that cannot be published, and why that was the better half

<a id="wp-159"></a>

`__version__` moves `0.6.0` to `0.7.0`, which is the whole of the version change — `pyproject.toml` declares the version dynamic and reads the module attribute. `[Unreleased]` closes as `[0.7.0]`. `make freeze-goldens MINOR=0.7` copies seven live metric sets into `goldens/frozen/0.7/`, the same seven `0.6` holds since [WP-154c](https://borda.github.io/lucid-YOLO/work_packages/wp-154c/) taught the mechanism to skip the two generator-derived goldens, and 43 goldens pass where 36 did before the freeze.

**The fourth clause could not be executed as written, and finding that out was the row's real work.** ADR-005 gates promoting `fuse-augmentations` to a runtime dependency on four conditions, the first being real SemVer releases to PyPI. Measured against PyPI's own API rather than recalled: the latest `fuse-augmentations` there is `0.10.0.dev0`, there is no 0.11 or 0.12 at all, and all eleven releases are `.dev0` pre-releases. The floor this phase stands on is `a5a276a`. Half of that was already written down in `pyproject.toml` before the row opened — PyPI forbids re-uploading the `0.10.0.dev0` version string — which is worth noting on its own: the blocker was legible in the tree for five work packages and nothing surfaced it, because `scripts/release_guard.py` checks the tag, the changelog section and the gate, and has no notion of dependency tiers.

**What made refusal the worse option is that ADR-005's own fallback expired.** The ADR says a refusal "returns the dependency story to a SHA pin, which keeps the augmentation stack local rather than making it unpublishable". That sentence was true when it was written and is not true now: `data/affine.py`, `data/augment.py`, `data/letterbox.py`, `data/mosaic.py` and `data/rotated_aug.py` all import `fuse_augmentations` at module level, so `lucid_yolo.data` — and `predict`, through `letterbox` — cannot import without it. The stack is not local any more, so refusing promotion returns nothing; it leaves the package in the `dev` group, where every install omitting that group yields a distribution that fails at import. The choice was never "publishable or not". It was "unpublishable, or broken for anyone who installs it without a development group", and those are not symmetrical.

**Condition 1 is therefore recorded as knowingly failed rather than quietly satisfied.** The pin moves into `[project].dependencies` as a direct reference, which is legal to build and install and illegal to upload, so the distribution is unpublishable to PyPI. That costs nothing this project currently does: `release.yml` states in its own header that publication is an unmade `[PRINCIPAL]` decision and deliberately omits it, so there is no upload for the rejection to break. Conditions 2, 3 and 4 are met and each was checked rather than asserted — the exact SHA is a stricter ceiling than the range condition 2 asks for; the promotion landed in its own work package whose licence audit was run and now places `fuse-augmentations` in the republished `base` tier beside `hotcoco`, clean at 107 distributions and 344 shipped binaries; and D20 with the `docs/ESCALATION.md` entry is the record condition 4 asks for. The principal was shown three alternatives — hold the release for PyPI, split the promotion into a later row, or stop — and chose this one. The remedy is small and dated: the day a 0.12 reaches PyPI, a `>=0.12,<0.13` range replaces the SHA and nothing else here changes.

**What this release does not claim.** No tag is cut and no distribution is published, as at 0.4.0, 0.5.0 and 0.6.0 — four release commits now stand ahead of the train's own tags. The contributor-admission rows [WP-141](https://borda.github.io/lucid-YOLO/work_packages/wp-141/) through [WP-144](https://borda.github.io/lucid-YOLO/work_packages/wp-144/) are still unstarted, [WP-141](https://borda.github.io/lucid-YOLO/work_packages/wp-141/) being a principal row whose three preconditions sit outside the roadmap, so Phase 14 ships with the same four-row tail Phase 13 did. A68, A69 and A70 remain open. No trained weights ship (D14). And the phase's subject is a boundary rather than a capability: nothing in 0.7.0 detects anything 0.6.0 could not, and the case for it is that the augmentation engine is now one implementation maintained in one place, with 43 goldens and a four-tier guard standing where the second copy used to be.