SettingsFlow extension

Implementation members of AgentCli for the settings-hub flows. Named (not anonymous) so hosts and tests can drive the flows directly.

on

Properties

mcpManagerForTest → McpManager?

Available on AgentCli, provided by the SettingsFlow extension

The live MCP manager when one runs this session (the flow tests assert real reconnect behavior through it).
no setter

Methods

pickSettingForTest(String key) → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

runProviderModelFlow({required String title, bool openAiCompatibleOnly = false, String? mediaSlot, required Future<void> apply(ProviderModelChoice choice)}) → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

The two-level "provider → model" pick: step 1 picks the provider (saved custom entries first, then the catalog), step 2 fetches that endpoint's /models (openai-like endpoints; manual entry otherwise or when the list is empty), then apply receives the choice. Cancelling any step aborts silently. openAiCompatibleOnly restricts the provider list to the wire format the media tools speak. mediaSlot opts the model-list fetch into catalog seeding — pass the slot name (e.g. imageGeneration) when the user is picking a media model so the remote catalog's per-slot ids show up in the result even when /v1/models returns an empty list.
settingsHubItems() → List<MenuItem>

Available on AgentCli, provided by the SettingsFlow extension

The settings-hub rows: one entry per configurable area, each launching the same interactive flow its dedicated slash command would. Pure builder so tests can assert the hub carries every area without a TUI controller.
settingsHubItemsForTest() → List<MenuItem>

Available on AgentCli, provided by the SettingsFlow extension

settingsPickerHandlerKeysForTest() → Set<String>

Available on AgentCli, provided by the SettingsFlow extension

startAgentModelFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Agent models: pick the task role (Quick model / Subagents model), then provider → model through the shared two-level flow, and the role's chain is pinned — live on the resolver from the next spawn and persisted into the config's roles: section. A role can also be cleared back to the main model (the chain is dropped, the role inherits default).
startChatModelFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Chat model: provider → model, then switch the connection. Mirrors _switchToSavedProvider for saved entries (secure-store key resolution included) but applies the picked model instead of the entry's last-used one.
startCompactionEngineFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Compaction: pick the engine (classic | structured), pick the scope to persist in (session = live only), and apply. The yaml write is surgical (other sections survive byte-for-byte) and the edited file is validated with the REAL parser before it is written — the flow can never persist a file the next boot would reject. Cancelling either pick aborts silently.
startDapHubFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → DAP / Hub: view the live hub snapshot (url, agent name, connection state), set the hub url or the agent name (persisted through AgentCliConfig.onDapHubConfigChanged — the hub client's ~/.dap/config.json read-modify-write, so channels and invites survive), test the connection, or write the hub: false plugin opt-out into .fah/packages.yaml. Loops until the pick is cancelled or done.
startImagesFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Images: the images: config section (issue #395) — the registry kill switch (images.registry: false reproduces today's request shape byte-for-byte) and the per-request unique-image cap. Writes go through the surgical validated-yaml upsert into the USER config (the file bin/fah.dart boots the registry from), and every successful write re-publishes the process-wide imageRegistryConfig from the saved file — the request build consults that global, so the change lands on the next request build without a restart (AC3/E3: what's live is what's on disk). Loops until cancelled or done.
startLoadModeFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

The load-mode flow (issue #680): pick default / pi / omp, which upserts agent.mode (validated by validateAgentSection — a bad value writes NOTHING) and applies LIVE: the pick re-assigns the CLI's live preset and rebuilds availability, so the next request's schema+prompt reflect it without a restart. The live session keeps its boot-time mode if the pick is cancelled.
startMcpServersFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → MCP servers (issue #396): manage the mcp: section live — per-server status (connecting/connected/failed) with view-tools / reconnect / edit / remove (confirm), plus an add wizard (stdio command/args/env or remote url/transport/headers). Every action re-reads the section (a concurrent edit survives — E3) and is validated with the real McpConfig parser BEFORE the surgical write into ~/.fah/config.yaml (AC2/AC4). With a live manager the same section diff applies through McpManager.applyConfig — only the touched servers reconnect; without one the note defers to the next boot (AC3). Loops until cancelled or done.
startMediaSlotFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Media models: pick the slot, then provider → model, then pin the slot override (same persistence as /models set).
startMemoryStoresFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Memory: edit the long-term memory store locations (memory.projectPath / memory.userPath). The project path belongs in the project config, the user path in the user config (the same files the boot loader reads); writes are surgical and validated with the real MemoryConfig parser first. Applies live — the memory controller re-reads the section before every memory operation.
startPowerFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Power: the power: config section (sleep prevention, issues #325/#326) — the sleepPrevention level and the hold lifecycle. Writes go through the surgical validated-yaml upsert into the USER config, and every successful write re-arms the session's assertion from the saved file (_reloadPowerAssertions — what's live is what's on disk). Loops until cancelled or done.
startRedactionFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Redaction: the redact: yaml section as an interactive flow (issue #391) — quick toggles, the entropy knobs, the allowlist and per-tool policy lists, per-layer toggles and a stats reset. Writes go through the surgical validated-yaml upsert into the USER config (the machine-level file fa config set redact… also uses); with a live pipeline the saved section is reloaded from disk and installed on the spot, without one the note honestly defers to the next boot. Loops until the pick is cancelled or done.
startResilienceFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Resilience: the providerTimeouts: watchdog knobs and the retry: backoff policy as an interactive flow (issue #393). Writes go through the surgical validated-yaml upsert into the USER config; the saved timeouts are re-published onto the process-wide override the watchdogs read on every request, and the saved retry policy is installed on the roles resolver when one runs. Loops until the pick is cancelled or done.
startToolsFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Tools: pick a tool, flip it, choose the scope to persist in (project default). Loops until cancelled or done.
startTtsrRulesFlow() → Future<void>

Available on AgentCli, provided by the SettingsFlow extension

Settings → Stream rules (TTSR): list the ttsr: section's rules (pattern, scope, enabled?) with per-rule enable/disable and delete, plus an add-rule prompt (name, pattern, body, scope). The section is read fresh for every action (a concurrent edit survives — E3) and written back surgically into ~/.fah/config.yaml — the boot-real home of the section (project .fah/rules.yaml is a separate file; a ttsr: block in the project config is never read for TTSR). Every write is validated with the real TtsrConfig parser first (AC4). When the session booted a live rule engine, the same rule diff is applied to the running manager (rules are consulted per stream — no restart); otherwise the flow says the change lands at next boot (AC3). Loops until cancelled or done.