Files
krow_backend/infrastructure
Suriyakumarvijayanayagam bd9a8f91fc
Some checks failed
CI / test (push) Failing after 4m40s
CI / fixture (push) Failing after 9s
Make the shipped example envs ones that can actually start
The krow-2 deploy failed on the ANTHROPIC_API_KEY guard, which is the guard
doing its job. Checking what an operator hits *after* fixing it turned up two
older faults in the files they are told to copy — both predating the Groq
switch, both fatal at boot.

HTTP_WRITE_TIMEOUT shipped as 30s in .env.example, .env.docker.example and the
compose default, while validateWriteTimeout refuses anything at or under the
deep tier's 2m deadline. `cp .env.docker.example .env && docker compose up`
could not start. Now 180s. krow-2 never saw this because someone had already
overridden it in that environment.

.env.docker.example carried no model block at all, so a production stack built
from it is refused for a missing MODEL_API_KEY. Added, with the Groq defaults
and the reasoning-effort note (most non-reasoning models reject the request
rather than ignoring the key).

Neither was subtle. Both survived because the examples were prose to every test
in this package: the validator and the file documenting it had no mechanical
connection, so tightening one silently invalidated the other. That connection
is now TestShippedExampleEnvActuallyBoots, which parses each example and runs
Load() on it under the APP_ENV the file itself declares — production for the
docker one, development for the root one, each internally consistent. Verified
by mutation: reverting the timeout, removing the key line, and restoring a
claude-* id each fail it with the message an operator would see.

Go does not treat these files as test inputs, so an example-only edit can be
served a stale pass from the test cache. Noted in the test; use -count=1.

Also documented the upgrade path in handover.md, including the one thing
startup validation cannot catch: renaming ANTHROPIC_API_KEY to MODEL_API_KEY
without replacing the value boots fine and 401s on every run.

gofmt clean, go vet clean, 15/15 packages pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g
2026-09-07 12:25:20 +05:30
..
2026-08-28 12:21:44 +05:30
2026-08-25 16:37:05 +05:30

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.