Test name claims "standard config names" but includes a non-standard path

test_local_override_filename_matches_standard_config_names asserts that nested/fnox.toml returns Some("fnox.local.toml"). The function itself behaves correctly (it only inspects the basename), but nested/fnox.toml is not a standard config path — it is a path with a directory prefix that, when passed to load_smart, takes the else branch and loads only the explicit file, meaning the adjacent fnox.local.toml is never picked up.

Including this case under "standard config names" may give future readers the false impression that this path is a supported input for the --local-file feature. Consider moving it to a separate test named something like test_local_override_filename_basename_only_match and pairing it with a comment that makes the limitation explicit:

#[test]
fn test_local_override_filename_basename_only_match() {
    // The function inspects only the basename. Note that paths with directory
    // components (e.g. "nested/fnox.toml") are technically accepted here but
    // the --local-file feature is NOT supported for such paths because
    // load_smart does not pick up the adjacent local override file.
    assert_eq!(
        local_override_filename(Path::new("nested/fnox.toml")),
        Some("fnox.local.toml")
    );
}

--local-file help text omits critical constraint

The flag's help text only says "Write sync overrides to the local override file next to the config file", but it silently accepts paths like --config nested/fnox.toml (the basename check in local_override_filename passes), writes nested/fnox.local.toml, yet those secrets are never read back because load_smart takes the direct-load path for any path with directory components.

The constraint that only bare fnox.toml / .fnox.toml config filenames are supported is documented in docs/guide/hierarchical-config.md, but a user reading the command reference first will see no warning. The same omission is present in docs/cli/commands.json and the fnox.usage.kdl help string.

Consider adding the restriction to all three help strings, e.g.:

effective_config_path computed unconditionally regardless of --local-file

find_local_config performs filesystem I/O (up to ~6 path.exists() calls) on every fnox sync invocation even when --local-file is not set. effective_config_path is only consumed inside the two self.local_file-gated branches (lines 67–77 and 241–251), so this work is entirely wasted for the common case.

Consider guarding the block:

let effective_config_path = if self.local_file {
    if cli.config == std::path::Path::new(config::DEFAULT_CONFIG_FILENAME) {
        let current_dir = std::env::current_dir().map_err(|e| {
            FnoxError::Config(format!("Failed to get current directory: {}", e))
        })?;
        let candidate = config::find_local_config(&current_dir, Some(&profile));
        if local_override_filename(&candidate).is_some() {
            candidate
        } else {
            cli.config.clone()
        }
    } else {
        cli.config.clone()
    }
} else {
    cli.config.clone() // unused, but avoids Option wrapping
};

local_override_filename variable shadows imported function

The let local_override_filename binding on line 67 shadows the local_override_filename function imported at line 2. Rust resolves name lookups in scope order, so any call to local_override_filename(...) after this point within run() would resolve to the Option<&'static str> value, not the function — resulting in a type error instead of a call. It doesn't cause a runtime bug today (the function isn't called again after line 77), but it's a maintainability hazard: a future refactor that calls the helper again after this point would get a confusing compile error rather than the expected behaviour.

Consider renaming the local binding to avoid the collision:

Then update the later usages at lines 249 and 307 accordingly (e.g. local_override_target.expect(...)).

effective_config_path computed unconditionally

find_local_config performs up to ~6 path.exists() filesystem calls on every fnox sync invocation, even when --local-file is not set. effective_config_path is only consumed inside the two self.local_file-gated branches (lines 67–77 and 241–251), so this I/O is entirely wasted for the common case.

Wrapping the block in an if self.local_file { ... } guard would make it a no-op unless the flag is actually passed:

let effective_config_path = if self.local_file {
    if cli.config == std::path::Path::new(config::DEFAULT_CONFIG_FILENAME) {
        let current_dir = std::env::current_dir().map_err(|e| {
            FnoxError::Config(format!("Failed to get current directory: {}", e))
        })?;
        let candidate = config::find_local_config(&current_dir, Some(&profile));
        if local_override_filename(&candidate).is_some() {
            candidate
        } else {
            cli.config.clone()
        }
    } else {
        cli.config.clone()
    }
} else {
    PathBuf::new() // unused; never accessed when local_file is false
};

Misleading test name includes a non-standard path

test_local_override_filename_matches_standard_config_names asserts that nested/fnox.toml returns Some("fnox.local.toml"). The function itself is correct (it only inspects the basename), but nested/fnox.toml is not a standard config path in the context of --local-file — it has a directory component that causes load_smart to take the direct-load branch and ignore adjacent local override files.

Including this case under "standard config names" may give future readers the false impression that paths with directory components are fully supported. Consider moving it to a dedicated test that makes the basename-only match behaviour explicit:

#[test]
fn test_local_override_filename_basename_only_match() {
    // The function inspects only the basename. Paths with directory components
    // are accepted here but are NOT valid --local-file inputs at the CLI level
    // because load_smart would not load the adjacent fnox.local.toml for them.
    assert_eq!(
        local_override_filename(Path::new("nested/fnox.toml")),
        Some("fnox.local.toml")
    );
}