Revert "docs: fix more extlinks"

This reverts commit 48f4b13.

Author: 56kyle

docs/topics/02_dependency-management.md

@@ -118,7 +118,7 @@ We evaluated the most prominent options for managing Python project dependencies
 ## Chosen Tool(s)
 
 - **{uv}`uv-documentation`** as the primary **Dependency Manager**.
-- **{virtualenv-documentation}`virtualenv` / {venv-tutorial}`venv`** (orchestrated by uv) for environment management.
+- **[:py{virtualenv}`class`](virtualenv-documentation) / [venv](python:venv-tutorial)** (orchestrated by uv) for environment management.
 
 ## Justification for the Choice
 
@@ -139,7 +139,7 @@ By choosing {uv}`uv-documentation`, the template makes a deliberate, opinionated
 ## Interactions with Other Topics
 
 - **pyproject.toml (01):** {uv}`uv-documentation` is the primary consumer and editor of the `[project]`, `[build-system]`, and `[project.optional-dependencies]` tables in `pyproject.toml`, acting as the interpreter for packaging standards. Its own configuration goes in `[tool.uv]`.
-- **Packaging Build (09):** {uv}`uv-documentation` acts as a PEP 517 build frontend (`uv build`), calling the appropriate backend ({setuptools-documentation}`setuptools` or {maturin-documentation}`maturin`) configured in `pyproject.toml`.
+- **Packaging Build (09):** {uv}`uv-documentation` acts as a PEP 517 build frontend (`uv build`), calling the appropriate backend ([`setuptools`](setuptools-documentation) or [`maturin`](maturin-documentation)) configured in `pyproject.toml`.
 - **Packaging Publish (10):** {uv}`uv-documentation` provides a command to publish packages (`uv publish`) as an alternative to using {twine}`twine-documentation` directly. The Task Automation layer (12) might call `uv publish`.
 - **Task Automation (12):** {Nox}`nox-documentation` will orchestrate workflows by calling {uv}`uv-documentation` commands (e.g., `uv run ruff check`, `uv run pytest`, `uv build`, `uv publish`). {uv}`uv-documentation` is also configured as the backend for Nox's virtual environments (`nox.options.default_venv_backend = "uv"`), ensuring all session environments are created and managed with {uv}`uv-documentation`'s performance.
 - **Container Build (11):** {uv}`uv-documentation` is the recommended tool for installing dependencies _inside_ the `Dockerfile` (`RUN uv sync`).

docs/topics/06_testing-coverage.md

@@ -28,15 +28,15 @@ We evaluated the primary testing framework and coverage tools:
 
 ### Option 1: {mod}`unittest` (+ [coverage.py](coveragepy-documentation))
 
-- **Description:** {unittest-documentation}`unittest` is Python's built-in testing framework, inspired by JUnit. Tests are written in classes inheriting from `unittest.TestCase`. {coverage.py}`coveragepy-documentation` is the standard standalone tool for measuring code coverage.
+- **Description:** [unittest](python:unittest) is Python's built-in testing framework, inspired by JUnit. Tests are written in classes inheriting from `unittest.TestCase`. {coverage.py}`coveragepy-documentation` is the standard standalone tool for measuring code coverage.
 - **Evaluation:**
 
   - **Ease of Use:** Moderate. Requires significant boilerplate (class definitions, inheritance, specific method names, explicit `setUp`/`tearDown` methods). Writing simple tests is more verbose than alternatives.
   - **Feature-Rich:** Moderate. Provides core testing features but lacks the advanced features and extensive plugin ecosystem of {pytest}`pytest-documentation` (e.g., simple functional fixtures, powerful parametrization decorators built-in).
   - **Performance:** Moderate. Test execution can be slower than {pytest}`pytest-documentation` for large test suites due to its architecture (creating a class instance per test method). {coverage.py}`coveragepy-documentation` performance is generally good.
