GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — Fix gem modes wiring a manifest Bundler ignores (#341, #390) by mikolalysenko · Pull Request #431 · SocketDev/socket-patch

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

LLM Description written by Claude Code:claude-opus-5-5

Fixes #341
Fixes #390

Summary

Gem hosted and vendored modes now wire only the manifest Bundler actually loads. Before this change, both modes could edit a Gemfile that Bundler ignores, report success, and let VEX attest a gem that was installed unpatched.

Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341 (vendored, gems.rb twin). Vendoring always wired Gemfile / Gemfile.lock, even with a gems.rb / gems.locked pair next to them. Bundler ≥ 2 loads that pair instead. Vendoring now refuses before any write, with gemfile_not_loaded. The refusal applies on every Bundler version: Bundler 1.x still reads the Gemfile first (the 1.17.3 CI leg showed this), and vendor can't tell which Bundler will run the install.
- The hosted→vendored takeover runs the same check before it reverts a live hosted pin, the same way the yarn-berry preflight works. A hosted gems.rb project that someone then vendors keeps its hosted wiring. Without the early check it would be left unpatched in both modes.
Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 (BUNDLE_GEMFILE). Set in the environment or in .bundle/config (bundle config set --local gemfile Gemfile.next, the dual-boot layout), it picks Bundler's manifest. Nothing in socket-patch read it.
- Hosted: the candidate file set now holds only the pair Bundler loads. A BUNDLE_GEMFILE that names the project's own Gemfile or gems.rb selects that pair, even when the other spelling is present. Any other value (for example Gemfile.next, or a file in another directory) redirects no gem and reports redirect_gem_bundle_gemfile_unsupported. The in-run VEX then attests nothing.
- Vendored: refused with gemfile_not_loaded, as above.
- The refusal names the right remedy for where the setting came from: unset the env var, or run bundle config unset --local gemfile.
- The setup half of Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390 no longer applies: v5 prerelease: scan → vex → vendor workflow, hosted by default #277 removed setup.

Root cause

Nothing answered "which manifest does Bundler load?" in one place. The hosted rewriter chose gems.rb or Gemfile by filename alone, and the vendored backend hardcoded Gemfile. Neither read BUNDLE_GEMFILE. Both issues come from that one missing decision, so one shared resolver fixes both:

formats::gem::manifest::classify holds the logic, with no I/O (the formats architecture test enforces this).
crawlers::ruby_crawler::bundler_loaded_manifest does the environment and app-config reads, next to the existing BUNDLE_PATH config reader.

It follows Bundler's order:

BUNDLE_GEMFILE from the environment.
BUNDLE_GEMFILE: in $BUNDLE_APP_CONFIG/config, else in .bundle/config.
Default discovery.

A relative value from either source is read against the project root, because that is where bundle runs. The user-level ~/.bundle/config is not consulted; the module docs note this as a known limit.

A configured manifest other than Gemfile / gems.rb is refused rather than supported. Hosted rollback, VEX discovery and the lock readers only know the two default lock names (BUNDLER_LOCKS). So a redirect written into Gemfile.next.lock could never be found again to roll back or attest.

Test evidence

Issue	Case	Test	Red without fix	Green
#341	vendored: `gems.rb` twin is refused before any write	`vendor::gem::tests::gems_rb_twin_is_refused_before_any_write`	✅	✅
#341	real Bundler (premise follows the Bundler era): vendor refuses the twin, all four files untouched	`e2e_vendor_gem_build::gem_vendor_refuses_a_gems_rb_twin`	✅ (exit 0, applied 1)	✅
#341	real Bundler, CHECKSUMS-converged hosted `gems.rb` pin: `get --mode vendored` refuses before the takeover reverts it	`e2e_redirect_gem_build::gem_hosted_gems_rb_pin_survives_a_refused_vendored_takeover`	✅ (takeover ran first)	✅
#390	vendored: `.bundle/config` `BUNDLE_GEMFILE: Gemfile.next` refused	`vendor::gem::tests::bundle_gemfile_naming_another_manifest_is_refused`	✅	✅
#390	real Bundler dual boot: vendor refuses, all four files untouched	`e2e_vendor_gem_build::gem_vendor_refuses_a_bundle_gemfile_dual_boot`	✅	✅
#390	hosted engine: `Gemfile.next` redirects nothing and warns	`hosted::engine::tests::bundle_gemfile_naming_another_manifest_redirects_nothing`	✅	✅
#390	hosted engine: `BUNDLE_GEMFILE: Gemfile` beside `gems.rb` edits the Gemfile pair	`hosted::engine::tests::bundle_gemfile_naming_the_gemfile_redirects_it_over_gems_rb`	✅	✅
#390	real Bundler dual boot, `scan --mode hosted --vex`: nothing redirected or attested, files byte-untouched	`e2e_redirect_gem_build::gem_hosted_bundle_gemfile_dual_boot_redirects_nothing`	✅ (`redirected: 1`, `vex.statements: 1`)	✅
#390 (Bugbot)	relative env value anchored at the project root, not the process cwd under `--cwd`	`formats::gem::manifest::tests::env_wins_over_config_and_is_anchored_at_the_project_root`	new	✅
#390 (Bugbot)	refusal remedy matches the knob (env vs `.bundle/config`)	`formats::gem::manifest::tests::unsupported_detail_names_the_knob_that_set_it`	new	✅
both	resolver order, env vs config, other directories, app-config read	`formats::gem::manifest::tests::*`, `crawlers::ruby_crawler::tests::loaded_manifest_reads_the_app_config_file`	new	✅
guard	no `BUNDLE_GEMFILE`: hosted still prefers `gems.rb`	`hosted::engine::tests::default_discovery_still_prefers_gems_rb`	guard	✅

Local runs on ffbe645, with the gem suites re-run on 522febb (Ruby 3.3.6, Bundler 4.0.17):

e2e_redirect_gem_build -- --ignored: 8 passed. e2e_vendor_gem_build -- --ignored: 5 passed. These are the full gem capstones, including the existing ones.
cargo test -p socket-patch-core --lib gem: 254 passed.
cargo test --workspace --all-features --no-fail-fast (ffbe645): 9,340 passed, 12 failed. All 12 are write-failure or permission tests that fail only because the sandbox runs as root (*_write_failure_*, *unremovable*, relax_loop_must_not_traverse_symlinked_root), the same set reported on the other agent PRs. None are in gem code, and CI runs them green.
cargo clippy --workspace --all-features -- -D warnings: clean.
cargo fmt: the touched files are formatted. main itself isn't fmt-clean, and CI runs no fmt gate.
node --test npm/socket-patch/bin/socket-patch.test.mjs: passed. The npm, PyPI and gem wrappers only dispatch, so they need no change.

Docs: docs/ecosystems.md (RubyGems row), CLI_CONTRACT.md (new additive warning code), and a Fixed entry in the CHANGELOG.

🤖 Generated with Claude Code

Note

Medium Risk
Changes which Ruby manifest/lock files are mutated and when VEX attests gems; incorrect behavior previously reported patched state while Bundler installed upstream bytes.

Overview
Gem hosted and vendored modes now target only the manifest Bundler actually loads, fixing false success and VEX attestation when an ignored Gemfile was edited (#341, #390).

A shared resolver (formats::gem::manifest::classify + bundler_loaded_manifest) mirrors Bundler’s order: BUNDLE_GEMFILE from the environment, then .bundle/config, then default discovery (gems.rb before Gemfile on Bundler ≥ 2). Hosted scan narrows redirect candidates to that pair; other configured manifests (e.g. Gemfile.next) redirect nothing and emit redirect_gem_bundle_gemfile_unsupported instead of redirect_gem_no_gemfile. Vendored vendor / takeover refuses with gemfile_not_loaded before any write (and before reverting a live hosted pin), including gems.rb twins and dual-boot layouts.

Docs (CLI_CONTRACT, ecosystems.md, CHANGELOG) and e2e/unit tests cover dual-boot hosted --vex, refused vendored takeover on hosted gems.rb, and real-Bundler vendor refusal paths.

^{Reviewed by Cursor Bugbot for commit a550b6f. Configure here.}

Generated by Claude Code

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions


          Start fix for #341, #390

47df632

Assisted-by: Claude Code:claude-opus-5-5

This was referenced Oct 1, 2026

Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it #341

Closed

Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) #390

Closed

Claude (claude) added 6 commits

October 1, 2026 06:36


          Refuse gem vendoring when Bundler loads gems.rb

cd44f10

Vendored gem mode always wired Gemfile and Gemfile.lock. When Bundler
loads a different manifest (a gems.rb twin, or BUNDLE_GEMFILE set in
the environment or in .bundle/config), vendor reported success while
Bundler installed the unpatched gem, and VEX then attested it.

Add one resolver for the manifest Bundler loads, following Bundler's
own order, and refuse vendoring before any write unless that manifest
is the Gemfile.

Refs #341, #390

Assisted-by: Claude Code:claude-opus-5-5


          Redirect only the gem manifest Bundler loads

6aca028

Hosted gem mode picked gems.rb or Gemfile by filename and ignored
BUNDLE_GEMFILE. With 'bundle config set --local gemfile Gemfile.next'
it rewrote Gemfile, reported success and attested the patch in the
in-run VEX, while Bundler kept installing the unpatched gem.

The hosted candidate files now hold only the pair Bundler loads. A
BUNDLE_GEMFILE naming the project's Gemfile or gems.rb selects that
pair; one naming any other file redirects no gem and reports
redirect_gem_bundle_gemfile_unsupported.

Refs #390

Assisted-by: Claude Code:claude-opus-5-5


          Test and document Bundler manifest selection

5499ee2

Real-Bundler e2e capstones for both issues. A hosted scan of a
dual-boot project (BUNDLE_GEMFILE: Gemfile.next in .bundle/config)
redirects and attests nothing. Vendor refuses a gems.rb twin and the
dual-boot layout, leaving every manifest and lock untouched. Docs,
CLI contract and CHANGELOG describe the new refusals.

Refs #341, #390

Assisted-by: Claude Code:claude-opus-5-5


          Refuse a gems.rb vendor before the hosted takeover

3e11f13

A hosted gems.rb project that is then vendored hit the hosted to
vendored takeover first: the takeover restored the upstream entry,
then vendoring refused gems.rb, leaving the gem unpatched in both
modes. The takeover now runs the gem manifest check first, like the
yarn berry preflight, so a refused gem keeps its hosted pin.

Refs #341

Assisted-by: Claude Code:claude-opus-5-5


          Explain the gems.rb twin refusal per Bundler era

f7dd00f

Bundler 1.x reads a Gemfile before gems.rb, while 2.x and later load
gems.rb, so the vendored refusal of a gems.rb twin no longer claims
that Bundler always loads gems.rb. The twin is still refused on every
version, because vendor cannot tell which Bundler will install. The
e2e premise now follows the host Bundler, which fixes the 1.17.3 leg.

Refs #341

Assisted-by: Claude Code:claude-opus-5-5


          Keep the Bundler manifest model free of I/O

ffbe645

The formats modules are pure by contract, and an architecture test
enforces that. Move the disk and environment reads for the manifest
Bundler loads into the ruby crawler, next to the BUNDLE_PATH config
reader. formats::gem::manifest keeps only the classification.

Refs #341, #390

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review

October 1, 2026 07:32

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

BugBot review

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 1, 2026

View reviewed changes

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Comment thread

crates/socket-patch-core/src/crawlers/ruby_crawler.rs Resolved

Uh oh!

There was an error while loading. Please reload this page.

Comment thread

crates/socket-patch-core/src/formats/gem/manifest.rs Resolved

Uh oh!

There was an error while loading. Please reload this page.


          Anchor BUNDLE_GEMFILE at the project root

522febb

A relative BUNDLE_GEMFILE was resolved against socket-patch's own
working directory, so a --cwd run classified BUNDLE_GEMFILE=Gemfile as
unsupported. Bundler expands the value in the directory bundle runs
in, which is the project. The refusal also always said to unset the
environment variable; for a .bundle/config setting it now gives the
matching 'bundle config unset --local gemfile' remedy.

Refs #390

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

BugBot review

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 1, 2026

View reviewed changes

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 1, 2026

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

[burn-down agent] Ready for review at 522febb3ab2e8460e730fc198a2a6db7bef932da.

CI: all checks green on the head (414 check runs: success or skipped, none failing). Up to date with main and mergeable.
Bugbot: reviewed 522febb with no new issues. Its two earlier findings on ffbe645 are fixed in 522febb and their threads are resolved: the relative BUNDLE_GEMFILE is now anchored at the project root, and the refusal remedy names the right knob.
Reviewer focus: the new shared resolver in crates/socket-patch-core/src/formats/gem/manifest.rs (gems.rb vs Gemfile precedence, env vs .bundle/config), and the new additive warning code in CLI_CONTRACT.md.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.


          Merge origin/main to resolve conflicts

9003ae8

Union the CHANGELOG Fixed entries from both sides.

Co-Authored-By: Claude <[email protected]>

Mikola Lysenko (mikolalysenko) removed the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 1, 2026

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

bugbot run

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 1, 2026

View reviewed changes

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions


          Merge origin/main into agent/fix-bundler-manifest-resolution

1ad573b

Keeps both CHANGELOG entries (gem manifest fix and the Poetry venv
fix from #330).

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L6i4cQ51yarBFnFs2b8HRx

Wenxin Jiang (Wenxin-Jiang) approved these changes

Oct 1, 2026

View reviewed changes


          Merge origin/main into agent/fix-bundler-manifest-resolution

a550b6f

Keeps both CHANGELOG entries (gem manifest fix and the npm non-registry
entry fix from #345).

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L6i4cQ51yarBFnFs2b8HRx

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

bugbot run

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot reviewed

Oct 1, 2026

View reviewed changes

cursor Bot left a comment

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit a550b6f. Configure here.}

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 1, 2026

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Copy link

Copy Markdown

Collaborator Author

Burn-down agent check: ready for review at a550b6f1.

CI: 97/97 non-skipped checks green on a550b6f (3 skipped)
Bugbot reviewed a550b6f and found no new issues. No review threads are open.
Reviewers: the last push was a merge of main to resolve a conflict; the fix itself didn't change since it was last reviewed.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) enabled auto-merge (squash)

October 1, 2026 16:48


          Merge origin/main into agent/fix-bundler-manifest-resolution

Keeps both new hosted-engine tests: the BUNDLE_GEMFILE cases from this
branch and the Pipfile presence test from #425.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01L6i4cQ51yarBFnFs2b8HRx

Mikola Lysenko (mikolalysenko) merged commit 9d718cf into main

Oct 1, 2026

66 checks passed

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) deleted the agent/fix-bundler-manifest-resolution branch

October 1, 2026 16:56

This was referenced Oct 1, 2026

Gem manifest resolution lets the BUNDLE_GEMFILE env var override .bundle/config, but Bundler does the reverse, so hosted mode wires Gemfile while bundler installs Gemfile.next unpatched and VEX attests it #507

Closed

Gem BUNDLE_GEMFILE check compares paths lexically, so a symlinked spelling of the project's own Gemfile (e.g. macOS /tmp/app/Gemfile) is refused, and vex / rollback reject the hosted patch Bundler is loading #896

Closed

Mikola Lysenko (mikolalysenko) pushed a commit that referenced this pull request

Oct 8, 2026


          Refuse every Gemfile + gems.rb twin instead of trusting BUNDLED WITH

d44c4fb

#751's fix picked a twin's pair from the locks' BUNDLED WITH: all 1.x
meant the Gemfile pair, otherwise gems.rb. But BUNDLED WITH records
which bundler wrote a lock, not which one installs it. Bundler chooses
the twin's spelling from the running major: 1.x loads the Gemfile,
>= 2 loads gems.rb. So bundler >= 2 installing a 1.x-stamped twin, or
1.x installing a 2.x-stamped one, read the pair the scan never pinned,
while the run (and its VEX) reported the gem redirected. Lock inventory
and VEX discovery used the same selector.

Nothing a scan can read says which bundler runs, so a twin under
default discovery is now refused everywhere, the way vendored mode
already refuses it:
- hosted mode: redirect_gem_twin_manifest_ambiguous (replaces the
  unreleased redirect_gem_twin_bundler_versions_diverge), nothing
  written or attested;
- lock readers (lock inventory, VEX discovery): no lock, with the
  gem_lock_unsupported diagnosis.
BUNDLE_GEMFILE naming either spelling still selects that pair, and a
lone Gemfile or gems.rb pair is unchanged. The BUNDLED WITH parser
this PR added is gone.

Tests: the engine, lock-inventory and hosted_memory_engine twin tests
now expect the refusal for 1.x, 2.x and mixed stamps. #431's
default_discovery_still_prefers_gems_rb now covers a lone gems.rb. The
real-Bundler e2e (gem_hosted_twin_redirects_nothing) runs on every
bundler line and checks the untouched twin still installs frozen.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_018ULgrJMQMWEBAsiuprY449

Reviewers

cursor[bot]

cursor[bot] left review comments

Wenxin Jiang (Wenxin-Jiang)

Wenxin-Jiang approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

Ready for review

Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Gem hosted redirect and setup ignore BUNDLE_GEMFILE from .bundle/config, so they wire Gemfile while bundler loads the configured manifest unpatched (VEX and setup --check still pass) Vendored gem mode wires Gemfile when gems.rb is also present, so bundler installs the unpatched gem while vex attests it

Uh oh!

There was an error while loading. Please reload this page.

3 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.

GeezerVison

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

LLM Description written by Claude Code:claude-opus-5-5

Summary

Root cause

Test evidence

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mikola Lysenko (mikolalysenko) commented Oct 1, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.