# 1.1 — Reverse proxy to configured upstreams (GREEN)

Phase: 1 — Proxy core
Stage: GREEN
Depends on: [0.2](0.2-route-configuration.md), [0.4](0.4-local-dev-harness.md)

- [ ] A request matching a configured route is proxied to that route's upstream address
- [ ] The upstream's status code, response headers and body reach the client unmodified
- [ ] The request method, query string and body reach the upstream unmodified
- [ ] The route's configured path rewrite is applied to the upstream request path
- [ ] Connections to upstreams are pooled and reused across requests — a second request to the same upstream does not open a new TCP connection
- [ ] A request matching no configured route returns `404` and contacts no upstream
- [ ] An unreachable upstream returns a `5xx` to the client and is logged with the upstream name

Connection reuse is not a micro-optimisation here: the chat upstreams hold long-lived
streaming responses, and churning connections under that pattern wastes handshakes and
file descriptors on both ends.

## Verify

```bash
go test ./internal/proxy/... -run 'TestProxy|TestConnectionReuse' -v
# expected: passes — stub upstream sees the rewritten path and original body, client
# sees the stub's exact status/headers/body, and the stub records one accepted
# connection across two sequential requests
```