main is red: lockfile-sync, compile fails on the merged tree

[github-actions]

The post-merge canary tested main at 40e3aaaf8 and it is red.

This names the commit that was tested, not the commit that broke the tree.
This run did not check 40e3aaaf8's parent, so the break may be older —
possibly by many merges. Confirm before reverting anything: re-run the failing
check on 40e3aaaf8^ and walk back while it still fails.

Failing: lockfile-sync, compile

lockfile-sync

check-lockfile-sync: FAIL — Cargo.lock is out of sync with the manifests.
check-lockfile-sync: 
check-lockfile-sync: cargo said:
check-lockfile-sync:          Updating crates.io index
check-lockfile-sync:      error: cannot update the lock file /home/runner/work/stella/stella/Cargo.lock because --locked was passed to prevent this
check-lockfile-sync:      help: to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.
check-lockfile-sync: 
check-lockfile-sync: Fix it by regenerating the lock and committing it:
check-lockfile-sync: 
check-lockfile-sync:        cargo metadata --format-version 1 >/dev/null   # or: cargo check --workspace
check-lockfile-sync:        git add Cargo.lock
check-lockfile-sync: 
check-lockfile-sync: Cargo.lock is tracked and install.sh builds --locked, so this reaches
check-lockfile-sync: people installing from source, not only CI. Commit the regenerated lock
check-lockfile-sync: in the same PR as the manifest change that moved it (#3332).

compile

�[1m�[91merror�[0m: cannot update the lock file /home/runner/work/stella/stella/Cargo.lock because --locked was passed to prevent this
help: to generate the lock file without accessing the network, remove the --locked flag and use --offline instead.

Why this was not caught before the merge

These checks are enforced against a shared cell — something every PR of a
given shape must write. Usually that is a file (Cargo.lock,
scripts/file-size-baseline.txt); it can equally be a seam two branches
each redesign in good faith (#3659). Either way, two branches can each be
correct, pass every check, and still compose into a broken tree once both
land. No pre-merge check has both halves in front of it, which is why this
canary exists (#3332).

How to fix

git checkout main && git pull

...then, per failing check:

lockfile-sync

cargo metadata --format-version 1 >/dev/null   # regenerates Cargo.lock
git add Cargo.lock

compile

cargo check --workspace --all-targets --locked

Land it on its own from a fresh main — do not fold it into an unrelated PR,
for the reason AGENTS.md gives about the file-size baseline.

Definition of done

• lockfile-sync passes on a fresh main with the fix applied
• compile passes on a fresh main with the fix applied
• The repair landed on its own from a fresh main, not folded into an
  unrelated PR.

Tick these on the repair PR's own tree — each is a command you can run before
you merge. The canary closes this issue itself on its next green run, so a box
nobody ticks costs the issue nothing; SCR-003's gate is what reads them, and it
runs on the PR.

Blast radius while this is open

A red main reds every open PR, so the next contributor inherits a failure
they did not cause and may spend their session on it.

If compile is among the failures, nothing builds: the whole test suite and
the release binary are down, not one crate. If lockfile-sync is, everything
that passes --locked breaks — the MSRV check, the stella-serve container
build, and install.sh, which reaches people installing from source rather
than only CI.

[github-actions]

Still red at 40e3aaaf8 — failing: lockfile-sync, compile.

[macanderson]

main-red-claim: macanderson b9ff105f6c72c7b5
Repairing this. The claim lapses after 20 minutes, so it cannot
hold the repair shut if this session dies (scripts/main-red-claim.sh, #4680).
The second word is this session's own, so another session of the same author
reads this as somebody else's claim.

[macanderson]

Repair is open as #6497: the stella-time lock entry from #6488 sat at 0.9.416 after the 0.9.417 sync in #6494. One-line lock regeneration; cargo metadata --locked passes on the branch.

[macanderson]

The break predates 40e3aaaf8. Evidence, so the next session does not bisect toward it:

lockfile-sync already fails on 40e3aaaf8^ (3fb123fd2). That commit's ci
run (34580661085)
fails in fmt + clippy + test with the identical message:

check-lockfile-sync: FAIL — Cargo.lock is out of sync with the manifests.
     error: cannot update the lock file ... because --locked was passed to prevent this

docker-serve and docs fail on that commit too, and its main-canary was
cancelled, so it never reported. That is why this issue names 40e3aaaf8:
it is the first commit whose canary ran to completion, not the one that broke
the tree.

40e3aaaf8 (#6493) cannot be the lockfile cause. Its diff contains no
Cargo.toml and no Cargo.lock — confirmed with
gh pr diff 6493 --name-only | rg -i 'Cargo\.(toml|lock)', which returns
nothing. 3fb123fd2 is the manifest-touching merge in that window: it adds the
stella-time crate and edits Cargo.lock plus six Cargo.toml files.

Two hypotheses I checked and ruled out, so nobody repeats them:

• stella-time missing from the lock — it is present at both 3fb123fd2 and
  40e3aaaf8.
• a stale version after the 0.9.417 sync — lock and workspace manifest both
  read 0.9.417 at 4db7928f8, 3fb123fd2 and 40e3aaaf8.

So the drift is something --locked sees that a name-and-version grep does
not; the next step is cargo metadata --format-version 1 on 3fb123fd2 and
reading what it rewrites. Walking back from there is the way to find the first
bad commit, per this issue's own instruction.

I am not taking the repair — main-red-claim.sh check stood me down for
this claim, and I am leaving it held. Posting only so the diagnosis is not
redone.

[macanderson]

main-red-claim: macanderson 6c62015fc283716c
Repairing this. The claim lapses after 20 minutes, so it cannot
hold the repair shut if this session dies (scripts/main-red-claim.sh, #4680).
The second word is this session's own, so another session of the same author
reads this as somebody else's claim.

[macanderson]

Repair: #6502 refreshes the one stale lock entry (stella-time 0.9.416 → 0.9.417). Cause: #6488's lock was refreshed against the 0.9.416 sync and the 0.9.417 sync (#6494) landed between its last rebase and its merge. Labelled unblocks-main; needs a merge once its ci run is green.

[macanderson]

Superseded: #6497 carried the same one-line lock refresh and merged first; #6502 is closed as an empty diff. The canary's next green run on main closes this.

[github-actions]

main is green again as of 544573f: every composition check
below passes. Closing automatically — reopen if you disagree.

Checked: lockfile-sync file-size compile prose ci-tests adr-numbering

[github-actions]

Closed by the post-merge canary at 544573f.