Skip to content

🚨 Escalation Log

Blocked-WP entries per the anti-guessing rule (AGENTS.md sec. 4). An agent stops and writes an entry here — then waits for a principal decision — when any of these occur:

  1. A gate fails after two documented assumption iterations (each iteration = a recorded ASSUMPTIONS.md revision plus a re-run).
  2. Answering a question would require a denylisted source. Never resolve an ambiguity by looking at the reference implementation.
  3. A WP's roadmap spec conflicts with the technical specification, or the specification conflicts with the papers.
  4. A change would require altering a frozen golden.
  5. A run would exceed 4 GPU-hours and is not already marked [PRINCIPAL].

Escalation is success, not failure: this log plus the assumption register is the research output a from-code port could never produce.

🧾 Entry template

## <date> — WP-<NNN> <slug>

- **Symptom**:
- **Hypotheses tried** (with ASSUMPTIONS.md revision ids):
- **Sources consulted** (allowlisted only):
- **Decision requested**:
- **Resolution** (filled by the principal):

📌 Entries

2026-09-03 — WP-154b the composition centre moves a frozen golden

  • Symptom: WP-154b changes AffineParams.matrix's composition centre from (W/2, H/2) to ((W-1)/2, (H-1)/2), the convention fuse-augmentations composes about. goldens/frozen/0.6/aug_invariants.json — a pure-code frozen golden written by the v0.6.0 release commit 22739e1 — pins five metrics the change moves past their tolerance: affine_image_mean 0.5565 → 0.5542 (tol 0.002), affine_bbox_coord_sum 121.3428 → 121.9856 (tol 0.05), affine_polygon_area 276.7792 → 277.6373 (tol 0.5), fused_image_mean 0.5529 → 0.5506 (tol 0.002), fused_bbox_coord_sum 91.0071 → 91.4892 (tol 0.05). Every hook, every one of 2543 unit tests and the other 35 goldens are green; the three residual pytest failures (scripts/_tests/test_check_goldens.py::test_real_goldens_pass, ::test_main_exit_code_zero_on_real_goldens, the check_all doctest) all assert "every real golden passes" and resolve with this one file. This is trigger 4: the row cannot be both gate-green and frozen-golden-clean.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): none — this is not an ambiguity to iterate on. The delta is fully traced rather than guessed: re-running aug_invariants with the centre reverted (and nothing else) reproduces all fifteen stored values bit-exactly, so the whole movement is the centre and there is no second cause to look for. mixup_image_mean (-0.0009) and rotated_rbox_area (-0.0001) move within tolerance from the same cause; every mirror-independent metric is unchanged, the mirror axis not being exercised by this producer.
  • Sources consulted (allowlisted only): docs/ENGINEERING_LOG.md WP-154b and WP-155b scope entries, docs/ROADMAP.md Phase 14 preamble, AGENTS.md sec. 4 and sec. 7, the WP-132 and WP-154 removals of generator-derived frozen goldens.
  • Decision requested: which of three, noting that the ruling covers the phase and not only this row — WP-155b plans to measure the letterbox resampling delta "against the 0.6 frozen goldens" and re-freeze what moves, and the metrics it will move (letterbox_image_mean, letterbox_pad_fraction, the fused pair) live in this same file.
    1. Remove goldens/frozen/0.6/aug_invariants.json, on the WP-132/WP-154 precedent. Different in kind from that precedent: those two were generator-derived and could never again be satisfied by any code change, whereas this one is pure-code and would be satisfiable by any release that did not deliberately give up the convention. Recoverable in history; costs a real regression guard for one release.
    2. Update its five values in place, which sec. 7 forbids outright and which makes "current code still satisfies every value a past release pinned" mean something weaker than it does today.
    3. Re-scope: hold WP-154b until 0.7 is released and freeze the new convention there, leaving 0.6 untouched — which blocks every remaining Phase 14 row, all of which depend on 154b.
  • Resolution (filled by the principal): Overriding AGENTS.md §7's standing prohibition on modifying a frozen golden, for this one file, on record — the values are updated in place rather than the file removed. goldens/frozen/0.6/aug_invariants.json's seven traced metrics (the five past tolerance plus mixup_image_mean and rotated_rbox_area, both moved within tolerance from the same cause) now match the live goldens/aug_invariants.json exactly. Presented with the removal alternative (same mechanism as WP-132/WP-154, no rule override needed) and chose the override instead.

