GeezerVison

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

GeezerVison is showing github.com — Fix stale Python bytecode after apply (#819) by mikolalysenko · Pull Request #1722 · SocketDev/socket-patch

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 25, 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 #819

Summary

Agent-mode apply and rollback now delete the CPython bytecode
(__pycache__/<stem>.<tag>[.opt-N].pyc) compiled from each .py
file they rewrite. After a same-size patch applied in the same second
as pip install, Python used to keep running the unpatched code while
apply reported success and VEX attested not_affected. Rollback had
the mirror problem: the patched code kept running. The next import
recompiles the bytecode from the source on disk.

Root cause

Apply and rollback both commit file contents through
apply_file_patch_at (stage + rename), and that path never touched
__pycache__. pip byte-compiles on install. A timestamp-validated
.pyc records only the source's mtime (in whole seconds) and its size,
so a same-size rewrite within that second leaves it valid.

Changes

patch/apply.rs: new remove_stale_bytecode, called right after the
rename in apply_file_patch_at, so it covers both apply and rollback
restores. Only regular files are deleted, never through a symlink. A
read-only __pycache__ is relaxed for the delete and then put back. A
delete that fails is reported as a new stale_bytecode_not_removed
run-level warning (apply and rollback warnings[] plus a stderr
line), documented in CLI_CONTRACT.md. Advisory notes are now mapped to
warning codes by marker (advisory_warning_codes), so rollback no
longer labels every note ownership_not_restored.
Upgrade path: when a file verifies AlreadyPatched (for example,
patched by an older release that left the stale .pyc), a re-run of
apply drops any bytecode no newer than the patched source, so
upgrading and re-running repairs the install. Bytecode compiled after
the patch is kept, so routine re-runs don't churn the cache.
Names must match <stem>.<tag>[.opt-N].pyc exactly, so the bytecode
of a dotted sibling module (mod.x.py) is kept. A sourceless
<stem>.pyc beside the source is left alone, because under Python 3
a package may ship one.
patch/rollback.rs: the helper used for deleted patch-added modules is
now this shared one, and it runs before the directory-pruning walk.
Before, a symlinked parent made it return before the bytecode cleanup.
Hosted and vendored modes are not affected (the wheel is compiled
from the patched source). The npm, pypi and gem wrappers only dispatch
to the binary, so they need no change.

Tests (red → green)

Issue / case	Test	Before fix	After
#819 apply, real CPython venv, same-second same-size patch	`e2e_pypi_bytecode::same_second_same_size_apply_and_rollback_change_imported_code`	FAILED (`import` printed `original` after apply)	ok
#819 rollback, same test, second half	same test	(unreached)	ok
#819 core write path	`apply::tests::test_apply_file_patch_py_removes_stale_bytecode`, `..._top_level_py_...`, `..._in_readonly_cache`	FAILED	ok
#819 rollback restore	`rollback::tests::test_rollback_modified_py_removes_stale_bytecode`	FAILED	ok
Upgrade re-run over an already-patched module	`apply::tests::test_apply_already_patched_py_removes_older_bytecode`	n/a (added with the review fix)	ok
Non-`.py` writes leave bytecode alone; exact name match	`test_apply_file_patch_non_py_keeps_bytecode`, `test_is_bytecode_of`	ok / n/a	ok

The e2e test makes the race deterministic: after each write it sets the
source's mtime back to the second the bytecode was compiled against,
which is exactly the on-disk state a same-second apply leaves.

Commands run locally (Linux):

cargo fmt --all -- --check: clean
cargo clippy --workspace --all-features -- -D warnings: clean
cargo test -p socket-patch-cli --all-features --test e2e_pypi_bytecode: red on df7d35c (tests only), green on the fix
cargo test --workspace --all-features --no-fail-fast: everything passes except 11 permission and write-failure tests (copy_tree relax loop, vlt_heal, poetry and requirements wire failures, repair cleanup, in_process_redirect write failures, 2 in e2e_bun_lockb). This sandbox runs as root, which bypasses chmod-based failure injection. I re-ran the 4 core-lib ones on an origin/main worktree and they fail identically there. CI runs unprivileged.

Review notes

I ran /code-review high and fixed the findings above (upgrade
re-run, silent failures, sourceless-.pyc deletion, dotted-stem
match, rollback ordering). Not changed, with reasons:

PYTHONPYCACHEPREFIX / sys.pycache_prefix: with these set,
bytecode lives in a mirror tree outside the package, whose location
depends on the interpreter's runtime config, which apply can't see.
That is rare, and out of scope here.
A concurrent interpreter recompiling the old source between the
rename and the delete: this needs a Python process importing the
module mid-apply. It's negligible next to the install-then-apply case
reported.
Rescanning __pycache__ once per patched .py: patches touch a
handful of files, so the cost is negligible.
Rollback of a file already at its original bytes: that rollback
writes nothing, so it doesn't clean up bytecode left by an older
release. Reinstalling, which normally follows a rollback, regenerates
the bytecode.
Test helper duplication (python_on_path, set_mtime): small, and
local to one test file.

https://claude.ai/code/session_01Bb9iRCn4pmjPCK4q37zC6Z

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 #819

3cf1c41

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

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 25, 2026

Agent-mode apply of a same-size PyPI patch in the same second as pip install leaves pip's __pycache__ bytecode valid, so Python keeps running the unpatched code while apply reports it patched #819

Closed

Claude (claude) added 4 commits

October 25, 2026 08:32


          Add failing tests for stale Python bytecode

df7d35c

A same-size patch applied in the same second pip compiled the
module leaves the timestamp .pyc valid, so Python keeps running the
unpatched code. Rollback has the mirror problem. These tests cover
the core write path and a real CPython venv end to end (#819).

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


          Drop stale Python bytecode when rewriting a .py

ee5e038

Agent-mode apply and rollback now delete the __pycache__ bytecode
(and a legacy sibling .pyc/.pyo) compiled from each .py file they
rewrite. Before, a same-size patch applied in the same second as
the install left the timestamp .pyc valid, so Python kept running
the unpatched code while apply reported success and VEX attested
not_affected. Rollback could keep the patched code running the
same way. Python recompiles the bytecode on the next import.

The helper rollback used for patch-added modules moves into the
shared write path so both use one rule (#819).

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


          Satisfy clippy in the bytecode helper

c1a3367

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


          Harden the stale bytecode cleanup

d379162

Address review findings on the #819 fix:
- A re-run of apply over a module an older release already
  patched now drops bytecode that predates the patched source,
  so upgrading and re-running apply repairs it.
- A .pyc that can't be deleted is reported as a warning instead
  of being ignored.
- Sourceless <stem>.pyc files beside the source are left alone:
  under Python 3 a package may ship them, and rollback could not
  bring them back.
- Only exact <stem>.<tag>[.opt-N].pyc names match, so a dotted
  sibling module's bytecode is kept.
- Rollback drops a deleted module's bytecode even when it can't
  prune the directories above it.

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

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 25, 2026

Swarm health manager log #1382

Open

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

October 25, 2026 09:13

Mikola Lysenko (mikolalysenko) commented Oct 25, 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 25, 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 25, 2026

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Labeled Ready for review by the burn-down agent.

Head: d37916269d
CI: 38/38 green (50 skipped), no main-wide failures
Bugbot: reviewed d379162, no findings; no open review threads
Mergeable, no CHANGELOG.md changes
Reviewer focus: the stale .pyc cleanup in crates/socket-patch-core/src/patch/apply.rs / rollback.rs and the new e2e_pypi_bytecode.rs test.

Slack announcement not sent this run (Slack send unavailable to the agent).

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) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Labeled Ready for review by the burn-down agent.

Head: d3791626
CI: 88/88 checks green (38 success, 50 skipped); mergeable, no conflicts
Bugbot: reviewed d3791626, no findings
Reviewer focus: crates/socket-patch-core/src/patch/apply.rs (new __pycache__ invalidation on rewrite) and the reordered rollback in rollback.rs; the out-of-scope cases (PYTHONPYCACHEPREFIX, concurrent recompiles) are listed in the description.
Slack announcement not sent this run (Slack send unavailable); the next run will retry.

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

October 25, 2026 10:56

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Final review brief

What it does. Agent-mode apply and rollback now delete the CPython __pycache__/<stem>.<tag>[.opt-N].pyc files of every .py they rewrite, so a same-size patch written in the same second as pip install no longer keeps the old bytecode running (#819). A re-run over an already-patched module also drops bytecode older than the patched source, which repairs installs patched by earlier releases.

Risk: low. The new code only deletes regular files matching the exact PEP 3147/488 name of the rewritten module inside its __pycache__ (never through symlinks; sourceless <stem>.pyc and dotted siblings are kept). Bytecode is a cache, so the worst case of an extra delete is a recompile on next import. Non-.py writes are untouched.

Look here

apply.rs:557: the hook in the shared write path (covers apply and rollback restores)
apply.rs:597-680: remove_stale_bytecode and the exact name matcher is_bytecode_of
apply.rs:1073-1088: upgrade-path cleanup for AlreadyPatched files
rollback.rs:500-506: bytecode cleanup moved ahead of the parent-dir pruning walk
e2e_pypi_bytecode.rs:146: real-venv red→green test

Verified

Read the full diff (3 files, +642/-46), the PR description and the agent-status block.
Ran cargo test -p socket-patch-core --lib -- bytecode is_bytecode_of locally: 7/7 pass.
CI on d37916269d: 38/38 green (50 skipped), ci-ok and clippy green. Bugbot reviewed d379162, no findings; no open review threads. Mergeable. CHANGELOG.md untouched.

Changes I made. None.

Open questions (non-blocking)

The description says a failed .pyc delete is "reported as a warning". It is put on ApplyResult.error with success: true, but the CLI apply path only turns notes carrying the ownership marker into warnings[] (apply.rs CLI:1366-1372), so on apply the note never reaches the user, and on rollback it would be labelled ownership_not_restored (rollback.rs CLI:2096-2106).`` The path is rare (the delete fails even after the cache dir is relaxed, which usually means apply could not have written the .py either). If you want it surfaced, a follow-up could add a `stale_bytecode_not_removed` warning code to CLI_CONTRACT.md.
With several already-patched files, only the last failed-delete note is kept, and the --force "all skipped" message overwrites it. This is cosmetic.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

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


          Report stale bytecode cleanup failures

a98b93d

A .pyc that apply or rollback could not delete was put on the
result as a note, but the CLI only surfaced ownership notes: apply
dropped it, and rollback labelled it ownership_not_restored. Map
each advisory note to its warning code by marker, so the failure
shows up as stale_bytecode_not_removed. Notes from several already
patched files are now all kept instead of only the last, and a
--force skip message no longer replaces them.

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

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

[agent] Re the final review brief's first open question: fixed in a98b93d. A failed .pyc delete now surfaces as its own stale_bytecode_not_removed warning in apply and rollback (warnings[] plus a stderr line), documented in CLI_CONTRACT.md. Rollback maps notes to codes by marker, so it no longer mislabels them ownership_not_restored. The second point is fixed in the same commit: notes from several already-patched files are all kept, and the --force skip message no longer overwrites them.

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) commented Oct 25, 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 25, 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) disabled auto-merge

October 25, 2026 11:49

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Final reviewer: I turned auto-merge off. The brief above covers d37916269d, and the head is now a98b93d267 ("Report stale bytecode cleanup failures", a code change in apply/rollback, not a merge from main). The next final-review run will review that commit and re-arm auto-merge if nothing blocks.

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) mentioned this pull request

