Proffalken's general preferences

Check the date/time at the start of every new session, and base all research and library usage on this information
If I ask you to do something and you think there is a better way to achieve the same results using different tools, technologies, or approaches, propose it, ELI5, and let me choose between the options before we start any new project
NEVER commit .env files
ALWAYS create a .gitignore for the appropriate languages

Software Development

Always plan before implementation, and show me the plan before starting to code
Adopt Test Driven Development for all things
Create Github Workflows and actions to run tests and build images when PR's are submitted so we don't get any issues when we merge to main
Use a git branch for all new features, only the first commit should ever be merged to main
Check if PR's are open before pushing code to them, if a PR has been closed then create a new one
Do not merge PR's without asking
Use Python for the backend and Javascript for the frontend
Prefer PostgreSQL over any other database engine, usually this will be an existing CNPG cluster
If Cloud Computing is involved, prefer Terraform (but use Open Tofu!) over other forms of IaC
Assume that we will be deploying in a containerised environment using either docker compose for development purposes or Helm and k8s for production
ALWAYS implement OpenTelemetry, but NEVER assume the platform to which the data will be sent
You can safely assume that there will be an Open Telemetry collector for you to point at, you do not need to create it
If using python and the OS is debian-based, you MUST NEVER use pip with the "break system packages" flag. Use uv or uvx instead.
When creating a UI, suggest some appropriate themes from awesome-design-md for me to pick from based on what you know about the project. If you don't know enough about the project, ask questions to ascertain that knowledge.

Always consult BRAND.md before writing any UI code. It is the source of truth for colours, typography, spacing, components, and tone of voice.

Always assume an ESP32 unless told otherwise
Make sure you are always using the latest versions of libraries unless there is a very good reason not to
If there is a good reason not to use the latest version of a library, explain why and let me take that decision
Never use deprecated functions or features of a library
Make sure your code is as forward-looking as possible
Use platformio for code management

When writing documentation, ALWAYS use mkdocs and markdown
Stick to the facts of what you are documenting, do not guess, estimate, or otherwise fantasise about what the system you are documenting is doing
Add references to external sources where appropriate, but recognise that not everything needs a reference, this is documentation, not wikipedia

When creating, scaffolding, or advising on Python packages:

Toolchain: Always use uv for project init, dependency management, building, and publishing. Never suggest the old venv + pip + build + twine workflow.
Project init: Use uv init --lib <name> for libraries.
Structure: Always use a src/ layout (src/my_package/ not top-level).
Config: Single pyproject.toml only — no setup.py, setup.cfg, or requirements.txt for libraries.
Build backend: Default to hatchling unless there's a specific reason not to.
Publishing: Use uv publish with PyPI Trusted Publishing (OIDC via GitHub Actions) — never suggest managing API tokens manually.
PyPI search: pip search is dead. Direct to pypi.org/search in a browser, or piptrends.com for comparisons.
Poetry: Don't suggest Poetry for new projects — uv is preferred. Only mention it if an existing project already uses it.

The local kubernetes cluster hosts a number of useful services including:
- Cloudnative PG for PostgreSQL Databases
- Garage for S3 compatibility (API at https://s3.mydomain.local)
- Apache Airflow (UI at https://airflow.mydomain.loca)
- Ollama (API at https://ollama.mydomain.local)
The host "DNS01" is the DNS server and is running Technitium