Install page: add keel's no-warning terminal installer (keel #479)

[eaitbrahim]

What changed upstream

keel merged the terminal installer (CodeGateSoftware/keel#479, commit 10882cf) — scripts/install.sh, "the no-warning path". The site's install page does not mention it. Today the only documented download route is: grab all eight wheels from the release page by hand, then pip install --find-links ..

Why this is announceable today (FR-9 check)

Verified 2026-08-25:

• curl -sI https://raw.githubusercontent.com/CodeGateSoftware/keel/main/scripts/install.sh → 200. The script is served from main and resolves right now.
• It installs from the latest GitHub release's wheels, and v0.11.2 carries all five production wheels plus config.yaml. So the path works end to end today.
• keel update is registered in v0.11.2's CLI (keel/cli.py:198,1414), so the "keeping it current" half is also true of the released engine.

What must NOT be claimed

• It is not a released artifact. The script lives on main; it has never been part of a tagged release. Say it works today, not that it shipped in v0.11.2.
• macOS and Linux only. The script refuses anything outside Darwin|Linux. Windows stays on the wheels path.
• No published wheel checksums exist. The script computes and prints each wheel's sha256 locally as an audit trail; it does not verify against anything GitHub published. The script says so itself — the page must not upgrade that into "verified".
• No desktop bundles. No .dmg, .exe, .zip or SHA256SUMS* exists on any release. Tracked separately.

Scope

• src/i18n/pages/install.ts — new copy block, all three locales; bump rev and both translatedFromRev.
• src/components/pages/InstallPage.astro — render the new section.
• Requires Python 3.11+ and a terminal; per-user venv at ~/.keel/.venv; never touches an existing config.yaml or database.
• Offer the audit-first variant (download, read, then run) alongside the pipe — this site's readers hand the program exchange API keys, so "pipe a script from the internet into bash" needs the read-it-first option beside it.
• A short "keeping it current" note: keel update / keel update --check for venv installs.

Acceptance

• npm run check clean; astro build green.
• EN/AR/FR at parity, rev bumped and translatedFromRev matching so no stale banner renders.
• Every claim traceable to scripts/install.sh or the v0.11.2 release.

[eaitbrahim]

Review found two factual errors — both corrected in #88

1. The landed config.yaml is NOT the paper profile (blocker)

The original copy said "The config.yaml it lands is the paper profile. Nothing in it can place a live order." Verified false by downloading the actual release asset:

# keel PRODUCTION configuration -- the `config.yaml` attached to a GitHub Release.
# Shipped in `auto_trade.mode: confirm`: keel previews every order and waits for your
# explicit approval before placing it. It is ready for live use...
auto_trade:
  mode: confirm

Per keel/cli.py at v0.11.2: paper simulates, confirm is live. So it is the live profile behind a per-order approval gate.

This originates upstream. scripts/install.sh says "the paper profile" itself, at the config-copy step and again in its next-steps output. The site had mirrored it faithfully. Reported separately for the keel repo.

2. The Python floor is 3.14, not 3.11 (blocker)

This one is instructive. The issue body above says "Requires Python 3.11+" — true of my local clone, which turned out to be 12 commits stale. The live script enforces 3.14:

say "step 2/7: finding Python >= 3.14"
for candidate in python3 python3.14; do
  if "$candidate" -c 'import sys; sys.exit(0 if sys.version_info >= (3, 14) else 1)'

Raised in keel 2d3934f, which is on main but not in the v0.11.2 tag. A reader on 3.12 would have followed this page and hit a hard failure.

Subtlety now stated on the page: the script's floor is stricter than the wheels it installs — v0.11.2 still declares requires-python = ">=3.11". The manual wheels path accepts a Python the script turns away.

3. Two should-fixes

• keel update installs only through uv and errors out when it is absent — but the installer works fine without uv, so a pip-path deployment cannot self-update until uv is added.
• The uv detection sentence was imprecise: detection requires uv --version to actually succeed, and the fallback uses the interpreter the script found, not literally python3.

Process note

The real delta since v0.11.2 is 17 commits, not 7. Because this page pins its one-liner to main, its copy can go stale with nobody touching this repo — which is exactly how the 3.11/3.14 error arose. Any future sync should git fetch keel and read origin/main, never a working tree. Filed the fallout as #89.

[eaitbrahim]

Both defects reported upstream against the keel repo:

• installer: the release config.yaml is confirm-mode production, not "the paper profile" keel#556 — install.sh calls the release's confirm-mode production config "the paper profile" and claims nothing in it can place a live order. This is the claim the site had mirrored faithfully and corrected in feat(install): the one-command terminal path, and how to read it before you run it (#86) #88.
• installer: broken on Linux — the 3.14 floor refuses Pythons the wheels it installs support keel#557 — the installer is broken on Linux: the 3.14 floor refuses Pythons the v0.11.2 wheels it installs actually support (requires-python = ">=3.11").

Both assigned and on the keel project. #557 also flags that keel's README.md still publishes the one-liner with no floor and no platform caveat — so a Linux reader arriving from the README gets a bare failure, while one arriving from this site is told what to install first.