[ENG-3630] Say request-path shielding is applicable, and generate the demo maps

[patchstackdave]

Two things on one subject: what the surface note claims, and where the demo example maps come from.

The note was a protection status

surfaceNote said, for a recognised server runtime:

Request-path protection applies to this app.

Recognising code that serves requests establishes which kind of protection is relevant to those paths. It establishes nothing about whether a guard is installed, fetching rules, or enforcing them — none of which a build-time map can see. So the sentence asserted the second thing while measuring the first.

It now reads:

Request-path shielding is APPLICABLE to these paths — this is not a statement that a guard is installed, fetching rules, or enforcing them.

This matters more than internal prose would: the note is copied into coverage.notes, and consumers render those verbatim. The claim was already on a dashboard, in five stored fixtures, beside a card whose whole design is to avoid exactly that claim.

Nothing pinned any of the three notes, which is how it drifted in the first place. The suite now asserts the applicability wording on the server state, the "not deployment attestation" caveat on static, the "must not be read as no server side" caveat on unknown, and scans all three for posture claims (is protected, is safe, protection applies, …). Restoring the old sentence fails the first of those.

The demo maps now have a generator

examples-emit does for the demo examples what ladder-emit does for the ladder fixtures. Four apps, one per state worth showing:

app	state	why it produces it
server-runtime	server-runtime-detected	Express routes the extractor recognises, request input reaching several dependency sinks
static-build	static-build-detected	a named static generator, nothing serving, no deployment artifact to veto it
unknown-unparsed-stack	unknown	a server framework whose routes are registered from a table — no call site to read
unknown-deployment-declared	unknown	a platform config and a named generator: the config rules out a static reading without proving anything serves

The two unknown variants are separate on purpose — their evidence differs, so a consumer deriving a next step from the evidence has something to derive from.

Hand-written demo data shows a shape the extractor does not emit and goes stale in silence; generated data can be regenerated and diffed. Output is byte-identical across runs, which is what makes "inspect the diff" a real review step rather than a ritual.

The states the extractor never emits are deliberately not here. A build with no serverSurface (older than the check) and one reporting a state the reader does not know (newer than it) are properties of the consumer's timeline, not of any source tree — no app produces them. The loader derives both from server-runtime.json, and the emitted index says so rather than leaving the next person to wonder why the set looks incomplete.

Each app also asserts its state in the ordinary suite, not only when someone is regenerating. An extractor change that moves one would otherwise turn the demo into a map of something else, discovered whenever someone next happened to regenerate.

Verification

1220 tests, typecheck clean (including the template harness). The note change is mutation-tested: restoring the previous wording fails the applicability assertion and nothing else, so that test is load-bearing rather than incidental.

Consumers embedding the old note text in stored fixtures will need to regenerate them after this lands — for the platform's ladder fixtures that is the ladder-emit step, and the platform PR carrying them is sequenced behind this one.

[coderbuds]

Comprehensive demo map generation and note wording update with thorough testing.

🎯 Quality: 100% Elite · 📦 Size: Medium

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

_{See how your team is trending →}

[patchstackdave]

/review