fix(proxy): answer 404 for a veryfront domain that names no project

[kojiwakayama]

Found while verifying the v0.1.1214 rollout.

development.veryfront.com -> 404 {"error":"No project configured for domain: development.veryfront.com"}
staging.veryfront.com     -> 502 {"error":"Missing project context","detail":"x-project-slug header is required in proxy mode"}
preview.veryfront.com     -> 502 {"error":"Missing project context","detail":"x-project-slug header is required in proxy mode"}

Same condition, three hosts, two answers.

Why they differ. parseProjectDomain has an explicit environment-root branch for ^(preview|staging|production)\.veryfront\.(com|org)$ (src/server/utils/domain-parser.ts:168) that returns slug null with isVeryfrontDomain: true. development is not in that list, so it falls through to the custom-domain case and gets the correct 404. Its two siblings hit handler.ts:817, which returned a forwarding context; injectContextHeaders then sends x-project-slug: "" and the runtime answers 502.

Why 404 is right for hosted domains. Nothing downstream can supply the missing slug, so each request spent a round trip to the renderer only to report a configuration gap as an upstream failure — and 502 reads as "the backend is broken", which is what made me stop and investigate mid-rollout. A custom domain in the same state has always answered 404.

Scope — corrected. My first version returned 404 for every project-less veryfront domain, including lvh.me, veryfront.me, veryfront.dev and the local environment roots. That was wrong, and the claim in the original description that those were intended scope was wrong too. ProjectsHandler is enabled for exactly isVeryfrontDomain && !projectSlug (src/server/handlers/dev/projects/index.ts:44-58) and serves the project chooser at / and /_projects, so locally that state is meaningful, not broken. The forwarding path was not dead code. Thanks to @chatgpt-codex-connector for catching it.

The 404 now applies only to hosted domains, via a new isHostedVeryfrontDomain that names the distinction: locally a project-less host means "no project chosen yet"; hosted it means the domain names no project at all. isLocalDevHost would have been the wrong predicate — it returns false for staging.lvh.me, which would have left that chooser broken.

Tests. Hosted roots (staging/preview/production.veryfront.com, staging.veryfront.org) assert 404; the local hosts assert they keep forwarding with no error context. I confirmed the hosted test fails against main before trusting it.

Not a regression from v0.1.1214 — this predates it; 1214 touched CSP, nanoid and skills, not host routing.

Summary by CodeRabbit

• Bug Fixes
  • Requests to hosted Veryfront environment domains without a configured project now return a clear 404 error.
  • Prevented these requests from being forwarded incorrectly and producing misleading project-related errors across staging, preview, production, and .org domains.
  • Project-less local development hosts remain reachable and continue working as expected.
  • Added regression coverage for hosted environment domains and local development behavior.

[coderabbitai]

📝 Walkthrough

Walkthrough

The proxy now returns a host-specific 404 for hosted Veryfront environment-root domains without a project slug. Local project-less hosts continue forwarding with contentSourceId: "no-project". Tests cover hosted and local hosts.

Changes

Proxy domain routing

Layer / File(s)	Summary
Hosted domain detection src/server/utils/domain-parser.ts	isHostedVeryfrontDomain identifies hosted veryfront.com and veryfront.org domains, including subdomains and optional ports.
Project-less domain error handling src/proxy/handler.ts, src/proxy/handler.test.ts	The proxy returns a 404 for project-less hosted domains and preserves local project-less forwarding. Tests cover staging, preview, production, .org, and local hosts.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• veryfront/veryfront-code#3332: Both changes handle local project-less development contexts and use isLocalProject.

Suggested reviewers: kwakayama

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: returning 404 for hosted Veryfront domains without a project.

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/proxy-env-root-404

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/proxy/handler.test.ts`:
- Around line 1626-1634: Add the production root and bare lvh.me, veryfront.me,
and veryfront.dev host forms to the host iteration in the project-less Veryfront
test, while preserving the existing request and 404 assertions for each host.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: c8d0e71d-6d99-4228-a98a-078af3f1b068

📥 Commits

Reviewing files that changed from the base of the PR and between 4af1bb9 and 3cdb270.

📒 Files selected for processing (2)

• src/proxy/handler.test.ts
• src/proxy/handler.ts

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3cdb270868

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".