Allow configuring mach6 skill agent models via settings with TUI ranking

[maxscheurer]

Summary

Users who want to change the default models used by mach6 skill agents (e.g. code-reviewer, explore, feature-dev) currently must copy the entire agent .md file to ~/.dreb/agents/ and edit the model: field. This works, but means losing upstream updates to the agent's system prompt, tools list, and description when dreb is updated.

Current Behavior

• Agent definitions bundle model fallback lists in their .md frontmatter (e.g. model: zai/glm-5-turbo, anthropic/sonnet)
• The only way to override these is to place a same-named .md file in ~/.dreb/agents/ or .dreb/agents/, which replaces the entire agent definition — prompt, tools, and all
• The settings system (~/.dreb/agent/settings.json) has defaultProvider/defaultModel but no per-agent model overrides
• Upgrading dreb doesn't update locally-copied agent files, so users miss improvements to prompts and tool configurations

Proposed Behavior

Add a mach6 section in settings with per-agent model overrides:

{
  "mach6": {
    "models": {
      "code-reviewer": ["anthropic/opus", "anthropic/sonnet"],
      "explore": ["anthropic/sonnet"],
      "feature-dev": ["anthropic/opus", "anthropic/sonnet"],
      "independent-assessor": ["anthropic/opus"]
    }
  }
}

Resolution order: per-invocation model override → mach6.models setting → agent definition model field → parent model fallback.

TUI Experience

• A "Mach6 Models" section in /settings (clearly labeled as mach6-specific)
• Shows each mach6 agent with its current model ranking
• Selecting an agent opens a ranking editor where you can:
  • See available models (from the model registry)
  • Add/remove models from the fallback list
  • Reorder models via up/down keys to set priority (first = preferred, rest = fallbacks)
• Visual feedback showing the ranked list (e.g. 1. anthropic/opus 2. anthropic/sonnet)

Acceptance Criteria

• New mach6.models field in Settings interface — a Record<string, string | string[]> mapping agent names to ordered model fallback lists
• resolveModelForSubagentSpawn respects mach6.models overrides (after per-invocation, before agent definition)
• Global (~/.dreb/agent/settings.json) and project (.dreb/settings.json) levels both work, with project overriding global via existing deepMergeSettings
• TUI /settings has a "Mach6 Models" submenu with a ranking/reorder UI for each agent's fallback list
• Existing behavior unchanged when mach6.models is not set
• Documentation updated

Technical Notes

• Settings infrastructure already supports deep merge and TUI editing — settings-manager.ts, settings-selector.ts
• Model resolution lives in resolveModelForSubagentSpawn() in packages/coding-agent/src/tools/subagent.ts
• The TUI submenu pattern exists for "Thinking Level" and "Theme" — a ranked list editor is a new component but fits the existing pattern
• discoverAgentTypes() returns the full agent map — can filter to mach6-relevant agents for the settings UI
• The ranking UI could use arrow keys (up/down to reorder) similar to sortable list patterns — @dreb/tui may need a new RankedList or ReorderableList component
• Consider grouping agents by tier in the UI (e.g. "strong" agents like feature-dev/independent-assessor vs "standard" agents like explore/code-reviewer) to help users understand which ones benefit from stronger models

[maxscheurer]

Issue Assessment

Summary

Allow users to override which models mach6 skill agents use via a mach6.models settings key (both in settings.json and the TUI), without having to copy entire agent .md files. Includes a new TUI ranked-list component for intuitively ordering model fallback priorities.

Current State

• Agent discovery (discoverAgentTypes): 3-tier cascade — package → ~/.dreb/agents/ → .dreb/agents/. Later entries fully replace earlier ones by name.
• Model resolution (resolveModelForSubagentSpawn): per-invocation override → agent definition model field → parent model fallback. For arrays, each candidate gets a static registry check + live 1-token probe.
• Settings system: Settings interface with deepMergeSettings(global, project). No mach6 or per-agent model fields exist. Supports nested object merge (one level deep).
• TUI settings: SettingsList with inline cycling and SelectSubmenu for complex choices (Theme, Thinking Level). No reorderable/ranked list component exists in @dreb/tui.
• Workaround today: Copy the full agent .md to ~/.dreb/agents/ and change the model: line — but this freezes the entire prompt/tools definition, losing upstream updates.

Gaps

• No settings field for per-agent model overrides — the Settings interface needs a new mach6 section.
• No injection point in executeSingle — currently it reads modelOverride || config.model with no step to consult settings between them.
• No ranked list TUI component — @dreb/tui has SelectList (single select) and SettingsList (cycle/submenu), but nothing for reordering items. A new component is needed.
• No way to enumerate available models for the TUI picker — the model registry exists but there's no API to list all authenticated models for selection.

Ambiguities

• Scope of "mach6" agents: Which agents are "mach6"? All discovered agents, or only those used by mach6 skills? The skills use code-reviewer, completeness-checker, error-auditor, explore, feature-dev, independent-assessor, simplifier, test-reviewer — but explore and feature-dev are also used outside mach6 (e.g., the main subagent tool). Should the setting apply to all subagent invocations of that agent, or only when invoked from a mach6 skill?
• deepMerge behavior for mach6.models: The current deepMergeSettings does one-level shallow merge for nested objects. So project mach6.models would replace all keys from global mach6.models, not merge per-agent. Is that the desired behavior? (Probably yes — project should be able to fully control its agent models.)
• Ranked list UX: How should the "add model" flow work? Free-text input? Pick from authenticated models? Both? What about models the user hasn't configured auth for yet?
• Empty override: If a user sets "explore": [], should it fall through to the agent definition, or be treated as "no models available"?

Scope

Medium complexity, ~3 distinct work streams:

1. Settings + resolution (small-medium): Add mach6 field to Settings, wire it into executeSingle between modelOverride and config.model. ~50-100 lines of code changes in settings-manager.ts and subagent.ts.

2. TUI ranked list component (medium): New @dreb/tui component for reorderable lists with add/remove. Needs keyboard handling (up/down to navigate, modifier+up/down to reorder, Enter to add, Delete to remove), rendering with position indicators, and integration with SettingsList submenu pattern. ~200-300 lines.

3. TUI settings integration (small-medium): Wire the ranked list into settings-selector.ts as a new "Mach6 Models" section. Needs to enumerate discovered agents, show current model rankings, and persist changes. ~100-150 lines.

Risks

• deepMergeSettings is shallow for nested objects: { ...base.mach6, ...override.mach6 } means project-level mach6.models replaces the entire models map from global. This is probably fine but should be documented.
• Agent name coupling: The settings key agents by name (e.g., "code-reviewer"). If agent names change upstream, user overrides silently stop matching. Mitigation: at settings load time, validate mach6.models keys against discovered agent names and emit a warning (via TUI notification or startup log) for any keys that don't match a known agent. This makes stale entries visible without breaking anything.
• Probe cost: If a user configures a long fallback list (e.g., 5 models), each failing model incurs a 1-token API call with up to 120s timeout. This is existing behavior but becomes more visible when users can easily configure long lists. Consider documenting or capping the list length.
• TUI component complexity: A reorderable list is a non-trivial UI component. Key conflicts with existing keybindings (up/down for navigation vs reordering) need careful design. Recommend modifier key (Shift+up/down or Ctrl+up/down) for reordering.

Suggested Implementation Order

1. Settings interface + executeSingle injection (can be tested via JSON editing immediately)
2. Stale-key validation warning (safeguard against agent name changes)
3. TUI ranked list component in @dreb/tui
4. TUI settings integration + documentation

---

Automated assessment by mach6