# 0.4 — Local development harness (GREEN)

Phase: 0 — Foundations
Stage: GREEN
Depends on: [0.2](0.2-route-configuration.md)

- [ ] The whole gateway runs from a checkout with no cluster, no kubeconfig and no credentials of any kind
- [ ] A committed local config points every upstream at stub servers started by the harness
- [ ] Stubs can serve a fixed JSON body, an SSE token stream, a chunked response, and a slow response
- [ ] A test can assert on the real HTTP response: status, headers and body
- [ ] A test can assert that streamed chunks arrive incrementally, before the upstream has finished
- [ ] A test can disconnect the client mid-response and assert on what the stub upstream observed
- [ ] One documented command runs the harness end to end and exits non-zero on failure
- [ ] Running the harness never contacts `*.riotpiao.com` or any cluster address

This is a hard requirement, not a convenience: it determines whether work can proceed
unattended. Upstreams are configuration, so pointing them at local stubs is the entire
mechanism. Every later phase's verification depends on this existing first.

"It compiles" and "it starts" are not verification. Asserting on an actual HTTP
response is.

## Verify

```bash
env -u KUBECONFIG go test ./internal/testsupport/... ./internal/proxy/... -v
# expected: passes with no kubeconfig and no network access beyond loopback —
# includes an SSE test asserting incremental arrival and a mid-response disconnect test
```