docs: replace docker compose links that aren't properly pointing to compose

Author: 56kyle

docs/our-chosen-toolchain.md

@@ -91,7 +91,7 @@ Here is the breakdown of the chosen tool(s) for each defined area:
 
 - **15: Container Orchestration (Local / Single Host):**
 
-  - **Chosen:** {docker}`Docker Compose<>`.
+  - **Chosen:** {docker-compose}`Docker Compose<>`.
   - **Why:** The standard, intuitive tool for defining and running multi-container applications locally, seamlessly integrating with built container images for development and testing stacks. ([Details](topics/15_compose-local.md))
 
 - **16: Deployment to Production Orchestrators:**

docs/topics/11_container-build.md

@@ -74,6 +74,6 @@ By choosing this approach, the template provides a standard, flexible, robust, a
 - **Dependency Management (02):** {uv}`uv<>` is the recommended tool for managing and installing dependencies _inside_ the Docker image.
 - **Task Automation (12):** {nox}`Nox<>` sessions call the `docker build` or `podman build` command via `uv run` (or `session.run` directly for the `docker`/`podman` command itself, as it's external) to build the image.
 - **CI Orchestration (13) & CD Orchestration (14):** Container image builds are often triggered in CI/CD pipelines via Task Automation. CD pipelines handle pushing the built images to container registries.
-- **Container Orchestration (Local) (15):** The image built in this area is the base for defining multi-container setups locally using {docker}`docker-compose<>`.
+- **Container Orchestration (Local) (15):** The image built in this area is the base for defining multi-container setups locally using {docker-compose}`docker-compose<>`.
 - **Deployment to Production Orchestrators (16):** The image built here is the primary artifact deployed to production environments managed by tools like Kubernetes/{helm}`Helm<>`/{argocd}`Argo CD<>`.
 - **Dev Containers (17):** The Dev Container often uses a similar or shared base image (or even the same `Dockerfile`) as the production image, leveraging common layers and consistency.

docs/topics/15_compose-local.md

@@ -25,7 +25,7 @@ This section evaluates tools used to define and run multi-container applications
 
 ## Tools and Approaches Evaluated
 
-### Option 1: {docker}`Docker Compose<>`
+### Option 1: {docker-compose}`Docker Compose<>`
 
 - **Description:** A widely used tool for defining and running multi-container Docker applications. Configuration is done via a `compose.yaml` (or `docker-compose.yml`) file using YAML.
 - **Evaluation:**
@@ -34,7 +34,7 @@ This section evaluates tools used to define and run multi-container applications
   - **Service Orchestration:** Excellent. Core purpose is to define and orchestrate multiple interconnected services, setting up internal networks, defining volumes for data persistence, and managing dependencies/startup order. Provides commands (`up`, `down`, `start`, `stop`, `restart`, `logs`, `exec`).
   - **Image Management:** Excellent. Can reference pre-built images from registries (`image: ...`) or build images locally based on a `Dockerfile` (`build: .` pointing to a directory containing a Dockerfile) – directly integrating with Topic 11's output.
   - **Ease of Use (Development Workflow):** Excellent. Designed for developer productivity. Simple commands (`docker compose up`) start the entire defined application stack. Easy to stop the stack or view combined logs.
-  - **OS Interoperability:** Excellent. The {docker}`Docker Compose<>` CLI tool itself works reliably across Linux, macOS, and Windows. It interacts with the local {docker}`Docker<>` or {podman}`Podman<>` runtime, which are also cross-platform.
+  - **OS Interoperability:** Excellent. The {docker-compose}`Docker Compose<>` CLI tool itself works reliably across Linux, macOS, and Windows. It interacts with the local {docker}`Docker<>` or {podman}`Podman<>` runtime, which are also cross-platform.
   - **Integration:** Excellent. Integrates directly with `Dockerfile`s (Topic 11). Commands are easily run from the terminal, within Dev Containers (Topic 17), or via Task Automation ({nox}`Nox<>`) if needed to control the multi-container setup. Can define health checks and dependencies for orchestration.
   - **Maturity & Stability:** Very High. A mature, stable, widely used standard for local/single-host container orchestration. Recently transitioned from `docker-compose` (Python CLI) to `docker compose` (built into Docker CLI, Go implementation), but the configuration file format remains compatible.
   - **Community & Documentation:** Very High. Large, active community, extensive documentation.
@@ -44,18 +44,18 @@ This section evaluates tools used to define and run multi-container applications
 ### Option 2: Orchestrator Tools (e.g., Raw Kubernetes Manifests, {helm}`Helm<>` - Kubernetes package manager, {argocd}`Argo CD<>` - Kubernetes CD)
 
 - **Description:** Tools used for orchestrating containers in production environments, primarily Kubernetes. (More aligned with Topic 16).
-- **Evaluation:** These tools (Kubernetes, Helm, Argo CD, etc.) are designed for complex, distributed, production-grade orchestration, not the streamlined local multi-container development experience. Their configuration is typically more complex and their local developer workflows are often less seamless for simple start/stop/log tasks compared to {docker}`Docker Compose<>`. They are designed to consume images, not necessarily simplify the local build-and-run loop for multiple dependent services in development.
+- **Evaluation:** These tools (Kubernetes, Helm, Argo CD, etc.) are designed for complex, distributed, production-grade orchestration, not the streamlined local multi-container development experience. Their configuration is typically more complex and their local developer workflows are often less seamless for simple start/stop/log tasks compared to {docker-compose}`Docker Compose<>`. They are designed to consume images, not necessarily simplify the local build-and-run loop for multiple dependent services in development.
 - **Conclusion:** While crucial for production (Topic 16), they are not the appropriate tools for the local/single-host multi-container development workflow task defined in this area.
 
 ## Chosen Tool(s)
 
-- Multi-container definition and orchestration: **{docker}`Docker Compose<>`** (using `compose.yaml` or `docker-compose.yml`).
+- Multi-container definition and orchestration: **{docker-compose}`Docker Compose<>`** (using `compose.yaml` or `docker-compose.yml`).
 
 ## Justification for the Choice
 
-**{docker}`Docker Compose<>`** is the definitive choice for defining and orchestrating multi-container applications in the context of this template's primary focus areas (local development, testing, simple single-host deployment) because it directly meets the needs of this specific layer:
+**{docker-compose}`Docker Compose<>`** is the definitive choice for defining and orchestrating multi-container applications in the context of this template's primary focus areas (local development, testing, simple single-host deployment) because it directly meets the needs of this specific layer:
 
-1.  **Standard for Local Orchestration:** {docker}`Docker Compose<>` is the **widely accepted standard tool** for defining multi-service Docker applications using a simple, **standard YAML format** (`compose.yaml`/`docker-compose.yml`). This makes the configuration **understandable and maintainable**.
+1.  **Standard for Local Orchestration:** {docker-compose}`Docker Compose<>` is the **widely accepted standard tool** for defining multi-service Docker applications using a simple, **standard YAML format** (`compose.yaml`/`docker-compose.yml`). This makes the configuration **understandable and maintainable**.
 2.  **Excellent Local Development DX:** It provides **easy-to-use command-line interface** for controlling the entire application stack locally (`docker compose up`, `docker compose down`, `logs`, etc.). This directly supports the goal of facilitating local development workflows for multi-service applications (addressing **Ease of Use**).
 3.  **Seamless Dockerfile Integration:** It natively supports referencing pre-built images and, crucially, **building images directly from a `Dockerfile`** within the compose configuration. This creates a direct link to the container image building process defined in Topic 11.
 4.  **Robust and Cross-Platform:** The tool is **highly OS-interoperable**, running reliably on Linux, macOS, and Windows, requiring only the underlying Docker or Podman runtime to be present (addressing **OS Interoperability**).
@@ -67,5 +67,5 @@ By choosing {docker-compose}`Docker Compose<>`, the template provides a standard
 ## Interactions with Other Topics
 
 - **Application Container Building (11):** {docker-compose}`Docker Compose<>` references the container images built in Area 11, often via a `build: .` directive pointing to the project's `Dockerfile` or via an `image:` reference to a registry.
-- **Dev Containers (17):** Dev Containers might potentially use {docker}`Docker Compose<>` as their backing "dev container" when setting up a development environment that itself consists of multiple containers.
+- **Dev Containers (17):** Dev Containers might potentially use {docker-compose}`Docker Compose<>` as their backing "dev container" when setting up a development environment that itself consists of multiple containers.
 - **Deployment to Production Orchestrators (16):** While different tools are used, the _concepts_ defined in `compose.yaml` (services, networks, volumes) have analogies in production orchestrators. Users might transition from a local compose setup to production manifests.

docs/topics/16_prod-deploy-guidance.md

@@ -52,15 +52,15 @@ We don't evaluate specific tools _for inclusion as configuration files in the te
 ## Chosen Approach
 
 - **Focus on Artifact Readiness:** Ensure the template's workflows reliably build and publish **standard, consumable artifacts** (container images from Topic 11, Python packages from Topic 09) suitable as inputs for common production deployment tools.
-- **Provide Documentation and Guidance:** Include clear documentation that acknowledges the external and complex nature of production deployment and guides users on how the template's outputs can be used with **common types of deployment tools and platforms**, mentioning examples like {docker}`Docker Compose<>` (Topic 15 for local context), Kubernetes orchestration (raw manifests, {helm}`Helm<>`), GitOps tools ({argocd}`Argo CD<>`), and serverless options. Do **NOT** include production deployment manifests or specific cloud configuration files within the template's core structure by default.
+- **Provide Documentation and Guidance:** Include clear documentation that acknowledges the external and complex nature of production deployment and guides users on how the template's outputs can be used with **common types of deployment tools and platforms**, mentioning examples like {docker-compose}`Docker Compose<>` (Topic 15 for local context), Kubernetes orchestration (raw manifests, {helm}`Helm<>`), GitOps tools ({argocd}`Argo CD<>`), and serverless options. Do **NOT** include production deployment manifests or specific cloud configuration files within the template's core structure by default.
 
 ## Justification for the Choice
 
 This approach provides maximum value to the user within the scope of a general Python project template while being realistic about the complexity of production deployment:
 
 1.  **Ensuring Compatibility:** By prioritizing the generation of **standard, high-quality build artifacts** (container images, packages) in Topics 09 and 11, the template fulfills the fundamental requirement that its outputs **CAN be consumed** by any standard production deployment method (addressing **Artifact Compatibility**). This is the template's core responsibility related to deployment readiness.
 2.  **Clear Scope Definition:** Explicitly stating that full production deployment configuration is complex and external to the template prevents users from expecting infrastructure-specific solutions within the base template. This sets realistic expectations (addressing **Scope Acknowledgment**). This aligns with **"Special cases should be allowed, but at their own expense"**, treating full infra config as a complex external special case.
-3.  **Empowering Users with Guidance:** Providing documentation that lists common types of deployment tools and platforms (Kubernetes, ECS, GKE, AKS, Lambda, Cloud Run, App Services, {helm}`Helm<>`, {argocd}`Argo CD<>`, {docker}`docker-compose<>` for local/simple reference) and explains how the template's standard outputs fit into these ecosystems gives users the knowledge to **choose and implement their specific deployment solution** (addressing **Guidance Quality** and **Relevance of Mentioned Tools**). It leverages the work done in Areas 09, 11, and 14.
+3.  **Empowering Users with Guidance:** Providing documentation that lists common types of deployment tools and platforms (Kubernetes, ECS, GKE, AKS, Lambda, Cloud Run, App Services, {helm}`Helm<>`, {argocd}`Argo CD<>`, {docker-compose}`docker-compose<>` for local/simple reference) and explains how the template's standard outputs fit into these ecosystems gives users the knowledge to **choose and implement their specific deployment solution** (addressing **Guidance Quality** and **Relevance of Mentioned Tools**). It leverages the work done in Areas 09, 11, and 14.
 
 By focusing on producing consumable artifacts and providing helpful guidance on how to integrate them into the wider deployment landscape, the template ensures its outputs are production-ready inputs for whatever external infrastructure and orchestration layer the user chooses, without adding overly complex or highly context-specific configurations to the template's core.
 
@@ -69,4 +69,4 @@ By focusing on producing consumable artifacts and providing helpful guidance on
 - **Packaging Build (09):** Produces Python packages (sdist/wheel) which can be deployment artifacts for serverless or other methods.
 - **Application Container Building (11):** Produces container images, the most common deployment artifact for orchestrated environments.
 - **Task Automation (12), CI Orchestration (13), CD Orchestration (14):** These workflows automate the creation and _potential_ publication of the artifacts needed for production deployment.
-- **Container Orchestration (Local) (15):** While focused on local use, {docker}`docker-compose<>` concepts and tools serve as a stepping stone or simplified analogy for understanding multi-service orchestration concepts used in production platforms. It's a related tool category mentioned in guidance.
+- **Container Orchestration (Local) (15):** While focused on local use, {docker-compose}`docker-compose<>` concepts and tools serve as a stepping stone or simplified analogy for understanding multi-service orchestration concepts used in production platforms. It's a related tool category mentioned in guidance.

docs/workflow/index.md

@@ -47,7 +47,7 @@ Here's how the template facilitates your day-to-day coding work:
 
     {nox}`Nox<>` handles running these tools within the correct, consistent environments using {uv}`uv run<>`.
 
-4.  **Local Container Development (Optional):** If your project involves multiple services or you prefer an encapsulated environment, use **Dev Containers** ([Containerized Development Environments (17)](../topics/17_dev-containers.md)) for a consistent development environment, and **{docker}`Docker Compose<>`** ([Container Orchestration (Local) (15)](../topics/15_compose-local.md)) to orchestrate local multi-service stacks.
+4.  **Local Container Development (Optional):** If your project involves multiple services or you prefer an encapsulated environment, use **Dev Containers** ([Containerized Development Environments (17)](../topics/17_dev-containers.md)) for a consistent development environment, and **{docker-compose}`Docker Compose<>`** ([Container Orchestration (Local) (15)](../topics/15_compose-local.md)) to orchestrate local multi-service stacks.
     ```bash
     # From project root with Docker/Podman running:
     # (Inside VS Code Dev Container or with compose installed)