Classify whether the app has a server side, from positive signals only

[patchstackdave]

ENG-3630 step 2, on the evidence layer from #147. serverSurface reports one of three states with the
signals behind it.

Why the static state is the one that has to be hard to reach

An app with no server runtime cannot run a request guard, so its advisories are dependency and bundle
hygiene rather than request-path risk. Said plainly, that is genuinely useful to the owner. Said wrongly, it
is "nothing to protect here" on an app nobody could read — the worst output this analysis can produce.

So static-build-detected needs a generator NAMED, and three things block it:

rule	why
a static generator must be identified	absence of server signals is not evidence — endpoints: [] is exactly what an unparsed framework looks like
a server-framework dependency blocks it	express installed with no endpoint parsed is a parsing gap, not a static site
any deployment shape blocks it, layout included	a root api/ holding source may be a front-end helper or platform functions; from here they are the same folder

And a layout shape cannot produce server-runtime-detected either — which is what the evidence strengths
in #147 were for. The classifier consumes that distinction rather than re-deriving it from folder names.

Generators identified: Vite, CRA, Gatsby, Parcel, the SvelteKit static adapter, Astro without an SSR
adapter, and Next only when it actually exports statically (next export in a script, or
output: 'export' in the config — read textually, because parsing a Next config means executing it).

Every state carries its own caveat

Not just the good news. static-build-detected states it is not deployment attestation: it describes
the source, and a function added at the platform level never appears here. unknown states it must not be
read as "no server side", and names the reason — an unparsed framework produces no endpoints, and
entry-point recognition has no completeness flag (importsComplete covers the import inventory only).

Your wording from the ticket is what the static note says, and it lives in coverage.notes so a JSON
consumer gets it too.

The interesting finding is in the tests

Mutation-testing turned up a hole in my own suite rather than in the code. Treating plain next as a static
generator changed no state, because the server-dependency rule blocks it independently — so that rule
was untested rather than redundant. The evidence list is consumer-visible, and a static-generator signal
sitting inside a state that says otherwise invites exactly the wrong displayed reason, so it is now asserted
directly. Both other rules fail their own tests when mutated.

Verification

17 tests here, full suite 1177 passed, 1 skipped; typecheck and capability contract clean. Additive, so
still version 3 — a v3 reader ignoring the field keeps behaving correctly.

Step 3 is the platform side: display the state with its evidence, and say what it means for shielding.

[coderbuds]

Well-structured server-surface classification added with clear documentation and exhaustive tests.

🎯 Quality: 100% Elite · 📦 Size: Large — consider splitting if possible

🛡️ Standards: no pre-flight fit check ran for this change — wire assess-change-fit into your coding agents to catch size before opening.

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

_{See how your team is trending →}

[patchstackdave]

All four fixed in e48739d. The first two were wrong in the direction that loses protection, which makes
them the more serious kind of wrong.

P1a — config alone is not a runtime. You are right that this is the common case rather than an edge: a
static Netlify site has a netlify.toml and nothing else. server-runtime-detected now needs something
that serves — a recognized endpoint, a worker entry, or a provider function directory holding source.

I renamed the evidence vocabulary rather than adding a check on top of it: runtime-entry /
deployment-config / layout. The old names (config, provider-directory) described where an artifact
was found, which is why a worker entry and a wrangler config sat in the same bucket despite one being a
server and the other a deploy target. Since the classifier keys on this, a taxonomy that answers the wrong
question would have kept inviting the same defect.

Config-only controls added for all three platforms, plus one asserting the config stays visible while the
state is unknown — it is the reason the static claim is refused, and a consumer needs to see it.

P1b — the config is parsed now. Comments never reach the AST, a string literal is one token, and only a
value reachable from the module's export counts, so your third case (dead example code) is covered too.
Wrapper and named-variable forms are followed, since that is how real configs are written. Regression test
covers all three false-positive shapes and both real ones. Parsing is not executing — the config never runs.

P2 — SvelteKit. Fixed, and your diagnosis of the test was the useful part: it installed the adapter with
no kit, so it proved the adapter path worked in a package set nobody ships. The veto is conditional now, and
the test uses the real pair plus adapter-node as the negative.

Vite. Agreed, and taken as you framed it: SSR companions (vike, vite-plugin-ssr, the React Router server
packages) veto the static reading. That list is where future stacks get added — the state's product meaning
is "no request-path protection needed", so it should fail toward unknown.

23 tests here, full suite 1183. Mutation-checked: restoring the any-shape rule, the regex, the unconditional
kit veto, and dropping the companion veto each fail their own assertions and nothing else.

One consequence worth naming for step 3: unknown is now the answer for a static site that merely deploys
to a platform, which is a common shape. The platform copy for unknown therefore needs to be useful rather
than apologetic — closer to "we could not determine this app's server surface" with the evidence listed than
to a blank state.

[patchstackdave]

Both fixed in 04997bb.

Supabase. The check now requires the layout the platform actually deploys — a child directory not
starting with _, holding an index.* file. A loose file directly under functions/ no longer qualifies
either, since that is not a deployable function.

Mutation testing then caught my test data rather than the code, which is worth recording because it is the
second time on this branch. My first _shared case used cors.ts — the index.* requirement rejects that
on its own, so the test passed without ever exercising the underscore rule. The case that makes the rule
load-bearing is _shared/index.ts: an ordinary barrel file, correct by convention, and it satisfies the
per-function entry test on name alone. That case is in now, and removing the underscore skip fails it.

Cycle safety. Visited set of names, so const a = b; const b = a; export default a ends the walk instead
of exhausting the stack. Your framing was the useful part: the catch made it look handled, and the cost of
exception-driven control flow is not just the throw — a RangeError discards any signal found before it. The
new test pins both halves, since a legitimate alias chain still has to resolve.

Full suite 1186. Mutation-checked: accepting any source under functions/, dropping the underscore skip, and
breaking alias following each fail their own assertions and nothing else.

[patchstackdave]

Fixed in c421380. You were right that the guarantee was the wrong one: refusing to report is not refusing
to look, and the previous shape walked an external tree on every scan before discarding the result.
Containment is settled first now, contents only inspected for a directory that passed — which also matches
what the helper's docblock already claimed.

The control took two attempts, and the first was worthless. I filtered recorded reads by the symlink's
TARGET path. The code reads the LINK path (<project>/api) and the kernel resolves it, so the target never
appears in a read call — the assertion would have passed against the unfixed code too. It asserts on the link
path now, and the followOutside half exists to prove the control can observe a read at all: a control that
cannot see the behaviour it forbids is not a control.

Reads are recorded through a delegating node:fs mock. vi.spyOn on an ESM module namespace throws
(Module namespace is not configurable), and the property under test is invisible in the return value —
which is precisely why this defect survived the last review.

Mutation-checked by restoring the original ordering: the new control fails, nothing else does. Full suite
1187.

Step 3 noted, and I'll build unknown the way you describe — "Server surface could not be determined",
the exact evidence listed (netlify.toml, an api/ layout folder, a server dependency), and no
"not protected" implication anywhere near it. Platform-config semantics will be a separate ticket.

One wording consequence I'd flag now: since static-build-detected also carries "this is not deployment
attestation", the static state cannot be phrased as "no protection needed" either. Both non-server states end
up as informational-with-evidence, and only the runtime state supports a definite statement — which I think is
right, but it does mean the screen's value comes from the evidence list rather than from the label.

[patchstackdave]

/review