[docs] Delete docs/ + config/docs.ts — prod already serves docs.stx, and dev shows the wrong product

There are two /docs and the two runtimes disagree about which one is real.

• Dev (bun scripts/dev.ts) proxies /docs to the BunPress site unconditionally.
• Prod — buddy serve, the only thing serving the site per DEPLOY.md — has no /docs branch at all, so it resolves resources/views/docs.stx.

So production has already chosen, and it chose the file that is unreachable locally.

Meanwhile the BunPress site is 100% stock Stacks framework documentation: 0 of its 198 markdown files mention analyticshq, config/docs.ts sets the title to "Stacks Documentation", and the sitemap points at stacksjs.com/docs.

Today's cost

Every local check of /docs shows the wrong product, so the page that actually ships is the one nobody ever looks at — inverted QA. It also forces 9 data-no-router anchors that are justified by a dev-only truth.

Recommendation

Delete docs/ and config/docs.ts, and drop the docs proxy from scripts/dev.ts. Dev then matches prod, ~80MB goes away, and the 9 anchors become StxLinks.

The alternative is committing to BunPress, which means rewriting 198 files and adding a /docs branch to buddy serve. Not obviously worth it for a product whose docs are one page today.

Before deleting

Confirm nothing else imports config/docs.ts and that no deploy step builds docs/.

Correcting this issue before acting on it — the plan I wrote in the body is wrong, and following it would have made dev worse rather than better.

I wrote "drop the docs proxy from scripts/dev.ts". The proxy is not in scripts/dev.ts. It is in framework code, @stacksjs/actions/dist/dev/views.js:98:

if (url.pathname === "/docs" || url.pathname.startsWith("/docs/"))
  return proxyToBackend(req, docsBase, "/docs");

Unconditional, and ahead of page routing. scripts/dev.ts only spawns the docs server so that proxy has something to talk to — its own comment says as much.

So deleting docs/ + config/docs.ts and stopping the spawn would leave dev proxying /docs to a dead port. docs.stx still would not be reachable locally; /docs would go from showing the wrong product to showing a connection error. Production is unaffected either way, since buddy serve has no /docs branch and resolves the page route.

The blocker is upstream. Filed as stacksjs/stacks#2213 — the proxy should be gated on a docs site actually existing, and fall through to page routing otherwise.

Two other corrections to the body:

• ~80MB is wrong. docs/ is 1.8M, 198 markdown files. Still worth deleting eventually, but it is not a size argument.
• The claim that 0 of 198 files mention analyticshq is confirmed (grep -rli analyticshq docs/ → 0), as is config/docs.ts pointing at ./docs with nothing else importing it.

Recommend keeping this open and blocked on stacksjs/stacks#2213. Once the proxy is gated, deleting docs/ and config/docs.ts becomes a clean one-commit change that actually delivers what this issue claims: dev and prod resolving /docs the same way. Doing it now would be a deletion in exchange for a different kind of broken.

Shipped in 83ca215 — though checking the premise changed what needed doing.

This issue reported that dev proxies /docs to BunPress unconditionally while prod resolves resources/views/docs.stx. The framework has since made that proxy conditional:

const hasUserDocsView = ['docs.stx', 'docs/index.stx'].some(...)
const docsProxyEnabled = !hasUserDocsView && hasDocsSite

We ship resources/views/docs.stx, so hasUserDocsView is true and the proxy has been off. Measured before touching anything: /docs in dev returned <title>Docs - analyticshq</title> with zero stock-Stacks markers. Dev already matched prod — the split described here was already closed upstream.

So what got deleted was dead weight rather than a fix:

• docs/ + config/docs.ts — 200 tracked markdown files of framework documentation, reachable from nowhere. 1.8 MB, not the ~80 MB estimated here.
• The docs server spawn in scripts/dev.ts, whose own comment called it "not optional" on the strength of the unconditional-proxy claim. It was binding :3006, idling at ~80 MB and receiving nothing. Dev is two servers now.
• The nine data-no-router anchors, now StxLinks. Their written justification ("served by the BunPress proxy, not by stx") is false.

Verified: /docs still answers 200 with the right title after the docs server is gone entirely, and the nav link SPA-navigates while the OAuth anchor on /login still reports reload — so the probe discriminates rather than reporting spa for everything. data-no-router now appears on exactly the four /api/ OAuth redirects, which are 302s and keep it permanently.