Choose the Harness, Model and Effort on the command line and in the User config, with Claude #392

Parent

#136

What to build

A user chooses the Harness, Model and Effort a Command runs on, on the command line or in the User config, and every session in that Command uses them. Only Claude Code works in this Ticket; Codex sessions come in a later Ticket of #136.

• Flags. harness <name>, model <name> and effort <level> are word-and-value flags like base <branch>. They can be given on a Run, an Architect run (not with --plan-only) and a Pickup run, in any order among the other flags.

• User config:

  [harness]
  default = "claude"
  
  [harness.claude]
  model = ""
  effort = ""
  
  [harness.codex]
  model = ""
  effort = ""

  Unknown keys and wrong types are errors, as elsewhere in the User config.

• Choosing a value. For each of the three, the command wins, then the User config, then the default. The Harness default is claude. The Model and Effort defaults are nothing, which leaves them to the Harness. A Model or Effort is taken from the chosen Harness's own section, so harness claude with a Codex default uses [harness.claude]. A model or effort on the command applies to whichever Harness is chosen.

• Reach. The chosen values reach every session in the Command: the implement session, each Repair and Resume, the Spec review, the Architecture review, each Ticket's Run, and a Base fix. They're passed to child Runs with their other asks. Claude sessions get --model and --effort when those are set.

• Checks before work. These fail the Run where an Origin match failure would, before the Claim, the worktree and any Command log:

  • The chosen Harness's CLI must be on PATH. The failure names it and the setting that chose it (the flag or the User config key).
  • When a Claude Model is named, a minimal non-interactive test call to Claude with that Model and Effort must succeed. Claude's error is shown on failure. Names are passed through unchanged.
  • harness codex fails here with a clear "not supported yet" until the Codex session Ticket lands.
  • A Pass makes these checks only once it has decided not to skip. A Spec run makes them once, not once per Ticket.

• Recording.

  • The Command log's opening lines and the Activity log's start line name the Harness, Model and Effort, showing the Harness's default where none is set.
  • The pull request body gets one line that thirdshift writes, such as Built with claude · claude-opus-5-5 · high. That includes the Spec PR, after the Spec review rewrites its body.
  • The Run notification carries the same line.

Acceptance criteria

• harness, model and effort are accepted on a Run, an Architect run and a Pickup run, and rejected with --plan-only and when given twice or without a value.
• With no flag and no User config, sessions run on claude without --model or --effort, exactly as today.
• The fallback works as described: command, then User config for the chosen Harness, then default. That includes the case where harness claude on the command overrides a Codex default and picks up [harness.claude].
• Every session kind, and every child Run (Ticket Runs, a Base fix, a Run dispatched by an Architect run or a Pickup run), runs with the same Harness, Model and Effort.
• A Harness missing from PATH, or a Claude Model that the test call rejects, fails the Run with no Claim, no worktree and no Command log.
• No test call is made when no Model is named. A skipped Pass makes no checks. A Spec run makes the test call once.
• harness codex fails the checks before work with "not supported yet".
• The Command log, the Activity log start line, the PR body (the Spec PR included) and the Run notification each name the Harness, Model and Effort.
• Unknown keys or bad values under [harness] are User config errors.

Blocked by

None (can start immediately).