Commit remaining Burrow platform work

evolution/proposals/0000-template.md

@@ -0,0 +1,57 @@
+# `BEP-XXXX` - Title Case Summary
+
+```text
+Status: Draft | In Review | Accepted | Implemented | Rejected | Returned for Revision | Superseded | Archived
+Proposal: BEP-XXXX
+Authors: <name(s) or agent ids>
+Coordinator: <name>
+Reviewers: <people, bots, contributors>
+Constitution Sections: <II, III, IV, etc.>
+Implementation PRs: <link(s)> (optional while drafting)
+Decision Date: <YYYY-MM-DD or Pending>
+```
+
+## Summary
+
+One or two paragraphs that state the desired outcome and why it matters.
+
+## Motivation
+
+- What problem exists today?
+- Why should Burrow solve it now?
+- Which issues, incidents, or constraints support the change?
+
+## Detailed Design
+
+- Architecture and boundaries
+- Data model and migration plan
+- Protocol or API changes
+- Observability, testing, and failure handling
+
+## Security and Operational Considerations
+
+- Access and secret handling
+- Abuse, downgrade, or supply-chain risks
+- Rollback and kill-switch plans
+
+## Contributor Playbook
+
+Give the concrete steps, commands, checks, and evidence a contributor should produce while implementing or rolling out the change.
+
+## Alternatives Considered
+
+List alternatives and why they were rejected.
+
+## Impact on Other Work
+
+- follow-up tasks
+- dependencies
+- compatibility constraints
+
+## Decision
+
+Record the final call, who made it, and any conditions.
+
+## References
+
+Link relevant issues, specs, transcripts, and external research.

evolution/proposals/BEP-0001-sovereign-forge-and-governance.md

@@ -0,0 +1,61 @@
+# `BEP-0001` - Sovereign Forge and Governance Bootstrap
+
+```text
+Status: Draft
+Proposal: BEP-0001
+Authors: gpt-5.4
+Coordinator: gpt-5.4
+Reviewers: Pending
+Constitution Sections: II, III, V
+Implementation PRs: Pending
+Decision Date: Pending
+```
+
+## Summary
+
+Burrow should own its forge, deployment logic, and operational context under `burrow.net`. This proposal establishes the repository-local governance and forge bootstrap required to move build, release, and infrastructure control out of GitHub-centric assumptions and into a self-hosted operating model.
+
+## Motivation
+
+- The repository currently keeps CI definitions under `.github/workflows/` but has no first-class self-hosted forge layout.
+- Infrastructure changes and protocol work are already entangled; without a design record, the project risks landing irreversible operations without enough context.
+- A self-hosted forge is a prerequisite for durable autonomy over source, runners, and release pipelines.
+
+## Detailed Design
+
+- Add a project constitution and BEP process under `evolution/`.
+- Introduce a Nix flake and NixOS host/module layout for `burrow-forge`.
+- Add Forgejo-native workflows under `.forgejo/workflows/` for repository-local CI.
+- Bootstrap the initial forge identity around `contact@burrow.net` and an agent-owned SSH workflow.
+
+## Security and Operational Considerations
+
+- Initial bootstrap may read credentials from local intake, but production must converge on encrypted secret handling.
+- The first forge host replacement must preserve rollback information before deleting any existing VM.
+- DNS for `burrow.net` is currently pending activation; the forge rollout must not assume public reachability until nameserver cutover completes.
+
+## Contributor Playbook
+
+- Keep destructive host operations behind explicit verification of the current Hetzner state.
+- Build and test repository-local workflows before using them for deployment.
+- Record the active server id, image, IPs, and SSH path before replacement.
+
+## Alternatives Considered
+
+- Continue relying on GitHub Actions while separately hosting services. Rejected because it leaves source authority and CI policy split across systems.
+- Stand up Forgejo without a repository-local operating model. Rejected because the repo would still be missing deployment truth.
+
+## Impact on Other Work
+
+- Blocks long-term migration of workflows away from GitHub.
+- Provides the governance anchor for protocol and control-plane proposals.
+
+## Decision
+
+Pending.
+
+## References
+
+- `CONSTITUTION.md`
+- `.github/workflows/`
+- `.forgejo/workflows/`

evolution/proposals/BEP-0002-control-plane-bootstrap-and-local-auth.md