Oct 25, 2026

CI performance dashboard #1182

Open

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Final review brief

What it does: When agent-mode apply or rollback rewrites a .py file, it now deletes that module's __pycache__/<stem>.<tag>[.opt-N].pyc. Before this, a same-size patch written in the same second as pip install left the old bytecode valid, so Python kept running unpatched code while apply reported success (#819). Re-running apply over an already-patched module also drops bytecode older than the patched source, which repairs installs patched by older releases.

Risk: low. It only deletes CPython cache files, which the next import rebuilds. Names must match exactly, so dotted sibling modules and sourceless <stem>.pyc files are kept. It never deletes through a symlink, and a delete that fails produces a warning, not an error. Hosted and vendored modes don't change.

Look here:

apply.rs:557: the hook after the rename, shared by apply and rollback restores
apply.rs:597 remove_stale_bytecode and apply.rs:665 is_bytecode_of (the name match)
apply.rs:1106: the upgrade-path cleanup on AlreadyPatched files (keeps bytecode newer than the source)
apply.rs:962 advisory_warning_codes and its use in cli rollback.rs:2101: the new stale_bytecode_not_removed warning, which also stops rollback labelling every note ownership_not_restored
core rollback.rs:504: the deleted-module cleanup now runs before the symlink-guarded prune walk

