chore(deps): weekly lockfile refresh

[github-actions]

Weekly npm update to pull transitive bug-fix releases within
existing semver ranges. Auto-generated by lockfile-refresh.yml.

Review-and-merge: CI on this PR will validate that the tree still
builds; merge manually after a quick scan of the diff. (Unlike
dependabot PRs, lockfile-refresh PRs are authored by
github-actions[bot] and the auto-merge workflow does not gate
on them.)

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: e8905e8

The dependency diff itself is clean and I verified it rather than eyeballing it. All 7 bumped packages have integrity hashes that match what the npm registry currently publishes, all 133 resolved URLs in the lockfile point at registry.npmjs.org (no registry substitution), lockfileVersion is unchanged at 3, and every bump stays inside the declared semver ranges. The one direct dependency touched is tsx (^4.21.0 → 4.23.12); the rest are transitive.

Critical Issues (0)

None.

Important Issues (1)

• [gstack/review] .github/workflows/lockfile-refresh.yml:41-47 (PR body text) — The PR body states "CI on this PR will validate that the tree still builds," but no CI is running on this PR. Measured at this head: check-runs → total_count: 0, combined status → pending, and both workflow runs (ci, Docker) → conclusion action_required, i.e. parked awaiting manual approval rather than executed. This is systemic, not a one-off — every bot-authored PR in this repo shows the same shape (#5 action_required, #4 skipped, #3 skipped), while the most recent human-authored PR (#2, kkroo) ran normally (success/failure). The usual cause is that PRs opened with the default GITHUB_TOKEN do not trigger normal workflow runs.
  • To be clear about blast radius: this specific diff is not unsafe to merge. The Confirm tree still builds step runs npm ci && npm run check && npm run build against the refreshed lockfile before create-pull-request, so this exact content was build-validated at generation time. Nothing renders a misleading green either — a reviewer sees "no checks," not a false pass.
  • The real exposure is the next commit. branch: chore/lockfile-refresh is a fixed, reused branch. Any commit pushed to it after the PR opens gets neither the pre-PR validation (already finished) nor PR CI (still parked), and would merge genuinely unvalidated.
  • Recommendation: pass a PAT or GitHub App installation token to peter-evans/create-pull-request instead of the default GITHUB_TOKEN so these PRs trigger workflows like any other. Failing that, correct the PR body so it claims what is actually true — that the tree was validated in the generating job, not on the PR — so no reviewer merges a follow-up commit on the strength of a guarantee that is not in force.

Suggestions (2)

• [native-codex] .github/workflows/lockfile-refresh.yml:26 — npm update --no-audit means a weekly dependency refresh is the one job that never looks at vulnerability data. Consider running npm audit after the update and folding the summary into the PR body; that turns this from "versions moved" into a signal a reviewer can act on, at near-zero cost.
• [native-codex] .github/workflows/lockfile-refresh.yml:26-27 — npm update already rewrites package-lock.json, so the follow-up npm install --package-lock-only is normally redundant. Harmless, but worth dropping unless it is there to normalize something specific.

Strengths

• The generate-time npm ci && npm run check && npm run build gate is the right design — it means a broken lockfile never becomes a PR in the first place.
• Scoping the action to add-paths: package-lock.json and deliberately leaving package.json to dependabot is a clean separation; it keeps this job incapable of silently widening a semver range.
• The lockfile is internally consistent: both nested content-type copies moved together to 2.1.0, and the top-level content-type@1.0.5 correctly stayed put as a separate major from a different parent.

Recommended Action

1. No Critical issues — this diff is safe to merge on its content.
2. Address the CI gap this cycle. It does not block this PR, but it silently voids the stated review protocol for any follow-up commit on the reused branch.
3. Consider the two suggestions opportunistically.

Systemic note for CTO: bot-authored PRs in this repo have never had CI actually execute (#3, #4, #5), while human-authored PRs do. Worth checking whether the same create-pull-request token pattern is in use in other Blockcast repos with automated PR workflows.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 27feda9

Prior Findings Dispositioned (1)

• prior:e8905e8 important 1 — still-present — .github/workflows/lockfile-refresh.yml:46 — The PR body still says CI will validate the tree, but at this exact head both ci and Docker runs are action_required and the head has zero check runs. The finding remains blocking because a later commit on the reused branch would not receive the promised PR validation.

Critical Issues (0)

Important Issues (1)

• [gstack/review] .github/workflows/lockfile-refresh.yml:46 — The generated PR claims that CI will validate the tree, but this PR has no executing CI: both workflow runs are parked as action_required and the head has total_count: 0 check runs. Because chore/lockfile-refresh is reused, a later commit pushed to this PR can merge without either the generation-time build or PR-time validation.
  • Use a PAT or GitHub App installation token for peter-evans/create-pull-request so the PR workflows execute, or change the body to state that only the generating job validated the tree and that PR checks may be unavailable.

Suggestions (2)

• [native-codex] .github/workflows/lockfile-refresh.yml:28 — Consider running npm audit after the refresh and including a concise result in the PR body.
• [native-codex] .github/workflows/lockfile-refresh.yml:29 — Consider removing the redundant npm install --package-lock-only unless it intentionally normalizes the lockfile.

Strengths

• The lockfile keeps lockfileVersion: 3 and the root semver ranges unchanged.
• The refreshed entries retain npm registry URLs and integrity hashes, and the generation job runs npm ci, npm run check, and npm run build before creating the PR.
• The update is scoped to package-lock.json, preventing this workflow from widening dependency ranges.

Recommended Action

1. Resolve the Important CI-validation gap before relying on this PR for future reused-branch commits.
2. The dependency-only content of this head is otherwise safe to merge after the validation limitation is understood.
3. Consider the Suggestions opportunistically.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 0276b31

Prior Findings Dispositioned (1)

• prior:27feda9 important 1 — still-present — .github/workflows/lockfile-refresh.yml:46 — The generated PR body still says CI will validate the tree, but both workflows for this exact head completed with action_required, and the commit has no executing CI checks. The finding remains blocking because a later commit pushed to the reused branch would not receive either the generation-time build or PR-time validation.

Critical Issues (0)

Important Issues (1)

• [gstack/review] .github/workflows/lockfile-refresh.yml:46 — The generated PR claims that CI will validate the tree, but this exact head has no executing CI: both ci and Docker workflow runs are action_required. Because chore/lockfile-refresh is reused, a later commit can merge without either the generation-time build or PR-time validation.
  • Use a PAT or GitHub App installation token for peter-evans/create-pull-request so PR workflows execute, or change the body to state that only the generating job validated the tree and that PR checks may be unavailable.

Suggestions (2)

• [native-codex] .github/workflows/lockfile-refresh.yml:26 — Consider running npm audit after the refresh and including a concise result in the PR body.
• [native-codex] .github/workflows/lockfile-refresh.yml:27 — Consider removing the redundant npm install --package-lock-only unless it intentionally normalizes the lockfile.

Strengths

• The lockfile remains at version 3 and the diff is limited to dependency resolution data.
• The refreshed entries retain npm registry URLs and integrity hashes; the direct dependency entries remain represented in the lockfile.
• The generation job runs npm ci, npm run check, and npm run build before creating the PR.

Recommended Action

1. Resolve the Important CI-validation gap before relying on this PR for future reused-branch commits.
2. The dependency-only content of this head is otherwise internally consistent.
3. Consider the Suggestions opportunistically.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 68938a2

The dependency diff is clean, and I verified it against the registry rather than eyeballing it. All 12 distinct bumped packages have integrity hashes that match what npm currently publishes, all 14 added resolved URLs point at registry.npmjs.org (no registry substitution), lockfileVersion is untouched, and the root packages[""] block is absent from the diff — so no declared semver range was widened. Every bumped package is transitive; package.json's four runtime and four dev dependencies are unchanged.

One change in this refresh deserved more than a glance, and I chased it down: negotiator 1.0.0 → 1.1.0 gains a runtime dependency (content-type: ^2.1.0) and raises its Node engine floor from >= 0.6 to >=18. Both are genuine upstream facts — the registry metadata for negotiator@1.1.0 declares exactly that — not lockfile tampering. It is also harmless here: package.json requires node >=20, CI pins Node 20, and Dockerfile.pod:22 is node:24-bookworm-slim, so the floor is satisfied on every surface. The nested content-type@2.1.0 that npm materialised under negotiator is the same version already resolved under body-parser and type-is, so no genuinely new package enters the tree.

Prior Findings Dispositioned (1)

• prior:0276b31 important 1 — still-present — .github/workflows/lockfile-refresh.yml:46 — The generated body still promises "CI on this PR will validate that the tree still builds," and at this exact head no CI executed: check-runs → total_count: 0, and both workflow runs (ci, Docker (designer-runtime:pod)) completed with conclusion action_required, i.e. parked awaiting manual approval. The reused chore/lockfile-refresh branch means a later commit would receive neither the generation-time build nor PR-time validation, so the finding remains blocking.

Critical Issues (0)

Important Issues (1)

• [gstack/review] .github/workflows/lockfile-refresh.yml:46 — (prior:0276b31 important 1, still-present, fourth consecutive week) The PR body claims CI will validate the tree; no CI runs on this PR. Both ci and Docker (designer-runtime:pod) sit at action_required and the head has zero check runs. Because branch: chore/lockfile-refresh (line 39) is fixed and reused, any commit pushed after the PR opens gets neither the pre-PR npm ci && npm run check && npm run build gate (already finished) nor PR CI (still parked).
  • Blast radius, stated precisely: this diff is not unsafe to merge on its content — the Confirm tree still builds step at lines 31-35 validated this exact lockfile at generation time, and nothing renders a misleading green. The exposure is the next commit on the reused branch.
  • Recommendation: pass a PAT or GitHub App installation token to peter-evans/create-pull-request (line 37) so these PRs trigger workflows normally. Failing that, correct the body text at lines 46-50 to say what is actually true — that the tree was validated in the generating job, not on the PR.

Suggestions (3)

• [native-codex] .github/workflows/lockfile-refresh.yml:43 — The body calls this "transitive bug-fix releases," but this refresh carries several minor bumps with real behavioural change — negotiator gained a dependency and 17 major versions of engine floor; express-rate-limit 8.6.2→8.7.0, qs 6.15.3→6.16.0, standardwebhooks 1.0.0→1.1.1, ip-address 10.4.0→10.7.0. npm update is behaving correctly (all in-range), but "bug-fix" undersells what a reviewer is being asked to scan for. "Transitive updates within existing semver ranges" would be accurate.
• [native-codex] .github/workflows/lockfile-refresh.yml:28 — npm update --no-audit means the one weekly job that moves dependencies is also the one that never looks at vulnerability data. Running npm audit after the update and folding a one-line summary into the body would turn "versions moved" into a signal worth acting on, at near-zero cost.
• [native-codex] .github/workflows/lockfile-refresh.yml:29 — npm update already rewrites package-lock.json, so the follow-up npm install --package-lock-only is normally redundant. Harmless; worth dropping unless it normalises something specific.

Strengths

• The generate-time npm ci && npm run check && npm run build gate (lines 31-35) is the right design: a broken lockfile never becomes a PR.
• add-paths: package-lock.json keeps this job structurally incapable of widening a semver range, and the diff confirms it — package.json and the lockfile root block are untouched.
• The lockfile is internally consistent under a non-trivial change: all three content-type@2.1.0 instances (body-parser, type-is, and the new negotiator nest) moved together, while the separate top-level content-type@1.x major correctly stayed put.
• Every bump lands inside the engine floors declared by package.json, CI, and Dockerfile.pod.

Recommended Action

1. No Critical issues. This diff is safe to merge on its content — the dependency data is verified against the registry.
2. The standing Important issue does not block this head, but it has now recurred for four consecutive weekly PRs and silently voids the stated review protocol for any follow-up commit on the reused branch. Worth fixing the token this cycle rather than re-reporting it a fifth time.
3. Consider the three suggestions opportunistically.

Note on the red status: the combined status at this head is failure, but both failing contexts (gate/ally-comment-findings, review/ally-comment) are review-attestation gates reflecting the undispositioned prior finding — not a build failure. ci and Docker have not run at all.

@cto — systemic, unchanged since 2026-08-16: bot-authored PRs in Blockcast/designer have never had CI execute (action_required on every one), while human-authored PRs run normally. Standard GITHUB_TOKEN + create-pull-request pattern; worth checking other Blockcast repos with automated PR workflows.