Add OpenAPI spec for Stainless SDK generation

[scottfrasso]

Summary

• Add camelCase operationId and resource tags to all 37 API route decorators across 7 route files + 2 meta routes in main.py
• Exclude SPA catch-all and favicon routes from the schema with include_in_schema=False
• Add scripts/generate_openapi.py to export openapi-spec.json from the FastAPI app
• Add tests/test_openapi.py regression test that validates every operation has a camelCase ID and at least one tag

Test plan

• uv run pytest tests/test_openapi.py -v — new test passes
• uv run pytest tests/ -v — all 216 tests pass
• uv run python -m scripts.generate_openapi — generates openapi-spec.json with 28 paths
• CI checks pass

🤖 Generated with Claude Code

[scottfrasso]

Code review

Found 2 issues:

1. Perception/trajectory/breakdown endpoints are tagged as "Runs" but are semantically perception analytics endpoints. Stainless uses the first tag for SDK namespace grouping, so these would incorrectly appear under a runs resource in the generated SDK.

https://github.com/geostorm-ai/geostorm/blob/19ac0b7f33256da1ac67eed4e39eea9e7e10e35b/src/routes/runs.py#L151-L153

2. Settings endpoints (/settings/api-key-status, /settings/api-key, /settings/models) are tagged as "Setup" via the router-level tag, but should be "Settings" to match their URL prefix and semantic intent. This would cause SDK consumers to find settings operations under a setup namespace.

https://github.com/geostorm-ai/geostorm/blob/19ac0b7f33256da1ac67eed4e39eea9e7e10e35b/src/routes/setup.py#L36-L58

Both issues are fixed in e13e4c3 by moving to per-route tags where the router contains mixed resource types.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}