docs: point install commands at polylane.com/setup

[boristane]

The README, the agent skill and the install shims now say polylane.com/setup instead of the legacy polylane.com/install alias. Behaviour is unchanged: both URLs serve the same script.

Why: The site, docs and CLI disagreed on the install URL; /setup is canonical and /install stays live only as an alias. Companions: polylanedotcom#585, nominal#4939.

Where to look

1. Shell shim now fetches the hosted installer from /setup. ⚠ The one functional change: it fetches a different (identical) URL.
2. Smoke workflow tests the /setup URL, the one we now publish.
3. README install section and the agent skill print /setup.sh and /setup.ps1.

Feedback wanted: Should install-smoke also keep testing the /install alias, so a regression in the alias is caught?

Risk: Low: /setup and /install serve identical bytes. Roll back by revert.

Verified: npm run lint passes, npm test 563 pass, sh -n install/install.sh ok. npm run typecheck fails on untouched src/commands/feed/* and src/commands/memory/*: codegen builds the client from the live API spec, which lacks those operations yet.

For agents

src/generated/skill.ts is gitignored and regenerates from skill/SKILL.md. Left alone: docs/plans/* (history) and comments naming install.sh as a file, not a URL. The AGENTS.md sentence also fixes a stale path (polylanedotcom's script is src/assets/setup.sh).

🤖 Generated with Claude Code

[polylane]

Warning

Polylane could not verify the production impact of this pull request.

I checked the changed install URLs against production: polylane.com/setup and /install both 301 to their trailing-slash path and serve byte-identical scripts (sha256 8eedd3039f4e19fc…), and /setup.sh and /setup.ps1 return HTTP 200. The pull request swaps one live URL for another.

View the full analysis →

Also considered · 2 refuted

• Refuted · Re-pointing the shim at /setup breaks installs when /setup does not serve the installer · The host already answers /setup: a live curl of /setup and /install returns byte-identical installer scripts (sha256 8eedd3039f4e19fc87b5ec42bfa7ec816b3286d7488c551a1ab52e6bd2137a62 for both), and /setup.sh and /setup.ps1 return HTTP 200.
• Refuted · Dropping the /install alias from install-smoke hides a future alias regression · This is a CI coverage question, not a production degradation on merge: no production resource reads the alias through this repository, and the change neither creates nor worsens any alias defect.

Analysed against 9 cloud accounts and 1 repository

• Cloud accounts: coreplane-prod, baseberry-uat, coreplane-infra, coreplane, coreplane-gtm, 251714435813, Polylane, coreplanelabs, nominal-493716
• Repository: coreplanelabs/cli

Polylane could not find the cloud resources this repository manages, so this review looked at the entire cloud account. Connect this repository to its resources and the next review will focus on exactly what this code deploys to.

_{Polylane analysed c3033e1 for production impact. You can ask follow-ups by mentioning @polylane in a comment.}

Did this help? React 👍 or 👎 so the next review is sharper.

[coreplane-switchboard]

LGTM: no issues found

Reviewed at c3033e1.

For agents

Rationale: The canonical setup URLs are live and serve identical installer bytes; no actionable regressions found.

Full review

No actionable issues found.

[github-actions]

Auto-approved: coreplane-switchboard[bot] reviewed this PR and posted an LGTM verdict (see its review). A repo admin enabled this via the auto-approve workflow.