fix(cli): open the Environments panel instead of a 404 for open --env

[kojiwakayama]

Problem

veryfront open --env <name> reported success: true while handing the user a dead link.

$ veryfront open --env production --json     # published 0.1.1229
{
  "success": true,
  "command": "open",
  "data": { "url": "https://veryfront.com/projects/<slug>/environments/production" }
}

$ curl -s -o /dev/null -w '%{http_code}' https://veryfront.com/projects/<slug>/environments/production
404

The dashboard has no /environments/ route. Studio's page tree only serves
pages/projects/[projectSlug] — there is no nested environments route, so every
--env invocation produced a hard 404 ("This page could not be found").

This is newly reachable ground: before #3576, open could not resolve a project slug from a
local link at all and errored No project found here, so no URL was ever produced. #3576 fixed
the resolution and exposed the broken --env route behind it.

Fix

Environments are a panel on the project page, addressed with ?panels=environments:

https://veryfront.com/projects/<slug>?panels=environments

The env name selects the panel, not a specific row. That is deliberate: the panel's own deep
link seeds a selection by environment id (?environments=edit:<id>, matched in
EnvironmentsPanelContainer with environments.find(env => env.id === selectedEnvironmentId)).
open only has the env name and has no token to resolve it to an id, so emitting
?environments=edit:production would open a detail drawer bound to an id that never matches —
strictly worse than landing on the panel list. Resolving the id would mean an authenticated API
call, which open deliberately does not make.

Also corrects the two places that described the old behaviour (--env help text and the
deploy-project guide sentence).

Verification against the published repro

Re-ran the finding's own command against this build:

URL	before	after
/projects/<slug>/environments/production (0.1.1229)	404	—
/projects/<slug>?panels=environments (this build)	—	302

302 is the signed-out redirect to /sign-in that every real Studio page returns for an
anonymous request — i.e. a route that exists — versus the 404 body the old URL rendered.

$ deno run -A cli/main.ts open --env production --project <slug> --json
{ "success": true, "command": "open",
  "data": { "url": "https://veryfront.com/projects/<slug>?panels=environments" } }

Tests

cli/commands/open/handler.test.ts — both fail on main for the right reason (asserted before
writing the fix):

• builds environment URL that opens the Environments panel — pins the exact corrected URL.
• never builds an /environments/ path segment for any env name — regression guard over
  production / staging / preview, since the dashboard has no /environments/ route at all.

Scope

Deliberately narrow. veryfront open's broader "opens Studio, never the deployed app" behaviour
and the deploy-project Verification step are separate findings owned by other agents; this PR
only stops --env from emitting a 404 and fixes the one clause that its behaviour change
invalidates.

Live docs

No published-docs change is required — veryfront-docs does not carry the
"environment's dashboard page" claim (verified by grep). The only doc edit is the in-repo
docs/getting-started/deploy-project.md.

[coderabbitai]

Warning

Review limit reached

@kojiwakayama, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 39 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f0ee86ef-1fd7-459b-b204-a47bd46cfc67

📥 Commits

Reviewing files that changed from the base of the PR and between 64d6850 and 2db42e8.

📒 Files selected for processing (4)

• cli/commands/open/command-help.ts
• cli/commands/open/command.ts
• cli/commands/open/handler.test.ts
• docs/getting-started/deploy-project.md

---

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