os-sdlc gates fail on a project with a stale .rubocop.yml and on git-pinned gems #1475

New issue

Open

opened 2026-10-29 18:21:06 +00:00 by jared · 1 comment

jared commented

2026-10-29 18:21:06 +00:00

Owner

Problem

os-sdlc gates fail on a project that has a stale .rubocop.yml.
os-sdlc gates also fail on a project that pins a gem to a git source.
In both cases the pipeline stops, and the agent that hits the failure cannot fix it.

Approach

Evidence from decision-model implementation 5.

The test-lint gate failed three test-writer rounds with cannot load such file -- .../lib/os_sdlc/cops/module_owns_instance_state.rb.
The project's copied .rubocop.yml used flat cop paths.
Those paths moved to os_sdlc_cops_loader.rb.
The test-writer cannot edit that file.
The bound ran out (escalation 3).
The diff-test gate runs plain ruby without bundler.
A git-pinned gem (llm-stack) raised LoadError.
The programmer worked around it with RUBYLIB.

Required work:

implementation-open checks that the project's rubocop config loads, before the first dispatch.
Run the gates under bundle exec when a Gemfile exists.

Acceptance criteria

Given a project whose .rubocop.yml requires a cop path that does not exist, when implementation-open runs, then it refuses with a message that names the path.
Given a project with a Gemfile that pins a gem to a git source, when the diff-test gate runs, then the gem loads without RUBYLIB.

Non-goals

Auto-repair of the project's .rubocop.yml.

Discoverer: jared/decision-model, session 4dc4e6fe-637f-4ccb-bed0-958ba608ffe3, 2026-10-29. Found in decision-model implementation 5 (decision-model#11).

## Problem os-sdlc gates fail on a project that has a stale `.rubocop.yml`. os-sdlc gates also fail on a project that pins a gem to a git source. In both cases the pipeline stops, and the agent that hits the failure cannot fix it. ## Approach Evidence from decision-model implementation 5. 1. The `test-lint` gate failed three test-writer rounds with `cannot load such file -- .../lib/os_sdlc/cops/module_owns_instance_state.rb`. The project's copied `.rubocop.yml` used flat cop paths. Those paths moved to `os_sdlc_cops_loader.rb`. The test-writer cannot edit that file. The bound ran out (escalation 3). 2. The `diff-test` gate runs plain `ruby` without bundler. A git-pinned gem (llm-stack) raised `LoadError`. The programmer worked around it with `RUBYLIB`. Required work: 1. `implementation-open` checks that the project's rubocop config loads, before the first dispatch. 2. Run the gates under `bundle exec` when a Gemfile exists. ## Acceptance criteria 1. Given a project whose `.rubocop.yml` requires a cop path that does not exist, when implementation-open runs, then it refuses with a message that names the path. 2. Given a project with a Gemfile that pins a gem to a git source, when the `diff-test` gate runs, then the gem loads without `RUBYLIB`. ## Non-goals Auto-repair of the project's `.rubocop.yml`. -------- **Discoverer:** jared/decision-model, session 4dc4e6fe-637f-4ccb-bed0-958ba608ffe3, 2026-10-29. Found in decision-model implementation 5 (decision-model#11).

jared commented

2026-11-09 17:46:38 +00:00

Author

Owner

Occurrence 2026-11-09, finance #47, implementation 5. The diff-test gate runs plain ruby -Itest without Bundler, so the git-sourced gem llm-stack (require "llm") raised LoadError. Under bundle exec the 4 new tests pass. The programmer tried require "bundler/setup" in lib/finance.rb. That failed with a Gem::LoadError because plain ruby had already activated newer gems (addressable, bigdecimal 4.1.3 vs locked 3.3.1). The run escalated (escalation 4), and the orchestrator finished it by hand.

Discoverer: /home/jared/projects/finance, session 39593748-0e8a-4358-b2de-32566949edfd, 2026-11-09. Gate escalation on a ticket that adds a git gem.

Occurrence 2026-11-09, finance #47, implementation 5. The `diff-test` gate runs plain `ruby -Itest` without Bundler, so the git-sourced gem `llm-stack` (`require "llm"`) raised LoadError. Under `bundle exec` the 4 new tests pass. The programmer tried `require "bundler/setup"` in lib/finance.rb. That failed with a Gem::LoadError because plain ruby had already activated newer gems (addressable, bigdecimal 4.1.3 vs locked 3.3.1). The run escalated (escalation 4), and the orchestrator finished it by hand. -------- **Discoverer:** /home/jared/projects/finance, session 39593748-0e8a-4358-b2de-32566949edfd, 2026-11-09. Gate escalation on a ticket that adds a git gem.