| 1 | # Runbook |
| 2 | |
| 3 | > Attempt #2's only setup instructions lived in a plan file describing an architecture |
| 4 | > that had already been deleted, so they were actively wrong. Keep this file honest: |
| 5 | > if a command here doesn't work, fix it or delete it. |
| 6 | |
| 7 | ## Status |
| 8 | |
| 9 | Milestone 0 is in progress and the app doesn't boot yet. Everything below marked |
| 10 | **(#2)** is carried from the previous attempt and needs re-verifying against Topcoat |
| 11 | before it can be trusted. |
| 12 | |
| 13 | ## Dev setup |
| 14 | |
| 15 | ```bash |
| 16 | cargo install topcoat-cli |
| 17 | cargo run |
| 18 | ``` |
| 19 | |
| 20 | Topcoat's CLI builds the app, bundles assets, and watches source directories for |
| 21 | rebuilds. How that interacts with the embedded SSH server is unresolved — see |
| 22 | [current.md](current.md#open-questions). |
| 23 | |
| 24 | ## Configuration (#2) |
| 25 | |
| 26 | Env vars, `STEID_` prefixed, loaded with `dotenvy` + `envy`. From attempt #2's |
| 27 | `.env.dev`: |
| 28 | |
| 29 | ``` |
| 30 | STEID_REGISTRATION=personal # personal | invite | open |
| 31 | STEID_OWNER_EMAIL=admin@localhost.dev |
| 32 | STEID_OWNER_PASSWORD=changeme |
| 33 | STEID_OWNER_USERNAME=admin |
| 34 | STEID_DATABASE_URL=sqlite:steid.db?mode=rwc |
| 35 | STEID_LISTEN_ADDR=127.0.0.1:3000 |
| 36 | STEID_DATA_DIR=./data # bare repos live here |
| 37 | ``` |
| 38 | |
| 39 | In `personal` mode the owner account is bootstrapped from `STEID_OWNER_*` on first |
| 40 | boot. Keep `.env.prod` out of git. |
| 41 | |
| 42 | ## Repo layout on disk (#2) |
| 43 | |
| 44 | Bare repos at `{STEID_DATA_DIR}/{org}/{repo}.git`. Created empty — no initial commit. |
| 45 | |
| 46 | ## SSH (#2) |
| 47 | |
| 48 | The SSH server is embedded (russh), not OpenSSH — there is no `authorized_keys` |
| 49 | configuration and no forced command. Users register public keys through the web UI at |
| 50 | `/{owner}/keys`, and the server matches incoming keys by SHA256 fingerprint. |
| 51 | |
| 52 | Host key generation and persistence was never written down. Sort it out during |
| 53 | Milestone 3 and document it here — a host key regenerated on each boot means every |
| 54 | client gets a changed-host-key warning. |
| 55 | |
| 56 | ```bash |
| 57 | git clone git@host:owner/repo |
| 58 | ``` |
| 59 | |
| 60 | ## Manual verification checklist (#2) |
| 61 | |
| 62 | Attempt #2 verified these by hand each milestone but never wrote down the steps. They |
| 63 | are the smoke test for Milestones 2–4: |
| 64 | |
| 65 | - [ ] Create a repo via the web UI → bare repo appears at |
| 66 | `{data_dir}/{org}/{repo}.git` |
| 67 | - [ ] `git clone` an empty repo → succeeds |
| 68 | - [ ] `git clone` a repo with history → succeeds |
| 69 | - [ ] `git clone` a non-existent repo → clean error, not a hang or panic |
| 70 | - [ ] First push to an empty repo → succeeds |
| 71 | - [ ] Push to a repo with history → succeeds |
| 72 | - [ ] Clone with an unregistered key → `Permission denied`, exit 128 |
| 73 | - [ ] Register key via `/{owner}/keys` → clone and push both succeed |
| 74 | - [ ] Revoke key via web UI → subsequent clone rejected at auth |
| 75 | - [ ] Clone a private repo as a non-member → rejected |
| 76 | - [ ] Push as a non-owner member → rejected |
| 77 | |
| 78 | Worth automating as an integration test rather than re-running by hand a fourth time. |
| 79 | |
| 80 | ## Suggested `.gitignore` additions |
| 81 | |
| 82 | Not applied yet — no code to ignore. When the app lands: |
| 83 | |
| 84 | ``` |
| 85 | /data |
| 86 | *.db |
| 87 | *.db-shm |
| 88 | *.db-wal |
| 89 | .env.prod |
| 90 | ``` |
| 91 | |
| 92 | **Do not add `/plans`.** Attempt #2 did, and that is why these docs had to be |
| 93 | hand-carried between repos. |