Each of the three was merged on evidence I could not reach myself. This
replaces that trust with a test that runs on every platform, on every CI run.
1. Windows lock (#1261). The no-sentinel fix was unverifiable on POSIX —
msvcrt is None, so the branch never executes and a regression would be
invisible to Linux and macOS CI. tests/test_windows_lock_no_sentinel.py
swaps the module-level fcntl/msvcrt handles for stubs and drives the
Windows branch anywhere, asserting behaviour (an empty file stays empty,
the first ledger append succeeds and verify_chain passes) rather than
'was locking() called'. Restoring the sentinel in all three lock sites
fails 3 of the 4 tests, including the first-append regression itself.
2. Dividend cash column (#1356). A dividend row has no quantity and no price,
so 'amount or qty * price' collapses to 0.0 when the export books the
payout under a cash-movement heading instead of the fill column. That is a
silent zero — the shape #1207 item 15 is about. Dividend rows now also try
发生金额 / 资金发生额 / 红利金额 / 实发金额 / 税后金额 and Futu's net-amount
columns, across all four parsers; anything still zero is counted into a new
dividend_rows_missing_cash profile field so the caller can SEE that the
journal was read but the money was not.
3. Docker action majors (#1359). The v4/v6/v7 bump had never executed in this
repository: docker-build.yml is workflow_dispatch only, total_runs=0. Every
input the workflow passes was checked against each new major's action.yml
at the pinned SHA (13 inputs, all present; the two setup actions take none).
A validate-build job now runs the SAME pins with push: false on any change
to the Dockerfile, this workflow, or pyproject, and the publish job is
gated to workflow_dispatch so the new triggers cannot publish an image.
That gate is one 'if:' line, so it is pinned too — removing it, flipping
validate-build to push: true, or unpinning an action each fail a test.
The file comment claiming these majors were 'a deliberate, separately testable
bump, not a drive-by change here' contradicted the file after #1359 and is
replaced by what is actually true now.
Four issues in the new workflow and Dockerfile:
- Every action floated on a mutable major tag, and BuildKit was pinned to
moby/buildkit:master. This was the only workflow in the repo doing so; the
other four already pin full commit SHAs. All seven actions are now SHA-pinned
with a version comment, and the custom driver-opts block is dropped, which
also removes an unneeded network=host.
- id-token: write was granted with no OIDC consumer anywhere in the workflow —
no cosign, attestation, provenance, or OIDC login step. Dropped.
- The Dockerfile installed channel extras with 'pip install -e ".[extras]"'
after the --require-hashes lock install. lark-oapi, qrcode and
python-telegram-bot are in neither requirements-lock.txt nor its source, so
the build resolved them and their transitive deps unhashed from PyPI at build
time — six lines below a comment stating deps come from the hash-pinned lock.
They now come from requirements-channels-lock.txt (16 pins, all hashed,
generated under the same constraint as the main lock: 12 packages are shared
with it and none diverge in version). The project install is --no-deps, which
is safe because all 44 pyproject base deps are already in the main lock.
- The workflow_dispatch input was interpolated directly into the Summary step's
run: body. It now passes through env, and the tag is validated against the
Docker tag grammar before any registry work.
CI verifies the new lock too. The existing 'Verify hash-locked dependencies'
step only dry-ran requirements-lock.txt, so a second lock could have rotted
undetected until a release build failed; both are now dry-run separately, since
the Docker build installs them as two independent --require-hashes passes.
The summary also states that a new GHCR package is private until its visibility
is set once, so the pull command it prints is not read as working out of the box.
Haozhe Wu