2 fetch paths
a Worker's self-checks need both, not one
1 flag
dsaEncoding: 'ieee-p1363' fixes the whole signing bug
8
tool schemas kept in sync from one source of truth
## Part 1: a Worker can't reliably fetch its own zone
The `/status` page needed to check whether the site itself was actually up. The obvious approach — `fetch('https://tunovix.com/')` from inside the Worker — looked correct and passed locally. In production it produced an intermittent "Site: Down" reading that had nothing to do with whether the site was actually down.
The tell was the timing: a genuine origin timeout takes seconds. This failure came back in about 30 milliseconds — too fast to be the network, which meant it wasn't really trying. A Worker making an outbound `fetch()` to its own public hostname is a known Cloudflare edge case: the request can get rejected as a loop/self-reference before it ever leaves the edge, producing a fast, wrong "down" answer instead of an honest slow one.
The fix was to stop going out to the internet to check something the Worker already had direct access to:
```ts
// Site: checked via the ASSETS binding directly — the mechanism that
// actually serves the homepage on this Workers + assets deploy — not a
// self-referential fetch('https://tunovix.com/').
const res = await assets.fetch(new Request('https://tunovix.com/'))
```
Same logic applies to the MCP health check on that same page: instead of the status endpoint sending an HTTP request back to its own `/mcp` route, it calls the exported `mcpHandler` function directly, in-process, with a real `tools/call` payload. Same result, zero self-fetch. The lesson looked closed.
### The same bug, one layer deeper
It reopened almost immediately on a harder self-check: the site's [AI Discoverability Checker](/tools/ai-discoverability-checker), a tool that live-audits any URL's robots.txt, sitemap, llms.txt, structured data, and agent-discovery files. Pointed at a third-party domain it worked immediately. Pointed at tunovix.com itself, every check failed — robots.txt "not found," llms.txt "not found," the [A2A Agent Card](/.well-known/agent-card.json) and MCP Server Card "not found" — despite all four being demonstrably live when opened directly in a browser.
Routing the self-check through the `ASSETS` binding, the same fix that closed Part 1's first bug, fixed some of those and immediately regressed robots.txt to a clean 404. Not the 30ms transport failure from before — `ASSETS` correctly reporting the file doesn't exist. Because it doesn't: `robots.txt` isn't a file in `.output/public/`. `@nuxtjs/robots` generates it dynamically, per request, as a Nitro server route. The `ASSETS` binding only serves what was actually written to disk at build time; it has no visibility into Nitro's own routing.
The obvious next step — fall back to Nitro's own internal fetch, `$fetch.raw()`, which dispatches to a route inside the same running Worker with no network hop — brought robots.txt back. It also broke llms.txt and both `.well-known/*.json` agent cards, which had been working a moment earlier.
The cause is the mirror image of the first regression. llms.txt and the `.well-known` cards genuinely are plain static files, but on this deploy shape — Cloudflare Workers plus a Static Assets binding, no traditional origin — Cloudflare serves a matching static file straight off `ASSETS` *before the request ever reaches Nitro's own app*. `$fetch.raw()` only ever sees routes Nitro itself registered; a pure static file was never one of them, so from Nitro's perspective the URL doesn't exist either — 404, for the opposite reason `ASSETS` 404'd on robots.txt.