DISMISSED — LCK-1 — the CI lock is version-pinned but hash-less

status: dismissed by TRIAGE 2026-08-31 · OVERFLOW — lowest-ranked at the pre-registered 12-item cap · raised 2026-08-29 (external design review finding 4) · body verbatim below

Resolution — mechanical overflow; the item parks itself for at least four weeks

research/queue/open/ held 15 files against the pre-registered 12-item cap (ops/QUEUE_TRIAGE.md:86-90). This is the second of the three lowest-ranked dismissals.

The premise is intact and re-verified at HEAD 528793d — grep -c -- '--hash' requirements-ci.lock is still 0, and every trading workflow installs with -c requirements-ci.lock (a constraint) rather than --require-hashes. Nothing here is overtaken.

It ranks last because the item defers itself, in its own words: "First quiet week after the owner returns; pair it with a normal trading day's soak before any selection day." Regenerating the lock re-resolves versions, i.e. it changes CI's install inputs — and momentum's monthly alpha selection runs on the first trading day of each month (2026-09-01, then 2026-10-01), with an owner absence expected between them. There is no decision for the owner to make about this row for at least four weeks, and carrying it through four weekly reports would spend the cap on a row whose only content this month is "not yet".

Nothing is lost by the dismissal: the finding is independently recorded in research/2026-08-29_design_review_verification.md, which is where the external review's five findings live, and the full fix shape and kill criterion are preserved verbatim below.

Reopen condition. Reopen in the first week after the owner returns that contains no first-trading-day selection, or immediately if a dependency compromise, a yanked wheel, or an unexplained CI install difference is observed on any pinned version. Reopen also if the owner decides the supply-chain exposure should not wait — the row's deferral is a judgement about timing, not about worth.

Body as filed (verbatim, untouched)

LCK-1 — the CI lock is version-pinned but hash-less, and nothing enforces it off the CI path

status: open · raised 2026-08-29 (external design review finding 4, narrowed by its own round 2) · class: reproducibility / supply-chain · judgement: YES · effort ~0.25 pd · horizon: deliberately after the September trip — see the scheduling note, which is the reason this row exists instead of a commit

What is true today (verified). CI installs with pip install . -c requirements-ci.lock across the trading workflows, so CI is version-reproducible. But the lock carries zero --hash entries (grep -c -- '--hash' requirements-ci.lock → 0), so CI is not hash-verified (a tampered or re-uploaded wheel of a pinned version installs silently), and a hand-provisioned venv (pip install . without -c) resolves pyproject.toml's floating floors to whatever exists that day.

Framing correction carried from the verification memo: "the box that trades real money" is GHA, which uses the lock — the residual is hash-verification plus local-parity, which is why this is the lowest-priority finding of the five, not why it is skippable.

Fix shape

1. Regenerate the lock with hashes (pip-compile --generate-hashes or equivalent) and install with --require-hashes everywhere trading code runs.
2. One-line tripwire so it cannot silently regress: a docs-consistency-style test asserting the lock contains --hash entries.

Kill criterion

CI green on the hashed lock; flip one hash locally and the install must fail loud. Revert the tripwire test and the hash-less state must red it.

Scheduling note (the point of this row)

Regenerating the lock RE-RESOLVES versions — it changes CI's install inputs. Doing that the week before a monthly selection day, into an owner absence, is a self-inflicted incident risk that outweighs the supply-chain risk it closes. First quiet week after the owner returns; pair it with a normal trading day's soak before any selection day.