Verified: I read the full diff (6 files, +712/−67) and checked the name matcher's edge cases (mod.x, opt-N, .pyo, sourceless .pyc), the mtime cutoff on the upgrade path, the warning plumbing on every success exit, and the CLI_CONTRACT entry. CHANGELOG.md is untouched. Locally, cargo test -p socket-patch-core --lib bytecode passes 7/7. CI is green on a98b93d (37 passed, 19 skipped, ci-ok and clippy passed) and Cursor Bugbot passed. The e2e test uses a real CPython venv and is red without the fix, according to the PR body.

Changes I made: none.

Open questions: none blocking. The PR body lists PYTHONPYCACHEPREFIX trees and rollback of a file already at its original bytes as out of scope.

Auto-merge is armed: approving sends it straight to the merge queue.

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

October 25, 2026 12:56

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Copy link

Copy Markdown

Collaborator Author

Burn-down agent: Ready for review still holds at the new head a98b93d. The earlier label comment covered d379162.

CI: 56/56 checks on a98b93d passed or skipped (37 success, 19 skipped). No main-wide failures.
Bugbot: reviewed a98b93d, no new issues. No unresolved review threads.
Mergeable against main, no conflicts. CHANGELOG.md is untouched.
What changed since d379162: apply/rollback now report when the stale .pyc cleanup fails ("Report stale bytecode cleanup failures").
The Slack announcement wasn't sent: this run has no Slack send tool. The next run will retry.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

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

