feat: add Layero deployment rule

[borisowvalia]

Adds a Project Rule for deploying to Layero, plus one line in Hosting and Deployments next to Netlify and Vercel.

Disclosure: I work on Layero.

What the rule covers. Layero is driven from the terminal and its CLI has a JSON-lines mode, so the useful thing to give an agent is not "here is a platform" but the event contract: which events arrive, which fields to read, and which mistakes silently produce a wrong result. Three of them cost real debugging time:

• constructing the deployed hostname from a template instead of reading ready.url — addresses live in a dedicated zone and organizations migrate between naming schemes, so a guessed host is simply wrong;
• npm install -g layero — global installs fail in sandboxed agent terminals;
• omitting --yes in CI — the confirmation prompt waits forever on a runner with no one to answer it.

The rule also states plainly that --prod must not be passed unless the user asked for production, since without it a deploy is an isolated preview.

Format. One .mdc under rules/ with description, globs, alwaysApply: false, per contributing.md. globs targets framework config files rather than sources, so the rule loads for the project rather than on every file edit.

Checks run locally, all passing:

check:readme-hygiene   README hygiene check passed.
check:rule-hygiene     Rule hygiene check passed.
check:awesome-list     Awesome list check passed.
check:repo-security    Repo security check passed.

grep -i layero on the current README returns nothing, so this is not a duplicate.

Summary by CodeRabbit

• Documentation
  • Added a new Layero deployment guide for publishing static sites and SPAs from the terminal.
  • Covers required Layero CLI commands, JSON-lines output handling, and the initial setup flow when project config is missing.
  • Includes recommended CI/token practices and safe “don’t do” constraints to avoid common misconfigurations.
  • Clarifies how deployment events are presented (including links) and redeploy behavior for updating the same project.
  • Updated the README “Hosting and Deployments” section to reference the new guide.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: a96a8001-0e44-4a32-a9ea-431cb95ccd46

📥 Commits

Reviewing files that changed from the base of the PR and between 334b7ff and da3286a.

📒 Files selected for processing (1)

• rules/layero-deployment.mdc

🚧 Files skipped from review as they are similar to previous changes (1)

• rules/layero-deployment.mdc

---

📝 Walkthrough

Walkthrough

Adds a Layero deployment rule covering trigger conditions, CLI execution, JSON event handling, redeploys, CI usage, constraints, and references, and adds the rule to the README’s hosting and deployments list.

Changes

Layero deployment support

Layer / File(s)	Summary
Rule discovery and deployment entry rules/layero-deployment.mdc, README.md	Defines Layero rule metadata, trigger conditions, project initialization, deployment command, and README indexing.
Deployment constraints and event handling rules/layero-deployment.mdc	Specifies prohibited workflows and handling for authentication, detection, build logs, readiness, and errors.
Redeploy, CI, and reference guidance rules/layero-deployment.mdc	Documents redeployment, token-based CI execution, confirmation behavior, project selection, and Layero references.

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

Sequence Diagram(s)

sequenceDiagram
  participant Agent
  participant LayeroCLI
  participant Project
  Agent->>Project: Check .layero/project.json
  Agent->>LayeroCLI: Run npx layero init when config is missing
  Agent->>LayeroCLI: Run npx layero@latest deploy --json
  LayeroCLI-->>Agent: Emit JSON-lines deployment events
  Agent-->>Project: Report authentication, errors, or ready.url

Loading

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately names the main change: adding a Layero deployment rule.
Description check	✅ Passed	The description covers the summary, rule scope, file format, and local checks, with only minor template-structure gaps.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
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.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

rules/layero-deployment.mdc (1)

79-80: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Make the CI example explicitly use JSON-lines output.

The rule defines --json as the event contract, but the CI example omits it. Add --json (or LAYERO_JSON=1) so CI behavior remains deterministic even when a runner allocates a pseudo-TTY. (docs.layero.ru)

Proposed fix

-LAYERO_TOKEN=... npx layero@latest deploy --prod --yes
+LAYERO_TOKEN=... npx layero@latest deploy --prod --yes --json

🤖 Prompt for 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.

