You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 0363312
Browse filesBrowse the repository at this point in the historyBrowse files
Let the deployed guard name the build it runs (#456)
The guard's live report sends `_patchstack.manifest_checksum` from its rules
file, but nothing wrote that field, so a live report could only say that some
build was serving. The `prebuild` scan now records the checksum of the package
list being built there, beside the map stamp, before the bundler reads the
file. A server-rendered deployment with no marker on its pages can then say
which build it is.
Co-authored-by: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
The generated `prebuild` scan deliberately carries no hard-coded environment. A production build with no override reports `production` only because the platform's own variables — its tier, or its branch name — say it is one; a preview or pull request on those platforms reports `sandbox` by itself, and a hosted builder's *workspace* reports `sandbox` for anything but a build lifecycle script, and must receive `PATCHSTACK_ENVIRONMENT=sandbox` from its host only if it runs builds (the Replit workspace reports `sandbox` on its own) — its published build needs no override, because a build in such a project is the publish step. Runtime protection itself is not environment-specific: `PATCHSTACK_ENVIRONMENT` labels manifests only. Use `PATCHSTACK_MODE=dry-run` when protection should observe rather than block.
466
466
467
-
During a build, the `prebuild` scan removes any previous map stamp. A later `map --upload` in the same pre-bundle lifecycle hashes the map's policy content (excluding analyser timing and memory observations) and records that identity in the guard's existing rules file. The guard presents it on the rules request it already makes; only an explicit Patchstack confirmation naming the same map lets a rule scoped to one of your app's parameter names block. A build with no confirmed identity still enforces every ordinary rule — only scoped rules drop to detect-only, with the reason reported. Outside a pre-bundle hook, `map --upload` changes no file and sends no identity. In any project whose guard has a rules file, unless `.patchstackrc.json` sets `"bundleRules": false`, a `scan` that holds the key also uploads the map, writes its identity and the site's current rules into the guard's rules file (keeping the starter signatures, only when something changed), so a keyless build of the same source — a hosted builder's publish, or any deploy without the key — ships those rules and is recognised. The same runs store a read-only rules credential in that file (`_patchstack.rules_reader`, from `monitor/pulse/rules-reader/<uuid>`), with which the published app fetches live rules and reports detections — it can read this site's rules and report detections for this site, and nothing else. Detections reported on it are stored **unverified** (set `PATCHSTACK_API_KEY` in the deployment to report as verified). See "Which build a rule belongs to" in `AGENT-INSTALL.md`.
467
+
During a build, the `prebuild` scan removes any previous map stamp and records the checksum of the package list being built as `_patchstack.manifest_checksum` in the guard's rules file; the deployed guard sends it when it reports the deployment live, so Patchstack knows which build is serving. A later `map --upload` in the same pre-bundle lifecycle hashes the map's policy content (excluding analyser timing and memory observations) and records that identity in the guard's existing rules file. The guard presents it on the rules request it already makes; only an explicit Patchstack confirmation naming the same map lets a rule scoped to one of your app's parameter names block. A build with no confirmed identity still enforces every ordinary rule — only scoped rules drop to detect-only, with the reason reported. Outside a pre-bundle hook, `map --upload` changes no file and sends no identity. In any project whose guard has a rules file, unless `.patchstackrc.json` sets `"bundleRules": false`, a `scan` that holds the key also uploads the map, writes its identity and the site's current rules into the guard's rules file (keeping the starter signatures, only when something changed), so a keyless build of the same source — a hosted builder's publish, or any deploy without the key — ships those rules and is recognised. The same runs store a read-only rules credential in that file (`_patchstack.rules_reader`, from `monitor/pulse/rules-reader/<uuid>`), with which the published app fetches live rules and reports detections — it can read this site's rules and report detections for this site, and nothing else. Detections reported on it are stored **unverified** (set `PATCHSTACK_API_KEY` in the deployment to report as verified). See "Which build a rule belongs to" in `AGENT-INSTALL.md`.
0 commit comments