docs: Fix documentation building inside CI

[xmnlab]

Pull Request description

How to test these changes

• ...

Pull Request checklists

This PR is a:

• bug-fix
• new feature
• maintenance

About this PR:

• it includes tests.
• the tests are executed on CI.
• the tests generate log file(s) (path).
• pre-commit hooks were executed locally.
• this PR requires a project documentation update.

Author's checklist:

• I have reviewed the changes and it contains no misspelling.
• The code is well commented, especially in the parts that contain more
  complexity.
• New and old tests passed locally.

Additional information

Reviewer's checklist

Copy and paste this template for your review's note:

## Reviewer's Checklist

- [ ] I managed to reproduce the problem locally from the `main` branch
- [ ] I managed to test the new changes locally
- [ ] I confirm that the issues mentioned were fixed/resolved .

[github-actions]

OSL ChatGPT Reviewer

NOTE: This is generated by an AI program, so some comments may not make sense.

workflows/docs.yaml

• Removing the CNAME creation will likely drop the custom domain from the deployed site. Unless the Pages deploy step explicitly sets cname, your docs may revert to the default GitHub Pages URL after each publish and/or cause custom domain flapping (L.44). Suggest either:

  • Re-add: echo "docs.makim.org" > ./build/CNAME (L.44), or
  • Configure the Pages deploy action to set cname: docs.makim.org.

• Security: If org-level domain verification isn’t enabled, unbinding the custom domain during deploys can open a subdomain takeover window. Ensure the repo/org has domain verification and that the deploy step preserves CNAME each run.

---

workflows/reviewer-pr.yaml

File deleted; no review.

---

.makim.yaml

• Correctness: Writing CNAME to ./build assumes mkdocs.yaml sets site_dir: build. If it’s still the default (site), the redirection will either fail (dir missing) or place CNAME in the wrong output, breaking Pages. Ensure site_dir matches, or adjust the target path accordingly, and make sure the directory exists before redirection.
• Deployment risk: If you deploy with mkdocs gh-deploy, it rebuilds to a temp dir and won’t use your local ./build. In that case, the CNAME won’t be included unless it lives in docs_dir (so MkDocs copies it) or you pass the proper option to include it.

---

poetry.lock

• (L.4316) Typer 0.24.1 raises its minimum dependency to click >= 8.2.1 (and rich >= 12.3.0). Please verify click in the lock/pyproject satisfies this (or bump it) to avoid import/runtime errors when loading Typer.

• (L.4438) Virtualenv 21.x is a major update and now introduces python-discovery plus tighter filelock/platformdirs constraints. Recommend a quick smoke test of your local/CI environment creation (pre-commit/tox/Make tasks) to catch any behavior changes.

• (L.3117) PyInstaller remains excluded for Python >= 3.14 (marker python_version < "3.14"). If your build/packaging runs on 3.14, confirm this intentional; otherwise packaging may fail on newer interpreters.

---

pyproject.toml

• Dependency resolution risk: You capped mkdocs to <2, but left plugins (mkdocs-material, mkdocs-jupyter, mkdocs-literate-nav, mkdocs-macros-plugin, mkdocs-exclude) without aligned upper bounds. When any of these plugins release a version that requires mkdocs>=2, installs will become unsatisfiable or silently downgrade other deps. Consider aligning each plugin with an upper bound known to support mkdocs 1.x.

• Potential conflict: You now constrain both mkdocstrings[python] (>=0.19.0) and mkdocstrings-python <2 alongside griffe <2. If a future mkdocstrings release raises its requirement to mkdocstrings-python >=2, your constraints will deadlock. Either:

  • keep the direct mkdocstrings-python <2 pin and also cap mkdocstrings to a compatible range, or
  • drop the direct mkdocstrings-python pin and rely on mkdocstrings[python] to manage compatibility.

---