Module llm_cli_wrap 

Per-CLI-binary WrapStrategy table for the ai-memory wrap <agent> subcommand.

Why this module exists (#1183, split out of #1174 PR4)

The ai-memory wrap subcommand spawns external CLI binaries (the codex, aider, gemini, ollama, … executables on $PATH) and prepends a system-message envelope onto each invocation. Each downstream CLI has its own ABI for accepting that envelope — --system "<msg>" vs. OLLAMA_SYSTEM=<msg> vs. --message-file <path> — and the table that maps “agent binary name” → “delivery strategy” is the canonical knowledge of those ABIs.

That table is adjacent to the LLM-backend alias tables in crate::llm (the default_base_url_for_alias / vendor URL + Bearer-key map used by the HTTP LLM client), but is not the same concern:

• crate::llm is the HTTP LLM client — POST /v1/chat/completions, Bearer auth, circuit breaker. The agent name here means “wire-shape selector” (xai, openai, …).
• This module is the CLI process-spawning wrapper — std::process::Command::new(<binary>), Stdio::inherit, tempfile cleanup. The agent name here means “binary on $PATH” (codex, aider, …).

Keeping the two tables in sibling modules at the crate root preserves both concerns at one substrate level without conflating them into the HTTP client module. The CLI-binary-name detection logic that PICKS a WrapStrategy stays in crate::cli::wrap (it’s CLI-specific); only the per-vendor TABLE lives here.

Enums

WrapStrategy

Strategy for delivering the assembled system message to the wrapped agent. Each variant maps to a distinct CLI ABI an agent might expose.

Functions

default_strategy

Built-in agent → strategy lookup. The list is small by design — we only encode strategies for agents we’ve actually verified. Anything not in the table falls through to --system <msg> because that’s the most common contract across OpenAI-compatible CLIs.