[patchstackdave]

Link 3 of 3. The chain is now closed end to end.

The platform proves "this reviewed recipe plus this map produces these exact rule bytes". This proves those exact bytes block the exploit and allow a benign control. Neither is worth anything alone — a rule generated correctly and never fired is the defining defect of this product, and it is invisible from the side that generated it.

The artifact is vendored, not rebuilt

Nothing here parses a recipe, evaluates a detector, or binds a coordinate. rule_v2 and when go into the bundle verbatim, exactly as the guard receives them from the rules endpoint. A second implementation of the binding would recreate the duplicate-implementation seam the canary exists to catch, and both sides could then be wrong together.

The exploit is the published shape — _$$ND_FUNC$$_function(){ require("child_process")... }() — not a string lifted from the signature. A payload copied out of the regex would only prove the regex matches itself.

Every assertion is load-bearing

Confirmed by mutating the handover:

mutation	result
rule pinned to the wrong parameter	3 failed
scope removed (applies everywhere)	2 failed
signature widened to /./	1 failed
scope points at a different route	3 failed

Four engine assertions: exploit blocked, benign allowed, another endpoint untouched (the scope is real, not decoration), and dry-run detects without blocking — the mode a site starts in; if it blocked, adopting protection would be a traffic change rather than an observation.

Three more check the handover itself so a hand-edited artifact cannot pass: the checksum must match its own rule bytes, the recipe hash must be present, and the rule must be scoped and bound.

Against the built engine, and against what shipped

dist/protect.js is what an application loads. Testing src/ would prove the source blocks the exploit and say nothing about the bundle — and the bundler is a real failure surface: an export dropped, a branch shaken out, an edge build diverging.

So, per your ruling:

• PR CI — after the build, against dist/protect.js from this checkout.
• Publish workflow — twice: on the build about to ship, and on the engine unpacked from the published tarball via PS_CANARY_ENGINE.

The second is the only proof that covers packaging: a file left out of files, a wrong exports map or a bad entry point produces an artifact that passes every local check and cannot protect an application. It runs after the publish because the tarball does not exist until then — a failure there cannot unpublish the version, but not knowing is worse. It retries the registry fetch and reports an install failure as unverified, never as a pass.

Verified against the real registry: the published 0.3.31 engine blocks the exploit and allows the control.

PS_REQUIRE_CANARY turns a skip into a failure, following bin-invocation. Verified both ways: it refuses to skip with the flag set, and without it the three artifact-integrity tests still run. The fixture ships nowhere — npm pack --dry-run finds no match.

Full suite: 1683 passed, 7 skipped; typecheck and template typecheck clean.

🤖 Generated with Claude Code

[coderbuds]

Comprehensive canary tests ensure the built and published engine block the exploit.

🎯 Quality: 100% Elite · 📦 Size: Medium

📈 This month: Your 146th PR — above team average · Averaging Excellent

_{See how your team is trending →}

[patchstackdave]

/review