Merge #303: refactor(infrastructure): [#301] Phase 4 - Extract ServiceTopology shared type

14a27e4 fix: [#304] add crate-level allow for clippy::large_stack_arrays false positive (Jose Celano)
2f3314a fix(domain): [#301] re-enable aggregate tests with clippy allow attribute (Jose Celano)
1962386 refactor(infrastructure): [#301] extract ServiceTopology shared type (Jose Celano)
195c80e refactor(infrastructure): [#301] remove unused fields from Grafana/Prometheus ServiceContext (Jose Celano)
e87b7ae refactor(infrastructure): [#301] remove legacy fields from TrackerServiceContext (Jose Celano)
f47326f docs: [#301] update Phase 4 progress - Step 7.5 complete (Jose Celano)
8452fb5 refactor(infrastructure): [#301] remove TrackerPorts type alias (Jose Celano)
7a9d035 refactor(infrastructure): [#301] rename service configs to *Context (Jose Celano)
1e28b43 refactor(domain): [#301] replace fixed_ports.rs with domain types for Caddy/MySQL (Jose Celano)
d98df1e docs: [#301] mark Phase 4 acceptance criteria complete (Jose Celano)
49a9eef docs: [#301] update Phase 4 progress - all main goals complete (Jose Celano)
30eb4a1 refactor(domain): [#301] add NetworkDerivation trait and EnabledServices abstraction (Jose Celano)
17a526e refactor: [#301] rename PrometheusServiceConfig and GrafanaServiceConfig constructors (Jose Celano)
9da19b6 refactor: [#301] complete DDD migration - remove TrackerServiceConfig::new() (Jose Celano)
15ae4c9 refactor: [#301] add fixed port functions for Caddy and MySQL in domain (Jose Celano)
62e02ff refactor: [#301] implement PortDerivation for TrackerConfig (Jose Celano)
cdbbda6 refactor: [#301] implement PortDerivation for GrafanaConfig (Jose Celano)
b8db37f refactor: [#301] implement PortDerivation for PrometheusConfig (Jose Celano)
894da3c refactor: [#301] add PortDerivation trait in domain topology (Jose Celano)

Pull request description:

  ## Summary

  Closes #301

  This PR completes Phase 4 of the Docker Compose Topology Domain Model Refactoring by extracting a shared `ServiceTopology` type to formalize the architectural pattern discovered during cleanup.

  ## Problem

  After Phase 3 cleanup that removed unused fields from all ServiceContext types, we observed that all 5 types (`TrackerServiceContext`, `GrafanaServiceContext`, `PrometheusServiceContext`, `CaddyServiceContext`, `MysqlServiceContext`) now share identical fields:

  ```rust
  pub ports: Vec<PortDefinition>
  pub networks: Vec<Network>
  ```

  This wasn't just coincidence - it represents a clear architectural pattern:
  - **Topology data** (ports/networks) → needed for `docker-compose.yml` template (inter-service relationships)
  - **Configuration data** (credentials, intervals) → injected via `.env` files (internal service config)

  ## Solution

  Extract a shared `ServiceTopology` type to make this pattern explicit:

  ```rust
  #[derive(Serialize, Debug, Clone, PartialEq, Default)]
  pub struct ServiceTopology {
      pub ports: Vec<PortDefinition>,
      pub networks: Vec<Network>,
  }
  ```

  All ServiceContext types now embed this with `#[serde(flatten)]` to maintain template compatibility (flat JSON structure).

  ## Changes

  ### New File
  - `service_topology.rs` - Shared topology structure with documentation explaining the design rationale

  ### Updated ServiceContext Types
  All now use the embedded `ServiceTopology` pattern:
  - `TrackerServiceContext`
  - `GrafanaServiceContext`
  - `PrometheusServiceContext`
  - `CaddyServiceContext`
  - `MysqlServiceContext`

  ### API Changes
  - Added `ports()` and `networks()` accessor methods to each ServiceContext
  - Updated `builder.rs` to use accessor methods
  - Updated all tests to use accessor methods

  ## Testing

  - All 2075 library tests pass
  - All E2E tests pass (infrastructure lifecycle + deployment workflow)
  - Pre-commit checks pass (linting, formatting, spell check, clippy)

  ## Architecture Diagram

  ```
  ┌─────────────────────────────────────────────────────┐
  │           ServiceContext (e.g., Tracker)            │
  ├─────────────────────────────────────────────────────┤
  │  #[serde(flatten)]                                  │
  │  pub topology: ServiceTopology                      │
  │    ├── ports: Vec<PortDefinition>    ─────┐         │
  │    └── networks: Vec<Network>         ────┼── JSON  │
  │                                           │  flat   │
  └───────────────────────────────────────────┴─────────┘
                          ↓
              docker-compose.yml.tera template
  ```

  ## Related

  - Epic: #287 - Docker Compose Topology Domain Model Refactoring
  - Predecessor: #300 - Phase 3 Port Topology Template Integration
  - Plan: `docs/refactors/plans/docker-compose-topology-domain-model.md`

ACKs for top commit:
  josecelano:
    ACK 14a27e4

Tree-SHA512: 3712632ca6c1cad234d31c99e424d7031ea9924d8033b1d5ca2e3743d83f2cd36e6d7861a928b9f21ccfb5a8023d3bdc251f26c4ba152c99c31b5a6d61075bd4

Author: josecelano

docs/issues/301-phase-4-service-topology-ddd-alignment.md

@@ -0,0 +1,114 @@
+# Issue #304: Clippy `large_stack_arrays` False Positive with `vec![]` Macro
+
+**GitHub Issue**: <https://github.com/torrust/torrust-tracker-deployer/issues/304>
+
+## Problem
+
+Clippy reports a false positive `large_stack_arrays` lint when using the `vec![]` macro
+to create vectors of `ServiceTopology` items in tests.
+
+### Error Message
+
+```text
+error: allocating a local array larger than 16384 bytes
+  |
+  = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.93.0/index.html#large_stack_arrays
+  = note: `-D clippy::large-stack-arrays` implied by `-D clippy::pedantic`
+  = help: to override `-D clippy::pedantic` add `#[allow(clippy::large_stack_arrays)]`
+```
+
+### Root Cause
+
+This is a known clippy bug where the `vec![]` macro is incorrectly flagged for creating
+a large stack array. The `vec![]` macro creates a `Vec<T>` which allocates on the heap,
+not the stack. The lint is a false positive.
+
+**Upstream Issue**: <https://github.com/rust-lang/rust-clippy/issues/12586>
+
+### Affected Code
+
+Tests in `src/domain/topology/aggregate.rs` that create vectors of `ServiceTopology`:
+
+```rust
+let topology = DockerComposeTopology::new(vec![
+    ServiceTopology::with_networks(Service::Tracker, vec![Network::Database]),
+    ServiceTopology::with_networks(Service::MySQL, vec![Network::Database]),
+])
+.unwrap();
+```
+
+### Workarounds Attempted (Did Not Work)
+
+1. **Outer attribute on module**: `#[allow(clippy::large_stack_arrays)]` on `mod tests`
+2. **Inner attribute on submodule**: `#![allow(clippy::large_stack_arrays)]` inside submodules
+3. **Outer attribute on test function**: `#[allow(clippy::large_stack_arrays)]` on `#[test]` functions
+4. **Inner attribute in function body**: `#![allow(clippy::large_stack_arrays)]` inside function
+
+None of these local suppression methods worked because the lint fires during macro
+expansion before the allow attributes are processed.
+
+## Solution
+
+Add a **crate-level allow attribute** in `src/lib.rs`:
+
+```rust
+// False positive: clippy reports large_stack_arrays for vec![] macro with ServiceTopology
+// This is a known issue: https://github.com/rust-lang/rust-clippy/issues/12586
+#![allow(clippy::large_stack_arrays)]
+```
+
+This is the only approach that successfully suppresses the false positive.
+
+### Trade-offs
+
+- **Downside**: Suppresses the lint crate-wide, potentially hiding legitimate issues
+- **Mitigation**: This lint is specifically for stack allocations. Since we use `Vec<T>`
+  (heap-allocated) throughout the codebase, legitimate triggers are unlikely
+- **Future**: Remove this allow once the upstream clippy issue is fixed
+
+## Affected Rust Versions
+
+- Rust 1.93.0 stable (confirmed on GitHub Actions CI)
+- Local nightly 1.95.0 does **not** reproduce the issue
+
+### Fix Timeline
+
+| Event                                                                                          | Date           | Version                            |
+| ---------------------------------------------------------------------------------------------- | -------------- | ---------------------------------- |
+| Fix merged to clippy master ([PR #12624](https://github.com/rust-lang/rust-clippy/pull/12624)) | April 27, 2024 | -                                  |
+| Rust 1.79.0 released                                                                           | June 13, 2024  | Nightly at merge time              |
+| Rust 1.80.0 released                                                                           | July 25, 2024  | **Expected first stable with fix** |
+
+### Potential Regression
+
+The fix was merged in April 2024 and should be in Rust 1.80.0+. However, we're still
+seeing this error on Rust 1.93.0 (January 2026). This suggests either:
+
+1. **Regression**: The bug may have regressed in a later clippy version
+2. **Different code pattern**: Our `vec![]` with `ServiceTopology` (large struct with
+   `EnumSet` fields) might trigger a variant not covered by the original fix
+3. **CI environment**: Some discrepancy in the clippy version used in CI
+
+Consider reporting this as a potential regression if the issue persists after verifying
+the clippy version matches the expected behavior.
+
+## Related Clippy Issues
+
+Other `large_stack_arrays` issues (not directly related to our problem):
+
+- [#13774](https://github.com/rust-lang/rust-clippy/issues/13774) - No span for error (closed)
+- [#13529](https://github.com/rust-lang/rust-clippy/issues/13529) - Nested const items (closed)
+- [#9460](https://github.com/rust-lang/rust-clippy/issues/9460) - Static struct (closed)
+- [#4520](https://github.com/rust-lang/rust-clippy/issues/4520) - Original lint creation (open)
+
+## References
+
+- Upstream clippy issue: <https://github.com/rust-lang/rust-clippy/issues/12586>
+- Related PR: #303 (Phase 4 Service Topology DDD Alignment)
+
+## Labels
+
+- `bug`
+- `workaround`
+- `clippy`
+- `technical-debt`

docs/issues/304-clippy-large-stack-arrays-false-positive.md

@@ -29,12 +29,12 @@ use std::sync::Arc;
 
 use tracing::{info, instrument};
 
-use crate::domain::environment::user_inputs::UserInputs;
 use crate::domain::environment::Environment;
 use crate::domain::template::TemplateManager;
-use crate::domain::tracker::{DatabaseConfig, TrackerConfig};
+use crate::domain::topology::EnabledServices;
+use crate::domain::tracker::DatabaseConfig;
 use crate::infrastructure::templating::docker_compose::template::wrappers::docker_compose::{
-    DockerComposeContext, DockerComposeContextBuilder, MysqlSetupConfig, TrackerServiceConfig,
+    DockerComposeContext, DockerComposeContextBuilder, MysqlSetupConfig, TrackerServiceContext,
 };
 use crate::infrastructure::templating::docker_compose::template::wrappers::env::EnvContext;
 use crate::infrastructure::templating::docker_compose::{
@@ -155,12 +155,8 @@ impl<S> RenderDockerComposeTemplatesStep<S> {
         self.environment.admin_token().to_string()
     }
 
-    fn build_tracker_config(&self) -> TrackerServiceConfig {
+    fn build_tracker_config(&self) -> TrackerServiceContext {
         let tracker_config = self.environment.tracker_config();
-        let user_inputs = &self.environment.context().user_inputs;
-
-        let (udp_tracker_ports, http_tracker_ports_without_tls, http_api_port, http_api_has_tls) =
-            Self::extract_tracker_ports(tracker_config, user_inputs);
 
         // Determine which features are enabled (affects tracker networks)
         let has_prometheus = self.environment.prometheus_config().is_some();
@@ -169,16 +165,26 @@ impl<S> RenderDockerComposeTemplatesStep<S> {
             DatabaseConfig::Mysql(..)
         );
         let has_caddy = self.has_caddy_enabled();
+        let has_grafana = self.environment.grafana_config().is_some();
 
-        TrackerServiceConfig::new(
-            udp_tracker_ports,
-            http_tracker_ports_without_tls,
-            http_api_port,
-            http_api_has_tls,
-            has_prometheus,
-            has_mysql,
-            has_caddy,
-        )
+        // Build list of enabled services for topology context
+        let mut enabled_services = Vec::new();
+        if has_prometheus {
+            enabled_services.push(crate::domain::topology::Service::Prometheus);
+        }
+        if has_grafana {
+            enabled_services.push(crate::domain::topology::Service::Grafana);
+        }
+        if has_mysql {
+            enabled_services.push(crate::domain::topology::Service::MySQL);
+        }
+        if has_caddy {
+            enabled_services.push(crate::domain::topology::Service::Caddy);
+        }
+
+        let topology_context = EnabledServices::from(&enabled_services);
+
+        TrackerServiceContext::from_domain_config(tracker_config, &topology_context)
     }
 
     /// Check if Caddy is enabled (HTTPS with at least one TLS-configured service)
@@ -205,7 +211,7 @@ impl<S> RenderDockerComposeTemplatesStep<S> {
 
     fn create_sqlite_contexts(
         admin_token: String,
-        tracker: TrackerServiceConfig,
+        tracker: TrackerServiceContext,
     ) -> (EnvContext, DockerComposeContextBuilder) {
         let env_context = EnvContext::new(admin_token);
         let builder = DockerComposeContext::builder(tracker);
@@ -215,7 +221,7 @@ impl<S> RenderDockerComposeTemplatesStep<S> {
 
     fn create_mysql_contexts(
         admin_token: String,
-        tracker: TrackerServiceConfig,
+        tracker: TrackerServiceContext,
         port: u16,
         database_name: String,
         username: String,
@@ -312,47 +318,6 @@ impl<S> RenderDockerComposeTemplatesStep<S> {
             env_context
         }
     }
-
-    fn extract_tracker_ports(
-        tracker_config: &TrackerConfig,
-        user_inputs: &UserInputs,
-    ) -> (Vec<u16>, Vec<u16>, u16, bool) {
-        // Extract UDP tracker ports (always exposed - no TLS termination via Caddy)
-        let udp_ports: Vec<u16> = tracker_config
-            .udp_trackers()
-            .iter()
-            .map(|tracker| tracker.bind_address().port())
-            .collect();
-
-        // Get the set of HTTP tracker ports that have TLS enabled
-        let tls_enabled_ports: std::collections::HashSet<u16> = user_inputs
-            .tracker()
-            .http_trackers_with_tls()
-            .iter()
-            .map(|(_, port)| *port)
-            .collect();
-
-        // Extract HTTP tracker ports WITHOUT TLS (these need to be exposed)
-        let http_ports_without_tls: Vec<u16> = tracker_config
-            .http_trackers()
-            .iter()
-            .map(|tracker| tracker.bind_address().port())
-            .filter(|port| !tls_enabled_ports.contains(port))
-            .collect();
-
-        // Extract HTTP API port
-        let api_port = tracker_config.http_api().bind_address().port();
-
-        // Check if HTTP API has TLS enabled
-        let http_api_has_tls = user_inputs.tracker().http_api_tls_domain().is_some();
-
-        (
-            udp_ports,
-            http_ports_without_tls,
-            api_port,
-            http_api_has_tls,
-        )
-    }
 }
 
 #[cfg(test)]