In `@rules/layero-deployment.mdc` around lines 79 - 80, Update the CI deployment
command example near the LAYERO_TOKEN invocation to explicitly enable JSON-lines
output by adding the --json flag, preserving the existing production and
noninteractive options.

Source: MCP tools

🤖 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 `@rules/layero-deployment.mdc`:
- Around line 40-41: Update the Layero deployment guidance to accurately
distinguish isolated previews from deployments that update the default live
branch. Remove the claim that omitting --prod is always isolated, and remove any
recommendation to use the unsupported --branch flag; document the supported
command/options for explicitly targeting previews versus production.

---

Nitpick comments:
In `@rules/layero-deployment.mdc`:
- Around line 79-80: Update the CI deployment command example near the
LAYERO_TOKEN invocation to explicitly enable JSON-lines output by adding the
--json flag, preserving the existing production and noninteractive options.

🪄 Autofix (Beta)

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 73489533-b658-4b7e-b55b-f940b5b8782b

📥 Commits

Reviewing files that changed from the base of the PR and between b044f95 and d084d41.

📒 Files selected for processing (2)

• README.md
• rules/layero-deployment.mdc

[coderabbitai]

Actionable comments posted: 2

🤖 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 `@rules/layero-deployment.mdc`:
- Line 42: Update the deployment guidance around the deploy command to reference
the CLI-provided ready.url value instead of constructing or hard-coding a
hostname. Remove the `.layero.app` claim and align the documented visitor URL
with the URL returned by Layero, preserving the existing instruction to rely on
ready.url.
- Line 87: Update the Layero deployment command to include the --json flag,
preserving the existing token, project, and approval options so CI emits
parseable JSON-lines ready/error events.

🪄 Autofix (Beta)

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 54687c20-3c62-4cdd-9e3c-639427038106

📥 Commits

Reviewing files that changed from the base of the PR and between d084d41 and 359f9ad.

📒 Files selected for processing (1)

• rules/layero-deployment.mdc

[borisowvalia]

Thanks for the review — both points were correct, and both are now fixed in 359f9ad.

I checked them against the live platform rather than against our own docs, and the docs turned out to be wrong too. That has been corrected on our side as well.

1. Omitting --prod is not an isolated preview. For a project created from the CLI, direct uploads auto-promote: every deploy replaces what visitors see at the project's live address. --prod only means something for projects with a connected git repository, where it targets the production environment. The rule said the opposite, which is the worst possible direction for an agent-facing instruction — it invites an agent to "safely" overwrite someone's live site.

2. --branch is not usable. It is accepted by the CLI and silently ignored for direct uploads: the backend files every archive deploy under a reserved cli environment. I reproduced this on a live project — passing --branch=probe created no probe environment and did change the live site. Isolated previews come from pushing to a branch of a connected repository, and the rule now says that instead of pointing at the flag.

Two more corrections while I was in the file:

• the CI example used --prod; it now uses --project. A repeatable pipeline needs --project, because --name only labels a project at creation — without a link, each run creates a new project.
• the reference links pointed at the Russian docs from an English rule; switched to the /en/ pages.

Happy to adjust further if anything still reads wrong.

[borisowvalia]

Pushed one more correction to this branch (da3286a), and it is worth flagging because it was my own mistake, not a review point.

The rule listed error codes copied from our own documentation: not_logged_in, project_unlinked, deploy_timed_out and others. I went to verify them against the CLI source today and seven of them are not emitted anywhere. They were real in an earlier version of the CLI — I found them in old worktrees — and our docs never followed when they were removed. Two of them cannot occur by construction: the failure code is assembled as deploy_${status}, and a deploy only has ready, building, failed and cancelled, so deploy_error and deploy_timed_out are impossible.

An agent that implemented handling from the old list would have matched nothing, while missing about fourteen codes that do occur — including project_unknown and prebuilt_no_dir, which a first run hits easily.

The rule now lists the codes the CLI actually emits and states the deploy_<status> rule, so the list cannot silently drift again. The same correction went into our docs, llms.txt, the AGENTS.md block the CLI writes into user repos, and the published npm README.