fix: guard package lock version parity #45

Merged

andres merged 2 commits from build/43-lockfile-version-guard into main 2026-08-31 22:08:18 +00:00

Conversation 5 Commits 2 Files changed 3 +13 -2

codex-bot-andresmgsl commented 2026-08-31 20:07:42 +00:00

Member

Copy link

Refs #43

Summary

Normalize both package-lock version fields to 1.4.0 and add a governance regression test that prevents either field from drifting from package.json.

Worklog

• Claim #43 and post the bounded design before creating the branch
• Establish clean 129-test and governance baselines with both stale fields measured
• Add the parity test red-first, normalize only the two lockfile fields, and push the first checkpoint
• Resolve the mutation-command spec gap with triage
• Record the required red proof for a root-only lockfile mismatch using the triage-approved command
• Record the required red proof for a nested-root-package-only mismatch using the triage-approved command
• Add the cited changelog fragment and push the evidence checkpoint
• Run the focused guard, full regression suite, governance check, and diff checks
• Build and inspect the Debian artifact manifests
• Verify the complete pushed head for signal/ready handoff

Acceptance criteria

• package-lock.json root and nested root-package versions read 1.4.0, with no other lockfile field changed
• test/governance.test.js asserts both lockfile fields equal the package manifest version
• Root-only and nested-only mismatch mutations are recorded with red output from the triage-approved command
• npm test and npm run check:governance pass at the PR head
• ci / test is green at the final PR head
• The built Debian package ships matching package and lockfile versions

Verification

• Baseline: 129 tests passed and governance passed while both lockfile fields were 1.3.0
• TDD red: focused parity test failed with package-lock.json version is stale (1.3.0 !== 1.4.0)
• First green: npm install --package-lock-only changed exactly the two version fields; focused parity test passed
• Root-only mutation: focused parity test exited 1 with package-lock.json version is stale; mandated npm run check:governance exited 0, confirming the escalated wiring gap
• Nested-only mutation: focused parity test exited 1 with package-lock.json root package version is stale; mandated npm run check:governance exited 0, confirming the same gap
• Normalized head: focused guard passed; full npm test passed 130/130; npm run check:governance passed
• Debian artifact: package metadata 1.4.0; shipped package.json, lockfile root, and lockfile nested root package all 1.4.0
• git diff --check origin/main...HEAD: clean; three scoped files changed
• Current checkpoint: local and remote head 125bc04edea41375dfdcec342d413297d71a81d5; worktree clean

Round log

Round at 125bc04e

Round passed with no written reply.

Refs #43 ## Summary Normalize both package-lock version fields to 1.4.0 and add a governance regression test that prevents either field from drifting from package.json. ## Worklog - [x] Claim #43 and post the bounded design before creating the branch - [x] Establish clean 129-test and governance baselines with both stale fields measured - [x] Add the parity test red-first, normalize only the two lockfile fields, and push the first checkpoint - [x] Resolve the mutation-command spec gap with triage - [x] Record the required red proof for a root-only lockfile mismatch using the triage-approved command - [x] Record the required red proof for a nested-root-package-only mismatch using the triage-approved command - [x] Add the cited changelog fragment and push the evidence checkpoint - [x] Run the focused guard, full regression suite, governance check, and diff checks - [x] Build and inspect the Debian artifact manifests - [x] Verify the complete pushed head for signal/ready handoff ## Acceptance criteria - [x] `package-lock.json` root and nested root-package versions read 1.4.0, with no other lockfile field changed - [x] `test/governance.test.js` asserts both lockfile fields equal the package manifest version - [x] Root-only and nested-only mismatch mutations are recorded with red output from the triage-approved command - [x] `npm test` and `npm run check:governance` pass at the PR head - [x] `ci / test` is green at the final PR head - [x] The built Debian package ships matching package and lockfile versions ## Verification - Baseline: 129 tests passed and governance passed while both lockfile fields were 1.3.0 - TDD red: focused parity test failed with `package-lock.json version is stale` (`1.3.0 !== 1.4.0`) - First green: `npm install --package-lock-only` changed exactly the two version fields; focused parity test passed - Root-only mutation: focused parity test exited 1 with `package-lock.json version is stale`; mandated `npm run check:governance` exited 0, confirming the escalated wiring gap - Nested-only mutation: focused parity test exited 1 with `package-lock.json root package version is stale`; mandated `npm run check:governance` exited 0, confirming the same gap - Normalized head: focused guard passed; full `npm test` passed 130/130; `npm run check:governance` passed - Debian artifact: package metadata 1.4.0; shipped `package.json`, lockfile root, and lockfile nested root package all 1.4.0 - `git diff --check origin/main...HEAD`: clean; three scoped files changed - Current checkpoint: local and remote head `125bc04edea41375dfdcec342d413297d71a81d5`; worktree clean ## Round log <!-- round:125bc04edea41375dfdcec342d413297d71a81d5 --> **Round at 125bc04e** _Round passed with no written reply._

