Ali Zarinkolah 9e8987968c feat(observability): add dual local logging sinks and static environment context
Why:
- Wanted human-readable console output while developing locally, without
  losing a machine-parseable log for later grepping/parsing. A single
  renderer chosen by a flag can't do both at once.
- ADR-0011 had no way to correlate an issue with a specific deployment
  (build/region/instance) independent of any one request.

Changes:
- configure_logging() now builds two independent handlers: console (always
  on, colored unless LOG_JSON_FORMAT=true) and an optional rotating JSON file
  (LOG_FILE_PATH, unset by default) -- the same structlog event fans out to
  both, so call sites are unaffected.
- A static structlog processor binds env/service_version onto every event.
  Deliberately not a contextvar: RequestIdMiddleware's clear_contextvars()
  would wipe a value bound there before the first request.
- New settings: APP_SERVICE_VERSION, LOG_FILE_PATH/LOG_FILE_MAX_BYTES/
  LOG_FILE_BACKUP_COUNT.
- ADR-0011 amended with both decisions ("console and file are independent
  sinks locally"; "bind process-level environment context once at startup").

Impact:
- configure_logging() signature changed to (logging_settings, app_settings);
  both call sites (lifespan, qdrant_bootstrap CLI) updated.
2026-08-20 19:20:27 +03:30
2026-08-02 15:52:46 +03:30

Talie chatbot service

Architecture decisions live in docs/adr. The first implementation milestone is documented in the ingestion vertical-slice plan.

Provisioning the datastores

Both schema steps run as explicit deployment steps. The application performs no DDL at startup — not for Postgres (ADR-0009) and not for Qdrant (ADR-0001, "Collection provisioning").

docker compose up -d                          # Postgres, MinIO, Qdrant
uv run alembic upgrade head                   # Postgres schema
uv run python -m src.cli.qdrant_bootstrap     # the `chunks` collection
uv run fastapi dev src/main.py

Before a tenant can upload, its domains must be registered — POST /v1/files rejects an unregistered or disabled domain with 400. The calling backend manages them over /v1/domains using a key with the domains:write scope:

curl -X POST http://localhost:8000/v1/domains \
  -H "Authorization: Bearer $API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"domain": "fire", "display_name": "Fire insurance"}'

Both bootstrap commands are idempotent and safe to re-run. qdrant_bootstrap verifies an existing collection against the pinned schema and exits non-zero on a mismatch, rather than leaving a silently degraded sparse index in place.

Local Langfuse

This repo includes a root-level development Compose file for Langfuse:

Start Langfuse locally:

cp .env.langfuse.example .env.langfuse
# edit .env.langfuse and replace CHANGE_ME values

docker compose --env-file .env.langfuse -f docker-compose.langfuse.yml up -d

Open:

http://localhost:3000

If the chatbot app runs on your host machine, configure it with:

LANGFUSE_HOST=http://localhost:3000

If the chatbot app later runs inside the same Compose project/network as Langfuse, configure it with:

LANGFUSE_HOST=http://langfuse-web:3000

A future app stack can be launched together with Langfuse using multiple Compose files:

docker compose \
  -f docker-compose.yml \
  -f docker-compose.langfuse.yml \
  --env-file .env \
  --env-file .env.langfuse \
  up -d
Description
No description provided
Readme 1.4 MiB
Languages
Python 99.3%
Shell 0.6%
Mako 0.1%