os-sdlc gate subprocess inherits the plugin's bundler env, so project tests cannot load their own gems #536

New issue

Open

opened 2026-09-08 18:35:57 +00:00 by jared · 0 comments

jared commented

2026-09-08 18:35:57 +00:00

Owner

Discovered in project hyperthrive-websites, ticket #37, in a git worktree at .claude/worktrees/ticket-37.

lib/os_sdlc/boot.rb (ADR-0166) sets ENV["BUNDLE_GEMFILE"] to the plugin's Gemfile and calls require "bundler/setup". Bundler exports BUNDLE_GEMFILE and RUBYOPT=-rbundler/setup into the process env.

lib/os_sdlc/runner/gate_evaluator.rb:22 runs the gate with Open3.capture3(command), which inherits that env. lib/os_sdlc/runner/gate_commands.rb:36 builds the diff-test step as plain ruby -I<test_path> -e ....

Result: the child ruby loads the plugin's gem set, not the project's. Observed error, identical across dispatches 7, 8, 9: cannot load such file -- webmock/minitest (LoadError) from migrator/test/test_helper.rb:6. The same command run by hand from the project dir passes: 19 runs, 43 assertions, 0 failures. The full project suite passes: 401 runs, 0 failures.

Consequence: the pipeline looped programmer-repair three times on a non-defect. The test-writer's gate accepted the LoadError as "red for the right reason", so the problem surfaced only at the programmer node. The operator had to abandon the pipeline and finish the ticket by hand.

Suggested fix (for the maintainer to judge): wrap the gate spawn in Bundler.with_unbundled_env { ... } and pass chdir: project_root; or build the command as bundle exec ruby ... when the project has a Gemfile. Also consider having the test-writer gate reject a LoadError as "red for the wrong reason".

Discoverer: hyperthrive-websites, session 74ec3fb6-e8b1-4a36-8f40-cd104339836b, 2026-09-08. os-sdlc pipeline loops on bundler env isolation issue

Discovered in project hyperthrive-websites, ticket #37, in a git worktree at .claude/worktrees/ticket-37. `lib/os_sdlc/boot.rb` (ADR-0166) sets `ENV["BUNDLE_GEMFILE"]` to the plugin's Gemfile and calls `require "bundler/setup"`. Bundler exports `BUNDLE_GEMFILE` and `RUBYOPT=-rbundler/setup` into the process env. `lib/os_sdlc/runner/gate_evaluator.rb:22` runs the gate with `Open3.capture3(command)`, which inherits that env. `lib/os_sdlc/runner/gate_commands.rb:36` builds the diff-test step as plain `ruby -I<test_path> -e ...`. Result: the child ruby loads the plugin's gem set, not the project's. Observed error, identical across dispatches 7, 8, 9: `cannot load such file -- webmock/minitest (LoadError)` from `migrator/test/test_helper.rb:6`. The same command run by hand from the project dir passes: `19 runs, 43 assertions, 0 failures`. The full project suite passes: `401 runs, 0 failures`. Consequence: the pipeline looped programmer-repair three times on a non-defect. The test-writer's gate accepted the LoadError as "red for the right reason", so the problem surfaced only at the programmer node. The operator had to abandon the pipeline and finish the ticket by hand. Suggested fix (for the maintainer to judge): wrap the gate spawn in `Bundler.with_unbundled_env { ... }` and pass `chdir: project_root`; or build the command as `bundle exec ruby ...` when the project has a Gemfile. Also consider having the test-writer gate reject a LoadError as "red for the wrong reason". -------- **Discoverer:** hyperthrive-websites, session 74ec3fb6-e8b1-4a36-8f40-cd104339836b, 2026-09-08. os-sdlc pipeline loops on bundler env isolation issue

jared added the

plugin/os-sdlc

filed-by/agent

labels

2026-09-08 18:35:57 +00:00

jared referenced this issue

2026-09-08 20:55:44 +00:00

Read-only guard rejects subagent-stop handoff with pipe chars; Runner records error #543