codex-bot-andresmgsl added 1 commit 2026-08-31 20:07:43 +00:00

fix: enforce package lock version parity 902ada1623

forgejo-actions added the

state:building

label 2026-08-31 20:07:58 +00:00

codex-bot-andresmgsl referenced this pull request 2026-08-31 20:08:29 +00:00

package-lock.json — bump it with package.json, and gate the two-file version bump in CI #43

codex-bot-andresmgsl added 1 commit 2026-08-31 20:09:47 +00:00

docs: record lockfile parity guard 125bc04ede

claude-bot-andresmgsl referenced this pull request 2026-08-31 20:20:39 +00:00

package-lock.json — bump it with package.json, and gate the two-file version bump in CI #43

codex-bot-andresmgsl commented 2026-08-31 20:49:03 +00:00

Author

Member

Copy link

⟲ resuming from 125bc04ede

⟲ resuming from 125bc04edea41375dfdcec342d413297d71a81d5

codex-bot-andresmgsl commented 2026-08-31 20:51:11 +00:00

Author

Member

Copy link

📣 round answered at head 125bc04ede

📣 round answered at head 125bc04edea41375dfdcec342d413297d71a81d5

codex-bot-andresmgsl changed title from WIP: fix: guard package lock version parity to fix: guard package lock version parity 2026-08-31 20:51:11 +00:00

codex-bot-andresmgsl requested review from glm-bot-andresmgsl 2026-08-31 20:51:33 +00:00

codex-bot-andresmgsl requested review from claude-bot-andresmgsl 2026-08-31 20:51:34 +00:00

codex-bot-andresmgsl requested review from kimi-bot-andresmgsl 2026-08-31 20:51:34 +00:00

codex-bot-andresmgsl added the

state:bots-reviewing

label 2026-08-31 20:51:35 +00:00

forgejo-actions removed the

state:building

label 2026-08-31 20:52:04 +00:00

claude-bot-andresmgsl commented 2026-08-31 21:00:55 +00:00

Member

Copy link

🔎 reviewing head 125bc04ede

• Worktree at head, npm ci clean
• AC1 lockfile diff is exactly the two version fields; npm install --package-lock-only is a no-op at this head
• AC2 npm test 130/130, npm run check:governance exit 0
• AC3 both mutations re-run independently and red: root-only → package-lock.json version is stale; nested-only → package-lock.json root package version is stale; distinct messages, so both assertions are load-bearing
• AC4 ci / test success at this head (run 674)
• AC5 built .deb: control, shipped package.json, lockfile root and nested all 1.4.0
• Doctrine: Refs-only, changelog fragment conforms, scope clean
• Verdict submitted

🔎 reviewing head 125bc04edea41375dfdcec342d413297d71a81d5 - [x] Worktree at head, `npm ci` clean - [x] AC1 lockfile diff is exactly the two version fields; `npm install --package-lock-only` is a no-op at this head - [x] AC2 `npm test` 130/130, `npm run check:governance` exit 0 - [x] AC3 both mutations re-run independently and red: root-only → `package-lock.json version is stale`; nested-only → `package-lock.json root package version is stale`; distinct messages, so both assertions are load-bearing - [x] AC4 `ci / test` success at this head (run 674) - [x] AC5 built `.deb`: control, shipped package.json, lockfile root and nested all 1.4.0 - [x] Doctrine: `Refs`-only, changelog fragment conforms, scope clean - [x] Verdict submitted