-  - **OS Interoperability:** Excellent. Both are foundational Python tools, highly robust across OSs. {unittest-documentation}`unittest` is standard library, {coverage.py}`coveragepy-documentation` is pure Python.
-  - **Integration:** High (Individual). Both have CLIs easily called from Task Automation/CI. Integrating them _together_ requires explicitly wrapping `unittest` execution with `coverage run -m unittest` or using less standardized plugins compared to the {pytest}`pytest-pytest-cov-documentation` ecosystem. Generating standard reports like JUnit XML also often requires extra steps or third-party runners for {unittest-documentation}`unittest`.
-  - **Reporting:** Moderate (Test) / Excellent (Coverage). {unittest-documentation}`unittest` provides basic terminal output. {coverage.py}`coveragepy-documentation` provides excellent, standard reports (text, HTML, XML).
+  - **OS Interoperability:** Excellent. Both are foundational Python tools, highly robust across OSs. [unittest](python:unittest) is standard library, {coverage.py}`coveragepy-documentation` is pure Python.
+  - **Integration:** High (Individual). Both have CLIs easily called from Task Automation/CI. Integrating them _together_ requires explicitly wrapping `unittest` execution with `coverage run -m unittest` or using less standardized plugins compared to the {pytest}`pytest-pytest-cov-documentation` ecosystem. Generating standard reports like JUnit XML also often requires extra steps or third-party runners for [unittest](python:unittest).
+  - **Reporting:** Moderate (Test) / Excellent (Coverage). [unittest](python:unittest) provides basic terminal output. {coverage.py}`coveragepy-documentation` provides excellent, standard reports (text, HTML, XML).
   - **Maturity & Stability:** Very High. Both are extremely mature, stable, battle-tested.
   - **Community & Documentation:** Very High. Widely adopted, vast documentation.
 
@@ -47,9 +47,9 @@ We evaluated the primary testing framework and coverage tools:
 - **Description:** A popular, feature-rich testing framework that allows writing tests using standard Python functions or methods, greatly reducing boilerplate.
 - **Evaluation:**
 
-  - **Ease of Use:** Very High. Simple function-based tests (`def test_something(): assert ...`). Intuitive organization. Powerful built-in parametrization (`@pytest.mark.parametrize`). Much less boilerplate than {unittest-documentation}`unittest`.
+  - **Ease of Use:** Very High. Simple function-based tests (`def test_something(): assert ...`). Intuitive organization. Powerful built-in parametrization (`@pytest.mark.parametrize`). Much less boilerplate than [unittest](python:unittest).
   - **Feature-Rich:** Excellent. Sophisticated fixture system, powerful parametrization, extensive plugin ecosystem for various testing needs (mocking, async, specific frameworks), robust hook system.
-  - **Performance:** High. Generally faster execution on large test suites than {unittest-documentation}`unittest`. Efficient test discovery.
+  - **Performance:** High. Generally faster execution on large test suites than [unittest](python:unittest). Efficient test discovery.
   - **OS Interoperability:** Excellent. Pure Python package, works reliably across OSs.
   - **Integration:** Excellent. Widely supported, integrates seamlessly into editors/IDEs, {pre-commit}`pre-commit-documentation`, Task Automation, CI/CD. Designed for external execution via CLI.
   - **Reporting:** Excellent. Provides clear terminal output. Standard support for generating JUnit XML reports (`--junitxml=...`), which is essential for CI platform integration.
@@ -93,7 +93,7 @@ We evaluated the primary testing framework and coverage tools:
 
 - **Description:** A generic virtual environment and test automation tool. Primarily used for running tests against multiple Python interpreters and dependency matrixes. Often configured via `tox.ini`. (Note: Already evaluated conceptually in Task Automation as a potential tool invoked by Nox for specific matrix needs).
 - **Evaluation:**
