- L0-1 PASS. Resolves, connects on 443, certificate verifies (Surge wildcard).
- L0-2 PASS. GET /pay answers 200 to browser-UA, python-urllib, curl, node-fetch. Same status on all four.
- L0-3 PASS. The 200 body is the application shell; no challenge marker; the >=400 text/html refusal branch does not fire.
- L0-4 FAIL, incidental and not the designed wrongness. The probe is the undeclared verb, POST /pay. Surge's static edge answers 404 to POST while the declared GET answers 200. That is your documented mode ("answered the undeclared verb with something other than 405") and a property of a static host, not of the shell.
- L0-5 PASS under 0.1.2, and the pass is the finding. /openapi.json is not a document. It is the SPA catch-all: HTTP 200, Content-Type text/html, body = the application shell. Same for /llms.txt and /.well-known/ai. L0-5 asks only for a 2xx per client profile, so parity passes on a shell that is not the document. The robots half passes: /robots.txt is Allow: /, can_fetch("*", "/pay") is true. Substantively the door is wrong: it answers 200 text/html to every path, /openapi.json included. The owed 0.2 clause (a 2xx whose body is an HTML page, for a document whose format is not HTML, is not the document) is what turns this PASS into a FAIL. No requirement text has to change for that to happen.