4 Commits

Include renames

Author	SHA1	Message	Date
NixReaperandClaude Sonnet 5	56a03f9cfe	Add a public API wiki at /wiki ... Builds docs/ into a static site via mkdocs + mkdocs-material in its own Docker build stage (docs-builder), so mkdocs itself never ends up in the runtime image -- only the rendered HTML does, mounted at /wiki alongside the existing /docs OpenAPI schema (unconditionally, unlike /docs, since this is curated content meant to be public regardless of AURORA_API_DOCS_ENABLED). docs/aurora-core-spec.md (the internal build spec, referenced by "section N" comments throughout the codebase) is excluded from the built site entirely via exclude_docs, not just left out of the nav -- it was never meant for public consumption. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-06 06:04:59 -05:00
NixReaperandClaude Sonnet 5	69ce41d54f	Fix media volume permission denied for the non-root worker/api user ... Neither Dockerfile created /app/media before switching to the non-root `aurora` user, so a fresh named volume mounted there (docker-compose.yml's aurora_media_data) defaulted to root ownership -- Docker only auto-populates a volume's initial content/ownership from the image the first time it's mounted, and nothing in the image owned that path yet. The worker's first artwork download then failed with a permission error trying to mkdir a subdirectory under it. Creating and chowning /app/media to aurora before USER aurora fixes this for any volume created fresh after this build; an already-created volume from a prior `up --build` needs a one-time manual fix (`docker compose exec -u root worker chown -R aurora:aurora /app/media`) since Docker won't retroactively re-populate an existing volume. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-05 07:35:50 -05:00
NixReaperandClaude Sonnet 5	e6841badf8	Fix worker never picking up code changes after restart ... docker compose restart worker looked like it should reflect new code (docker-compose.yml bind-mounts ./app:/app/app for dev), but the worker Dockerfile installed the app package non-editably (pip install .), which copies a frozen snapshot into site-packages at image build time. The bare `arq` console-script just imports whatever site-packages says `app` is -- unlike uvicorn --reload, which explicitly resolves its import string against the CWD -- so the worker silently kept running whatever code existed at the last `docker compose up --build`, no matter how many times it was restarted or how recent the git pull was. Confirmed live: after pulling the series/season ingestion pipeline and restarting, the worker log still read "Starting worker for 2 functions: ingest_movie_task, ingest_person_task" -- proof it never saw ingest_series_task/ingest_season_task at all. Switching to `pip install -e .` makes site-packages point at /app by absolute path instead of a frozen copy, so the same bind mount that already worked for the API now actually reaches the worker process too -- a plain restart after `git pull` is enough going forward. Applied to both Dockerfiles for consistency, since the API's working behavior was incidental to uvicorn, not something to rely on either. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 19:51:52 -05:00
NixReaperandClaude Sonnet 5	c20df1c503	Initial Aurora Core 0.1 implementation ... Production-grade media metadata backend per docs/aurora-core-spec.md: Aurora-owned UUIDv7 identity system, normalized movie/TV/people/credits schema, provider abstraction with a TMDb adapter, an idempotent async ingestion pipeline (normalize -> match -> upsert -> provenance), a Postgres FTS/trigram search layer, a stateless FastAPI v1 API with Redis caching/rate-limiting, arq workers, dev/prod Docker Compose topologies, unit + integration + load tests, CI, and architecture/ database/API/ERD documentation. Co-Authored-By: Claude Sonnet 5 <[email protected]>	2026-09-04 17:34:03 -05:00