# Deployment Targets

## Scenario: Wulanchabu Server Deployment

### 1. Scope / Trigger

- Trigger: the user asks to deploy this project.
- Default target: Wulanchabu server, reached through SSH host alias `wlcb1`.
- This preference is project-specific and should be used for future deployment requests unless the user explicitly names another target.

### 2. Signatures

- SSH entrypoint: `ssh wlcb1`
- Repository remote: push code to `origin` before deploying.
- Database migration command: `pnpm db:migrate`
- Production build command: `pnpm build`

### 3. Contracts

- Required environment on the server:
  - `DATABASE_URL` must point to the production PostgreSQL database.
  - Node.js and pnpm must be available.
- Deployment should run from the server-side checkout for this repository.
- Code should be pushed to `origin` before server deployment so `wlcb1` deploys committed source.

### 4. Validation & Error Matrix

- Missing `DATABASE_URL` -> deployment is not healthy; setup/login APIs return database configuration failures.
- Migration failure -> stop deployment and report the failing migration output.
- Build failure -> stop deployment and report the failing command output.
- SSH failure -> report that `wlcb1` could not be reached.

### 5. Good/Base/Bad Cases

- Good: commit locally, push to `origin`, SSH to `wlcb1`, update checkout, install deps, migrate DB, build, restart app.
- Base: if the server has a project-specific deploy script, run that script after pushing.
- Bad: deploy uncommitted local files, deploy to a different host by default, or skip migrations after schema changes.

### 6. Tests Required

- `pnpm lint`
- `pnpm type-check`
- `pnpm build`
- After deploy, verify the app responds and `/api/auth/bootstrap` returns a structured JSON response.

### 7. Wrong vs Correct

#### Wrong

```bash
ssh some-other-host
```

#### Correct

```bash
ssh wlcb1
```