# .env.production is committed deliberately, at the repo owner's instruction, so
# the deployment does not depend on re-entering config in the Dokploy UI.
#
# It is NOT named .env, and that matters: Dokploy writes its own .env into the
# build context from the service's Environment tab after cloning, so a committed
# .env is silently replaced (with an empty file when that tab is blank).
# The Dockerfile copies .env.production to /app/.env inside the image.
#
# The two database secrets are NOT in it - they are set as Dokploy environment
# variables, which override the file (settings.py calls load_dotenv() without
# override=True, so the process environment wins).
#
# The auth secrets ARE in it. AUTH_SECRET_KEY signs every access token, so
# anyone with read access to this repository can mint an admin token, and git
# history keeps it after any rotation. Regenerate with
# `python scripts/make_auth_secrets.py` if that stops being acceptable.
!.env.production
.env

# Local overrides and the generated sign-in passwords stay out of git.
.env.local
SIGNIN_PASSWORDS.txt

# Python
__pycache__/
*.pyc
*.pyo
.venv/
venv/
*.egg-info/
.pytest_cache/

# Logs
*.log

# OS
.DS_Store
Thumbs.db

# Dagster (orchestration layer, development only)
# Run/event history, compute logs and the pickled asset outputs from the
# filesystem IO manager. Regenerated on demand; nothing here is source.
orchestration/.dagster_home/storage/
orchestration/.dagster_home/history/
orchestration/.dagster_home/logs/
orchestration/.dagster_home/schedules/
orchestration/.dagster_home/*.db
orchestration/.dagster_home/*.db-*
orchestration/.dagster_home/.telemetry/
# dagster.yaml IS committed - it is the instance configuration.
# .env.orchestration IS committed - it holds no secrets, only the local
# database pin that keeps orchestrated writes off production.

# Spreadsheets sent to the catalog ingestion endpoints, plus their
# manifests. This is operator data, not source: it is whatever a colleague
# happened to send, it can contain a store's real pricing, and in a container
# it lives on the /app/data volume rather than in the image. Committing it
# would put customer files in the repository permanently.
# BATCH_UPLOAD_DIR overrides the location; this covers the default.
data/batch_uploads/