The AtmosphereConf talks your skyline missed
docs(plan): railway deploy review round 1
- Explain as-const rationale (return-type widening vs contextual typing)
- Reorder Task 6: generate domain before setting env vars
- Add note to Task 5 truncated 'Before' snippet about preserved code
- Redact ASSEMBLYAI_API_KEY from plan text
- Fix spec §2: 'one env var' → 'two env vars' (APP_URL + HOSTNAME)
+19
-17
+18
-16
docs/superpowers/plans/2026-04-10-railway-deploy.md
+18
-16
docs/superpowers/plans/2026-04-10-railway-deploy.md
···
195
195
}
196
196
```
197
197
198
-
The `as const` assertions on `application_type` and `token_endpoint_auth_method` are needed because the `@atproto/oauth-client-node` SDK expects literal string types for these fields, not `string`. The other array fields (`redirect_uris`, `grant_types`, `response_types`) must remain mutable (no top-level `as const`) because the SDK's Zod input types expect mutable tuples.
198
+
The `as const` assertions on `application_type` and `token_endpoint_auth_method` are needed because the metadata is now built in a separate function (not inline in the `NodeOAuthClient` constructor). Without contextual typing from the call site, TypeScript widens `"web"` and `"none"` to `string`, which won't match the SDK's union-of-literal types (`"web" | "native"`, `"none" | "client_secret_post" | ...`). The `as const` keeps them as string literals. The other array fields (`redirect_uris`, `grant_types`, `response_types`) must remain mutable (no top-level `as const`) because the SDK's Zod input types expect mutable tuples. If `tsc --noEmit` passes without the `as const` assertions, they can be safely removed — the verification step will tell you.
199
199
200
200
- [ ] **Step 2: Verify tsc is clean**
201
201
···
300
300
dpop_bound_access_tokens: true,
301
301
token_endpoint_auth_method: "none",
302
302
},
303
-
stateStore: { ... },
304
-
sessionStore: { ... },
303
+
stateStore: { ... }, // full Map-backed implementation — preserved in Step 2
304
+
sessionStore: { ... }, // full Map-backed implementation — preserved in Step 2
305
305
});
306
306
}
307
+
308
+
// globalThis.__oauthClient caching pattern also present — preserved in Step 2
307
309
```
308
310
311
+
> **Note:** The snippet above truncates the stateStore, sessionStore, and globalThis caching pattern for brevity. Step 2's "After" code includes the complete implementations of all three. They are preserved unchanged.
312
+
309
313
- [ ] **Step 2: Rewrite `createClient` to use `buildClientMetadata`**
310
314
311
315
Replace the entire file with:
···
383
387
384
388
```
385
389
APP_URL=http://127.0.0.1:3000
386
-
ASSEMBLYAI_API_KEY=aa551c5e26674976a3103e6a4bfa7674
390
+
ASSEMBLYAI_API_KEY=<your-key-here>
387
391
```
388
392
389
393
> **Note:** `.env` is gitignored — this change is local only.
···
497
501
498
502
This creates the `staging` branch (initially identical to `main`) so Railway's staging environment has a branch to track.
499
503
500
-
- [ ] **Step 5: Set environment variables — staging**
504
+
- [ ] **Step 5: Generate a domain for the staging environment**
501
505
502
-
Switch Railway context to staging, then set env vars:
506
+
Use the MCP tool `generate-domain` for the staging environment, or check the Railway dashboard for the auto-generated domain.
507
+
508
+
Note the domain (e.g., `understory-staging-abc123.up.railway.app`) — it's needed for the `APP_URL` env var in the next step.
509
+
510
+
- [ ] **Step 6: Set environment variables — staging**
511
+
512
+
Switch Railway context to staging, then set env vars using the domain from Step 5:
503
513
504
514
Use the MCP tool `set-variables` for the staging environment, or:
505
515
506
516
```bash
507
517
railway link --environment staging
508
-
railway variables set APP_URL=https://<staging-domain>.up.railway.app
518
+
railway variables set APP_URL=https://<staging-domain-from-step-5>.up.railway.app
509
519
railway variables set HOSTNAME=0.0.0.0
510
520
```
511
521
512
-
> **Note:** You'll get the staging domain after the first deploy. Set `APP_URL` to a placeholder initially, deploy, read the generated domain from Railway's dashboard, then update `APP_URL` with the real domain and redeploy.
513
-
514
-
- [ ] **Step 6: Set environment variables — production**
522
+
- [ ] **Step 7: Set environment variables — production**
515
523
516
524
Switch Railway context to production:
517
525
···
520
528
railway variables set APP_URL=https://understory.watch
521
529
railway variables set HOSTNAME=0.0.0.0
522
530
```
523
-
524
-
- [ ] **Step 7: Generate a domain for the staging environment**
525
-
526
-
Use the MCP tool `generate-domain` for the staging environment, or check the Railway dashboard for the auto-generated domain.
527
-
528
-
Note the domain — it will be needed to update `APP_URL` in Step 5.
529
531
530
532
---
531
533
+1
-1
docs/superpowers/specs/2026-04-10-railway-deploy.md
+1
-1
docs/superpowers/specs/2026-04-10-railway-deploy.md