@symerian/symi 3.0.20 → 3.0.22

package/docs/install/migrating.md

@@ -1,192 +0,0 @@
----
-summary: "Move (migrate) a Symi install from one machine to another"
-read_when:
-  - You are moving Symi to a new laptop/server
-  - You want to preserve sessions, auth, and channel logins (WhatsApp, etc.)
-title: "Migration Guide"
----
-
-# Migrating Symi to a new machine
-
-This guide migrates a Symi Gateway from one machine to another **without redoing onboarding**.
-
-The migration is simple conceptually:
-
-- Copy the **state directory** (`$SYMI_STATE_DIR`, default: `~/.symi/`) — this includes config, auth, sessions, and channel state.
-- Copy your **workspace** (`~/.symi/workspace/` by default) — this includes your agent files (memory, prompts, etc.).
-
-But there are common footguns around **profiles**, **permissions**, and **partial copies**.
-
-## Before you start (what you are migrating)
-
-### 1) Identify your state directory
-
-Most installs use the default:
-
-- **State dir:** `~/.symi/`
-
-But it may be different if you use:
-
-- `--profile <name>` (often becomes `~/.symi-<profile>/`)
-- `SYMI_STATE_DIR=/some/path`
-
-If you’re not sure, run on the **old** machine:
-
-```bash
-symi status
-```
-
-Look for mentions of `SYMI_STATE_DIR` / profile in the output. If you run multiple gateways, repeat for each profile.
-
-### 2) Identify your workspace
-
-Common defaults:
-
-- `~/.symi/workspace/` (recommended workspace)
-- a custom folder you created
-
-Your workspace is where files like `MEMORY.md`, `USER.md`, and `memory/*.md` live.
-
-### 3) Understand what you will preserve
-
-If you copy **both** the state dir and workspace, you keep:
-
-- Gateway configuration (`symi.json`)
-- Auth profiles / API keys / OAuth tokens
-- Session history + agent state
-- Channel state (e.g. WhatsApp login/session)
-- Your workspace files (memory, skills notes, etc.)
-
-If you copy **only** the workspace (e.g., via Git), you do **not** preserve:
-
-- sessions
-- credentials
-- channel logins
-
-Those live under `$SYMI_STATE_DIR`.
-
-## Migration steps (recommended)
-
-### Step 0 — Make a backup (old machine)
-
-On the **old** machine, stop the gateway first so files aren’t changing mid-copy:
-
-```bash
-symi gateway stop
-```
-
-(Optional but recommended) archive the state dir and workspace:
-
-```bash
-# Adjust paths if you use a profile or custom locations
-cd ~
-tar -czf symi-state.tgz .symi
-
-tar -czf symi-workspace.tgz .symi/workspace
-```
-
-If you have multiple profiles/state dirs (e.g. `~/.symi-main`, `~/.symi-work`), archive each.
-
-### Step 1 — Install Symi on the new machine
-
-On the **new** machine, install the CLI (and Node if needed):
-
-- See: [Install](/install)
-
-At this stage, it’s OK if onboarding creates a fresh `~/.symi/` — you will overwrite it in the next step.
-
-### Step 2 — Copy the state dir + workspace to the new machine
-
-Copy **both**:
-
-- `$SYMI_STATE_DIR` (default `~/.symi/`)
-- your workspace (default `~/.symi/workspace/`)
-
-Common approaches:
-
-- `scp` the tarballs and extract
-- `rsync -a` over SSH
-- external drive
-
-After copying, ensure:
-
-- Hidden directories were included (e.g. `.symi/`)
-- File ownership is correct for the user running the gateway
-
-### Step 3 — Run Doctor (migrations + service repair)
-
-On the **new** machine:
-
-```bash
-symi doctor
-```
-
-Doctor is the “safe boring” command. It repairs services, applies config migrations, and warns about mismatches.
-
-Then:
-
-```bash
-symi gateway restart
-symi status
-```
-
-## Common footguns (and how to avoid them)
-
-### Footgun: profile / state-dir mismatch
-
-If you ran the old gateway with a profile (or `SYMI_STATE_DIR`), and the new gateway uses a different one, you’ll see symptoms like:
-
-- config changes not taking effect
-- channels missing / logged out
-- empty session history
-
-Fix: run the gateway/service using the **same** profile/state dir you migrated, then rerun:
-
-```bash
-symi doctor
-```
-
-### Footgun: copying only `symi.json`
-
-`symi.json` is not enough. Many providers store state under:
-
-- `$SYMI_STATE_DIR/credentials/`
-- `$SYMI_STATE_DIR/agents/<agentId>/...`
-
-Always migrate the entire `$SYMI_STATE_DIR` folder.
-
-### Footgun: permissions / ownership
-
-If you copied as root or changed users, the gateway may fail to read credentials/sessions.
-
-Fix: ensure the state dir + workspace are owned by the user running the gateway.
-
-### Footgun: migrating between remote/local modes
-
-- If your UI (WebUI/TUI) points at a **remote** gateway, the remote host owns the session store + workspace.
-- Migrating your laptop won’t move the remote gateway’s state.
-
-If you’re in remote mode, migrate the **gateway host**.
-
-### Footgun: secrets in backups
-
-`$SYMI_STATE_DIR` contains secrets (API keys, OAuth tokens, WhatsApp creds). Treat backups like production secrets:
-
-- store encrypted
-- avoid sharing over insecure channels
-- rotate keys if you suspect exposure
-
-## Verification checklist
-
-On the new machine, confirm:
-
-- `symi status` shows the gateway running
-- Your channels are still connected (e.g. WhatsApp doesn’t require re-pair)
-- The dashboard opens and shows existing sessions
-- Your workspace files (memory, configs) are present
-
-## Related
-
-- [Doctor](/gateway/doctor)
-- [Gateway troubleshooting](/gateway/troubleshooting)
-- [Where does Symi store its data?](/help/faq#where-does-symi-store-its-data)

package/docs/install/nix.md

@@ -1,98 +0,0 @@
----
-summary: "Install Symi declaratively with Nix"
-read_when:
-  - You want reproducible, rollback-able installs
-  - You're already using Nix/NixOS/Home Manager
-  - You want everything pinned and managed declaratively
-title: "Nix"
----
-
-# Nix Installation
-
-The recommended way to run Symi with Nix is via **[nix-symi](https://github.com/symi/nix-symi)** — a batteries-included Home Manager module.
-
-## Quick Start
-
-Paste this to your AI agent (Claude, Cursor, etc.):
-
-```text
-I want to set up nix-symi on my Mac.
-Repository: github:symi/nix-symi
-
-What I need you to do:
-1. Check if Determinate Nix is installed (if not, install it)
-2. Create a local flake at ~/code/symi-local using templates/agent-first/flake.nix
-3. Help me create a Telegram bot (@BotFather) and get my chat ID (@userinfobot)
-4. Set up secrets (bot token, Anthropic key) - plain files at ~/.secrets/ is fine
-5. Fill in the template placeholders and run home-manager switch
-6. Verify: launchd running, bot responds to messages
-
-Reference the nix-symi README for module options.
-```
-
-> **📦 Full guide: [github.com/symi/nix-symi](https://github.com/symi/nix-symi)**
->
-> The nix-symi repo is the source of truth for Nix installation. This page is just a quick overview.
-
-## What you get
-
-- Gateway + macOS app + tools (whisper, spotify, cameras) — all pinned
-- Launchd service that survives reboots
-- Plugin system with declarative config
-- Instant rollback: `home-manager switch --rollback`
-
----
-
-## Nix Mode Runtime Behavior
-
-When `SYMI_NIX_MODE=1` is set (automatic with nix-symi):
-
-Symi supports a **Nix mode** that makes configuration deterministic and disables auto-install flows.
-Enable it by exporting:
-
-```bash
-SYMI_NIX_MODE=1
-```
-
-On macOS, the GUI app does not automatically inherit shell env vars. You can
-also enable Nix mode via defaults:
-
-```bash
-defaults write bot.molt.mac symi.nixMode -bool true
-```
-
-### Config + state paths
-
-Symi reads JSON5 config from `SYMI_CONFIG_PATH` and stores mutable data in `SYMI_STATE_DIR`.
-When needed, you can also set `SYMI_HOME` to control the base home directory used for internal path resolution.
-
-- `SYMI_HOME` (default precedence: `HOME` / `USERPROFILE` / `os.homedir()`)
-- `SYMI_STATE_DIR` (default: `~/.symi`)
-- `SYMI_CONFIG_PATH` (default: `$SYMI_STATE_DIR/symi.json`)
-
-When running under Nix, set these explicitly to Nix-managed locations so runtime state and config
-stay out of the immutable store.
-
-### Runtime behavior in Nix mode
-
-- Auto-install and self-mutation flows are disabled
-- Missing dependencies surface Nix-specific remediation messages
-- UI surfaces a read-only Nix mode banner when present
-
-## Packaging note (macOS)
-
-The macOS packaging flow expects a stable Info.plist template at:
-
-```
-apps/macos/Sources/Symi/Resources/Info.plist
-```
-
-[`scripts/package-mac-app.sh`](https://github.com/symi/symi/blob/main/scripts/package-mac-app.sh) copies this template into the app bundle and patches dynamic fields
-(bundle ID, version/build, Git SHA, Sparkle keys). This keeps the plist deterministic for SwiftPM
-packaging and Nix builds (which do not rely on a full Xcode toolchain).
-
-## Related
-
-- [nix-symi](https://github.com/symi/nix-symi) — full setup guide
-- [Wizard](/start/wizard) — non-Nix CLI setup
-- [Docker](/install/docker) — containerized setup

package/docs/install/node.md

@@ -1,138 +0,0 @@
----
-title: "Node.js"
-summary: "Install and configure Node.js for Symi — version requirements, install options, and PATH troubleshooting"
-read_when:
-  - "You need to install Node.js before installing Symi"
-  - "You installed Symi but `symi` is command not found"
-  - "npm install -g fails with permissions or PATH issues"
----
-
-# Node.js
-
-Symi requires **Node 22 or newer**. The [installer script](/install#install-methods) will detect and install Node automatically — this page is for when you want to set up Node yourself and make sure everything is wired up correctly (versions, PATH, global installs).
-
-## Check your version
-
-```bash
-node -v
-```
-
-If this prints `v22.x.x` or higher, you're good. If Node isn't installed or the version is too old, pick an install method below.
-
-## Install Node
-
-<Tabs>
-  <Tab title="macOS">
-    **Homebrew** (recommended):
-
-    ```bash
-    brew install node
-    ```
-
-    Or download the macOS installer from [nodejs.org](https://nodejs.org/).
-
-  </Tab>
-  <Tab title="Linux">
-    **Ubuntu / Debian:**
-
-    ```bash
-    curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
-    sudo apt-get install -y nodejs
-    ```
-
-    **Fedora / RHEL:**
-
-    ```bash
-    sudo dnf install nodejs
-    ```
-
-    Or use a version manager (see below).
-
-  </Tab>
-  <Tab title="Windows">
-    **winget** (recommended):
-
-    ```powershell
-    winget install OpenJS.NodeJS.LTS
-    ```
-
-    **Chocolatey:**
-
-    ```powershell
-    choco install nodejs-lts
-    ```
-
-    Or download the Windows installer from [nodejs.org](https://nodejs.org/).
-
-  </Tab>
-</Tabs>
-
-<Accordion title="Using a version manager (nvm, fnm, mise, asdf)">
-  Version managers let you switch between Node versions easily. Popular options:
-
-- [**fnm**](https://github.com/Schniz/fnm) — fast, cross-platform
-- [**nvm**](https://github.com/nvm-sh/nvm) — widely used on macOS/Linux
-- [**mise**](https://mise.jdx.dev/) — polyglot (Node, Python, Ruby, etc.)
-
-Example with fnm:
-
-```bash
-fnm install 22
-fnm use 22
-```
-
-  <Warning>
-  Make sure your version manager is initialized in your shell startup file (`~/.zshrc` or `~/.bashrc`). If it isn't, `symi` may not be found in new terminal sessions because the PATH won't include Node's bin directory.
-  </Warning>
-</Accordion>
-
-## Troubleshooting
-
-### `symi: command not found`
-
-This almost always means npm's global bin directory isn't on your PATH.
-
-<Steps>
-  <Step title="Find your global npm prefix">
-    ```bash
-    npm prefix -g
-    ```
-  </Step>
-  <Step title="Check if it's on your PATH">
-    ```bash
-    echo "$PATH"
-    ```
-
-    Look for `<npm-prefix>/bin` (macOS/Linux) or `<npm-prefix>` (Windows) in the output.
-
-  </Step>
-  <Step title="Add it to your shell startup file">
-    <Tabs>
-      <Tab title="macOS / Linux">
-        Add to `~/.zshrc` or `~/.bashrc`:
-
-        ```bash
-        export PATH="$(npm prefix -g)/bin:$PATH"
-        ```
-
-        Then open a new terminal (or run `rehash` in zsh / `hash -r` in bash).
-      </Tab>
-      <Tab title="Windows">
-        Add the output of `npm prefix -g` to your system PATH via Settings → System → Environment Variables.
-      </Tab>
-    </Tabs>
-
-  </Step>
-</Steps>
-
-### Permission errors on `npm install -g` (Linux)
-
-If you see `EACCES` errors, switch npm's global prefix to a user-writable directory:
-
-```bash
-mkdir -p "$HOME/.npm-global"
-npm config set prefix "$HOME/.npm-global"
-export PATH="$HOME/.npm-global/bin:$PATH"
-```
-
-Add the `export PATH=...` line to your `~/.bashrc` or `~/.zshrc` to make it permanent.

package/docs/install/northflank.mdx

@@ -1,49 +0,0 @@
----
-title: Deploy on Northflank
----
-
-Deploy Symi on Northflank with a one-click template and finish setup in your browser.
-This is the easiest “no terminal on the server” path: Northflank runs the Gateway for you,
-and you configure everything via the `/setup` web wizard.
-
-## How to get started
-
-1. Click [Deploy Symi](https://northflank.com/stacks/deploy-symi) to open the template.
-2. Create an [account on Northflank](https://app.northflank.com/signup) if you don’t already have one.
-3. Click **Deploy Symi now**.
-4. Set the required environment variable: `SETUP_PASSWORD`.
-5. Click **Deploy stack** to build and run the Symi template.
-6. Wait for the deployment to complete, then click **View resources**.
-7. Open the Symi service.
-8. Open the public Symi URL and complete setup at `/setup`.
-9. Open the Control UI at `/symi`.
-
-## What you get
-
-- Hosted Symi Gateway + Control UI
-- Web setup wizard at `/setup` (no terminal commands)
-- Persistent storage via Northflank Volume (`/data`) so config/credentials/workspace survive redeploys
-
-## Setup flow
-
-1. Visit `https://<your-northflank-domain>/setup` and enter your `SETUP_PASSWORD`.
-2. Choose a model/auth provider and paste your key.
-3. Click **Run setup**.
-4. Open the Control UI at `https://<your-northflank-domain>/symi`
-
-If Telegram DMs are set to pairing, the setup wizard can approve the pairing code.
-
-## Getting chat tokens
-
-### Telegram bot token
-
-1. Message `@BotFather` in Telegram
-2. Run `/newbot`
-3. Copy the token (looks like `123456789:AA...`)
-4. Paste it into `/setup`
-
-5. **New Application** → choose a name
-6. **Bot** → **Add Bot**
-7. **Enable MESSAGE CONTENT INTENT** under Bot → Privileged Gateway Intents (required or the bot will crash on startup)
-8. Copy the **Bot Token** and paste into `/setup`
-9. Invite the bot to your server (OAuth2 URL Generator; scopes: `bot`, `applications.commands`)

package/docs/install/podman.md

@@ -1,108 +0,0 @@
----
-summary: "Run Symi in a rootless Podman container"
-read_when:
-  - You want a containerized gateway with Podman instead of Docker
-title: "Podman"
----
-
-# Podman
-
-Run the Symi gateway in a **rootless** Podman container. Uses the same image as Docker (build from the repo [Dockerfile](https://github.com/symi/symi/blob/main/Dockerfile)).
-
-## Requirements
-
-- Podman (rootless)
-- Sudo for one-time setup (create user, build image)
-
-## Quick start
-
-**1. One-time setup** (from repo root; creates user, builds image, installs launch script):
-
-```bash
-./setup-podman.sh
-```
-
-This also creates a minimal `~symi/.symi/symi.json` (sets `gateway.mode="local"`) so the gateway can start without running the wizard.
-
-By default the container is **not** installed as a systemd service, you start it manually (see below). For a production-style setup with auto-start and restarts, install it as a systemd Quadlet user service instead:
-
-```bash
-./setup-podman.sh --quadlet
-```
-
-(Or set `SYMI_PODMAN_QUADLET=1`; use `--container` to install only the container and launch script.)
-
-**2. Start gateway** (manual, for quick smoke testing):
-
-```bash
-./scripts/run-symi-podman.sh launch
-```
-
-**3. Onboarding wizard** (e.g. to add channels or providers):
-
-```bash
-./scripts/run-symi-podman.sh launch setup
-```
-
-Then open `http://127.0.0.1:18789/` and use the token from `~symi/.symi/.env` (or the value printed by setup).
-
-## Systemd (Quadlet, optional)
-
-If you ran `./setup-podman.sh --quadlet` (or `SYMI_PODMAN_QUADLET=1`), a [Podman Quadlet](https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html) unit is installed so the gateway runs as a systemd user service for the symi user. The service is enabled and started at the end of setup.
-
-- **Start:** `sudo systemctl --machine symi@ --user start symi.service`
-- **Stop:** `sudo systemctl --machine symi@ --user stop symi.service`
-- **Status:** `sudo systemctl --machine symi@ --user status symi.service`
-- **Logs:** `sudo journalctl --machine symi@ --user -u symi.service -f`
-
-The quadlet file lives at `~symi/.config/containers/systemd/symi.container`. To change ports or env, edit that file (or the `.env` it sources), then `sudo systemctl --machine symi@ --user daemon-reload` and restart the service. On boot, the service starts automatically if lingering is enabled for symi (setup does this when loginctl is available).
-
-To add quadlet **after** an initial setup that did not use it, re-run: `./setup-podman.sh --quadlet`.
-
-## The symi user (non-login)
-
-`setup-podman.sh` creates a dedicated system user `symi`:
-
-- **Shell:** `nologin` — no interactive login; reduces attack surface.
-- **Home:** e.g. `/home/symi` — holds `~/.symi` (config, workspace) and the launch script `run-symi-podman.sh`.
-- **Rootless Podman:** The user must have a **subuid** and **subgid** range. Many distros assign these automatically when the user is created. If setup prints a warning, add lines to `/etc/subuid` and `/etc/subgid`:
-
-  ```text
-  symi:100000:65536
-  ```
-
-  Then start the gateway as that user (e.g. from cron or systemd):
-
-  ```bash
-  sudo -u symi /home/symi/run-symi-podman.sh
-  sudo -u symi /home/symi/run-symi-podman.sh setup
-  ```
-
-- **Config:** Only `symi` and root can access `/home/symi/.symi`. To edit config: use the Control UI once the gateway is running, or `sudo -u symi $EDITOR /home/symi/.symi/symi.json`.
-
-## Environment and config
-
-- **Token:** Stored in `~symi/.symi/.env` as `SYMI_GATEWAY_TOKEN`. `setup-podman.sh` and `run-symi-podman.sh` generate it if missing (uses `openssl`, `python3`, or `od`).
-- **Optional:** In that `.env` you can set provider keys (e.g. `GROQ_API_KEY`, `OLLAMA_API_KEY`) and other Symi env vars.
-- **Host ports:** By default the script maps `18789` (gateway) and `18790` (bridge). Override the **host** port mapping with `SYMI_PODMAN_GATEWAY_HOST_PORT` and `SYMI_PODMAN_BRIDGE_HOST_PORT` when launching.
-- **Paths:** Host config and workspace default to `~symi/.symi` and `~symi/.symi/workspace`. Override the host paths used by the launch script with `SYMI_CONFIG_DIR` and `SYMI_WORKSPACE_DIR`.
-
-## Useful commands
-
-- **Logs:** With quadlet: `sudo journalctl --machine symi@ --user -u symi.service -f`. With script: `sudo -u symi podman logs -f symi`
-- **Stop:** With quadlet: `sudo systemctl --machine symi@ --user stop symi.service`. With script: `sudo -u symi podman stop symi`
-- **Start again:** With quadlet: `sudo systemctl --machine symi@ --user start symi.service`. With script: re-run the launch script or `podman start symi`
-- **Remove container:** `sudo -u symi podman rm -f symi` — config and workspace on the host are kept
-
-## Troubleshooting
-
-- **Permission denied (EACCES) on config or auth-profiles:** The container defaults to `--userns=keep-id` and runs as the same uid/gid as the host user running the script. Ensure your host `SYMI_CONFIG_DIR` and `SYMI_WORKSPACE_DIR` are owned by that user.
-- **Gateway start blocked (missing `gateway.mode=local`):** Ensure `~symi/.symi/symi.json` exists and sets `gateway.mode="local"`. `setup-podman.sh` creates this file if missing.
-- **Rootless Podman fails for user symi:** Check `/etc/subuid` and `/etc/subgid` contain a line for `symi` (e.g. `symi:100000:65536`). Add it if missing and restart.
-- **Container name in use:** The launch script uses `podman run --replace`, so the existing container is replaced when you start again. To clean up manually: `podman rm -f symi`.
-- **Script not found when running as symi:** Ensure `setup-podman.sh` was run so that `run-symi-podman.sh` is copied to symi’s home (e.g. `/home/symi/run-symi-podman.sh`).
-- **Quadlet service not found or fails to start:** Run `sudo systemctl --machine symi@ --user daemon-reload` after editing the `.container` file. Quadlet requires cgroups v2: `podman info --format '{{.Host.CgroupsVersion}}'` should show `2`.
-
-## Optional: run as your own user
-
-To run the gateway as your normal user (no dedicated symi user): build the image, create `~/.symi/.env` with `SYMI_GATEWAY_TOKEN`, and run the container with `--userns=keep-id` and mounts to your `~/.symi`. The launch script is designed for the symi-user flow; for a single-user setup you can instead run the `podman run` command from the script manually, pointing config and workspace to your home. Recommended for most users: use `setup-podman.sh` and run as the symi user so config and process are isolated.

package/docs/install/railway.mdx

@@ -1,95 +0,0 @@
----
-title: Deploy on Railway
----
-
-Deploy Symi on Railway with a one-click template and finish setup in your browser.
-This is the easiest “no terminal on the server” path: Railway runs the Gateway for you,
-and you configure everything via the `/setup` web wizard.
-
-## Quick checklist (new users)
-
-1. Click **Deploy on Railway** (below).
-2. Add a **Volume** mounted at `/data`.
-3. Set the required **Variables** (at least `SETUP_PASSWORD`).
-4. Enable **HTTP Proxy** on port `8080`.
-5. Open `https://<your-railway-domain>/setup` and finish the wizard.
-
-## One-click deploy
-
-<a href="https://railway.com/deploy/symi-railway-template" target="_blank" rel="noreferrer">
-  Deploy on Railway
-</a>
-
-After deploy, find your public URL in **Railway → your service → Settings → Domains**.
-
-Railway will either:
-
-- give you a generated domain (often `https://<something>.up.railway.app`), or
-- use your custom domain if you attached one.
-
-Then open:
-
-- `https://<your-railway-domain>/setup` — setup wizard (password protected)
-- `https://<your-railway-domain>/symi` — Control UI
-
-## What you get
-
-- Hosted Symi Gateway + Control UI
-- Web setup wizard at `/setup` (no terminal commands)
-- Persistent storage via Railway Volume (`/data`) so config/credentials/workspace survive redeploys
-- Backup export at `/setup/export` to migrate off Railway later
-
-## Required Railway settings
-
-### Public Networking
-
-Enable **HTTP Proxy** for the service.
-
-- Port: `8080`
-
-### Volume (required)
-
-Attach a volume mounted at:
-
-- `/data`
-
-### Variables
-
-Set these variables on the service:
-
-- `SETUP_PASSWORD` (required)
-- `PORT=8080` (required — must match the port in Public Networking)
-- `SYMI_STATE_DIR=/data/.symi` (recommended)
-- `SYMI_WORKSPACE_DIR=/data/workspace` (recommended)
-- `SYMI_GATEWAY_TOKEN` (recommended; treat as an admin secret)
-
-## Setup flow
-
-1. Visit `https://<your-railway-domain>/setup` and enter your `SETUP_PASSWORD`.
-2. Choose a model/auth provider and paste your key.
-3. Click **Run setup**.
-
-If Telegram DMs are set to pairing, the setup wizard can approve the pairing code.
-
-## Getting chat tokens
-
-### Telegram bot token
-
-1. Message `@BotFather` in Telegram
-2. Run `/newbot`
-3. Copy the token (looks like `123456789:AA...`)
-4. Paste it into `/setup`
-
-5. **New Application** → choose a name
-6. **Bot** → **Add Bot**
-7. **Enable MESSAGE CONTENT INTENT** under Bot → Privileged Gateway Intents (required or the bot will crash on startup)
-8. Copy the **Bot Token** and paste into `/setup`
-9. Invite the bot to your server (OAuth2 URL Generator; scopes: `bot`, `applications.commands`)
-
-## Backups & migration
-
-Download a backup at:
-
-- `https://<your-railway-domain>/setup/export`
-
-This exports your Symi state + workspace so you can migrate to another host without losing config or memory.