[FEAT] Add Ollama provider to config-wizard whitelist + downstream gaps in agentdb / aidefence

Summary

Three intersecting gaps where ruflo's downstream surface is fixed but the upstream agentic-flow / agentdb / aidefence packages still need follow-up. Filing as one issue so the integration story stays coherent — please split if upstream prefers.

---

Gap 1 — agentic-flow config-wizard hardcoded to 4 providers

Reproduces with agentic-flow@2.0.7 (downstream report ruflo#1725):

$ npx agentic-flow config set OLLAMA_API_KEY "$OLLAMA_API_KEY"
Error: Unknown configuration key: OLLAMA_API_KEY
Available keys: ANTHROPIC_API_KEY, OPENROUTER_API_KEY, GOOGLE_GEMINI_API_KEY, ...

$ npx agentic-flow config set PROVIDER ollama
Error: Available providers: anthropic, openrouter, gemini, onnx

Root cause — dist/cli/config-wizard.js:182 enforces a hardcoded provider enum.

Why it matters — Ollama Cloud is the documented Tier-2 provider in ruflo's ADR-026 3-tier routing (Tier-1 = WASM, Tier-2 = Ollama, Tier-3 = Anthropic). For users on Anthropic Max plans (which don't expose ANTHROPIC_API_KEY) plus Ollama Cloud subscriptions ($100/mo flat), Ollama is the only viable Tier-2 option. The downstream workflow_execute MCP tool is unusable for them until this lands.

Downstream workaround already shipped in ruflo 3.6.27 (commit):

• Added Ollama to providers.ts catalog (env var: OLLAMA_API_KEY)
• agent-execute-core.callAnthropicMessages falls back to Ollama OpenAI-compat (<OLLAMA_BASE_URL>/v1/chat/completions) when RUFLO_PROVIDER=ollama OR ANTHROPIC_API_KEY unset + OLLAMA_API_KEY set
• OLLAMA_BASE_URL lets users target self-hosted endpoints (validated end-to-end against a tailnet-hosted ollama 0.23.0 — 611ms round-trip on llama3.2:1b)

Upstream fix proposed:

1. Extend config-wizard.js's key allowlist to accept OLLAMA_API_KEY, OLLAMA_BASE_URL.
2. Extend the provider enum to accept 'ollama'.
3. Mirror the OpenAI-compat call site I shipped in ruflo/v3/@claude-flow/cli/src/mcp-tools/agent-execute-core.ts:callOllamaCompat() — drop-in adaptation, ~70 lines.

The downstream patch is non-breaking — old configs keep working — so this issue can take its time.

---

Gap 2 — agentdb v3 controllers should expose initialization hints

In ruflo 3.6.23/3.6.24 we manually activated 5 of the 6 disabled-by-default controllers via direct file:// URL imports:

• gnnService (no-arg construction — safe)
• rvfOptimizer (no-arg)
• mutationGuard (no-arg)
• attestationLog (needs a sqlite db handle — better-sqlite3)
• GuardedVectorBackend (wraps vectorBackend + mutationGuard + attestationLog)

The 6th — graphAdapter — needs an external graph DB connection and is still pending.

Upstream ask: expose a documented "construction prerequisites" map per controller in agentdb's public API surface, so downstream consumers don't have to read the dist source to know which controllers can default-activate. Today the activation knowledge lives in ruflo/v3/@claude-flow/cli/src/memory/memory-bridge.ts:180 as a hand-curated list — it would be a lot cleaner if agentdb shipped:

import { ControllerRegistry, controllerPrerequisites } from 'agentdb';
const safe = controllerPrerequisites.filter(c => c.requirements.length === 0);
// → ['gnnService', 'rvfOptimizer', 'mutationGuard', ...]

Less brittle than the path/import-by-URL trick we currently use to dodge agentdb's subpath exports field.

---

Gap 3 — aidefence should pair with file-mode + encryption-at-rest signals

Ruflo 3.6.25+ added three host-level hardening features that pair naturally with aidefence's threat scoring (per ADR-096):

1. validateEnv() loader-hijack denylist — LD_PRELOAD, LD_LIBRARY_PATH, LD_AUDIT, DYLD_*, NODE_OPTIONS, NODE_PATH are rejected at the terminal_create MCP boundary.
2. File mode 0600 / dir 0700 on session/terminal/memory stores via fs-secure.writeFileRestricted.
3. Opt-in encryption at rest (CLAUDE_FLOW_ENCRYPT_AT_REST=1) — AES-256-GCM with RFE1 magic-byte sniff for backward-compat migration.

Upstream ask: aidefence's threat scoring should consume these signals (when present) so a hardened host gets a lower threat score for the same input. Today aidefence treats the host as opaque — a host with validateEnv enforcing a denylist is materially less exposed than one without, but the threat report doesn't reflect that.

Concrete proposal: introduce a host_posture parameter on aidefence_scan / aidefence_analyze that aidefence factors into confidence weights. Downstream consumers (ruflo) populate it from ruflo doctor -c encryption + the validateEnv presence check.

---

Cross-references

• ruflo#1725 — downstream report of Gap 1
• ruflo ADR-095 — architectural gaps that produced the agentdb controller wiring
• ruflo ADR-096 — encryption-at-rest design + 4 implementation phases
• ruflo ADR-098 — plugin-side capability-sync pass that documented all three pairings

Happy to send PRs for any/all of these — easier with a thumbs-up on the scope first since #1 is structural and #2/#3 are API surface additions.

Start with dist/cli/config-wizard.js:182 and the downstream callOllamaCompat() reference in ruflo's agent-execute-core.ts, then review memory-bridge.ts:180-290 and ADR-096 for the other proposed API changes. The work is done when the Ollama configuration and provider path, agentdb controller prerequisites, and aidefence host_posture signals are implemented with appropriate upstream-facing behavior.