Layout and testing¶
Layout¶
cmd/geniusrise/ entrypoint, mode dispatch
internal/spec deploy.yaml types, strict parse, env resolution, writeback
internal/catalog recipe types, embedded loader, engine commands
internal/pricing snapshot types, cache, embedded fallback
internal/planner pure: (spec, catalog, prices) -> plan
internal/gateway api, auth+limits, router, autoscaler, budget, reconciler, state
internal/tunnel CA, join tokens, mTLS ALPN routing, yamux tunnel, RPC
internal/node engine supervisor, canary, spot watchers, admin endpoint
internal/hostagent ssh host mode (docker per gpu)
internal/provider interface; fake, ssh, aws (gcp/azure/runpod in P2/P3)
internal/gui templates + static, localhost session guard
internal/cli commands
catalog/*.yaml recipes
images/<engine>/ Dockerfiles
tools/pricegen daily price snapshot generator
Testing strategy¶
- unit — spec validation golden tests, planner table tests against a fixed snapshot, autoscaler/budget on a simulated clock, limits accounting
- in-process integration (every PR) — gateway + fake provider + fake engine over a real tunnel: scale-from-zero with streaming, canary-detected replacement, spot interruption fallback, orphan cleanup, budget thresholds, invalid config rejection, state restore
- provider contract suite — one suite; runs against the fake in CI, against real clouds via
make e2e PROVIDER=<p>(opt-in, budget-capped test account, cpu variants) - catalog — CI validates schema;
tested:is mandatory
Conventions¶
- no comments in code unless a comment is the point
- gofmt-clean,
go vetclean, tests green — CI enforces all three - one feature or logical block per commit