feat: migrate secrets to Infisical

README.md

@@ -17,8 +17,8 @@ Create or update the local database:
 npm run db:migrate
 ```
 
-The default file is `data/shd-build.db`. Copy `.env.example` to `.env` and set a
-different location if needed.
+The Infisical `dev` environment sets the local file to
+`./data/shd-build-development.db`.
 
 Store custom avatars as metadata-free 256 × 256 WebP files. Set
 `TDR_AVATAR_STORAGE_PATH` to a persistent, writable directory in production; it
@@ -30,9 +30,10 @@ Seed the initial local accounts once:
 npm run db:seed-users
 ```
 
-The seed creates administrator `Aewyn` and standard user `Quartermaster`. It
+The seed creates `Aewyn` and `Quartermaster` with the standard user role. It
 generates and displays strong temporary passwords once, then stores only salted
-Argon2id hashes.
+Argon2id hashes. The separate bootstrap policy promotes the first authenticated
+account when no administrator exists.
 
 ## Develop
 
@@ -40,30 +41,28 @@ Argon2id hashes.
 npm run dev
 ```
 
-## Encrypted environment files
+## Infisical secrets
 
-Keep development, staging, and production settings in the committed, encrypted
-`.env.development`, `.env.staging`, and `.env.production` files. Keep private
-decryption keys only in the ignored `.env.keys` file and back it up in a
-password manager.
+The committed `.infisical.json` connects the project to the self-hosted
+Infisical instance at `https://secrets.jb.codes`. Authenticate the local CLI
+once. The CLI uses its configured system vault and can fall back to an encrypted
+file vault when the operating-system keyring is unavailable.
 
 ```sh
-npm run env:decrypt              # decrypt all environment files for editing
-npm run env:encrypt              # encrypt all environment files again
-npm run env:stage                # encrypt and git-add all environment files
-npm run env:decrypt:development  # operate on one environment
-npm run env:decrypt:staging
-npm run env:decrypt:production
-npm run env:sync:staging-credentials # copy shared Discord/SMTP values from development
+npx infisical login --domain=https://secrets.jb.codes
+npm run dev
 ```
 
-The repository pre-commit hook runs `env:stage` and replaces staged plaintext
-environment files with encrypted versions. Git has no pre-add hook. Use
-`npm run env:stage` instead of directly adding these two files.
+Local commands use the `dev` environment. Application configuration lives under
+`/app`; the scheduler bearer token lives under `/shared/scheduler`. Staging and
+production commands select the `staging` and `prod` environments explicitly.
+`npm run check`, `npm test`, and `npm run build` do not contact Infisical.
 
-Keep `.env.keys` out of Git and retain a backup. Production deployments receive
-`DOTENV_PRIVATE_KEY_PRODUCTION` through their secret manager; do not copy the
-keys file to the server.
+Staging and production containers authenticate at startup with separate
+Universal Auth identities. Gitea stores each client secret, while repository
+variables hold the matching non-secret client IDs. The containers fetch current
+values before migration or startup and stop if authentication or validation
+fails.
 
 ## Containers and staging deployment
 
@@ -72,23 +71,25 @@ The application uses the official SvelteKit Node adapter and a multi-stage
 game-data icons under `/app/data` on a persistent volume. Inject runtime secrets
 when the container starts; keep them out of the image.
 
-[docs/DEPLOYMENT.md](docs/DEPLOYMENT.md) documents the staging Compose topology
-and Gitea Actions deployment. A push to `main` validates the application, builds
-the candidate image while staging stays online, stops the application and
-scheduler for the database backup and migration, then starts the release.
+[docs/DEPLOYMENT.md](docs/DEPLOYMENT.md) documents the staging and production
+Compose topologies. A push to `main` triggers both deployment workflows. Each
+workflow validates Infisical access and the candidate image while the current
+service stays online, then stops its application and scheduler for backup and
+migration.
 
 ## Passwordless authentication
 
 Use passkeys as the preferred sign-in method. Set `APP_ORIGIN` to the exact
 public origin for registration and authentication. Set `PASSKEY_RP_ID` to that
 hostname or a registrable parent domain. Hosted environments use `shd.build`,
-which permits credentials on `shd.build` and `dev.shd.build`. Use `localhost`
-for direct local development.
+which permits credentials on `shd.build`, `stage.shd.build`, and
+`dev.shd.build`. Use `localhost` for direct local development.
 
-Magic links require `SMTP_HOST`, `SMTP_PORT`, `SMTP_SECURE`, `SMTP_USER`,
-`SMTP_PASSWORD`, and `SMTP_FROM`. Use `SMTP_SECURE=true` on port 465. Use
-`false` on port 587 and upgrade with STARTTLS. An account owner activates an
-email identity by following a 15-minute, single-use verification link.
+Magic links require `SMTP_HOST` and `SMTP_FROM`. `SMTP_PORT` defaults to `587`.
+Set `SMTP_SECURE=true` for implicit TLS, normally on port 465; the default
+`false` uses STARTTLS. If the SMTP server requires authentication, set both
+`SMTP_USER` and `SMTP_PASSWORD`. An account owner activates an email identity by
+following a 15-minute, single-use verification link.
 
 ## Validate
 
@@ -97,47 +98,6 @@ npm run check
 npm run build
 ```
 
-[`sv`](https://github.com/sveltejs/cli) creates and configures Svelte projects.
-
-## Creating a project
-
-```sh
-# create a new project
-npx sv create my-app
-```
-
-To recreate this project with the same configuration:
-
-```sh
-# recreate this project
-npx sv@0.16.5 create --template minimal --types ts --install npm .
-```
-
-## Developing
-
-Install dependencies with `npm install` (or `pnpm install` or `yarn`), then
-start a development server:
-
-```sh
-npm run dev
-
-# or start the server and open the app in a new browser tab
-npm run dev -- --open
-```
-
-## Building
-
-Build a production version:
-
-```sh
-npm run build
-```
-
-Preview the production build with `npm run preview`.
-
-> Deployments may require an [adapter](https://svelte.dev/docs/kit/adapters) for
-> the target environment.
-
 The shared visual language and dashboard conventions are documented in
 [docs/DESIGN_SYSTEM.md](docs/DESIGN_SYSTEM.md).