@@ -0,0 +1,60 @@
+# `BEP-0002` - Control-Plane Bootstrap and Local Auth
+
+```text
+Status: Draft
+Proposal: BEP-0002
+Authors: gpt-5.4
+Coordinator: gpt-5.4
+Reviewers: Pending
+Constitution Sections: I, II, III, V
+Implementation PRs: Pending
+Decision Date: Pending
+```
+
+## Summary
+
+Burrow needs a repository-owned control-plane model instead of ad hoc network payload storage plus third-party-only auth. This proposal introduces a local username/password bootstrap for `contact@burrow.net`, plus a register/map data model shaped to support a Tailscale-style control server without claiming full parity yet.
+
+## Motivation
+
+- Current auth support is limited and does not provide a plain local bootstrap path for the project's own operator identity.
+- The existing database stores network payloads, but not a durable model for users, nodes, sessions, or control-plane negotiation state.
+- Future work on route policy, device coordination, and richer negotiation needs a real data model now.
+
+## Detailed Design
+
+- Add control-plane types for users, nodes, register requests, and map responses.
+- Extend the auth server schema with local credentials, sessions, provider logins, and control nodes.
+- Expose JSON endpoints for local login, node registration, and map retrieval.
+- Seed the initial operator account from intake-backed bootstrap credentials.
+
+## Security and Operational Considerations
+
+- Passwords are stored with Argon2id hashes only.
+- Session tokens are bearer credentials and must be treated as sensitive.
+- The bootstrap credential path is a short-term path; follow-up work should move it into encrypted secret management before public deployment.
+
+## Contributor Playbook
+
+- Verify bootstrap account creation in an isolated test database.
+- Exercise login, register, and map end to end with integration tests.
+- Do not advertise protocol parity beyond the implemented request/response contract.
+
+## Alternatives Considered
+
+- Wait for full external identity-provider integration first. Rejected because the forge needs an operator account now.
+- Keep control-plane state implicit in daemon-local configuration. Rejected because it cannot express multi-device coordination.
+
+## Impact on Other Work
+
+- Unblocks forge bootstrap and future device control-plane work.
+- Creates the storage model needed for richer policy and transport proposals.
+
+## Decision
+
+Pending.
+
+## References
+
+- `burrow/src/auth/server/`
+- `burrow/src/control/`

evolution/proposals/BEP-0003-connect-ip-and-negotiation-roadmap.md

@@ -0,0 +1,61 @@
+# `BEP-0003` - CONNECT-IP and Negotiation Roadmap
+
+```text
+Status: Draft
+Proposal: BEP-0003
+Authors: gpt-5.4
+Coordinator: gpt-5.4
+Reviewers: Pending
+Constitution Sections: I, II, V
+Implementation PRs: Pending
+Decision Date: Pending
+```
+
+## Summary
+
+Burrow should grow from a WireGuard-first tunnel runner into a transport stack that can support HTTP/3 MASQUE `CONNECT-IP` and a richer node negotiation model. This proposal stages that work so Burrow can adopt the right abstractions instead of stapling QUIC-era semantics onto a WireGuard-only daemon.
+
+## Motivation
+
+- `CONNECT-IP` introduces HTTP/3 sessions, context identifiers, address assignment, and route advertisements that do not fit the current daemon model.
+- A Tailscale-style control plane requires explicit node, endpoint, and session state rather than raw network blobs.
+- The project needs a roadmap that distinguishes data-model work, control-plane work, and actual transport implementation.
+
+## Detailed Design
+
+- Stage 1: land control-plane types and persistent auth/session/node storage.
+- Stage 2: add transport-agnostic route, address-assignment, and policy abstractions in Burrow.
+- Stage 3: implement MASQUE `CONNECT-IP` framing and HTTP Datagram handling.
+- Stage 4: connect the transport layer to real relay, policy, and observability paths.
+
+## Security and Operational Considerations
+
+- `CONNECT-IP` changes the trust boundary from WireGuard peers to HTTP/3 peers and relays; authentication, replay handling, and scope restriction must be explicit.
+- Route advertisements and delegated prefixes must be validated before touching the data plane.
+- Control-plane capability claims must not imply support that the transport layer does not yet implement.
+
+## Contributor Playbook
+
+- Keep protocol codecs independently testable before integrating them into live transports.
+- Add interoperability tests for every new capsule or datagram type.
+- Separate request parsing, policy validation, and packet forwarding so regressions stay localized.
+
+## Alternatives Considered
+
+- Implement MASQUE directly in the daemon without control-plane refactoring. Rejected because the current daemon has no transport-neutral contract for routes or prefixes.
+- Treat Tailscale negotiation as a one-off compatibility shim. Rejected because Burrow needs first-class control-plane concepts either way.
+
+## Impact on Other Work
+
+- Depends on BEP-0002.
+- Informs future relay, policy, and node coordination work.
+
+## Decision
+
+Pending.
+
+## References
+
+- RFC 9484
+- `burrow/src/daemon/`
+- `burrow/src/control/`