-  - **Testing Framework:** Moderate. It's not a testing _framework_ like {pytest}`pytest-pytest-cov-documentation` or {unittest-documentation}`unittest`, but an _orchestrator_ that runs other tools (like `pytest`) within isolated environments. Requires learning Tox config (`tox.ini`).
+  - **Testing Framework:** Moderate. It's not a testing _framework_ like {pytest}`pytest-pytest-cov-documentation` or [unittest](python:unittest), but an _orchestrator_ that runs other tools (like `pytest`) within isolated environments. Requires learning Tox config (`tox.ini`).
   - **Matrix Testing:** Excellent. Historically one of the best tools for defining and running tests across complex Python version and dependency variations.
   - **Integration with Test Tools:** Excellent. Designed to run commands like `pytest` or `python -m unittest` within its managed environments.
   - **OS Interoperability:** High. Designed for cross-platform matrix testing. Can have nuances depending on underlying shell commands in `tox.ini`.
@@ -112,13 +112,13 @@ We evaluated the primary testing framework and coverage tools:
 
 The combination of **{pytest}`pytest-documentation`**, **{coverage.py}`coveragepy-coverage-documentation`**, and **{pytest-cov}`pytest-pytest-cov-documentation`** is the best fit for providing robust testing and coverage capabilities in this template, complemented by **{Nox}`nox-documentation`** for matrix execution:
 
-1.  **Developer Experience:** {pytest}`pytest-pytest-cov-documentation` offers significantly **easier test writing and organization** compared to {unittest-documentation}`unittest`, with powerful features like fixtures and parametrization that improve test maintainability and expressiveness (addressing **Ease of Use** and **Feature-Rich**). This aligns with the **"Obvious way to do it"** for writing tests.
+1.  **Developer Experience:** {pytest}`pytest-pytest-cov-documentation` offers significantly **easier test writing and organization** compared to [unittest](python:unittest), with powerful features like fixtures and parametrization that improve test maintainability and expressiveness (addressing **Ease of Use** and **Feature-Rich**). This aligns with the **"Obvious way to do it"** for writing tests.
 2.  **Standards and Integration:** {pytest}`pytest-pytest-cov-documentation` is the de facto standard modern Python testing framework, and {coverage.py}`coveragepy-coverage-documentation` is the universal coverage engine. **{pytest-cov}`pytest-pytest-cov-documentation`** provides **seamless, standard integration** between them via a simple command-line flag (`--cov`), making combined testing and coverage easy to run and automate (addressing **Integration**).
 3.  **Reporting:** This combination provides **excellent standard reporting**, including JUnit XML from {pytest}`pytest-pytest-cov-documentation` and Cobertura XML/HTML from {coverage.py}`coveragepy-coverage-documentation`, which are essential for integration into CI/CD platforms (Area 13, 14) (addressing **Reporting**).
 4.  **Performance & OS Interoperability:** All chosen tools are **performant** for their tasks and **highly OS-interoperable**, working reliably across development and CI environments (addressing **Performance** and **OS Interoperability**).
 5.  **Matrix Testing:** While {pytest}`pytest-pytest-cov-documentation` itself isn't a matrix orchestrator, **{Nox}`nox-documentation`** (Area 12) is explicitly designed to run sessions (like our test session) across different Python versions and environments using `uv`, effectively providing the necessary matrix testing capability within the template's primary automation layer. For complex scenarios or community conventions, {Nox}`nox-documentation` can easily **invoke {Tox}`tox-documentation`**.
 
-{unittest-documentation}`unittest` was discounted due to its comparative verbosity, lack of features, and less streamlined integration for testing+coverage. {Tox}`tox-documentation` is better suited as a matrix _runner_ called by {Nox}`nox-documentation` than the primary testing _framework_ itself.
+[unittest](python:unittest) was discounted due to its comparative verbosity, lack of features, and less streamlined integration for testing+coverage. {Tox}`tox-documentation` is better suited as a matrix _runner_ called by {Nox}`nox-documentation` than the primary testing _framework_ itself.
 
 By choosing this combination, the template leverages the strengths of each tool – {pytest}`pytest-pytest-cov-documentation` for writing tests, {coverage.py}`coveragepy-coverage-documentation` for coverage, {pytest-cov}`pytest-pytest-cov-documentation` for integration, and {Nox}`nox-documentation` for orchestration – to provide a robust, modern, and well-integrated testing and coverage solution.