Archive staging-environments change; update local-dev spec

Staging environments are live and fully operational. Marks the remaining
verification tasks complete, syncs the delta spec to main specs, and
archives the change.

Also adds a "When to Use Local vs. Staging" reference table to the
local-dev-environment spec so the boundary between the two environments
is documented in one place.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Ullrich Schäfer 2026-05-17 20:38:07 +02:00
parent 264276d1de
commit 9d4c7d2b41
No known key found for this signature in database
GPG key ID: A32FF691A0F752D9
8 changed files with 70 additions and 3 deletions

View file

@ -2,6 +2,18 @@
One-command local development setup with PostgreSQL, BRouter, automatic schema migration, and segment downloading.
## When to Use Local vs. Staging
| Scenario | Use |
|----------|-----|
| Everyday development, unit tests, E2E tests | Local (`pnpm dev:full`) |
| Sharing a work-in-progress with reviewers | PR preview (`pr-<N>.staging.trails.cool`) |
| Testing against production-like infra (Caddy TLS, Docker networking) | Staging (`staging.trails.cool`) |
| Wahoo OAuth callback testing | Local with `HTTPS=1` (see CLAUDE.md) |
| ActivityPub federation testing | Staging (requires real HTTPS + public domain) |
The Planner, Journal, PostgreSQL, and BRouter all run locally. The local stack is the default for all development work. Staging is not a replacement for local dev — it is a pre-merge verification surface and a way to share work without merging first.
## Requirements
### Requirement: One-command dev startup