Trait ModuleConfig 

pub trait ModuleConfig {
    // Required methods
    fn name(&self) -> &'static str;
    fn validate(&self) -> Vec<ConfigIssue>;

    // Provided method
    fn apply_defaults(&mut self) { ... }
}

Trait for module-owned configuration sections.

Each mcpr module implements this on its file config struct (the struct that maps to a [section] in mcpr.toml). This gives each module ownership over:

• Naming: what TOML section key it lives under.
• Defaults: runtime-aware defaults (e.g., platform-specific paths).
• Validation: checking its own fields without the CLI knowing the rules.

Example

use mcpr_core::config::{ModuleConfig, ConfigIssue, Severity};

#[derive(serde::Deserialize, Default)]
pub struct FileStoreConfig {
    pub path: Option<String>,
}

impl ModuleConfig for FileStoreConfig {
    fn name(&self) -> &'static str { "store" }

    fn validate(&self) -> Vec<ConfigIssue> {
        let mut issues = vec![];
        if let Some(ref p) = self.path {
            if p.is_empty() {
                issues.push(ConfigIssue {
                    severity: Severity::Error,
                    module: "store",
                    message: "store.path cannot be empty string".into(),
                });
            }
        }
        issues
    }
}

CLI integration

The CLI collects all &dyn ModuleConfig and calls validate() on each:

let modules: Vec<&dyn ModuleConfig> = vec![&config.store, &config.cloud, ...];
let issues: Vec<ConfigIssue> = modules.iter().flat_map(|m| m.validate()).collect();

Required Methods

fn name(&self) -> &'static str

Module name — must match the TOML section key (e.g., “store”, “cloud”, “tunnel”).

Used in error messages and logging so the user knows which section of mcpr.toml to fix.

fn validate(&self) -> Vec<ConfigIssue>

Validate this module’s configuration.

Returns an empty vec if everything is valid. Each issue carries its own severity — the CLI decides whether to abort (on Error) or continue (on Warn).

Implementations should validate field values, required combinations, and cross-field constraints within this module. Cross-module validation (e.g., “relay mode requires port”) stays in the CLI.

Provided Methods

fn apply_defaults(&mut self)

Apply runtime-aware defaults that can’t be expressed in Default::default().

Called after TOML deserialization, before validation. Use this for defaults that depend on the platform, environment variables, or other runtime state (e.g., platform-specific DB paths, env-based feature flags).

The default implementation is a no-op.

Implementors