[JacobStephens2]

Summary

Setup's first questions now choose the Harness, then the Model and Effort for it.

 questions::ask
+  ask_harness
+    Harness? claude or codex (not supported yet) [claude]
+      refuse unknown / not installed / not supported yet → ask again
+    Model for claude [claude's own default]      (- clears a current one)
+    Effort for claude [claude's own default]
+    Choice::test_call  (the Run's check)  → refused: show Claude's error, ask Model and Effort again
   Every Run a Merge run? …

• Harness::unavailable() is the one place that says why sessions can't run on a Harness (not supported yet, not installed). Choice::check and Setup both use it.
• DEFAULTS gains [harness], [harness.claude] and [harness.codex] with every key. complete now recurses into subsections, so an existing User config keeps its values and comments and gains the keys it lacks. That includes dotted, inline and header-less [harness] forms.
• With no terminal, Setup writes default = "claude" and blank Models and Efforts.

Evidence

• Before: setup on a terminal asked nothing about the Harness and wrote no [harness] sections.
• After: new tests in tests/setup.rs pass:
  • the Harness question lists both Harnesses, marks codex and defaults to claude
  • codex and an unknown name are refused and asked again
  • with claude not on PATH, the harness settings are left as they were
  • the Model and Effort answers are written after a test call with them
  • the current values are the defaults, and - clears one
  • a Model Claude refuses is asked again, with Claude's error shown
• completing_adds_each_harness_key_a_user_config_lacks (unit) passes, and the existing Setup and Setup-offer tests pass with the new questions.
• Full cargo test, cargo clippy --all-targets and cargo fmt --check are clean.

Merge Danger

Door: two-way

Blast Radius: Setup

Every terminal Setup, including the first Run's offer, now asks three more questions first. Rerunning Setup over an existing User config adds the [harness] sections. harness.default = "claude" means a Run's failure messages name the User config, not the default, as what chose the Harness. Sessions run the same either way.

Unaddressed findings

Standards

• Duplicated refusal wording and repeated match on Unavailable (Choice::check and ask_harness): skipped. The condition is already shared through Harness::unavailable(). The sentences differ on purpose: a Run names the setting that chose the Harness and what to change, while Setup only says why it refuses.
• Option<(Harness, ModelAndEffort)> tuple instead of a named type: skipped. It is used in three nearby places, and a new type would add more than it explains.
• chosen_by: ChosenBy::UserConfig in Setup's test call: skipped. test_call never reads chosen_by, and Setup is choosing what the User config will say.
• Hard-coded model/effort key list in with_answers, and the README copy of DEFAULTS (Shotgun Surgery): skipped. Each has two keys and matches the existing style of the email settings.

Spec

• A blank answer keeps a current Model or Effort, and - clears it: kept. The spec asks for both "the current value as its default answer" and "a blank answer means the Harness's own default", which conflict when a value is set. With no current value, a blank answer does mean the Harness's own default. - is documented in the README.
• With no Harness sessions can run on (claude not installed, codex not supported yet), Setup lists both, says so, and asks nothing: kept. Asking would loop forever. Setup leaves the harness settings as they are, and a fresh file still says claude, the default.
• An Effort without a Model gets no test call: kept. This matches how a Run checks it, which the spec asks for.

Closes #393

🤖 Generated with Claude Code