chore: remove legacy startup paths

deploy/README.md

@@ -10,37 +10,12 @@ For the planned convergence work, see
 
 ## Contents
 
-- [deploy/systemd/evotraders.service](./systemd/evotraders.service)
-  - systemd unit for the long-running 大时代 gateway process
-- [scripts/run_prod.sh](../scripts/run_prod.sh)
-  - production launch script used by the systemd unit
 - [deploy/nginx/bigtime.cillinn.com.conf](./nginx/bigtime.cillinn.com.conf)
   - HTTPS nginx config with WebSocket proxying
 - [deploy/nginx/bigtime.cillinn.com.http.conf](./nginx/bigtime.cillinn.com.http.conf)
   - plain HTTP/static-site variant
 
-## Deployment Topology Options
-
-This directory documents two deployment topologies:
-
-### 1. Compatibility Topology (backend.main) - CURRENT PRODUCTION DEFAULT
-
-The checked-in production path uses the **compatibility gateway** (`backend.main`):
-
-- nginx serves the built frontend from `/var/www/bigtime/current`
-- public domain examples use `bigtime.cillinn.com`
-- nginx proxies `/ws` to `127.0.0.1:8765`
-- systemd runs `scripts/run_prod.sh`
-- `scripts/run_prod.sh` starts `python3 -m backend.main` in live mode on `127.0.0.1:8765`
-
-This is a **monolithic gateway** that embeds all services internally. It is the
-current production default for simplicity but does not expose the split FastAPI
-services directly.
-
-**When to use**: Single-server deployments, simpler operational requirements,
-backwards compatibility with existing monitoring.
-
-### 2. Preferred Topology (Split Services) - RECOMMENDED FOR NEW DEPLOYMENTS
+## Recommended Topology
 
 The modern architecture exposes individual FastAPI services:
 
@@ -76,27 +51,9 @@ To deploy in split-service mode, you would:
 
 ## systemd
 
-The current systemd unit:
-
-- uses `WorkingDirectory=/root/code/evotraders`
-- executes [scripts/run_prod.sh](../scripts/run_prod.sh)
-- restarts automatically on failure
-
-Enable and start:
-
-```bash
-sudo cp deploy/systemd/evotraders.service /etc/systemd/system/evotraders.service
-sudo systemctl daemon-reload
-sudo systemctl enable evotraders
-sudo systemctl start evotraders
-```
-
-Check status and logs:
-
-```bash
-sudo systemctl status evotraders
-journalctl -u evotraders -f
-```
+No maintained systemd unit is checked into the repository anymore. If deployment
+work resumes, add units that mirror the split-service topology used in local
+development.
 
 ## nginx
 
@@ -124,7 +81,7 @@ The checked-in TLS config expects Let's Encrypt assets at:
 Before using the production scripts, ensure the runtime environment has:
 
 - a usable Python environment
-- backend dependencies installed from `requirements.txt`
+- backend dependencies installed from the checked-in Python package metadata in `pyproject.toml`
 - the package installed with `pip install -e .` or `uv pip install -e .`
 - frontend dependencies installed with `npm ci`
 - repo dependencies installed
@@ -136,30 +93,10 @@ Recommended production install sequence:
 ```bash
 python3 -m venv .venv
 source .venv/bin/activate
-pip install -r requirements.txt
 pip install -e .
 cd frontend && npm ci && npm run build && cd ..
 ```
 
-The production script currently sets:
-
-```bash
-PYTHONPATH=/root/code/evotraders/.pydeps:.
-TICKERS=${TICKERS:-AAPL,MSFT,GOOGL,AMZN,NVDA,META,TSLA,AMD,NFLX,AVGO,PLTR,COIN}
-```
-
-It then launches the current compatibility gateway/runtime process:
-
-```bash
-python3 -m backend.main \
-  --mode live \
-  --config-name production \
-  --host 127.0.0.1 \
-  --port 8765 \
-  --trigger-time now \
-  --poll-interval 15
-```
-
 ## Skill Sandbox Configuration
 
 Production deployments should enable Docker-based skill sandbox for security isolation:
@@ -172,7 +109,7 @@ pip install -e ".[docker-sandbox]"
 docker info
 ```
 
-Environment variables (set by `scripts/run_prod.sh` with defaults):
+Example environment variables for a future deployment:
 
 | Variable | Default | Description |
 |----------|---------|-------------|
@@ -196,6 +133,5 @@ The checked-in deployment artifacts do not currently document or automate:
 - frontend build/publish steps
 - secret management
 
-If you move production fully to split-service mode, update this directory so it
-documents the new service topology explicitly instead of relying on the gateway-
-only path.
+If deployment returns to active development, rewrite this directory around the
+same split-service topology used by `start-dev.sh`.