v2.2.0

TaskManager+ v2.2 — Phase 7: Destructive MCP, BYO Ollama, DirectML Embeddings

v2.2 closes out Phase 7, the three-track expansion of the AI surface that started shipping in v2.0 and got its first follow-up in v2.1. Three independent additions, each opt-in:

1. Destructive MCP tools — end_process, recycle_files, empty_recycle_bin exposed to AI assistants with a two-phase dry-run/confirm pattern.
2. BYO Ollama backend — point TaskManager+ at your own local Ollama install instead of the bundled Qwen2.5-0.5B model.
3. DirectML embedding acceleration — run the file-search embedding model on the GPU through ONNX Runtime + DirectML.

Each is independently togglable; none of them changes anything for users who don't opt in.

Destructive MCP tools (Z1)

The MCP integration ships three new tools that actually do things instead of just reading. Default OFF — they don't show up in the AI's tool catalog until you flip the toggle in Settings.

• end_process — terminate a process by PID. Default dry_run=true returns the target's name + image path + window title for the AI to surface before commit; re-call with dry_run=false to actually kill. PID 0/4, the MCP sidecar itself, and critical Windows processes (csrss, wininit, services, lsass, winlogon, smss) are refused regardless of the flag.
• recycle_files — send paths to the Windows Recycle Bin (recoverable). Each path goes through the same path classifier the in-app Smart Organizer uses: drive roots, C:\Windows, Program Files are always refused; the profile root and well-known top folders (Documents, Downloads, …) are refused unless allow_unsafe=true. Default dry_run=true returns a per-path verdict preview.
• empty_recycle_bin — permanently empties the bin. Default confirm=false returns the current bin size as a dry-run preview. Pass confirm=true to actually empty.

Every destructive tool follows the same two-phase pattern: the AI calls once to see what would happen, surfaces it for human approval, then calls again to commit. The dry_run/confirm flags are for UX; the backend's hard refusals apply regardless of how the AI calls.

Flow: Settings → AI Assistant Integration (MCP) → Allow destructive actions (advanced) → flip the toggle → restart your MCP client. The sidecar reads the flag once at startup, so a running client won't see the new tools until it reconnects. The flag persists at %LOCALAPPDATA%\com.taskmanagerplus.app\mcp_config.json; any read or parse failure on that file defaults to off.

BYO Ollama backend (Z3)

For the generative model (Smart Rename, file/folder summaries, "what's in this folder?"), v2.2 adds a third backend alongside CPU and Vulkan: point TaskManager+ at a local Ollama instance and use any model you've pulled. Useful when you want something larger or more capable than 0.5 B parameters without us having to ship multiple bundled models.

The bundled model and the Vulkan accelerator are unchanged — Ollama is an alternative.

Flow: install Ollama → ollama pull llama3.2 (or whatever you want) → Settings → AI Writing Acceleration → pick "Use a local Ollama instance" → paste the model name → hit "Test connection" to verify reachability and see what's installed. The dispatcher does not silently fall back from Ollama to CPU when Ollama is unreachable — you explicitly picked Ollama, and a silent fallback would hide that your selected backend is broken.

Privacy: Ollama is the only path in the AI subsystem that opens a socket, and it only runs when the user has selected it and set a URL. Default URL is loopback (http://localhost:11434). Pointing at a LAN host or remote URL is allowed but the Settings card spells out that those prompts and the extracted file content go to that host.

See docs/OLLAMA.md for full setup, trade-offs vs the bundled model, and troubleshooting.

DirectML embedding acceleration (Z4)

The bge-small-en-v1.5 embedding model — used by "find files about X" intent search, folder clustering, the find_files_by_intent MCP tool, Smart Organizer's similar-files grouping — runs on CPU by default via tract. v2.2 adds an opt-in DirectML path through ONNX Runtime that runs the same model on the GPU. Meaningfully faster on big scans where tens of thousands of files get embedded.

The CPU path is unchanged; DirectML is a runtime swap, controlled separately from the generative LM's GPU acceleration (each has its own Settings card).

Flow: Settings → AI Search Acceleration (GPU) → Download bundle (~35 MB; ORT 1.22 + DirectML 1.15 from Microsoft's official NuGets) → flip the radio to DirectML → restart the app. Bundle lands at <app local data>/onnx_dml/ containing onnxruntime.dll (~16 MB) and DirectML.dll (~18 MB). Requires DirectX 12-capable hardware (basically any GPU built since 2015).

If DirectML init fails (missing DLLs, unsupported GPU, driver hiccup), the dispatcher permanently routes to CPU for the rest of the process and the "Running on" label reflects it. No silent lie about what just ran.

See docs/EMBEDDING_GPU.md for architecture, when it helps, troubleshooting.

Privacy summary

Unchanged baseline. Bundled CPU + Vulkan + DirectML paths all run 100 % on-device with zero network calls. The Ollama backend is the one exception — explicit user opt-in, loopback by default, documented next to the URL field. Destructive MCP tools don't move the privacy boundary; they let the AI act locally with the human still in the loop via dry_run.

Notes

• The genlm dispatcher and embeddings dispatcher are now structurally parallel: preference static + sticky active backend + per-call routing through a pick_* function. Future backends (CUDA, Metal, etc.) plug into the same shape.
• ort (the new ONNX Runtime crate) is added with load-dynamic so the installer doesn't gain ~15 MB from statically-linked runtime. Users who never enable DirectML pay zero size cost.

---

Full Changelog: v2.1.0...v2.2.0