Add Dockerfile and docker-compose.yml (#8)

[sql-hkr]

This pull request introduces Docker support for the project, enabling containerized development and deployment. The main changes include the addition of a Dockerfile for building the application image and a docker-compose.yml for orchestrating the container setup.

Containerization setup:

• Added a new Dockerfile based on python:3.13-slim-trixie, installs dependencies, and uses uv for Python environment management.
• Added docker-compose.yml to define a service for the application, specifying build context, working directory, and volume mounting for local development.

[Copilot]

Pull Request Overview

Adds initial Docker support for local development and containerized runs.

• Introduces a Dockerfile using python:3.13-slim-trixie and uv for dependency management.
• Adds a minimal docker-compose.yml to build the image, set working directory, and bind-mount the project.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
Dockerfile	Builds a Python 3.13 image, installs build tools and graphviz, copies the app, installs deps with uv, and sets PATH.
docker-compose.yml	Defines an app service with build context, TTY, working_dir, and a host bind mount to /app.

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The bind mount of the project root to /app will shadow any files created at build time under /app, including the virtual environment created by uv sync in the Docker image (/app/.venv). This makes the layer from uv sync ineffective in dev containers. Consider either (a) moving the virtual environment outside /app (e.g., set ENV UV_PROJECT_ENVIRONMENT=/venv and ENV PATH="/venv/bin:$PATH" in the Dockerfile) or (b) mounting a named volume at /app/.venv in compose so it is not overridden by the bind mount.

Suggested change

	- .:/app
	- .:/app
	- venv:/app/.venv
	volumes:
	venv:

[Copilot]

Copying the entire build context before running uv sync prevents effective layer caching; any code change invalidates dependency installation. Reorder to copy only dependency manifests first, run uv sync, then copy the rest. Example: set WORKDIR /app, COPY pyproject.toml uv.lock* /app/, RUN uv sync --frozen, then COPY . /app.

Suggested change

	COPY . /app
	WORKDIR /app
	RUN uv sync --frozen
	WORKDIR /app
	COPY pyproject.toml uv.lock* /app/
	RUN uv sync --frozen
	COPY . /app

[Copilot]

[nitpick] Using the floating tag latest for the uv image makes builds non-reproducible and can break unexpectedly when upstream updates. Pin to a specific version or digest, e.g., COPY --from=ghcr.io/astral-sh/uv:vX.Y.Z /uv /uvx /bin/ or use a @sha256 digest.

Suggested change

	COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/
	COPY --from=ghcr.io/astral-sh/uv:v0.1.23 /uv /uvx /bin/

[Copilot]

[nitpick] The service does not define a command, which makes behavior depend on the base image default (currently python3). For predictable developer experience, specify an explicit command (e.g., bash, uv run your_app, or a dev server entrypoint) aligned with your workflow.

Suggested change

	working_dir: /app
	working_dir: /app
	command: bash