CI / test (push) Successful in 4s
- Add test/integration.test.ts: getServicePublicKey, full flow (register, login, createCollection, createPointFeature, listFeatures) - Update docs example: registerBySigningServiceKey then loginWithSignature - Document integration tests in typescript-frontend-integration.md Made-with: Cursor
1.7 KiB
1.7 KiB
AGENTS.md
This file gives future coding agents a fast path map for this repository.
Repository map
- API entrypoint:
cmd/api/main.go - HTTP routes/handlers:
internal/http/handlers.go - Core domain logic:
internal/app/service.go - Persistence:
internal/store/— PostgreSQL (whenDATABASE_URLset) or in-memory; migrations ininternal/store/migrations/ - Auth utilities:
internal/auth/ - Frontend static app:
web/ - TypeScript API client:
libs/geo-api-client/ - CI workflow:
.gitea/workflows/ci.yml - Architecture/planning docs:
docs/ - Server keys:
etc/(generated by./bin/gen-server-keys.sh)
Most common commands
From repo root:
go test ./...
go run ./cmd/api
./bin/gen-server-keys.sh # before first docker up (creates etc/server-service.*)
./bin/up.sh # or: docker compose up --build -d
docker compose down
docker compose --profile test run --rm test # run tests as root (avoids var/ permission issues)
TypeScript client:
cd libs/geo-api-client
bun install
bun test
bun run build
Path conventions
- Use repository-relative paths in docs and comments (never absolute machine paths).
- Keep API route changes in
internal/http/handlers.go. - Keep business rule changes in
internal/app/service.go. - Keep frontend integration docs under
docs/.
Editing guidance for agents
- Prefer minimal changes and avoid unrelated refactors.
- Add tests when behavior changes.
- Verify Go tests after backend changes.
- Verify Bun tests after TS client changes.
- For DB-required tests, prefer embedded/ephemeral Postgres fixtures over relying on an externally managed database.
- If CI fails due runner/network infrastructure, keep logs explicit in workflow output.