Repository navigation
bun.lock: regenerate deliberately when the bun pin moves (stale workspace bin metadata) #594
Description
Problem
Under bun 1.4.3, the pinned packageManager, bun install never refreshes a workspace package's bin metadata in bun.lock. The --force and --lockfile-only variants do not refresh it either. bun.lock had kept "archctx": "./cli/src/main.ts" after packages/surfaces/package.json moved its bin to ./cli/bin/archctx. #574 S1 (#589) corrects that one line by joint decision, so the lock matches its package.json authority.
Regenerating the whole lock (delete and reinstall) moves it to lockfile v2 and re-resolves more than 100 packages, for example @node-rs/jieba 2.0.1 to 2.0.4. That drift needs its own review.
Scope
When the bun pin next moves, regenerate bun.lock with the new bun. Verify:
bun install --frozen-lockfilepasses in CI;- every workspace
binrow in the lock equals its package.json; - the resolved dependency changes are listed in the PR and reviewed.
Write scope: bun.lock and package.json (packageManager) only. Medium tier.
Seat: orchestrator t7
Activity
fix(build): point the workspace archctx bin at cli/bin/archctx in bun…
Ancienttwo commentedon Nov 13, 2026
Joint decision (orchestrator + advisor), 2026-11-14. The owner said in pane t12: "那就更新到bun 1.4.4" (update to Bun 1.4.4). This replaces the hand-edit of
bun.lock:56in 574#issuecomment-6856897068.The advisor probed it on a clean worktree at origin/main.
bun@1.4.4 install --lockfile-onlyrewrites the stale workspace bin line (./cli/src/main.tsto./cli/bin/archctx) with no regeneration drift. Bun 1.4.4 fixes the stale workspace-bin bug.A separate PR pins Bun 1.4.4 before S1 merges, Tier Medium with one GPT review. It is tracked here on bun.lock: regenerate deliberately when the bun pin moves (stale workspace bin metadata) #594, because moving the pin is the deliberate lock regeneration that bun.lock: regenerate deliberately when the bun pin moves (stale workspace bin metadata) #594 asks for.
Write scope: every in-force 1.4.3 pin:
package.json(packageManager,bun-types);.github/workflows/verify.yml, with its sixbun-versionsites and the :82 comment;.github/workflows/windows-acl-diagnostics.yml;scripts/verify-ci.mjs;packages/contracts/src/product-version.tsandfixtures/valid/product-version-manifest.json;docs/runbooks/governance-revalidation.mdandverify-sharding.md;bun.lock, regenerated by bun 1.4.4 and never hand-edited.Dated records stay as they are:
docs/verification,docs/researchesand the release checklists. The downstream-corpus fixture is recorded data from other repositories, so it stays unless a test asserts it. The PR lists each 1.4.3 hit as changed or left, with the reason.The workflow edits change the required-CI definition, which is an owner item. The owner's instruction covers it. The advisor merges this PR from t12 once the orchestrator signs off the gate (green CI plus GPT PASS), as for chore(repo-harness): refresh repo-local harness config to 0.32.0 #590.
S1 (feat(codegraph-adapter): one in-process read-only read session (#574 S1) #589) drops its
bun.lockcommit, waits for the Bun PR, rebases, and runs CI under 1.4.4. 1a, 2a and the darwin module stay. S1 re-checks under 1.4.4 whether the WindowsEBUSYand the macOS Bun sidecar behavior still reproduce, and shrinks the guards if either changed.Seat: orchestrator t7
chore: pin Bun 1.4.4 (#594) (#595)