Suriyakumarvijayanayagam
7d83c16ec5
Two comments in the compose model block were wrong in a way that mattered to the question "do we actually need a Groq key". The note about agent routes had lost its antecedent in the previous commit and dangled above MODEL_PROVIDER, appearing to describe provider selection. It belongs to MODEL_API_KEY. It was also only half true. It said an absent key is "a legitimate way to run this", which is correct outside production and impossible inside it: this stack defaults to APP_ENV=production, where validateModel refuses to start without a credential unless MODEL_BASE_URL is loopback. isLoopback accepts only localhost, 127.0.0.1 and ::1, so host.docker.internal does not qualify and no containerised deployment can take the keyless path. Reading the old comment, an operator would reasonably conclude they could leave the key empty and get a working API without Owliver. They get a container that will not boot. The endpoint count was stale too: routeRuns registers two, not three. routeOwliver's one endpoint does not touch s.agents and stays registered. Comments only; no behaviour change. vet clean, config and httpserver pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g
infrastructure
Deployment and local-environment definitions.
Empty in Phase 1, on purpose. The Phase 1 scope is the Go module, the
database connection and the initial migration, run against a PostgreSQL 18.6
instance that already exists on the developer's machine. Nothing here is needed
to get make migrate-up && make run working.
What lands here in later phases, once each is actually approved:
| File | Phase | Contents |
|---|---|---|
docker-compose.dev.yml |
2 | PostgreSQL + pgvector, so the dev database stops being a machine-local install |
docker-compose.dev.yml (extended) |
later | Redis, MinIO — each only when the phase that needs it starts |
Dockerfile.api |
later | Multi-stage build for go-api |
Dockerfile.owliver |
later | The Python service |
otel-collector.yaml |
later | OpenTelemetry collector config |
NATS is deliberately absent from that table: it is not part of the target architecture, and nothing here should reintroduce it.
Adding any of these before its phase would be speculative, so the directory holds only this note for now.