chore: refresh the install-scripts allowlist against the lockfile

[ggbdpq]

Small hygiene fix for npm's install-scripts approval gate (npm ≥ 11.6): on a fresh clone of this repository, the gate flags seven packages whose install scripts are not covered by the allowScripts map in package.json.

• Two entries trail the lockfile: esbuild@0.27.7 is allowlisted while the lockfile pins 0.28.2, and @jackwener/opencli@1.8.4 while the lockfile pins 1.8.7. The exact-version keys no longer match what actually installs, so the gate still flags them.
• Five packages were never allowlisted: electron-winstaller, protobufjs, tree-sitter-javascript, @astryxdesign/cli, and @astryxdesign/core all carry install/postinstall scripts but had no entry at all.

Every allowlist entry is now the exact version pinned in package-lock.json (verified against node_modules), and a fresh npm install completes with no unreviewed-script warnings.

Verification

Check	Result
npm install-scripts ls after install	no unreviewed packages
npm install	0 vulnerabilities, no gate warnings
A full node_modules scan for install/postinstall scripts	exactly the 8 allowlisted packages, all version-matched
biome format package.json	clean

Devs on npm versions without the approval gate never see the warnings, which is why the list drifted.

AI use

Implemented with GLM-5.3-Flash (ZCode): the lockfile cross-check, the allowlist refresh, and the completeness scan.

• I have read the project's contributing guidelines
• The commit message follows the repository convention
• Every allowlist version is verified against package-lock.json

[hqhq1025]

Reviewed exact head 1e899b5dc088e3cbfdbb9f0854696f27591e6731. All eight allowScripts entries match non-optional packages and exact versions in package-lock.json whose lock entries have hasInstallScript: true. The only other dependency with that flag is the optional, Darwin-only fsevents, which this PR does not approve.

P3 — Do not approve lifecycle scripts that this repository does not need (package.json:130-132,136). The published @astryxdesign/cli@0.6.2 and @astryxdesign/core@0.6.2 postinstall scripts only print setup nudges; protobufjs@7.6.5 only checks the version notation and prints a warning; and @jackwener/opencli@1.8.7 skips its shell-completion postinstall on this repository's local install (and in CI). None produces an install artifact needed by Maka. Setting these entries to true grants four packages install-time code execution solely to remove npm's unreviewed-script warning. npm's install-scripts deny records an explicit false decision and also clears that warning without executing the scripts. Please deny these nonessential scripts and retain approval only where installation/build behavior requires it.

The one-file diff is whitespace-clean and merges cleanly with current main. Visible checks on this head are successful. I inspected the lock entries and the published lifecycle scripts but did not run npm 11's install-scripts gate or a fresh install locally, so this is not an independent runtime confirmation of the author's warning-free install claim. This COMMENTED review is not merge approval.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[hqhq1025]

Reviewed the current head 7bdbbe1e. This follow-up changes only package.json:130-132,136, explicitly denying the four nonessential lifecycle scripts identified in my previous review. The four remaining approved scripts retain exact-version matches to non-optional hasInstallScript entries in package-lock.json; optional Darwin-only fsevents is not approved. I found no remaining P0–P3 issue in this one-file change.

The current-head test, package, package-linux, audit, and platform owner checks succeeded, and the diff is whitespace-clean and merges cleanly with current main. I did not independently run npm 11's install-scripts gate or a fresh install locally (this host has Node 18/npm 9), so the warning-free install claim remains unverified here. This COMMENTED review is not merge approval.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[me2seeks]

Automated review notice: This comment was posted by an automated review agent operated by me2seeks make. It is not an independent human review and does not replace one.

Summary

The PR refreshes the root allowScripts map to match package-lock.json for npm ≥ 11.6's install-script approval gate: two stale exact-version keys are corrected (esbuild 0.27.7→0.28.2, @jackwener/opencli 1.8.4→1.8.7) and five previously unlisted script-carrying packages are added. The issue is real — base package.json:129-133 trails the lockfile (package-lock.json:9571, 3291) — and a config-only edit is the right-sized fix. However, the "exactly the 8 allowlisted packages" completeness claim is false per the lockfile itself.

Findings

1. [P2] package.json:129-138 — fsevents@2.3.3 is missing from the map. package-lock.json:10178-10185 shows fsevents with "hasInstallScript": true, optional: true, os: ["darwin"]. The author's "full node_modules scan" was evidently run on Linux, where this darwin-only optional dependency is never installed, so the ninth script-carrying package was missed. macOS is a first-class platform here (CI owner (macos-latest), Electron desktop app), so a fresh npm install on a Mac will still trip the gate — or silently block fsevents' install script — exactly what this PR claims to eliminate. Fix: add a deliberate "fsevents@2.3.3": true|false entry.
2. [P3] package.json:129 — no guard prevents recurrence. Nothing in CI or scripts cross-checks allowScripts against the lockfile (the only in-repo references are the staging-strip at scripts/package-macos-arm64-cli.mjs:184 and its test; no .github workflow mentions it). The PR body itself states drift is why the list broke ("Devs on npm versions without the approval gate never see the warnings"), so without a check in the existing audit job the map goes stale again on the next esbuild/opencli bump.

Non-issue verified: the @jackwener/opencli true→false flip is safe and arguably more correct — its postinstall only installs shell completions and a global-install adapter sync (node_modules/@jackwener/opencli/scripts/postinstall.js, fetch-adapters.js header: "Only runs on global install"), while the desktop app consumes it purely as a library (apps/desktop/src/main/browser/session.ts:20). Likewise electron-winstaller@5.4.0: true is harmless cross-platform (select-7z-arch.js copies prebuilt vendor/7z-{x64,arm64}.exe, both present).

