AI-spel frontend
This repository contains the static Swedish web client for the AI-driven life simulator. The intended deployment is a small Nginx pod in the ai-spel namespace. The existing Rust service remains authoritative for accounts, game state, and all /api/... routes.
Players provide a character biography, not a world description. The client asks the backend to create a biography-based starting place. It does not preview a person the player may meet; encounters belong to later world exploration.
Place descriptions are available as text with separate visual, sound, smell, air/temperature, touch/surface, and spatial-orientation cues so important scene information does not depend on sight. The current product has no image input or image interpretation flow; these cues are generated as part of the place proposal.
The browser and API stay on the same public origin, https://ai-spel.k3s.k0.nu. The ingress routes / to this frontend service and routes /api, /version, and /health to the Rust service. That keeps the current server-side session cookie same-origin and avoids browser CORS configuration.
Release flow
VERSION is the only version source for this repository. Gitea Actions on the existing large runner runs the static checks, Helm lint/template, publishes a commit image, bumps the patch version through scripts/bump-version.py, creates the matching release commit and Git tag, and publishes the release image, Helm chart, and rendered frontend manifest to Harbor. Argo CD tracks the newest published frontend chart. The image and chart releases use the same version as the commit and tag.
CI needs repository Action secrets named HARBOR_USERNAME and HARBOR_PASSWORD. The Harbor pull secret harbor-pull is already present in the Kubernetes namespace. Argo CD uses the existing ai-spel project and Harbor OCI credentials.
The first Argo Application is described in deploy/argocd/application.yaml. The backend ingress must be switched to the frontend Service before public traffic uses this pod. That cutover is intentionally coordinated with a backend release so the API routes and login session remain on the same host.
Builds, checks, and runtime verification happen in the pipeline and Kubernetes. Do not run the app, tests, container images, or binaries locally.