evolution/proposals/BEP-0004-hosted-mail-and-saas-identity.md

@@ -0,0 +1,68 @@
+# `BEP-0004` - Hosted Mail Backups and SaaS Identity
+
+```text
+Status: Draft
+Proposal: BEP-0004
+Authors: gpt-5.4
+Coordinator: gpt-5.4
+Reviewers: Pending
+Constitution Sections: II, III, V
+Implementation PRs: Pending
+Decision Date: Pending
+```
+
+## Summary
+
+Burrow should start with hosted mail on Forward Email instead of self-hosting SMTP and IMAP on the first forge machine. Backup retention should still be controlled by Burrow through custom S3-compatible storage backed by Burrow-owned object storage. In parallel, Burrow should treat SaaS identity as a separate track and converge on Authentik as the long-term IdP, with Linear SAML SSO as a planned downstream integration rather than an immediate bootstrap dependency.
+
+## Motivation
+
+- The first forge host already carries source control, CI, and deployment bootstrap risk. Adding a self-hosted mail stack increases operational scope before the forge is stable.
+- Forward Email already exposes SMTP and IMAP while allowing per-domain custom S3 backup storage, which preserves Burrow's data ownership over mailbox backups.
+- The repository needs a durable decision record that separates hosted mail operations from future SaaS SSO work.
+
+## Detailed Design
+
+- Use Forward Email as the operational mail provider for `burrow.net` and `burrow.rs`.
+- Configure custom S3-compatible storage per domain using Burrow-controlled object storage credentials.
+- Keep one backup bucket per domain and enforce lifecycle expiration at the bucket layer.
+- Add repository-owned tooling and documentation for applying and testing the Forward Email custom S3 configuration.
+- Treat Authentik as the future identity authority for SaaS applications, but keep Linear SAML as a later rollout once the workspace and vendor prerequisites are available. Linear's current docs place SAML and SCIM behind higher-tier workspace security settings, so Burrow should treat plan availability as an explicit precondition.
+
+## Security and Operational Considerations
+
+- Forward Email API tokens and S3 credentials must stay in secret files and must not be passed directly on the shell command line.
+- Buckets must remain private. Public bucket detection by the vendor should be treated as a hard failure, not a warning.
+- Backup growth is unbounded without lifecycle rules. Retention policy is part of the rollout, not optional cleanup.
+- Hosted mail reduces MTA attack surface on the forge host, but it adds third-party dependency risk; keeping backups in Burrow-owned storage limits that blast radius.
+
+## Contributor Playbook
+
+- Put the Forward Email API token in `intake/forwardemail_api_token.txt`.
+- Use `Tools/forwardemail-custom-s3.sh` to configure `burrow.net` and `burrow.rs`.
+- Run the helper again with `--test-only` after any credential rotation.
+- Record the chosen endpoint, region, bucket names, and lifecycle policy alongside rollout evidence.
+- Do not claim Linear SAML is live until the Authentik app, Linear workspace settings, workspace plan prerequisites, and end-to-end login flow are verified.
+
+## Alternatives Considered
+
+- Self-host Stalwart on the forge host immediately. Rejected for the first rollout because it expands host scope before source control and CI are stable.
+- Rely on Forward Email default backup storage only. Rejected because it gives Burrow less control over retention and data location.
+- Delay all SaaS identity planning until after forge cutover. Rejected because Linear and other SaaS integrations will otherwise accrete without an agreed authority.
+
+## Impact on Other Work
+
+- Narrows the first forge host scope.
+- Creates a clean mail path for `contact@burrow.net` without requiring self-hosted SMTP and IMAP.
+- Leaves Authentik and Linear SAML as explicit follow-up work instead of hidden assumptions.
+
+## Decision
+
+Pending.
+
+## References
+
+- `docs/FORWARDEMAIL.md`
+- `Tools/forwardemail-custom-s3.sh`
+- Forward Email FAQ: custom S3-compatible storage for backups
+- Linear docs: SAML SSO