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.
After login, character creation and play use one dialogue history and one text input. The player writes a free biography, receives a temporary AI draft, can request revisions, and approves it by writing godkänn. The player then receives a proposed start world and place based on the biography. That draft can also be revised in dialogue and is saved only after a second explicit godkänn. Drafts stay in the browser until approval and are lost if the page is reloaded first. The backend creates the character and initializes the world only after their respective approvals.
During play the UI has no persistent location, task, inventory, economy, status, or purchase panels. The player asks for information or writes an action in the same input. Rust validates state changes; the AI can only propose a typed intent. A direct request to travel may establish a new place and an encounter when Rust commits that movement.
The separate /admin route provides an authenticated, read-only operations view for player search/profile/trace, YAML prompt assets, generated Luau rules with validation results, and the append-only audit log. All privileged data comes from the Rust /api/admin/... API; the browser never connects directly to PostgreSQL. Backend endpoints require accounts.is_admin=true.
The game is text- and dialogue-based and uses no images. Place descriptions include sound, smell, air/temperature, touch/surface, and spatial-orientation cues. Visible details may also be described in words, but are never required to understand the scene or play. The transcript is screen-reader announced, and Enter submits the input while Shift+Enter inserts a newline; no separate send button is required.
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 routes /api, /version, and health checks to Rust while serving the static client at /. Both services share the same origin so the session cookie remains same-origin.
Builds, checks, and runtime verification happen in the pipeline and Kubernetes. Do not run the app, tests, container images, or binaries locally.