The scaffold

AFAS MCP Server was generated from the Paleofuturistic Python copier template. The template gave this project a working toolchain — dependency management, a task runner, testing, security, docs, and CI — so you could start writing code instead of wiring plumbing.

Everything under this Developer section documents that inherited scaffold, kept apart from the rest of the site so your project's own documentation stays about your software. This page is the quick tour; each heading links the deeper pages. For documenting your own software, start with Document your project.

uv for everything

Every Python operation — virtualenvs, dependency resolution, the lockfile, fetching interpreters, publishing — goes through uv. One tool, one config surface (pyproject.toml + uv.lock), reproducible environments on your laptop and in CI.

→ Full rationale: How uv is used

The _CI task runner

./workflow.cmd <task> is the single entry point for every development action (format, lint, test, build, release, …). It dispatches into vendored Invoke tasks under _CI/, so a fresh clone works immediately with no extra install step. See the Invoke task catalog for the full list.

Prefer ./workflow.cmd for everything it covers — it's what CI runs, so your local results match. Running a tool directly with uv run <tool> is an advanced escape hatch: fine for a one-off it doesn't cover, but you then own the environment and flags. If you reach for one regularly, model it as a task instead (a two-minute change — see Add a workflow task below).

→ How it's built: The _CI tasks architecture · Add a workflow task · Customize the bootstrap

Testing and the coverage ratchet

./workflow.cmd test runs pytest with branch coverage. Coverage has a ratchet: once you start writing real tests, the fail_under floor only ever moves up, so coverage can't silently regress. tox runs the suite across your whole Python version range. See Run tests for one Python version.

→ Full rationale: Testing strategy

Security and the SBOM

./workflow.cmd secure runs pip-audit and builds a CycloneDX SBOM that ships inside your wheel. Findings you've reviewed are suppressed via .security-overrides. See Triage a security finding.

→ Full rationale: SBOM and security model

Continuous integration

The project ships a GitHub Actions workflow that runs the same ./workflow.cmd tasks you run locally — lint, the full tox test matrix, and build — so CI and your machine never disagree. The matrix is generated from your Python version range.

→ Full rationale: Testing strategy

The principles behind all of it

The scaffold's choices — pipelines that only run template commands, dependency groups over extras, ruff + ty over the older stack, vendored CI tooling — were deliberate. They ship with this project so you can read them offline.

→ Design principles

Keeping the scaffold up to date

This project stays linked to the template through .copier-answers.yml. To pull in later template improvements, run uvx copier update --trust from the project root — see the copier update docs.

Generation-time topics — the copier questions, switching git hosts, changing the Python version range — live in the template's own documentation: Using the template.

See also