30 lines
1.5 KiB
Markdown
30 lines
1.5 KiB
Markdown
|
# 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
|
||
|
|
```
|