lib_std.sh: PATH-manipulation trio (and the "misc" grab-bag) show no evidence they belong in the foundation module boundary

[codeforester]

Summary

A surgical pass over lib_std.sh looking specifically at module-boundary fit (not bugs) turned up one section that's architecturally disconnected from the rest of the "foundation" library — base_std_add_to_path/base_std_dedupe_path/base_std_print_path — plus a smaller, related "misc" grab-bag worth reviewing at the same time. This is not a request to split lib_std.sh into fragments; per STANDARDS.md, a new library file is the correct move "when the repository adds a distinct reusable library boundary," and that's the question being raised here for two specific pieces.

Method

For every public function in lib_std.sh, checked whether it's called by any other function inside lib_std.sh itself (internal load-bearing coupling — the strongest signal something is genuinely foundational, the way logging is called from cleanup, command execution, assertions, etc.), and whether it's called by any other module in the repo or by the example/reference apps (external evidence it's a real cross-cutting dependency, the way base_app_prompt in lib_app.sh depends on base_std_ask_yes_no).

Findings

base_std_add_to_path / base_std_dedupe_path / base_std_print_path — no internal or external callers anywhere in the repo

$ grep -rn "base_std_add_to_path\|base_std_dedupe_path\|base_std_print_path" lib/ examples/ --include="*.sh"
(no matches outside their own definitions in lib_std.sh)

These three functions (the entire PATH MANIPULATION section, ~95 lines) are not called by anything else in lib_std.sh, not called by any of the other eight modules, and not exercised by any of the three reference applications. They're also a narrower concern than the rest of the file: "safely edit the current shell's PATH" is an environment-bootstrapping utility, not something every consumer of the framework needs the way logging, cleanup, or command execution are. Contrast with base_std_ask_yes_no, which looked like a similar candidate at first glance but turned out to have a real internal dependent (base_app_prompt in lib_app.sh calls it directly) — that one earns its place in the foundation layer; PATH manipulation doesn't show the same evidence anywhere.

The MISC FUNCTIONS section is a naming smell worth resolving at the same time

base_std_safe_cd, base_std_safe_unalias, and base_std_get_my_source_dir (~185 lines including doc comments) share no internal callers either, and the section itself is literally named "misc" — a label that usually means the original placement was never confidently decided rather than deliberately foundational. base_std_safe_unalias in particular is hard to justify as a standard-library primitive: unaliasing a command name inside a script is a narrow, rarely-needed defensive habit, not a cross-cutting concern.

What I checked and concluded correctly belongs

• Logging (~565 lines): every other subsystem in the file — cleanup, command execution, assertions, introspection — calls into it. It's load-bearing infrastructure for the rest of lib_std.sh itself, not just for consumers. Extracting it would create a foundation module that depends on a non-foundation module for its own internals. Correctly placed.
• The timeout/process-supervision machinery inside COMMAND EXECUTION (roughly 500 of that section's 1084 lines): large and self-contained, but it's the direct implementation of the framework's headline "safe execution with dry-run/retry/timeout" capability. I'm not raising this as a boundary problem on its own — see the note on Background guardian-process pattern duplicated between lib_std timeout supervisor and lib_gh retry-capture guardian #395 below, since that issue already captures the more specific, actionable version of this observation (the same guardian-process pattern is duplicated in lib_gh.sh, which is the real argument for extraction, not just size).
• base_std_ask_yes_no/base_std_wait_for_enter: real internal dependent in lib_app.sh. Correctly placed.

Suggested action

Consider extracting PATH manipulation into its own module (e.g. lib/bash/env/lib_env.sh) the next time a v-major or otherwise compatibility-breaking window is open, consistent with how file and git already earned their own boundaries per STANDARDS.md. Fold in a decision on the MISC FUNCTIONS three at the same time — likely base_std_get_my_source_dir and base_std_safe_cd stay in the foundation layer (they're general enough), while base_std_safe_unalias is worth a specific call on whether it's pulling its weight as public API at all.

This is scope hygiene, not urgency — nothing here is broken, and I'm not proposing splitting the current file, just naming the one piece that doesn't show any of the internal-dependency evidence the rest of the file does.