chore: decommission dev environment from contributor docs

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,8 +12,7 @@
 
 ## Target Branch
 
-- [ ] `dev` - New feature or non-urgent fix
-- [ ] `staging` - Ready for QA validation
+- [ ] `staging` - New feature or non-urgent fix (deploys to staging for QA)
 - [ ] `main` - Hotfix for production issue
 
 ## Changes Made

CONTRIBUTING.md

@@ -4,13 +4,12 @@ Thank you for contributing to the ZK Email Registry!
 
 ## Branch Strategy
 
-This project uses three environment branches:
+This project uses two environment branches:
 
 | Branch    | Purpose                          | Deploys to       |
 |-----------|----------------------------------|------------------|
 | `main`    | Production-ready code            | Production       |
-| `staging` | QA and validation                | Staging          |
-| `dev`     | Active development               | Development      |
+| `staging` | Active development and QA        | Staging          |
 
 ## Workflow
 
@@ -19,38 +18,32 @@ This project uses three environment branches:
 Features flow upward through environments:
 
 ```
-dev ← feature branch
-  ↓ merge (when feature complete)
-staging (QA/validation)
-  ↓ merge (when approved)
+staging ← feature branch
+  ↓ merge (after QA validation)
 main (production)
 ```
 
-1. Create a feature branch from `dev`
+1. Create a feature branch from `staging`
 2. Develop and test locally
-3. Open a PR to `dev`
-4. Once merged, changes deploy to the development environment
-5. When ready for QA, merge `dev` into `staging`
-6. After validation, merge `staging` into `main` for production release
+3. Open a PR to `staging`
+4. Once merged, changes deploy to staging for QA
+5. After validation, merge `staging` into `main` for production release
 
 ### Bug Fixes (Hotfixes)
 
-Production bugs are fixed in `main` first, then propagated downward:
+Production bugs are fixed in `main` first, then propagated back to `staging`:
 
 ```
 main ← hotfix branch
-  ↓ merge/cherry-pick
+  ↓ merge (to keep staging in sync)
 staging
-  ↓ merge/cherry-pick
-dev
 ```
 
 1. Create a hotfix branch from `main`
 2. Fix the bug and open a PR to `main`
-3. Once merged and deployed, cherry-pick or merge the fix into `staging`
-4. Cherry-pick or merge the fix into `dev`
+3. Once merged and deployed, merge `main` into `staging` so the two stay in sync
 
-This ensures production issues are resolved quickly while keeping all environments in sync.
+This ensures production issues are resolved quickly while keeping environments aligned.
 
 ## Key Guidelines
 
@@ -60,20 +53,20 @@ This ensures production issues are resolved quickly while keeping all environmen
 - Write clear, descriptive commit messages
 - Keep PRs focused and reasonably sized
 - Test your changes locally before opening a PR
-- Merge `main` back into `dev` periodically to prevent drift
+- Merge `main` back into `staging` after a hotfix to prevent drift
 
 ### Don't
 
-- Rebase shared branches (`main`, `staging`, `dev`) - use merges instead
+- Rebase shared branches (`main`, `staging`) - use merges instead
 - Push directly to environment branches without a PR
-- Leave environments out of sync after hotfixes
+- Leave `staging` out of sync with `main` after hotfixes
 
 ## Getting Started
 
 1. Clone the repository
 2. Install dependencies: `bun install`
 3. Start the development server: `bun run dev`
-4. Create a feature branch: `git checkout -b feature/your-feature dev`
+4. Create a feature branch: `git checkout -b feature/your-feature staging`
 
 ## Questions?