Verdict

needs-changes — add the missing fsevents@2.3.3 entry so the completeness claim holds on macOS; otherwise the version-refresh itself is verified correct.

[ggbdpq]

Addressed the P2 at aa31461d4: "fsevents@2.3.3": true sits in sorted position in the map. Confirmed against the lockfile (node_modules/fsevents: version 2.3.3, hasInstallScript: true, optional, os: ["darwin"]) — the entry allows its native build script, matching the treatment of node-pty/esbuild, so a fresh macOS install no longer trips the gate for it.

On the P3 (no guard against recurrence): agreed the map can drift again, but I'd keep this PR config-only and land the cross-check as a follow-up — a small script comparing allowScripts against the lockfile's hasInstallScript entries, wired into the existing audit job. Happy to open that follow-up PR with the check if you'd rather review it separately; say the word and it's coming.

The opencli true -> false flip stays as your non-issue note describes: its postinstall only wires shell completions and global-install adapter sync, and the desktop consumes it as a library.

[hqhq1025]

Reviewed the current head. The added fsevents@2.3.3 decision matches the optional Darwin-only, install-script-bearing lockfile entry; the four previously unnecessary scripts remain denied. The new guard compares every script-bearing lockfile package with exact allowScripts keys, rejects stale or non-boolean decisions, and runs in the dependency-audit workflow. Its four focused tests and the real-lockfile check pass locally. I found no substantiated P0–P3 issue in these changes. I could not exercise npm 11 installation on macOS, and the current head’s hosted checks were still running at review time. This is not a merge approval.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[ggbdpq]

Both review threads are now closed on head c43d3b077:

• P2 (fsevents missing): addressed at aa31461d4 — "fsevents@2.3.3": true sits in sorted position in the map, verified against the lockfile entry (optional: true, os: ["darwin"], hasInstallScript: true).
• P3 (no drift guard): implemented at c43d3b077. scripts/check-allow-scripts.mjs fails on any lockfile entry carrying hasInstallScript that the map does not key (optionality is not an exemption — the fsevents case), any map key trailing the lockfile (this PR's root cause), and any non-boolean decision. dependency-audit.yml runs it beside the shipped-closure audit and its paths filter now covers the script. The script's own test covers the synced map, the fsevents case, the stale-version bump, and a non-boolean value (4/4 green locally), and the audit job on this head already passed with the step in place.

The test failure on the earlier head aa31461d4 was not from this PR either: it is the main-preexisting acp-goal-plan-child-process.test.js timeout, now filed as #5777 (red starts at 0fd754083, parent ca1ac87ca green; #5265 hits the identical signature).

[ggbdpq]

The test red on 0339c3ae4 is a single timing-sensitive assertion in packages/runtime's code-mode.test.js ("excludes host waiting from the execution budget and preserves dependent Promise.race progress", false !== true at line 64) — nothing this PR touches, and the same file passes three consecutive local runs (33/33 each) on this exact tree. Head is now a5b07c507, a tree-identical retrigger.

[hqhq1025]

Reviewed commit a5b07c5. The new tip is an empty CI retrigger after merging main; the effective PR change remains the exact-version allowScripts inventory and its drift guard. On this head, node scripts/check-allow-scripts.mjs reports all nine install-script dependencies covered, and the four guard tests pass. The merge-tree and diff-check against fresh main de4fc5f are clean. I found no new substantiated P0-P3 issue in the changed code.

This is not merge-ready yet: the current-head Windows package job failed while electron-builder's icon-tool process exited with 3221225477 during ICO conversion. I cannot establish from this run whether it is transient or caused by the integrated main/toolchain, so the required gate remains red. The current-head test, audit, package-linux, and Windows/macOS owner jobs passed. I did not run npm 11 installation on macOS or a Windows package build locally.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[hqhq1025]

Reviewed commit 58d09e0. This tip is an empty-tree CI retrigger: its tree is byte-for-byte identical to the preceding reviewed head a5b07c5. The effective change is still the exact-version allowScripts inventory plus its lockfile drift guard. The preceding same-tree local guard run covered all nine script-bearing packages and passed 4/4 focused tests; no new code finding is introduced by this tip.

The current-head test, audit, package-linux, Windows package, and Windows/macOS owner jobs are now SUCCESS. Fresh main de4fc5f merge-tree and diff-check are clean. The earlier Windows icon-tool crash did not recur, but a single successful retry does not establish its cause. I did not run macOS npm 11 installation or local Windows packaging.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

[ggbdpq]

Heads-up for reviewer bandwidth: #4865 (open since Sep 5, cross-referenced above) overlaps this PR on both halves — it refreshes the same stale esbuild/@jackwener/opencli pins and adds a guard at the same path, scripts/check-allow-scripts.mjs. The two guards differ in mechanism: #4865 delegates detection to npm install-scripts prune --dry-run --json (npm 11.19 semantics, pinned npm) and gates via check:allow-scripts; this PR's guard is a lockfile cross-check wired into the dependency-audit workflow (already green here, 6/6).

The allowlist-refresh half is duplicated labor — whichever PR merges first settles it. For the guard, #4865's npm-native semantics may be the better long-term replacement for this PR's lockfile cross-check; if the maintainers prefer that, I'm happy to rebase this PR's guard onto the prune-based approach or drop it in favor of #4865's — whichever avoids two competing scripts at the same path.