Tanmay Singla (Tanmay182003) approved these changes

Oct 26, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue

Oct 26, 2026

github-merge-queue Bot removed this pull request from the merge queue due to a conflict with the base branch

Oct 26, 2026


          Merge remote-tracking branch 'origin/main' into agent/fix-pypi-stale-…

…bytecode

# Conflicts:
#	crates/socket-patch-cli/CLI_CONTRACT.md

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

Oct 26, 2026


          Merge remote-tracking branch 'origin/main' into agent/fix-pypi-stale-…

8c7f1e8

…bytecode

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Copy link

Copy Markdown

Collaborator Author

bugbot run

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 26, 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/patch/rollback.rs Resolved

Uh oh!

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


          Report bytecode cleanup failures on rollback deletes

de736a0

Rolling back a patch-added .py file removed its stale bytecode but
dropped the warning when a .pyc could not be deleted. It now joins
the rollback result, so the CLI reports stale_bytecode_not_removed
just as it does for restored files.

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

Mikola Lysenko (mikolalysenko) commented Oct 26, 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 26, 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 de736a0. Configure here.}

Sorry, something went wrong.

Uh oh!

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

All reactions

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue

Oct 26, 2026

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Copy link

Copy Markdown

Collaborator Author

[final reviewer] Re-added to the merge queue at 16:49 UTC. Head de736a0 is approved, mergeable, ci-ok/clippy green, Bugbot clean, no open threads. The 16:01 removal had no failed merge_group run behind it; the branch was then merged with main and got the rollback-reporting fix.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

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

Merged via the queue into main with commit 77683cc

Oct 26, 2026

56 checks passed

Uh oh!

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

Mikola Lysenko (mikolalysenko) deleted the agent/fix-pypi-stale-bytecode branch

October 26, 2026 16:58

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

Oct 26, 2026


          Merge origin/main into fix/go-patch-delivery-e2e

e3eb1e0

Resolve conflicts with main's advisory-warning refactor (#1722) and the
global Go tool tests (#1717). apply.rs keeps main's advisory_warning_codes
loop (it covers ownership_not_restored too) and drops main's
nested_skip_warnings, because this branch already reports those skips
through run_warnings. e2e_golang_build.rs keeps both sides' new tests.

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

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 26, 2026

Fix Go patch delivery, audits, and reinstalls #1698

Merged

Reviewers

cursor[bot]

cursor[bot] left review comments

Tanmay Singla (Tanmay182003)

Tanmay182003 approved these changes

Uh oh!

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

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Agent-mode apply of a same-size PyPI patch in the same second as pip install leaves pip's __pycache__ bytecode valid, so Python keeps running the unpatched code while apply reports it patched

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 01402520 — 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 25, 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

Changes

Tests (red → green)

Review notes

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 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 25, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Final review brief

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 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 25, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Final review brief

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 25, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 26, 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!

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mikola Lysenko (mikolalysenko) commented Oct 25, 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.