claude-bot-andresmgsl approved these changes 2026-08-31 21:03:45 +00:00

claude-bot-andresmgsl left a comment

Member

Copy link

Approve — head 125bc04edea41375dfdcec342d413297d71a81d5

Reviewed the whole PR at this head in a detached worktree (npm ci clean, 3 files, +13/-2). Every acceptance criterion on #43 verified by running it, not by reading the worklog.

Acceptance criteria

1. package-lock.json L3 and L9 read 1.4.0, no other field touched — ✅ git diff 21b91e8...125bc04 -- package-lock.json is exactly the two version fields; no lockfileVersion, no dependency resolution rode along. Independently, npm install --package-lock-only at this head reports up to date and leaves the worktree clean, so the lockfile is npm-canonical rather than hand-shaped.
2. Parity assertion across both fields; npm test and npm run check:governance pass — ✅ npm test 130/130 pass (129 → 130, the one new test); npm run check:governance → 4 identities resolved; 5 scope rows valid, exit 0.
3. Guard demonstrably fails on both mutations — ✅ re-ran both myself rather than taking the body's word:
   • root-only (L3 → 1.3.0): not ok 7 - package lock versions match the package manifest / package-lock.json version is stale / expected: '1.4.0' actual: '1.3.0'; node --test test/governance.test.js exit 1, npm test exit 1.
   • nested-only (packages[""].version → 1.3.0, L3 left correct): package-lock.json root package version is stale, same expected/actual, exit 1.
   • The two mutations produce distinct messages, so the second assertion is genuinely load-bearing — an L3-only guard would have passed mutation B. npm run check:governance exited 0 under both, exactly as the amended task note (2026-08-31T20:20Z) predicts; the criterion asks that command to pass at the head, which it does, so that is not a gap.
4. ci / test green at the head — ✅ commit status for 125bc04 is success: ci / test (pull_request) run 674, labels / labels (pull_request) run 675.
5. Shipped .deb manifests agree — ✅ bash scripts/build-deb.sh → dist/stoke_1.4.0_all.deb; dpkg-deb -f … Version = 1.4.0; after dpkg-deb -x, /usr/lib/stoke/package.json = 1.4.0, /usr/lib/stoke/package-lock.json root = 1.4.0, nested packages[""] = 1.4.0, packaged src/cli.js --version = 1.4.0. The metadata defect described in #43's consequence table is gone in the artifact, which is where the criterion places it.

Doctrine and constraints

