feat: full GCP deployment pipeline for backend + frontend

[GeorgePearse]

Summary

Completes the GCP deployment story by adding frontend deployment alongside the existing backend infrastructure.

Changes

Rust Backend API (new endpoints):

• GET /api/runs/:id - single run details
• GET /api/runs/:id/individuals - all individuals for a run
• GET /api/runs/:id/generations - generation summaries
• GET /api/runs/:id/generations/:gen - single generation detail
• GET /api/runs/:id/lineage - code lineage edges

Frontend:

• Rewired api.ts from Express/SQLite to Rust backend REST API
• VITE_API_URL env var for configurable API base (defaults to /api)
• Multi-stage Dockerfile (node build + nginx with reverse proxy)
• Fixed pre-existing TS build errors

Terraform:

• cloud_run_frontend.tf - second Cloud Run service for frontend
• frontend_image variable + frontend_url output
• Frontend proxies /api/* to backend via BACKEND_URL env var

CI/CD (deploy.yml):

• build-and-push-frontend job
• deploy-frontend job (depends on backend deploy for URL)
• Path trigger includes genesis/webui/frontend/**

Database:

• Migration 008: adds code, language, text_feedback to individuals table

docker-compose:

• Added frontend service on port 3000

Architecture

User -> Cloud Run (frontend/nginx:8080)
           |
           +-- /api/* -> Cloud Run (backend/rust:8080)
                              |
                              +-- Cloud SQL (Postgres 15, private VPC)

---

Future direction: Git notes for interleaving free text with code

A natural evolution of the storage model would be to use git notes (git notes add) to attach rich metadata directly to code commits, replacing or complementing the Postgres individuals table for code + feedback storage.

How it would work:

Each individual's code gets committed to a per-run branch (e.g. runs/<run_id>). Then git notes namespaces layer on the metadata without polluting the commit history:

# Evolution engine commits code for each individual
git commit -m "gen=3 mutation=diff parent=abc123"

# Attach evaluation feedback as a note
git notes --ref=refs/notes/feedback add -m "Score: 0.87. Loop is tighter but edge-case on empty input still fails."

# Attach LLM reasoning
git notes --ref=refs/notes/reasoning add -m "I noticed the parent duplicated work in the inner loop. Fused the two passes into one..."

# Attach structured metrics
git notes --ref=refs/notes/metrics add -m '{"combined_score": 0.87, "api_cost": 0.003, "is_pareto": true}'

Why this is interesting for Genesis:

1. Code + commentary in one view -- git log --notes=feedback --notes=reasoning interleaves the LLM's thought process, evaluator feedback, and the actual code diffs in a single linear history.
2. Standard tooling for free -- git diff, git log --graph, git blame all work on the evolution tree. The lineage graph is the git DAG. Merge commits could represent crossover operations.
3. Multiple annotation layers -- Separate namespaces (feedback, reasoning, metrics, meta-summary) let you toggle which context you see.
4. Immutable audit trail -- Notes are git objects with free versioning of annotations.
5. Cheap sync -- git push origin 'refs/notes/*' replicates all annotations.

Possible hybrid model:

• Git repo: stores code commits + notes (feedback, reasoning, metrics)
• Postgres: stores denormalized run-level analytics, generation summaries, cost tracking
• Rust backend: reads from both, serves the frontend a unified view

🤖 Generated with Claude Code

[gitguardian]

⚠️ GitGuardian has uncovered 2 secrets following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secrets in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
29340437	Triggered	Generic Password	28cc37b	scripts/export_ddl.sh	View secret
29340438	Triggered	Username Password	28cc37b	docker-compose.yml	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secrets safely. Learn here the best practices.
3. Revoke and rotate these secrets.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}