[brettheap]

Lane: openreposhape-3 (openRepoShape-3)
Claim: #595 (comment)

Stacked on #587; lands after it. The base is l3-564-carry-to-main (#587's branch, head 25b2aeed), because #587 is what carries install.sh into main. GitHub retargets this PR to main when #587's branch is deleted.

What

Four commits, the last two from the review round below. The head is f03a192f.

• 3ca08528 and 274dc070, install.sh and its tests:

  • Step 3 uses uv where there is no pipx. It installs git-filter-repo==2.47.0 with pipx where pipx is there, as before. Otherwise it uses uv tool install git-filter-repo==2.47.0 where uv is there. It makes one attempt with one tool: a pipx that fails is not followed by the uv beside it. "Installed" means command -v git-filter-repo finds it afterwards. If the tool's directory is not on PATH yet, the line names that tool's own fix: pipx ensurepath or uv tool update-shell, then a new shell.

  • With neither tool, it prints one command and never runs it. The line holds the command alone, so it pastes and runs as printed:

    • brew install git-filter-repo where brew is there;
    • sudo apt-get install -y pipx && pipx install git-filter-repo==2.47.0 && pipx ensurepath, and the same with dnf;
    • sudo pacman -S --needed git-filter-repo: Arch's own package, version 2.47.0-3 in extra on 2026-10-15 (pacman cannot pin it);
    • with no package manager it knows, install uv (<uv's installation page>), then run: uv tool install git-filter-repo==2.47.0.

    The python3 -m pip install --user fallback is gone.

  • The run now ends with two readinesses. After the preflight it prints adoption: and then done:. adoption: says whether git-filter-repo is there. Where it is not, it says why and what to do first, with any command after run: at the end of the line or between backticks. done: says "this machine is ready" only when git-filter-repo is there. Otherwise it says "this machine is ready to scaffold, not yet to adopt".

  • The exit status does not change. It stays the preflight's and the pin's, because only adopting needs git-filter-repo.

  • The privilege boundary holds. install.sh still never runs sudo, and it never installs pipx, uv or a system package. The header, --help and the comments say so.

• 1a448059 and f03a192f, README.md and docs/handbook.html: step 3 said install.sh installs git-filter-repo "with pipx where it can". It now says pipx or uv, and that the run says last whether the machine is ready to adopt or only to scaffold.
  • README: the paragraph is re-wrapped within its own eight lines, so README stays at its 1449-line cap with no ledger entry.
  • Handbook: the masthead and start (step 3 and the consent rules) say the same.
  • Markers: the seven § Starting markers move to d55fef86. Each of the seven page parts was re-read, and the commit message says which parts changed text and which only moved their marker.

What the run ends with, per acceptance case

Every row is a case in tests/test_install_sh_filter_repo.py, with a preflight that passed and exit status 0. Each adoption: line is quoted from a run at f03a192f. Every NOT READY line begins adoption: NOT READY: adopt-project.py needs git-filter-repo, and …; the table shows the part after and.

case	step 3	adoption:	done: says
git-filter-repo on PATH, or git filter-repo answers (pipx and uv there, neither run)	already installed (…)	git-filter-repo is installed, which adopt-project.py needs beyond what the preflight checks.	this machine is ready
pipx only; uv only (Raven); pipx and uv (pipx used, uv not asked)	installing it with <tool>: … / installed with <tool>	installed (as above)	ready
pipx fails, with or without uv beside it	pipx could not install it (exit 1) …	… pipx could not install it (exit 1). Before adopting a repository, run: pipx install git-filter-repo==2.47.0	ready to scaffold, not yet to adopt
uv fails	uv could not install it (exit 2) …	… uv could not install it (exit 2). Before adopting a repository, run: uv tool install git-filter-repo==2.47.0	ready to scaffold, not yet to adopt
installed, not on PATH yet	installed with <tool>, into a directory that is not on PATH yet: …	… pipx installed it into a directory that is not on PATH yet. Before adopting a repository, run `pipx ensurepath`, then open a new shell (uv: uv tool update-shell)	ready to scaffold, not yet to adopt
neither tool, with brew, apt-get, dnf or pacman	there is neither pipx nor uv …; before adopting a repository, run: and the command	… it is not installed. Before adopting a repository, run: <that command>	ready to scaffold, not yet to adopt
neither tool, no package manager it knows	…; before adopting a repository, install uv (<page>), then run: and the command	… it is not installed. Before adopting a repository, install uv (https://docs.astral.sh/uv/getting-started/installation/), then run: uv tool install git-filter-repo==2.47.0	ready to scaffold, not yet to adopt

The other two outcomes keep their own done: lines and exit 1, with the adoption: line still above them:

• a preflight that did not pass;
• a command that does not stay on the release, whose line becomes "… and this machine is ready to scaffold, not yet to adopt, but the command does not stay on …".

Where adoption readiness is reported, and why only install.sh changes

• install.sh's final summary: new here.
• setup-project.py --preflight: has no git-filter-repo row, and not by oversight. Every branch has 0 matches for filter (main, install.sh and openRepoShape --install, carried into main from v1.0.1 (#577): the one line curl -fsSL https://github.com/opensoft/openRepoShape/releases/latest/download/install.sh | bash installs the newest release's command pinned to that release, installs git-filter-repo with pipx where it can, and ends with the preflight (#564) #587, The openreposhape package: openRepoShape and four tool commands, run from a clone of the standard at the stamped commit and checked against its digest; --install and install.sh refuse a symlinked target (#563) #590, Git Bash on Windows: run the launcher and install.sh tests under Git Bash in the Windows job, so the one-line install is tested there (follow-up to #564) #585). The launcher says why at openRepoShape:306: git-filter-repo is something "only adopt-project.py needs and --preflight therefore does not ask about". The preflight is section (1) of the scaffold, so a row there would make an adoption-only dependency a scaffold prerequisite. The issue's acceptance rules that out.
• shape-doctor.py's machine row: already says "git-filter-repo is not on PATH, which only adopt-project.py needs" (shape-doctor.py, check_machine). The row is n/a by status, so it never moves the verdict. tests/test_doctor_machine_row.py holds it with and without git-filter-repo. Unchanged.
• openRepoShape --install's machine: block lists git-filter-repo present/MISSING, and adopt-project.py execute refuses with FILTER_REPO_HINT. Both are unchanged.

Not changed here: possible follow-ups

• The preflight's own verdict. It still prints [ok] this machine is ready. (setup-project.py:1161-1163), and under install.sh that line sits above adoption: NOT READY. The preflight could say "ready to scaffold" instead. Changing it touches the scaffold's and the doctor's wording and tests, so it is not done here.
• adopt-project.py's FILTER_REPO_HINT leads with pip install git-filter-repo, and so do README § Adopting and the handbook's adopt section. That is the same externally-managed trap, met at the moment adoption refuses.
• The launcher's machine: block prints run: openRepoShape --preflight (offers what is missing; …) when only git-filter-repo is MISSING, but the preflight never offers git-filter-repo.

Why

Brett Heap's #595, from Raven (Omarchy / Arch Linux, uv, no pipx, no git-filter-repo).

1. The v1.0.1 installer installed and pinned the command.
2. It found no pipx, so it printed python3 -m pip install --user git-filter-repo==2.47.0, which Arch's externally managed Python refuses.
3. The preflight passed, and the run ended "this machine is ready".
4. Adoption could not proceed.

The issue asks for:

• uv alongside pipx, at the pin, verified on PATH, with actionable guidance;
• no pip --user;
• general readiness kept apart from adoption readiness, with the next command;
• nothing privileged installed silently.

Tests

• tests/test_install_sh_filter_repo.py (new, 18 tests). It reuses tests/test_install_sh.py's Net, pin and preflight call, and inherits its pytestmark, so one skip policy covers both files. Its one fake of its own is uv. Every case also puts logging fakes for sudo, python3, python, pip and pip3 on PATH, plus its own package manager.
  • The 15 acceptance cases above are each held to:
    • the installers they run, and nothing in sudo/pip/package managers run;
    • no pip install and no --user anywhere in the output;
    • the step-3 lines before the preflight;
    • the last two lines, adoption: then done:;
    • exit 0;
    • where there is a next step, its command copied off the adoption: line and pasted into bash, with every program it names a logging fake: the calls it makes, and no # in it.
  • Two more tests: a failed preflight with and without git-filter-repo (exit 1, adoption: still said).
  • One more test: a command that does not stay on the release, with git-filter-repo missing.
• tests/test_install_sh.py: only four hunks change, at base lines 466, 479, 490-494 and 513-516. They are the no-pipx and apt-get commands it expects, the docstring, and the line above those commands, now read up to "before adopting a repository, ". An untouched line stands between them and Git Bash on Windows: run the launcher and install.sh tests under Git Bash in the Windows job, so the one-line install is tested there (follow-up to #564) #585's hunks at 436 and 518.
• Local runs. All with a stub gh exiting 97 first on PATH, GH_TOKEN=bogus and an empty GH_CONFIG_DIR. Full suite and the macOS and Windows jobs not run locally.
  • test_install_sh.py, test_install_sh_filter_repo.py, test_readme_sections.py, test_repo_hygiene.py, test_setup_by_hand_commands.py, test_cli_reference.py, test_agents_md_codes.py, test_update_add_codes_documented.py, test_doctor_machine_row.py, test_openreposhape_command.py: 358 passed under bash 5.2.21.
  • Against install.sh and openRepoShape --install, carried into main from v1.0.1 (#577): the one line curl -fsSL https://github.com/opensoft/openRepoShape/releases/latest/download/install.sh | bash installs the newest release's command pinned to that release, installs git-filter-repo with pipx where it can, and ends with the preflight (#564) #587's own install.sh, all 18 new tests fail. Against the reviewed head 1a448059, 8 fail: every case whose next step changed.
  • shellcheck -s bash install.sh is clean.
• Real tools, sandboxed (every uv, pipx and XDG directory inside a scratch directory):
  • uv tool install git-filter-repo==2.47.0 (uv 0.12.18): into a bin directory not on PATH it exits 0 with a warning; run again it exits 0 ("already installed"); an unsatisfiable pin exits 1.
  • pipx ensurepath (pipx 1.17.12) exits 0 whether its directory is already on PATH, newly added, or added before.
• CRLF emulation. A throwaway plugin, never committed, made Path.write_text write \r\n.
  • On this base, test_install_sh.py's own Net.fake writes #!/bin/sh\r launchers, so the installer tests fail there: 26 of 45 existing, and all of the new ones. That trap is Git Bash on Windows: run the launcher and install.sh tests under Git Bash in the Windows job, so the one-line install is tested there (follow-up to #564) #585's to fix, and Git Bash on Windows: run the launcher and install.sh tests under Git Bash in the Windows job, so the one-line install is tested there (follow-up to #564) #585 does.
  • Merged with Git Bash on Windows: run the launcher and install.sh tests under Git Bash in the Windows job, so the one-line install is tested there (follow-up to #564) #585/tests: a tests-git-bash job runs the launcher's and install.sh's suites in Git for Windows' own bash, so README and the handbook say Git Bash runs the one-line install, tested in CI but for a typed yes, which it cannot take there (#585) #596 (3095a9c0), both installer files pass 63/63 plain and 63/63 under emulation.
  • The first round showed the plugin live: a file the test writes with write_text carried CRs, while the launchers bash executes are written as bytes and carried none.
• Merges with the sibling PRs. In a throwaway clone:
  • tests: a tests-git-bash job runs the launcher's and install.sh's suites in Git for Windows' own bash, so README and the handbook say Git Bash runs the one-line install, tested in CI but for a typed yes, which it cannot take there (#585) #596 at 3095a9c0 (the review read 01e8c2c0) conflicts in more than the seven § Starting markers. README step 3 and the handbook's consent rule conflict in text too, because tests: a tests-git-bash job runs the launcher's and install.sh's suites in Git for Windows' own bash, so README and the handbook say Git Bash runs the one-line install, tested in CI but for a typed yes, which it cannot take there (#585) #596 adds a Git Bash sentence ("in Git Bash it can take none") to each.
    • Whichever PR lands second unions the sentences and recomputes the markers.
    • It may also need a README cap ledger line or a trim. Unioned, README is 1450 lines against the cap of 1449.
    • After the union and the recompute, the marker check reported no problems. The only hygiene failure was test_readme_is_short_enough_to_be_read.
  • The openreposhape package: openRepoShape and four tool commands, run from a clone of the standard at the stamped commit and checked against its digest; --install and install.sh refuse a symlinked target (#563) #590 at d090f0c5 merges with no conflict, and the two installer files pass 65/65 on the result.

Review (RV598) and fix round

RV598 found no MUST. Fixed in 274dc070 (install.sh and tests) and f03a192f (handbook):

• SHOULD 1: every printed next step pastes and runs as printed.

  • At 1a448059, uv's printed command ended # once uv is installed: <url>. An interactive zsh with default options passes that to uv as arguments, and uv exits 2.

  • The off-PATH adoption: line put pipx ensurepath, then open a new shell in the run: slot.

  • Now adoption_not_ready takes the caller's own instruction:

    • run: <the install> for a failed install;
    • run `pipx ensurepath`, then open a new shell (or uv tool update-shell) off PATH;
    • run: <the command> with a known package manager;
    • install uv (<page>), then run: uv tool install git-filter-repo==2.47.0 with none.

    Step 3's own line says the same before the indented command.

  • The new paste check fails on both old lines, fed to it verbatim: the off-PATH line on its argv, and the uv line on its # (bash itself reads it as a comment, which is why that assertion exists).

• SHOULD 2: one attempt, with one tool. The new case pipx_failing_uv_there holds that a failed pipx is not followed by the uv beside it.
• SHOULD 3: the tests: a tests-git-bash job runs the launcher's and install.sh's suites in Git for Windows' own bash, so README and the handbook say Git Bash runs the one-line install, tested in CI but for a typed yes, which it cannot take there (#585) #596 note above is corrected: text conflicts, a union, and a possible cap line.
• SHOULD 4: the preflight's own "this machine is ready" line is listed as a possible follow-up above, and is not changed here.
• Nits:
  • pacman now prints Arch's own git-filter-repo package, checked to exist in extra (2.47.0-3) via archlinux.org's package search JSON; it is not pinned.
  • apt-get and dnf end in && pipx ensurepath.
  • The fake uv exits 2 in uv_failing, so (exit $status) is the tool's own.
  • The test file no longer ends in a blank line.
  • "itself" is back in the handbook's step 3 ("install.sh itself never runs sudo"), on its own line at 100 columns. It is not back in README: at the paragraph's 80-column wrap it costs a ninth line, and README is at its cap.
• Not run: bash 3.2. No bash 3.2 binary was on this workstation. I fetched bash-3.2.57's source and verified its GNU signature (Chet Ramey's key), but it does not build here: there is no yacc or bison, and the shipped y.tab.c predates the patched parse.y. The new code uses only local, shift 2, "$@" || status=$?, case and [ ], and "$@" always has arguments where it is used. The macOS job is the check.

Merge of #587's squash and main

#587 landed on main as 22eaceed, its branch (this PR's old base) was deleted, and GitHub retargeted this PR to main. The stacking note at the top is history. The head is now eda2654e, three merge commits on f03a192f, pushed as a fast-forward:

• 09edc24 merges install.sh and openRepoShape --install, carried into main from v1.0.1 (#577): the one line curl -fsSL https://github.com/opensoft/openRepoShape/releases/latest/download/install.sh | bash installs the newest release's command pinned to that release, installs git-filter-repo with pipx where it can, and ends with the preflight (#564) #587's final head 3d8fa05e.
  • The one conflict was the seven § Starting markers in docs/handbook.html. Both sides changed that README segment: this PR's step 3, and install.sh and openRepoShape --install, carried into main from v1.0.1 (#577): the one line curl -fsSL https://github.com/opensoft/openRepoShape/releases/latest/download/install.sh | bash installs the newest release's command pinned to that release, installs git-filter-repo with pipx where it can, and ends with the preflight (#564) #587's macOS sentence (ci: run the test suite on Linux only #597) and Windows paste-quoting sentence (bump-leg.py and update-shape.py quote the paste lines that named a root or a path bare, the doctor's quote_arg quotes a leading = for zsh, and README says the printed commands are for a POSIX shell (#532) #588).
  • All seven move to the merged README's blob d1666fa6. § The three legs changed on install.sh and openRepoShape --install, carried into main from v1.0.1 (#577): the one line curl -fsSL https://github.com/opensoft/openRepoShape/releases/latest/download/install.sh | bash installs the newest release's command pinned to that release, installs git-filter-repo with pipx where it can, and ends with the preflight (#564) #587's side alone and already carried the merged blob.
  • Both sides' prose merged cleanly, and handbook_marker_problems reports nothing.
• a307230 merges main 22eaceed.
  • The merge base is 62ef256, from before install.sh, so four files conflicted: README.md and docs/handbook.html (content), and install.sh and tests/test_install_sh.py (add/add).
  • For each, main's blob was proved equal to 3d8fa05e's. This branch's side, that head plus this PR, was kept; main's side would have dropped the PR.
  • 22eaceed's tree equals merge-tree 2b6dbb78 3d8fa05e. It differs from 3d8fa05e only in adopt-project.py and tests/test_adopt_root_symlinks.py, which come in as main's blobs.
• 9ccc29f and eda2654e merge main 55faad26 and fbbbc8d0. No conflict, and none of this PR's files touched. Every file they change comes in as main's blob.

Against main, the PR is the same change as before. The patches to install.sh, both test files and README.md are identical. In docs/handbook.html only the seven § Starting marker values differ (d77a1e59 → d1666fa6).

Caps. README.md is 1449 lines, at its cap of 1422 + 5 + 22. AGENTS.md is 492, at its cap. Lane 5's #596 also edits README step 3's install.sh paragraph and the handbook. Keeping both texts costs a 1450th line, for whichever of the two lands second.

Predicted squash. git merge-tree --write-tree origin/main HEAD (main fbbbc8d0) is clean and gives 046fa02c, HEAD's own tree.

Tests at eda2654e, with a stub gh first on PATH, GH_TOKEN=bogus and an empty GH_CONFIG_DIR:

• 361 passed under bash 5.2.21:
  • test_install_sh.py 45, test_install_sh_filter_repo.py 18
  • test_openreposhape_command.py 66
  • test_repo_hygiene.py 65, test_readme_sections.py 76
  • test_readme_windows_quoting_sentence.py 3, test_setup_by_hand_commands.py 5
  • test_cli_reference.py 22, test_agents_md_codes.py 47, test_update_add_codes_documented.py 6
  • test_doctor_machine_row.py 8
• The two installer files pass 63/63 under bash 3.2.57, RV598's build, put first on PATH. A kept test directory shows its PATH's bash resolving to that build. This replaces the review section's "Not run: bash 3.2".

Closes #595

🤖 Generated with Claude Code

Summary by Sourcery

Introduce a release-pinned one-line installer that safely installs openRepoShape, reports separate scaffold and adoption readiness, and supports git-filter-repo through existing pipx or uv tooling without privileged fallback installations.

New Features:

• Add a release-pinned one-line installer that installs the command and records the release reference for subsequent runs.
• Add adoption readiness reporting for git-filter-repo, including pipx/uv support, platform-specific installation guidance, and separate scaffold/adoption outcomes.
• Add release documentation and notes covering the one-line installation, pinned behavior, and v1.0.1 release process.

Bug Fixes:

• Avoid the externally managed Python environment failure caused by the previous pip install --user fallback.
• Prevent installation from silently following main by verifying and preserving the installed release reference.

Enhancements:

• Expand bash entry-point validation and enforce HTTPS-only downloads for the installer.
• Update repository guidance and documentation to clarify consent boundaries, installation behavior, and release pinning.

CI:

• Extend macOS CI syntax checks to include install.sh.

Deployment:

• Document the release asset, tagging, and publication process for the pinned one-line installer.

Documentation:

• Update the README, CLI reference, handbook, agent guidance, and release notes for the release-pinned installer and adoption readiness.

Tests:

• Add comprehensive installer coverage for release discovery, pinning, failure handling, command validation, and idempotent upgrades.
• Add coverage for git-filter-repo installation paths, readiness summaries, actionable follow-up commands, and preserved exit statuses.
• Extend command and repository hygiene tests to cover recorded references, linked installations, release pinning, and install.sh.

[sourcery-ai]

Reviewer's Guide

The installer now uses an already-available pipx or uv to install pinned git-filter-repo without ever invoking pip --user or privileged installation, reports adoption readiness separately from scaffold preflight readiness, and adds comprehensive behavioral tests plus synchronized documentation.

Sequence diagram for install.sh dependency setup and readiness

sequenceDiagram
    participant User
    participant Install as install.sh
    participant Tool as pipx_or_uv
    participant Preflight as openRepoShape_preflight
    participant Path as PATH

    User->>Install: Run installer
    Install->>Path: Check git-filter-repo
    alt git-filter-repo already available
        Path-->>Install: Found
    else pipx available
        Install->>Tool: pipx install git-filter-repo==2.47.0
        Tool-->>Install: Success or failure
        Install->>Path: command -v git-filter-repo
        alt Not on PATH
            Install-->>User: Run pipx ensurepath, then open a new shell
        end
    else uv available and no pipx
        Install->>Tool: uv tool install git-filter-repo==2.47.0
        Tool-->>Install: Success or failure
        Install->>Path: command -v git-filter-repo
        alt Not on PATH
            Install-->>User: Run uv tool update-shell, then open a new shell
        end
    else Neither tool available
        Install-->>User: Print package-manager or uv tool install command
    end
    Install->>Preflight: Run --preflight
    Preflight-->>Install: Scaffold readiness and exit status
    Install-->>User: Print adoption readiness
    Install-->>User: Print done readiness

Loading

File-Level Changes

Change	Details	Files
Expand git-filter-repo installation to prefer existing pipx or uv while preserving the installer's non-privileged behavior and removing the pip --user fallback.	Retain pipx as the first-choice installer and use uv when pipx is unavailable. Detect successful installation by checking git-filter-repo on PATH, and report tool-specific PATH remediation when needed. Print, but never execute, actionable Homebrew, apt, dnf, pacman, or uv-based commands when neither installer is present. Keep the dependency pinned to git-filter-repo 2.47.0 and preserve the preflight/pin exit-status semantics.	install.sh tests/test_install_sh.py tests/test_install_sh_filter_repo.py
Add explicit adoption readiness reporting after the preflight without making the adoption-only dependency a scaffold prerequisite.	Track whether git-filter-repo is available and emit an adoption: line with either readiness or the next required command. Emit a done: line that distinguishes machines ready to adopt from those ready only to scaffold. Preserve separate failure messaging and exit codes for failed preflight or release pin validation. Cover existing, successful, failed, off-PATH, missing-installer, and failed-preflight scenarios with focused tests.	install.sh tests/test_install_sh_filter_repo.py
Synchronize user-facing installation documentation with uv support and the two readiness outcomes.	Update README installation guidance to mention pipx or uv and adoption-versus-scaffolding readiness. Update handbook setup, masthead, and consent-rule text to describe the same behavior and privilege boundary. Refresh handbook section markers for the revised README content.	README.md docs/handbook.html

Possibly linked issues

• Installer: support uv for git-filter-repo and distinguish adoption readiness from general readiness #595: The PR adds uv installation, actionable PATH guidance, safe alternatives to pip --user, and separate adoption and scaffolding readiness summaries.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sourcery-ai]

Sorry @brettheap, you've used your own review budget of 250,000 diff characters for the last 7 days.

You can request another review in 1 day and 1 hour by commenting @sourcery-ai review. Upgrade to get a review now.