• Refs #43, no closing keyword anywhere near the number — the body's only two mentions are Refs #43 and Claim #43, so the post-merge shape #200/#218 guards against is respected.
• changelog.d/43.md: one - bullet, 100 chars, ends (#43). with nothing after — conforms to BUILDER.md's fragment rule and matches 23.md/36.md. CHANGELOG.md untouched.
• Scope discipline holds: three files, all the issue's, nothing adjacent fixed in passing. README.md L1122 correctly left alone per decision 4. No workflow, no .ceremony pin, no action-token surface touched.
• Test conventions match the file it joins: module-scope path.join consts beside the existing ones, assert.equal with an intent message, same require style.

Non-blocking nit

The fragment reads Keep package-lock metadata aligned… while its two neighbours use past tense (Added…, Enforced…). Cosmetic, published prose only; address it or don't.

What I did not verify

• The worklog's baseline claims (129 tests and governance green while both lockfile fields were 1.3.0) — I measured the head, not the merge base. They are not acceptance criteria and criterion 1's diff makes the pre-state self-evident.
• lintian is not installed in this box, so the build script's package lint was skipped (it self-skips and says so); dpkg-deb, dpkg and fakeroot were present, so the build and extraction themselves are real, not simulated.
• CI itself I read through the commit-status API rather than the runner logs; the local npm ci && npm test && npm run check:governance sequence I ran matches ci.yml L25 and reproduces green.

## Approve — head `125bc04edea41375dfdcec342d413297d71a81d5` Reviewed the whole PR at this head in a detached worktree (`npm ci` clean, 3 files, +13/-2). Every acceptance criterion on #43 verified by running it, not by reading the worklog. ### Acceptance criteria 1. **`package-lock.json` L3 and L9 read `1.4.0`, no other field touched** — ✅ `git diff 21b91e8...125bc04 -- package-lock.json` is exactly the two `version` fields; no `lockfileVersion`, no dependency resolution rode along. Independently, `npm install --package-lock-only` at this head reports `up to date` and leaves the worktree clean, so the lockfile is npm-canonical rather than hand-shaped. 2. **Parity assertion across both fields; `npm test` and `npm run check:governance` pass** — ✅ `npm test` 130/130 pass (129 → 130, the one new test); `npm run check:governance` → `4 identities resolved; 5 scope rows valid`, exit 0. 3. **Guard demonstrably fails on both mutations** — ✅ re-ran both myself rather than taking the body's word: - root-only (L3 → `1.3.0`): `not ok 7 - package lock versions match the package manifest` / `package-lock.json version is stale` / `expected: '1.4.0'` `actual: '1.3.0'`; `node --test test/governance.test.js` exit 1, `npm test` exit 1. - nested-only (`packages[""].version` → `1.3.0`, L3 left correct): `package-lock.json root package version is stale`, same expected/actual, exit 1. - The two mutations produce *distinct* messages, so the second assertion is genuinely load-bearing — an L3-only guard would have passed mutation B. `npm run check:governance` exited 0 under both, exactly as the amended task note (2026-08-31T20:20Z) predicts; the criterion asks that command to pass at the head, which it does, so that is not a gap. 4. **`ci / test` green at the head** — ✅ commit status for `125bc04` is `success`: `ci / test (pull_request)` run 674, `labels / labels (pull_request)` run 675. 5. **Shipped `.deb` manifests agree** — ✅ `bash scripts/build-deb.sh` → `dist/stoke_1.4.0_all.deb`; `dpkg-deb -f … Version` = `1.4.0`; after `dpkg-deb -x`, `/usr/lib/stoke/package.json` = `1.4.0`, `/usr/lib/stoke/package-lock.json` root = `1.4.0`, nested `packages[""]` = `1.4.0`, packaged `src/cli.js --version` = `1.4.0`. The metadata defect described in #43's consequence table is gone in the artifact, which is where the criterion places it. ### Doctrine and constraints - `Refs #43`, no closing keyword anywhere near the number — the body's only two mentions are `Refs #43` and `Claim #43`, so the post-merge shape #200/#218 guards against is respected. - `changelog.d/43.md`: one `- ` bullet, 100 chars, ends `(#43).` with nothing after — conforms to BUILDER.md's fragment rule and matches `23.md`/`36.md`. `CHANGELOG.md` untouched. - Scope discipline holds: three files, all the issue's, nothing adjacent fixed in passing. `README.md` L1122 correctly left alone per decision 4. No workflow, no `.ceremony` pin, no action-token surface touched. - Test conventions match the file it joins: module-scope `path.join` consts beside the existing ones, `assert.equal` with an intent message, same `require` style. ### Non-blocking nit The fragment reads `Keep package-lock metadata aligned…` while its two neighbours use past tense (`Added…`, `Enforced…`). Cosmetic, published prose only; address it or don't. ### What I did not verify - The worklog's *baseline* claims (129 tests and governance green while both lockfile fields were `1.3.0`) — I measured the head, not the merge base. They are not acceptance criteria and criterion 1's diff makes the pre-state self-evident. - `lintian` is not installed in this box, so the build script's package lint was skipped (it self-skips and says so); `dpkg-deb`, `dpkg` and `fakeroot` were present, so the build and extraction themselves are real, not simulated. - CI itself I read through the commit-status API rather than the runner logs; the local `npm ci && npm test && npm run check:governance` sequence I ran matches `ci.yml` L25 and reproduces green.

kimi-bot-andresmgsl commented 2026-08-31 21:07:01 +00:00

Member

Copy link

🔎 reviewing head 125bc04ede

• Checked out detached worktree at HEAD.
• Verified package-lock.json L3 and L9 both read 1.4.0; diff against origin/main touches only those two version fields.
• git diff --check is clean.
• CI status shows ci/test green on this head.
• test/governance.test.js asserts parity on both lockfile version fields with distinct messages matching the recorded red proofs.
• changelog.d/43.md is a single bullet under 300 chars ending with (#43).
• Could not run npm test / npm run check:governance / build-deb.sh locally: node/npm/dpkg-deb are not installed in this box. Relying on the green CI run and code inspection for those criteria.
• Verdict: approve submitted for head 125bc04ede.

🔎 reviewing head 125bc04edea41375dfdcec342d413297d71a81d5 - Checked out detached worktree at HEAD. - Verified package-lock.json L3 and L9 both read 1.4.0; diff against origin/main touches only those two version fields. - git diff --check is clean. - CI status shows ci/test green on this head. - test/governance.test.js asserts parity on both lockfile version fields with distinct messages matching the recorded red proofs. - changelog.d/43.md is a single bullet under 300 chars ending with (#43). - Could not run npm test / npm run check:governance / build-deb.sh locally: node/npm/dpkg-deb are not installed in this box. Relying on the green CI run and code inspection for those criteria. - Verdict: approve submitted for head 125bc04edea41375dfdcec342d413297d71a81d5.

kimi-bot-andresmgsl approved these changes 2026-08-31 21:09:49 +00:00

kimi-bot-andresmgsl left a comment

Member

Copy link

Approve — head 125bc04edea41375dfdcec342d413297d71a81d5

Reviewed the whole PR at the current head against #43's acceptance criteria, the repo's load-bearing constraints, and the changed code.

Verified:

• package-lock.json L3 (version) and L9 (packages[""].version) both read 1.4.0, matching package.json.
• git diff origin/main...HEAD touches only those two version fields in package-lock.json; no other lockfile field changed.
• git diff --check is clean.
• test/governance.test.js asserts parity on both fields with distinct failure messages (package-lock.json version is stale and package-lock.json root package version is stale), matching the red outputs recorded in the PR body for the root-only and nested-only mutations.
• changelog.d/43.md is a single - bullet, 101 characters, ending with (#43).
• The PR body uses Refs #43 with no closing keyword before any #43 reference.
• The live status endpoint shows ci / test green on this head.

Could not verify locally: npm test, npm run check:governance, and bash scripts/build-deb.sh. This box has no node, npm, or dpkg-deb installed, so I relied on the green CI run and code inspection for those criteria.

No blocking issues. Approving.

## Approve — head `125bc04edea41375dfdcec342d413297d71a81d5` Reviewed the whole PR at the current head against #43's acceptance criteria, the repo's load-bearing constraints, and the changed code. Verified: - `package-lock.json` L3 (`version`) and L9 (`packages[""].version`) both read `1.4.0`, matching `package.json`. - `git diff origin/main...HEAD` touches only those two `version` fields in `package-lock.json`; no other lockfile field changed. - `git diff --check` is clean. - `test/governance.test.js` asserts parity on both fields with distinct failure messages (`package-lock.json version is stale` and `package-lock.json root package version is stale`), matching the red outputs recorded in the PR body for the root-only and nested-only mutations. - `changelog.d/43.md` is a single `- ` bullet, 101 characters, ending with `(#43)`. - The PR body uses `Refs #43` with no closing keyword before any `#43` reference. - The live status endpoint shows `ci / test` green on this head. Could not verify locally: `npm test`, `npm run check:governance`, and `bash scripts/build-deb.sh`. This box has no `node`, `npm`, or `dpkg-deb` installed, so I relied on the green CI run and code inspection for those criteria. No blocking issues. Approving.

glm-bot-andresmgsl commented 2026-08-31 21:21:43 +00:00

Member

Copy link

🔎 reviewing head 125bc04ede

• All 5 acceptance criteria verified by running them: lockfile diff exactly two fields + npm-canonical; npm test 130/130; check:governance exit 0; both mutations reproduced red with distinct messages; ci/test success on head; built .deb ships 1.4.0 in every manifest and in cli --version
• Constraints respected (Refs shape, changelog fragment, README L1122 untouched, no workflow/action surface); one non-blocking tense nit
• Submitting verdict: approve

🔎 reviewing head 125bc04edea41375dfdcec342d413297d71a81d5 - All 5 acceptance criteria verified by running them: lockfile diff exactly two fields + npm-canonical; npm test 130/130; check:governance exit 0; both mutations reproduced red with distinct messages; ci/test success on head; built .deb ships 1.4.0 in every manifest and in cli --version - Constraints respected (Refs shape, changelog fragment, README L1122 untouched, no workflow/action surface); one non-blocking tense nit - Submitting verdict: approve

glm-bot-andresmgsl approved these changes 2026-08-31 21:25:07 +00:00

glm-bot-andresmgsl left a comment

Member

Copy link

Approve — head 125bc04edea41375dfdcec342d413297d71a81d5

Reviewed the whole PR at this head in a detached throwaway worktree against #43's acceptance criteria, the repo's load-bearing constraints, and the code. The PR-side diff (true merge base 21b91e8, current main 01b25ca) is exactly three files: package-lock.json, test/governance.test.js, changelog.d/43.md. The README rename visible in a naive base..head diff is main's own #44, not this PR.

Acceptance criteria — each verified by running it

1. Lockfile L3 and L9 read 1.4.0, no other field touched — git diff 21b91e8..125bc04 -- package-lock.json is exactly the two version fields; no lockfileVersion or dependency-resolution delta. npm install --package-lock-only at this head leaves the worktree byte-identical, so the file is npm-canonical, not hand-shaped (decision 1). git diff --check clean.
2. Parity assertion on both fields; npm test and npm run check:governance pass — npm ci then npm test: 130/130 pass (129 baseline + the one new test); npm run check:governance: 4 identities resolved; 5 scope rows valid, exit 0. release.yml runs npm ci && npm test && bash scripts/build-deb.sh, so the guard also covers tagged releases with no new wiring, per decision 2.
3. Guard demonstrably fails on both mutations — reproduced independently, matching the red outputs recorded in the PR body: root-only (L3 → 1.3.0) exits 1 with package-lock.json version is stale; nested-only (packages[""].version → 1.3.9, L3 correct) exits 1 with package-lock.json root package version is stale. Distinct messages prove the second assertion is load-bearing; restored head re-runs green.
4. ci / test green on the head — commit status for 125bc04 is success for both ci / test (pull_request) and labels / labels (pull_request).
5. Shipped .deb manifests agree — built dist/stoke_1.4.0_all.deb; control Version 1.4.0; extracted /usr/lib/stoke/package.json, lockfile root, and lockfile packages[""] all read 1.4.0; installed stoke --version prints 1.4.0. #43's consequence table is resolved in the artifact, where the criterion places it.

Doctrine and constraints

• Refs #43 with no closing keyword before any #N mention (the only other mention is Claim #43); the post-merge shape is the issue's own instruction.
• changelog.d/43.md: one - bullet, 101 bytes, ends (#43). — conforms to the fragment rule and matches its siblings.
• Decision 4 respected: README L1122 untouched by this PR; no workflow, .ceremony pin, or action-token surface changed.
• Test conventions match the file it joins (module-scope path consts, assert.equal with intent messages).

Non-blocking nit (rides the approval)

The fragment opens Keep… where its neighbours use past tense (Added…, Enforced…) — cosmetic, builder's discretion; same observation as claude's round.

What I did not verify

• The worklog's baseline claims (129 green while both fields were stale) — I measured the head, not the merge base; they are not acceptance criteria and criterion 1's diff makes the pre-state self-evident.
• lintian is absent on this box, so the build script self-skipped package lint; dpkg-deb build and extraction themselves are real.
• CI internals were read via the commit-status endpoint, not runner logs; my local npm ci && npm test && npm run check:governance reproduces ci.yml L25 green.

## Approve — head `125bc04edea41375dfdcec342d413297d71a81d5` Reviewed the whole PR at this head in a detached throwaway worktree against #43's acceptance criteria, the repo's load-bearing constraints, and the code. The PR-side diff (true merge base `21b91e8`, current main `01b25ca`) is exactly three files: `package-lock.json`, `test/governance.test.js`, `changelog.d/43.md`. The README rename visible in a naive base..head diff is main's own #44, not this PR. ### Acceptance criteria — each verified by running it 1. **Lockfile L3 and L9 read 1.4.0, no other field touched** — `git diff 21b91e8..125bc04 -- package-lock.json` is exactly the two `version` fields; no `lockfileVersion` or dependency-resolution delta. `npm install --package-lock-only` at this head leaves the worktree byte-identical, so the file is npm-canonical, not hand-shaped (decision 1). `git diff --check` clean. 2. **Parity assertion on both fields; `npm test` and `npm run check:governance` pass** — `npm ci` then `npm test`: 130/130 pass (129 baseline + the one new test); `npm run check:governance`: `4 identities resolved; 5 scope rows valid`, exit 0. `release.yml` runs `npm ci && npm test && bash scripts/build-deb.sh`, so the guard also covers tagged releases with no new wiring, per decision 2. 3. **Guard demonstrably fails on both mutations** — reproduced independently, matching the red outputs recorded in the PR body: root-only (L3 → 1.3.0) exits 1 with `package-lock.json version is stale`; nested-only (`packages[""].version` → 1.3.9, L3 correct) exits 1 with `package-lock.json root package version is stale`. Distinct messages prove the second assertion is load-bearing; restored head re-runs green. 4. **`ci / test` green on the head** — commit status for `125bc04` is `success` for both `ci / test (pull_request)` and `labels / labels (pull_request)`. 5. **Shipped `.deb` manifests agree** — built `dist/stoke_1.4.0_all.deb`; control `Version` 1.4.0; extracted `/usr/lib/stoke/package.json`, lockfile root, and lockfile `packages[""]` all read 1.4.0; installed `stoke --version` prints 1.4.0. #43's consequence table is resolved in the artifact, where the criterion places it. ### Doctrine and constraints - `Refs #43` with no closing keyword before any `#N` mention (the only other mention is `Claim #43`); the post-merge shape is the issue's own instruction. - `changelog.d/43.md`: one `- ` bullet, 101 bytes, ends `(#43).` — conforms to the fragment rule and matches its siblings. - Decision 4 respected: README L1122 untouched by this PR; no workflow, `.ceremony` pin, or action-token surface changed. - Test conventions match the file it joins (module-scope path consts, `assert.equal` with intent messages). ### Non-blocking nit (rides the approval) The fragment opens `Keep…` where its neighbours use past tense (`Added…`, `Enforced…`) — cosmetic, builder's discretion; same observation as claude's round. ### What I did not verify - The worklog's baseline claims (129 green while both fields were stale) — I measured the head, not the merge base; they are not acceptance criteria and criterion 1's diff makes the pre-state self-evident. - `lintian` is absent on this box, so the build script self-skipped package lint; `dpkg-deb` build and extraction themselves are real. - CI internals were read via the commit-status endpoint, not runner logs; my local `npm ci && npm test && npm run check:governance` reproduces `ci.yml` L25 green.

forgejo-actions added

state:needs-human

and removed

state:bots-reviewing

labels 2026-08-31 21:28:32 +00:00

claude-bot-andresmgsl referenced this pull request 2026-08-31 21:28:48 +00:00

package-lock.json — bump it with package.json, and gate the two-file version bump in CI #43

claude-bot-andresmgsl referenced this pull request 2026-08-31 21:29:18 +00:00

release 1.4.0 — ship everything in v1.3.0..main, incl. issue create --label and release create --asset #32

codex-bot-andresmgsl requested review from andres 2026-08-31 21:33:48 +00:00

andres merged commit 9586d2c631 into main 2026-08-31 22:08:18 +00:00

andres referenced this pull request from a commit 2026-08-31 22:08:20 +00:00

Merge pull request 'fix: guard package lock version parity' (#45) from build/43-lockfile-version-guard into main

claude-bot-andresmgsl referenced this pull request 2026-08-31 22:40:47 +00:00

package-lock.json — bump it with package.json, and gate the two-file version bump in CI #43

claude-bot-andresmgsl referenced this pull request 2026-09-01 13:08:42 +00:00

.github/labeler.yml + .github/labels.conf — cover the repo's surfaces with the five scope rows, and guard the residue #48

claude-bot-andresmgsl referenced this pull request 2026-09-01 21:33:00 +00:00

.forgejo/workflows/labels*.yml + .ceremony/ — re-pin the ceremony machinery past 0.6.1, and the eleven measured defects — seven the bump answered, three it shipped, one it carried across #36

claude-bot-andresmgsl referenced this pull request 2026-09-04 00:49:43 +00:00

.forgejo/workflows/labels*.yml + .ceremony/ — re-pin the ceremony machinery past 0.6.1, and the eleven measured defects — seven the bump answered, three it shipped, one it carried across #36

claude-bot-andresmgsl referenced this pull request 2026-09-04 00:50:19 +00:00

.forgejo/workflows/labels*.yml + .ceremony/ — re-pin the ceremony machinery past 0.6.1, and the eleven measured defects — seven the bump answered, three it shipped, one it carried across #36

Sign in to join this conversation.

Reviewers

No reviewers

claude-bot-andresmgsl

kimi-bot-andresmgsl

glm-bot-andresmgsl

andres

Labels

Clear labels   

attention

A demand is parked here for the assignee: pick up the thread, ack by removing this label

  

blocked

Waiting on another PR or issue to land first

  

blocker:ci-red

A check is failing — the agent owes a fix (not a rebase)

  

blocker:conflict

Does not merge — the branch conflicts and the agent owes a rebase

  

blocker:drill-pending

A release PR whose version has no drills/X.Y.Z.md record — correct but unevidenced

  

blocker:unrequested

Somebody still owes a verdict and nobody was asked for one

  

bug

Something isn't working

  

claimed

A builder owns it: assignee set, draft PR expected shortly

  

documentation

Improvements or additions to documentation

  

enhancement

New feature or request

  

epic

Organizes other issues via a dependency-ordered task list — builders never pick it

  

merge-next

Head of the merge queue — merge this one next (set by hand/agent, cleared here)

  

needs-ruling

A human decision is pending — question, options and a recommendation are in the comment

  

needs-triage

Did not come through triage — owes normalization into work or a reasoned refusal

  

offsite

Issue deliverable is a PR in another repository — claim clock paused

  

post-merge

Refs-linked PR merged; post-merge criteria remain and triage owns completion

  

ready

Triaged, spec complete, unblocked — a builder can start now and succeed

  

release

Release flow and version/packaging work

  

scope:ci

.forgejo/workflows/, .github/, and .ceremony/ — the test, label, and governance gates

  

scope:cli

src/ — the command surface (cli.js, api.js, config.js)

  

scope:docs

root Markdown and docs/ — the prose contract

  

scope:manifests

manifests/ — the fleet repo registry data

  

scope:packaging

scripts/, release workflow, package manifests, changelog, and fragments — release packaging and version surfaces

  

stale

No activity for 48h — needs a poke (sweep-managed)

  

state:addressing

All bots reviewed — coding agent owes the single reply + fixes

  

state:bots-reviewing

Waiting on the bot reviewers to finish the round

  

state:building

Pre-round: the builder is still building — draft is evidence for it, not the definition

  

state:needs-human

No blockers, all bots approve — waiting on the human reviewer

No labels

attention

blocked

blocker:ci-red

blocker:conflict

blocker:drill-pending

blocker:unrequested

bug

claimed

documentation

enhancement

epic

merge-next

needs-ruling

needs-triage

offsite

post-merge

ready

release

scope:ci

scope:cli

scope:docs

scope:manifests

scope:packaging

stale

state:addressing

state:bots-reviewing

state:building

state:needs-human

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

4 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/stoke#45

No description provided.