[JacobStephens2]

Summary

Base fixes can be turned on per machine: base.fix in the User config, no-base-fix to forbid one for a Run, and a Setup question asked only when every Run is a Merge run.

 may this Run start a Base fix?
-  given base-fix                      -> yes
-  otherwise                           -> no
+  a child Run (Ticket's Run, Base fix)
+    given base-fix by what started it -> yes   # never reads base.fix itself
+    otherwise                         -> no
+  given base-fix                      -> yes
+  given no-base-fix                   -> no
+  given both                          -> argument error, exit 2, before any work
+  otherwise                           -> base.fix in the User config (default false)

 Setup's questions
   Every Run a Merge run?
+    yes -> Every Run may start a Base fix when the Base branch's CI is red?  (default: current base.fix)
+    no  -> not asked; base.fix written at its default, false
   Every Run first fast-forwards your checkout of the Base branch?
   Run notifications, an email as each Run ends?

 # the User config Setup writes
 [merge]
 always = false   # every Run is a Merge run, without the merge word; default false

+[base]
+fix = false      # every Run may start a Base fix, without the base-fix word; default false
+
 [launch]

A non-boolean base.fix stops the Run with base.fix must be true or false in the User config <path>, like merge.always. Help and the README name --no-base-fix and base.fix.

Seam under test: the binary, through tests/support::Scenario with the fake gh and fake claude (tests/user_config.rs, tests/command_surface.rs, tests/setup.rs, tests/setup_offer.rs, tests/spec_run.rs, tests/base_fix.rs), plus the existing UserConfig::parse unit table in src/config.rs.

One decision to check: from a terminal, answering no to "Every Run a Merge run?" writes base.fix = false even if the file had base.fix = true. That is the literal reading of "Otherwise it writes base.fix out at its default", and it keeps a user who just turned merging off from being left with Runs that still merge a Base fix into the Base branch. The cost: someone who hand-set base.fix = true with merge.always = false loses it on the next Setup from a terminal. Setup with no terminal asks nothing and keeps the value.

Evidence

• Before: each new test was run red first:

  base_fix_lets_a_run_without_the_base_fix_word_start_a_base_fix
    thirdshift: unknown section [base] in the User config …/config.toml
  no_base_fix_overrides_base_fix_for_one_run
    thirdshift: not a GitHub issue URL: no-base-fix
  on_a_terminal_with_merging_on_setup_asks_about_base_fixes_and_writes_the_answer
    the terminal never showed "Every Run may start a Base fix when the Base branch's CI is red?"
  help_lists_no_base_fix_and_base_fix_in_the_user_config
    help lacks "--no-base-fix"
  

  After: cargo test passes in full (26 test binaries, 0 failed), with cargo fmt --check and cargo clippy --all-targets -- -D warnings clean. New tests:

  user_config    base.fix = true starts a Base fix with no flag; no-base-fix / --no-base-fix override it;
                 unset or false fails on the Inherited failure; a bad base.fix names the key and the file;
                 base-fix with no-base-fix exits 2 before the config is read
  command_surface  base-fix with no-base-fix: "base-fix and no-base-fix can't be used together";
                 repeated no-base-fix; help lists --no-base-fix and base.fix
  setup          asks about Base fixes with merging on and writes the answer; asks nothing with merging
                 off and writes false; the question's default is the file's base.fix
  setup_offer    accepting the offer and allowing Base fixes lets that first Run start one
  spec_run       base.fix reaches a Ticket's Run; no-base-fix on the Spec wins over base.fix for Tickets
  base_fix       with base.fix = true, the Base fix's own Run still starts no Base fix
  

Unaddressed findings

Standards

• base.fix rejections asserted in both the src/config.rs unit table and tests/user_config.rs: kept, since every other key (merge.always, launch.pull, logs.dir, spec.parallel) is in both, and the issue asks for the test through the binary.
• RUN_OPENS_PR_WITH_INHERITED_FAILURE and BASE_FIX_OPENS_PR redeclared in tests/user_config.rs: kept, since each test file here declares its own agent scripts (AGENT_OPENS_PR is in four), and moving them to tests/support would be a refactor of files this change doesn't otherwise touch.
• child_run::start(…, base_fix: bool) carries a bool where BaseFixAsk now exists: not changed; the bool is BaseFix::may_start() from A Base fix, when the base-fix flag is given #222, threaded through spec_run, and this change no longer touches child_run.rs.
• Shotgun Surgery, one setting touching HELP, DEFAULTS, the parser and the README: the existing shape of every setting; reshaping it is out of scope.
• default_base_fix is a third bool-to-ask if/else beside default_goal and default_ask: kept for consistency with its neighbours, as the reviewer suggested.

Spec

• No test of the Spec PR's own Base fix allowed by base.fix: the Spec PR uses the same BaseFix value resolved once in main, already covered with the flag in with_base_fix_the_spec_prs_inherited_failure_gets_a_base_fix_into_the_base_branch and with the config for a plain Run.
• No assertion that declining the first Run's Setup offer writes base.fix = false: declining_writes_the_defaults_and_a_second_run_does_not_offer already compares that file with what setup with no terminal writes, which is asserted to hold base.fix = false.

Merge Danger

Door: two-way

A new, default-off setting and a new flag; reverting removes them. A User config that already holds [base] would then be refused by the older version as an unknown section.

Blast Radius: Setup

Every machine's next thirdshift setup adds [base] fix = false to its User config, and Setup from a terminal asks one more question when merging is on. Runs behave as before unless base.fix = true or no-base-fix is given.

Closes #223

🤖 Generated with Claude Code