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-10-26 — WP-208…214 one A100 session over the GPU-hour budget

  • Symptom: closing the six [GPU] packages of the audit stack (WP-208, WP-210, WP-211, WP-212, WP-213, WP-214) under D32 needed a green make gate-gpu and each package's accelerator tests on its own commit. Run as one session, that is about seven GPU-hours, over trigger 5's four.
  • Hypotheses tried: none; this is a budget question, not a failure.
  • Sources consulted: none.
  • Decision requested: one A100 session of about seven hours, or the tip's gate and the per-commit arms split across two.
  • Resolution (principal, 2026-10-26): one session. It ran green: make gate-gpu at the tip 72b5505, tests/ptl on py3.13, and each package's own commit.

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.

2026-09-15 — WP-177 the keypoint OKS golden moves outside its stored band

  • Symptom: WP-177 batches equal-shape MuSGD matrices (PR #3, 38b30ac). make gate is 50/50 offline-green; make gate-gpu is 54/55 — goldens/gpu/overfit_micro_kp.json's train_oks_ap is frozen at 0.574728 with tolerance 0.05 (band 0.524728–0.624728), and the patched run measures 0.691134, 0.1164 above the band ceiling. A same-L4 ABBA control isolates the cause to this patch alone: unchanged f8de2e2 scores 0.5315, 0.5315; this patch scores 0.6911, 0.6911 — deterministic and repeated, not run noise. This is trigger 4: closing WP-177 as specified requires either altering the frozen golden or accepting a value outside it, and docs/ROADMAP.md row 177's own DoD ("make gate and make gate-gpu green") is consequently unmet — its status stays 🔄.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): none opened — the PR's own multi-seed baseline sweep (unpatched code) already shows the stored band is seed-sensitive: seed 0 0.5315 (inside band), seed 1 0.595869 (inside), seed 2 0.408795 (outside the same 0.574728 ± 0.05 band, on code that has not changed). That is evidence the band's reliability is separate from this PR's correctness, not a hypothesis to iterate — no seed-1/seed-2 run of the patched code exists yet, so whether the patch shifts the trajectory or only widens it under the same seed noise is undetermined either way.
  • Sources consulted (allowlisted only): PR #3 body and its measurement section; /oss:review report .reports/review/2026-09-15T18-47-30Z/review-report.md ([blocking] HIGH — keypoint OKS AP golden shift unresolved, corroborated independently by solution-architect, challenger and Codex, with a documented sw-engineer dissent); goldens/gpu/overfit_micro_kp.json; docs/ROADMAP.md row 177; docs/ENGINEERING_LOG.md WP-177 entry.
  • Decision requested: three, per the review's shared unblock path (solution-architect and challenger independently proposed the same GPU experiment) plus the sw-engineer dissent as a fourth framing of the same underlying gap:
    1. Run the patched code at seeds 1 and 2 on GPU before deciding anything else. Lands inside the sampled baseline cloud (0.409–0.596) → the band itself is miscalibrated (single-seed), fix the band under option 3 and merge; lands systematically higher at all three seeds → the batched path shifts the trajectory rather than moving within float-scheduling noise, and needs a mechanism explanation before merge. Requires L4 GPU access this workflow does not have.
    2. Accept 0.691134 outside the frozen band now, per sec. 7's sanctioned override route: python scripts/freeze_goldens.py --reseal after this entry is answered — same mechanism as the two 2026-09-03 aug_invariants.json overrides above. A short-horizon overfit metric moving up is not evidence of quality gain (both PR body and review agree on this), so accepting the movement is a statement about gate calibration, not about the change being good.
    3. Re-freeze overfit_micro_kp.json on a multi-seed band (sw-engineer's dissent) — derive the tolerance from observed multi-seed spread rather than a single fixed seed, since the unpatched baseline already escapes the current band at seed 2. Fixes the measuring instrument independent of whether WP-177's patch is accepted, at the cost of leaving WP-177 open until the new band exists.
  • Resolution (filled by the principal): pending — awaiting decision; WP-177 stays 🔄 in docs/ROADMAP.md until answered.

2026-09-19 — WP-183 the keypoint and oriented accelerator goldens move outside their bands

  • Symptom: WP-183 scores the box terms densely over every anchor instead of gathering the positives (loss-identical per step: the masked form is kept as an oracle in the tests and the dense form matches it to 1e-6 on values and gradients; the CPU step golden holds). make gate is 50/50; make gate-gpu on an A100-40GB (venv torch 2.14.0+cu130) is 53/55 — goldens/gpu/overfit_micro_kp.json train_oks_ap measures 0.491935 against the band 0.574728 ± 0.05, and goldens/gpu/overfit_micro_obb.json train_rotated_map50 measures 0.908802 against 0.964928 ± 0.05; detection, segmentation and shapes_regression_det pass on the same dense loss. A same-machine per-commit control attributes the move: pre-WP baseline 30aea93 scores 0.5696 / 0.9783 (both in band); WP-182 channels_last alone 0.5486 / 0.9388 (in band, a −0.021 / −0.040 move from a layout change that alters no arithmetic); WP-183 0.4919 / 0.9088 (out); WP-184 with the flag off repeats WP-183 to four decimals. Deterministic on the machine, repeated across two rounds. This is trigger 4.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): none opened. The per-step arithmetic is proven identical; what differs on the accelerator is the order of a sum over B × A terms carrying exact zeros against a sum over the P positives — a ~1e-7 relative difference per step that a 100-epoch overfit on 100 images amplifies into a different endpoint. WP-182's own −0.040 on obb from a pure kernel-selection change, and the WP-177 entry above (unpatched code at seeds 0, 1, 2: 0.5315, 0.5959, 0.4088 — the last outside the same band), put both moves inside the spread this metric shows on code that has not changed. A single seed per commit cannot separate that from a bias; det/seg/shapes passing on the same _box_losses is the evidence against one.
  • Sources consulted (allowlisted only): .plans/closed/results_compile-gate_run{2,3}.ipynb (the two rounds' outputs); the WP-177 entry above and its seed sweep; goldens/gpu/overfit_micro_{kp,obb}.json; scripts/overfit_micro.py (clamped_tolerance); docs/ENGINEERING_LOG.md WP-183.
  • Decision requested: (1) a three-seed control, baseline against WP-183, on both tasks, before deciding (about two A100-hours); (2) reseal both goldens on the current tree at the measured values — a statement about gate calibration on this machine, not about WP-183; (3) re-freeze on a multi-seed band (the WP-177 entry's option 3), which would resolve both entries at once. Reverting WP-183 is not offered: it is what lets the training step trace as one graph (WP-184), and it is loss-identical per step.
  • Resolution (filled by the principal, 2026-09-19): Option 2. goldens/gpu/overfit_micro_kp.json is resealed at 0.491935 ± 0.05 and goldens/gpu/overfit_micro_obb.json at 0.908802 ± 0.008802 — the oriented tolerance is clamped_tolerance's min(0.05, score − 0.9), so that band is now as narrow as the score's headroom above its floor, and the next environmental move on obb will be reported rather than absorbed. Recorded as WP-186. The WP-177 entry stays pending on its own question; this resolution does not answer it.
  • Follow-up (2026-09-20, Colab rounds 4–5, same A100): the three-seed control the entry asked for was run afterwards, per commit — baseline 30aea93, WP-182 16f4101, HEAD 37f3ce5 (WP-183 plus the compile flag off) — at seeds 0, 1, 2. Keypoints train_oks_ap: baseline 0.5696 / 0.6187 / 0.5331, WP-182 0.5486 / 0.7259 / 0.5858, HEAD 0.4919 / 0.5668 / 0.5715; oriented train_rotated_map50: baseline 0.9783 / 0.9690 / 0.9696, WP-182 0.9388 / 0.9628 / 0.9544, HEAD 0.9088 / 0.9379 / 0.9670. The oriented move that looked monotone at HEAD (3 of 3 seeds down, mean −0.034) belongs to WP-182 (−0.020, 3 of 3) and not to WP-183 (−0.014, 2 of 3, seed 2 up) — a memory-layout change that alters no arithmetic produces the same signature as the loss rewrite, which is the control that says the signature is trajectory chaos rather than a bias. Keypoints span 0.49–0.73 across the nine runs; the two 3-of-3 sign results out of four comparisons, one per WP, are what a null with p = 0.125 each expects. Reading: no evidence of a systematic move on either WP; the reseal stands as calibration; the band widths (± 0.05 inside a ± 0.12 process, ± 0.0088 inside ± 0.03) are the WP-177 entry's question and remain with it. Notebooks results/compile_gate.ipynb, results/compile_gate_round5.ipynb.

2026-10-20 — WP-193d CUDA accumulation checks fail on the unmodified baseline

  • Symptom: WP-193d keeps pose replay native under gradient accumulation because "the shared recorder's accumulation checks diverge on the unchanged baseline", and records that "existing CUDA accumulation failures reproduce on the unmodified baseline and are outside this scheduling change". Which tests fail is not recorded in WP-193d, and neither is the torch version or driver they failed on: the torch 2.9.1 and 2.4.0 runs and driver 580.178.04 it names belong to its passing focused cases and its timing cohort, not to these failures, so the divergence cannot be re-run from the record as written. The rest of the record still describes accumulation as safe — WP-193c's "Accumulation retains its own gradients" paragraph, and docs/TRAINING.md's "Accumulation or custom optimiser/zero-grad hooks preserve live gradients outside the graph-owned backward buffers" — while the accumulation guard in DetectionLitModule._training_network (src/lucid_yolo/ptl/module.py) retires keypoint replay only, so detection replay under accumulation keeps running. No sec. 4 trigger fires literally: no gate failed after two assumption iterations and no frozen golden moves. The entry is written because the questions below are principal decisions and this log is where the next agent looks for them.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): none opened. WP-193d treats the failures as pre-existing and outside its change, and contains them for pose by staying native rather than diagnosing them; no ASSUMPTIONS.md revision was made.
  • Sources consulted (allowlisted only): WP-193d ("One fit owns one signature" and "Compatibility and remaining evidence"), WP-193c ("Accumulation retains its own gradients"), docs/TRAINING.md "Opt-in CUDA network replay", src/lucid_yolo/ptl/module.py _training_network, src/lucid_yolo/ptl/network_capture.py _before_replayed_backward, AGENTS.md sec. 4 and sec. 7.
  • Decision requested: three, none of which an executing agent can settle from the code.
    1. Whether detection replay must also stay native under gradient accumulation, as pose already does — the guard covers task: keypoints only — and whether that change lands as its own work package.
    2. Whether docs/TRAINING.md and WP-193c gain an accumulation caveat now, before the divergence is reproduced on CUDA with named tests and runtime, or only once it is.
    3. Whether CUDA cases failing on the unmodified baseline count as a red main under sec. 7, given that the offline gate runs without a GPU.
  • Resolution (principal, 2026-10-23): the divergence was a defect in the shared recorder, not in the baseline. WP-206 found it on CUDA (named tests, L4 and A100, two runtimes) and fixed it: the live-gradient copy runs at forward time again instead of from a pre-hook inside the replayed backward. With that fix, pose, oriented and segmentation network replay match native bitwise at accumulate_grad_batches=2, and the tree before the fix does not; the counts are on WP-207.
    1. Replay under accumulation: allowed for every task. Detection already replayed; WP-207 removes the accumulation retirement for keypoints, oriented and segmentation network replay. Segmentation head capture keeps its own accumulation guard.
    2. No accumulation caveat. The CUDA performance page drops the accumulate_grad_batches=1 requirement for network replay. The history stays on the WP-206 and WP-207 pages.
    3. A known failing CUDA test is a red main until fixed, and a [GPU] work package does not close without a make gate-gpu run. The contract change lands as its own commit. The 🔄 status of WP-193c and WP-193d is a separate check against their own DoD, which names runs still outstanding; this resolution does not flip it.

2026-10-24 — WP-209 the keypoint accelerator golden moves outside its band again

  • Symptom: make gate-gpu on an A100-SXM4-40GB under Python 3.11 / torch 2.9.1+cu129 is 54/55 on 6109747 and on the uncommitted WP-208 tree alike: goldens/gpu/overfit_micro_kp.json train_oks_ap measures 0.582045 against the band 0.491935 ± 0.05 that the 2026-09-19 entry resealed. A same-machine control repeats it: scripts/overfit_micro.py --task kp scores 0.5820 once on 6109747 and twice on the WP-208 tree, which sets no replay flag on this path. The detection, segmentation, oriented and shapes_regression_det accelerator goldens pass on the same run. This is trigger 4.
  • Hypotheses tried (with ASSUMPTIONS.md revision ids): none opened. The 2026-09-19 entry's follow-up measured this metric at 0.49–0.73 across nine runs (three commits, three seeds) whose per-step arithmetic matched, and read both earlier moves as trajectory spread rather than a bias. 0.582045 lies inside that spread. The sealed value was measured under torch 2.14.0+cu130 (the 2026-09-19 entry), this one under 2.9.1+cu129; the 43 commits since the seal were not bisected, because a single-seed attribution inside that spread names a commit without showing a cause.
  • Sources consulted (allowlisted only): the 2026-09-15 and 2026-09-19 entries above and the latter's follow-up; goldens/gpu/overfit_micro_kp.json; scripts/overfit_micro.py (clamped_tolerance); the two Colab result sets (colab_11, colab_12) recorded on WP-209.
  • Decision requested: reseal at the measured value on this runtime (the 2026-09-19 route), re-freeze on a multi-seed band (the WP-177 entry's option 3), or bisect the commits since the seal first.
  • Resolution (principal, 2026-10-24): reseal. goldens/gpu/overfit_micro_kp.json stores train_oks_ap 0.582045 with tolerance 0.05 (clamped_tolerance keeps the nominal width, the score sitting well above the 0.30 floor), measured on an A100 under torch 2.9.1, and lands with WP-209. This is calibration on that runtime, not a claim about any commit. The WP-177 entry stays pending on its own band question.