From 34f0a19e270de68bcd5048f42d697e4cb92820e8 Mon Sep 17 00:00:00 2001
From: Zoltan Kochan <z@kochan.io>
Date: Thu, 13 Aug 2026 17:09:12 +0200
Subject: [PATCH] docs: put lifecycle scripts on the right side of the upload
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The previous commit listed a dependency's own scripts among the things that
run after the install, which is where they do not run: pnpm executes them
during the install, ahead of the upload, so they stay inside the window rather
than being closed out of it. What keeps that narrow is that pnpm refuses to
run them at all — `ERR_PNPM_IGNORED_BUILDS` — unless the repository
allow-lists the package, and such a package can already run code in the job.
---
 README.md                                | 4 +++-
 src/lockfile-verification-cache/index.ts | 8 +++++---
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/README.md b/README.md
index 68b83ae..3e154b9 100644
--- a/README.md
+++ b/README.md
@@ -221,7 +221,9 @@ The action restores and saves that file on every run, independently of the `cach
 
 Reusing a verdict is not a weaker check: pnpm re-verifies whenever the lockfile content changes, and whenever the recorded policy is looser than the one now configured.
 
-The log is uploaded as soon as the install that produced it finishes, not at the end of the job, so nothing the job runs afterwards — its tests, its build, a dependency's own scripts — can alter what later jobs restore. A job that installs in a step of its own rather than through this action is saved at the end of the job instead, since that is the first moment the log is known to be complete.
+The log is uploaded as soon as the install that produced it finishes, not at the end of the job, so nothing the job runs afterwards — its tests, its build, any later step — can alter what other jobs restore. Dependency lifecycle scripts are the exception, since they run inside the install itself, ahead of the upload: pnpm refuses to run them unless the repository allow-lists the package through `allowBuilds`, and a package on that list can already run code in the job.
+
+A job that installs in a step of its own rather than through this action is saved at the end of the job instead, since that is the first moment the log is known to be complete.
 
 ### Cache dependencies from multiple lockfiles
 
diff --git a/src/lockfile-verification-cache/index.ts b/src/lockfile-verification-cache/index.ts
index 6414e78..43bc6f6 100644
--- a/src/lockfile-verification-cache/index.ts
+++ b/src/lockfile-verification-cache/index.ts
@@ -60,9 +60,11 @@ export async function restoreVerificationCache(lockfileHash: string): Promise<vo
 
 /**
  * Uploaded as soon as the install that produced the log finishes, rather than
- * at the end of the job: whatever a job runs after installing — its tests, its
- * build, a dependency's own scripts — can rewrite the log on disk, and the
- * job's own cache write would then publish that for later jobs to trust.
+ * at the end of the job: whatever a job runs after installing can rewrite the
+ * log on disk, and the job's own cache write would then publish that for later
+ * jobs to trust. Lifecycle scripts of the installed packages stay inside the
+ * window — they run during the install — but pnpm only runs those the
+ * repository has allow-listed.
  *
  * Safe to call more than once; the second call is a no-op.
  */