2026-09-03 — WP-155 the letterbox resample moves the same frozen golden again

  • Symptom: WP-155 delegates Letterbox's resize-and-pad to fuse-augmentations, replacing an antialiased bilinear F.interpolate plus F.pad with one grid_sample from the source canvas to the letterboxed one. Geometry is bit-unchanged — letterbox_pad_fraction holds at 0.4, every coordinate round-trip case passes, goldens/data_checksums.json does not move — and exactly one image-derived value moves: letterbox_image_mean 0.5024 → 0.4994 against a 0.002 tolerance, in the live goldens/aug_invariants.json and in goldens/frozen/0.6/aug_invariants.json. 34 of 36 goldens pass; the two failures are that one metric in those two files. This is trigger 4 again, on the same frozen file WP-154b overrode eight commits ago, whose resolution was recorded as one dated exception and explicitly not a precedent.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): the delta is measured rather than assumed, and one alternative was tested rather than argued. Upstream's opt-in antialias=True was enabled and the producer re-run: the metric stays at 0.4994, the Gaussian mipmap prefilter not engaging at this producer's downscale, so recovering the old pixels is not available short of keeping the local implementation. A32 is revised in this change (non-antialiased resampling widens from the train path's deviation to the whole pipeline's filter) rather than contradicted.
  • Sources consulted (allowlisted only): the installed fuse_augmentations 0.12.0.dev0 source (affine/matrix.py, affine/segment.py, targets.py, factories.py, pipeline.py), docs/ENGINEERING_LOG.md WP-155 and WP-155b scope entries, docs/ASSUMPTIONS.md A32, AGENTS.md sec. 4 and sec. 7 ["sec. 6.5" struck 2026-09-06: AGENTS.md has never had a section 6.5 — it runs 1 to 8, sec. 6 is Naming hygiene and has no subsections, and git log -S "6.5" -- AGENTS.md returns nothing, so no revision of the file ever carried one. The entry is left otherwise as written; what cannot be left is a source list naming a document that does not exist], and the 2026-09-03 WP-154b entry above.
  • Decision requested: four, noting that WP-155 and WP-155b cannot both keep their commit boundary and a green gate — the swap moves the value, so WP-155 alone fails make gate and WP-155b alone has nothing left to measure.
    1. Keep the row split, accepting that WP-155's own commit fails the golden check and main is red between the two commits, which sec. 5 forbids.
    2. One commit, override the frozen value again: land the swap, the live re-freeze and frozen/0.6/aug_invariants.json's letterbox_image_mean together. Gate green, but a second sec. 7 override on the same file, and it merges a delegation swap with a frozen move — the exact pairing [citation corrected 2026-09-06, the original read "sec. 6.5", which does not exist in AGENTS.md; the standing rule carrying this content is ADR-005's migration protocol, step 3 (docs/DECISIONS.md): an expectation that turns red at a swap is diagnosed, and either the integration is fixed or a separate work package argues the old value was wrong — "never both in one commit, because that combination is indistinguishable from adjusting the test until the new code passes", which docs/CONTRIBUTING.md states again for contributors under A golden moved. Identified by matching the rule to the words, not from the author's stated intent, which is not on record] exists to prevent.
    3. Remove goldens/frozen/0.6/aug_invariants.json on the WP-132/WP-154 precedent, no rule override — at the cost of all fifteen of that file's metrics, fourteen of which are still satisfiable.
    4. Narrow WP-155 to the keep mask and the letterbox geometry, keeping _resize_pad local and antialiased so nothing moves — leaving two resample implementations in the tree and deferring the delegation to 0.7's freeze.
  • Resolution (filled by the principal): Option 2. Overriding sec. 7 a second time, on record: letterbox_image_mean becomes 0.4994 in both the live and the frozen copy, and WP-155 and WP-155b land as one commit. Presented with option 3 (removal, no override needed) and option 4 (no pixel moves at all) and chose the override. Two dated exceptions now stand on this file; neither is a standing waiver, and the next frozen-golden case is a fresh decision rather than one this precedent settles.

2026-09-04 — WP-159 the release cannot satisfy ADR-005's first condition

  • Symptom: WP-159's fourth clause promotes fuse-augmentations from a development pin to a runtime dependency "under the four conditions ADR-005 records". Condition 1 requires real SemVer releases to PyPI. Measured against PyPI's own JSON API: the latest fuse-augmentations there is 0.10.0.dev0, there is no 0.11 or 0.12 at all, and every one of the eleven releases is a .dev0 pre-release. The capability floor Phase 14 stands on is the commit a5a276a, which is unreleased. pyproject.toml already recorded half of this before the row opened — PyPI forbids re-uploading the 0.10.0.dev0 version string, so a bare version pin cannot reach the needed code.
  • What changed the shape of the question: ADR-005's stated fallback is that "a refusal returns the dependency story to a SHA pin, which keeps the augmentation stack local rather than making it unpublishable". That was written while the stack was still local. It has moved: src/lucid_yolo/data/{affine,augment,letterbox,mosaic,rotated_aug}.py all import fuse_augmentations at module level, so lucid_yolo.data — and predict, through letterbox — cannot import without it, while the package sat only in the dev group. Refusing promotion therefore no longer returns anything; it leaves a distribution that fails on import for anyone installing without that group. scripts/release_guard.py checks the tag, the changelog section and the gate, and has no notion of dependency tiers, so nothing automated would have caught it.
  • Sources consulted (allowlisted only): PyPI's JSON API for fuse-augmentations, pyproject.toml [project].dependencies and [dependency-groups].dev, .github/workflows/release.yml, scripts/release_guard.py, docs/DECISIONS.md ADR-005 and D19, and the module-level imports listed above, all read at f285af5.
  • Decision requested: four.
    1. Hold WP-159 until fuse cuts 0.12 to PyPI, then land the row whole with a >=0.12,<0.13 ceiling — the only path satisfying all four conditions as written, at the cost of an unbounded wait on a separate session and a broken-without-dev install in the meantime.
    2. Promote to a runtime git pin and accept the distribution is unpublishable: conditions 2, 3 and 4 met, condition 1 knowingly failed, on the grounds that publication is itself an unmade [PRINCIPAL] decision release.yml deliberately omits.
    3. Split the row: land 0.7.0 as the version bump, the changelog close and the 0.7 freeze, and defer the promotion to a new row gated on the PyPI release, documenting the exposure rather than fixing it.
    4. Stop, leaving WP-159 untouched alongside the four contributor-admission rows already blocked on principal preconditions.
  • Resolution (filled by the principal): Option 2. The runtime pin lands as a direct reference and the distribution is unpublishable to PyPI until a 0.12 exists there; recorded as D20. This is a decision about this dependency at this moment, not a general waiver of ADR-005 condition 1 — a second package arriving in the same state is a fresh decision.