[brettheap]

Lane: openreposhape-1 (openRepoShape-1)
Claim: #524 (comment)

What

Two plans passed adopt-project.py check, and execute failed on them only after it had made and pushed both leg repositories. check now finds both, and execute refuses both before any leg repository exists. They are lines L1-K1 and L1-K10 of #457, filed as #524.

• L1-K1, a path the root keeps at the shape's own pin. This covers a file, a directory or a symlink the plan keeps in the root at contracts/shape-pin.yaml, with a pin declared or without. Each is now plan-root-holds-pin, adopt-project.py --pin <name> is accepted by plan, check and execute ("adoption verified"), but writes only the name into neutral_product_pins: and no contracts/<name>-pin.yaml, so the adopted root's own validate-pins.py (and its validate.yml) refuses with neutral-pin-missing from the first run #273's finding. Until now that finding asked only about each declared pin's file. As adopt-project.py --pin <name> is accepted by plan, check and execute ("adoption verified"), but writes only the name into neutral_product_pins: and no contracts/<name>-pin.yaml, so the adopted root's own validate-pins.py (and its validate.yml) refuses with neutral-pin-missing from the first run #273 does for a declared pin's file, it also asks once case is ignored, so a case twin such as contracts/Shape-Pin.yaml is found too. On Linux such a twin adopted and verified on bfed143; it is refused now on every system, as a declared pin's twin is. One link gives one finding from these two rules (an empty-target link is adopt-project.py check passes a source whose tree holds a symlink with an empty target, so with symlinks on execute creates both leg repositories and then fails cloning the source (on main with exit 2 and nothing on stderr, #171), and with core.symlinks=false it says adoption verified over a leg or root that no clone with symlinks on can check out #303's as well; see Known limits). A link there that leads nowhere used to be adopt-project.py: check follows each symlink the plan keeps where the shape writes its files, and execute refuses one the shape cannot write through, or one it writes beneath that git checks out as a file, before any leg exists, so such a link no longer breaks the run after both legs are pushed or has the shape's files written outside the assembly (#183, #178) #504's plan-root-symlink. It is now the kept-pin rule's, and the walk does not report it again.
• L1-K10, a --work-dir this user cannot write in. execute first makes a directory in the work directory and removes it again. It does this before it opens the source. If that fails, it refuses as adopt-work-dir-unwritable and names the directory. check --work-dir reports the same thing as a finding, next to the plan's own findings. Where an org/repo source would be cloned into that directory, check refuses it as execute does.

Why (repro on main)

Measured on main bfed143 (the v1.0.0 release commit). Each run used a local source, --local-remote-dir, and a stub gh first on PATH that nothing called.

case	check	execute	leg repositories made
contracts/ kept, contracts/shape-pin.yaml -> openglass-pin.yaml, --pin openGlass@<commit> (the issue's)	0, plan ok	1, FINDING adopt-shape-pin-unreadable	both
contracts/ kept, a file contracts/shape-pin.yaml, --pin	0, plan ok	1, adopt-shape-pin-unreadable	both
the same file, no pin	0, plan ok	1, adopt-shape-pin-unreadable	both
contracts/shape-pin.yaml -> README.md (a kept file), no pin	0, plan ok	1, adopt-shape-pin-unreadable	both
--work-dir with chmod 500	0, plan ok	2, REFUSED extracting the spec leg.	both
the same, with .github -> ci kept	0, plan ok	2, REFUSED extracting the spec leg.	both
control: neither	0, plan ok	0, adoption verified	both

On this branch (17dd55ca), every case above except the control gives check exit 1 with exactly one finding: plan-root-holds-pin for the first four rows, and adopt-work-dir-unwritable for the last two. execute exits 2 with the same line, and no leg repository exists. The control still adopts and verifies.

How

• _pin_files(plan) lists each declared pin's file, then the shape's own pin, in the order place writes them. _kept_pin_findings and _links_at_a_pin both read this one list. So the kept-pin rule and the walk's exclusion cannot disagree about which files are pins.
• Which code L1-K1 uses. It keeps adopt-project.py --pin <name> is accepted by plan, check and execute ("adoption verified"), but writes only the name into neutral_product_pins: and no contracts/<name>-pin.yaml, so the adopted root's own validate-pins.py (and its validate.yml) refuses with neutral-pin-missing from the first run #273's code, plan-root-holds-pin, its opening and its fix ("send contracts/ to a leg, drop it, or rename it in the source and re-run plan"). This is the same rule, extended to one more pin file. Only the middle of the sentence differs, because the two pins are read by different things. It names the shape's own pin (the openRepoShape commit the root's copies came from, and each copy's digest). It names what reads that pin there: execute's verification, the root's own validate-pins.py and make bootstrap. And it says what the split would hold: the source's file, directory or symlink at that path, with the shape's pin beside it under shape/. For a symlink it adds "or written through it where it leads nowhere".
• The order of the checks. _unwritable_work_dir(args, work_root) runs only when --work-dir is given. It calls tempfile.mkdtemp(dir=work_root) and then os.rmdir. On an OSError it returns a sentence that names the directory and the operating system's reason. Without --work-dir, _work_root makes a new directory that this user owns, and nothing is checked.
  • cmd_execute runs _refuse_an_unwritable_work_dir right after _work_root, before open_source. So it comes after only Plan.load and _refuse_a_mistyped_plan, which read the plan, and before open_source, _require_filter_repo, every other refusal and _create_leg_remotes.
  • cmd_check runs the same probe at the same point. It lists the result first among its findings. If the probe failed, it turns the OSError from making an org/repo source's clone directory there into a refusal with the same code and words.
• The new code. adopt-work-dir-unwritable sits next to adopt-work-dir-occupied. It has the same remediation shape: "no leg repository was created and nothing was pushed. Pass a --work-dir this user can write in, or none: without one, each run makes a new one."

Tests

New: tests/test_adopt_shape_pin_and_work_dir.py, 17 tests. Every one fails with adopt-project.py as on bfed143 (the revert table's last row: 17 of 17, with git filter-repo). The first 16 were written before the change and run on bfed143 itself: 16 failed with git filter-repo, and 15 failed and 1 skipped without it. The file imports its helpers and fixtures from tests/test_adopt_root_symlinks.py, including J4's unwritable_work, instead of copying them.

• L1-K1, a path kept at the shape's pin: a file, a case twin (contracts/Shape-Pin.yaml) and a directory of that name, each with a pin declared and without (6 tests). check prints exactly that one finding, and execute refuses with that line alone, before any leg exists.
• L1-K1, a symlink at the shape's pin (5 tests): to the pin's file that place writes first (the issue's case), to a kept file, leading nowhere with a pin and without, and a case twin leading nowhere. Each gives exactly one finding, plan-root-holds-pin, and no plan-root-symlink.
• The issue's run on the command line (1 test, needs git filter-repo): execute exits 2 with REFUSED plan-root-holds-pin, and no leg remote exists.
• L1-K10 (5 tests):
  • check --work-dir with no link and with .github -> ci. A writable directory passes and is left empty. An unwritable one gives the finding, word for word.
  • check --source acme/thing with an unwritable --work-dir refuses with adopt-work-dir-unwritable, where it ended in a PermissionError traceback. Nothing asks gh.
  • execute with no link and with .github -> ci, in process and on the command line. Each refuses with the same words before any leg exists.

Changed: three tests that used the source's own contracts/shape-pin.yaml kept in the root to make a verification fail after both legs. That plan is now refused before any leg exists, so each test needed another way to fail the verification:

• tests/test_adopt_late_failure.py::test_a_failed_verification_is_flushed_and_its_way_out_runs now fails it with a pre-commit hook that takes a pinned copy (scripts/validate-pins.py) out of the split commit. The hook comes from conftest.a_hook_that_unstages, through a global core.hooksPath, as the file's pre-receive hooks already come. The test's way-out half is unchanged: it re-runs without the hook.
• tests/test_adopt_github_exits.py does the same through github_run(failing=True), for test_a_failed_verification_outranks_a_refused_pull_request. Its control, test_the_same_source_verifies_when_gh_opens_the_pull_request, runs without the hook. Both stay WINDOWS_SKIP, as before.
• tests/test_adopt_ignored_shape_files.py::test_a_source_pin_kept_in_the_root_fails_verification_with_the_plan_answer keeps its source and all its assertions about adopt-project.py _commit_the_split stages with git add -A -- ., so a source .gitignore of .* silently drops .gitattributes and validate.yml from the split, execute still says adoption verified, and the assembly fails its first bootstrap #167's finding, but changes how it runs. It first asserts that check now exits 1 with plan-root-holds-pin. It then runs execute in process with the shape's pin left out of _pin_files, as before adopt-project.py check: refuse a kept file at the shape's pin path, and an unwritable --work-dir, before any leg exists #524, and the verification still reports the problem. This follows the file's own _stage_the_split test of adopt-project.py _commit_the_split stages with git add -A -- ., so a source .gitignore of .* silently drops .gitattributes and validate.yml from the split, execute still says adoption verified, and the assembly fails its first bootstrap #167.
• tests/test_adopt_root_symlinks.py: one docstring now says that plan-root-holds-pin answers the issue's link, where it said that the verification fails.

Runs at 17dd55ca. The head was clean (dirty 0) and every log ends EXIT=0. All runs used /usr/bin/python3 -m pytest with a stub gh first on PATH, a bogus GH_TOKEN and an empty GH_CONFIG_DIR. The stub logged no call. The file set has 70 files and 5,720 tests: every file that names adopt-project, adopt_project or conftest's ADOPT, every tests/test_adopt_*.py, tests/test_shape_doctor.py and tests/test_scaffold_leg_path_collisions.py. It ran in five chunks per mode.

mode	passed	skipped	failed
git filter-repo on PATH	5,707	13 (none of this PR's)	0
hidden (PATH=/usr/local/bin:/usr/bin:/bin, stub first)	5,393	327	0

In hidden mode, the only test of the new file that skipped is the one command-line execute run that needs git filter-repo.

Revert table. Each change was reverted alone in adopt-project.py, in a scratch checkout of 17dd55ca. Each row lists the tests that then fail, out of the 17 new tests and the 5 touched ones. Nothing fails with no change reverted (22 passed).

reverted	what that takes away	fails
C1: _kept_pin_findings asks about the shape's pin	the L1-K1 finding	13: the 6 kept-path tests, the 5 link tests, the command-line test, and the reworked test_adopt_ignored_shape_files test
C2: _links_at_a_pin names the shape's pin	one link, one finding	3: leading-nowhere, leading-nowhere-with-a-pin, a-case-twin-leading-nowhere (two findings each)
C3: check's adopt-work-dir-unwritable finding	check agreeing with execute	2: test_check_names_a_work_directory_it_cannot_write_in[no-link, a-link-above]
C4: execute's refusal	the L1-K10 refusal	2: test_execute_refuses_a_work_directory_it_cannot_write_in_before_any_leg[no-link, a-link-above] (both legs made)
C5: check's OSError from the clone becomes the refusal	no traceback in check	1: test_check_refuses_a_source_it_would_clone_into_that_directory
all: adopt-project.py as on bfed143	everything	18: all 17 new tests and the reworked test_adopt_ignored_shape_files test

The other four touched tests pass with any change reverted, by design. Three of them only change how a verification is made to fail after both legs, which does not depend on #524. The fourth is a docstring.

Windows

• The work-directory tests skip on Windows. chmod cannot keep a Windows user, or root anywhere, from making a directory. So the five work-directory tests skip there through unwritable_work, as materialize_assembly_root writes the shape files through a root-kept symlink to anywhere on disk, and crashes with a traceback on a link loop, after both legs are pushed #183's J4 test does.
• The L1-K1 tests run on Windows. Their links exist only in the source's tree (update-index --cacheinfo), as adopt-project.py: check follows each symlink the plan keeps where the shape writes its files, and execute refuses one the shape cannot write through, or one it writes beneath that git checks out as a file, before any leg exists, so such a link no longer breaks the run after both legs are pushed or has the shape's files written outside the assembly (#183, #178) #504's tests make them. The one command-line test needs git filter-repo, which tests-windows installs.
• Paths are legal on NTFS. Every path the tests create is, and a source holds only one of each case twin.
• The new probe runs on Windows too. It makes a directory with tempfile.mkdtemp, which works there.
• Newline emulation. This is a pytest plugin kept outside the repository. Under it, Path.write_text and text-mode stdin write \r\n. With it, the 17 new tests and the 5 touched ones ran at 17dd55ca: 20 passed and 2 failed.
  • The 2 that failed are the GitHub-mode tests. github_run writes its gh shim with write_text, so under the emulation the shim's #! line ends in \r and gh cannot start (FileNotFoundError: 'gh').
  • The same happens on bfed143 under the emulation: 3 of 3 GitHub-mode tests run fail, one of them a test this branch does not touch.
  • Those tests are WINDOWS_SKIP, so a real Windows run never runs them. No test asserts "...\n" in bytes read back from a file written with write_text.
• The new pre-commit hook is not tested on Windows from here. It is LF and #!/bin/sh, like the pre-receive hook that tests-windows already runs from the same file through Git for Windows' sh. I did not run it on a Windows host.

Not in this PR

Measured on 17dd55ca. Each is a new edge case for #457's checklist, and none is fixed here:

• A symlink ABOVE a pin's file that lands on a file the root keeps. Example: contracts -> governance with governance/shape-pin.yaml kept. check gives 0; execute gives 1 with adopt-shape-pin-unreadable after both legs. For a declared pin (governance/openglass-pin.yaml, --pin openGlass@<commit>), check gives 0 and execute gives 0 with adoption verified. But the root's contracts/openglass-pin.yaml then leads to the source's file, which the root's own validate-pins.py reads. Neither the kept-pin rule (it follows no link) nor the walk (the path is taken, and the copy goes under shape/) asks this.
• A --work-dir that cannot be made, or that names a file. _work_root's mkdir raises PermissionError or FileExistsError, as a traceback, in plan, check and execute. No leg exists by then.
• plan --source <org/repo> with an unwritable --work-dir. This is a PermissionError traceback at source-readonly. check and execute now refuse the same case.
• The release notes. docs/release-notes/v1.0.0.md keeps its two known-limit lines for adopt-project.py check: refuse a kept file at the shape's pin path, and an unwritable --work-dir, before any leg exists #524, because they describe 1.0.

Known limits

• An empty-target link at the shape's pin gives two findings. They are adopt-project.py check passes a source whose tree holds a symlink with an empty target, so with symlinks on execute creates both leg repositories and then fails cloning the source (on main with exit 2 and nothing on stderr, #171), and with core.symlinks=false it says adoption verified over a leg or root that no clone with symlinks on can check out #303's plan-empty-symlink and plan-root-holds-pin. adopt-project.py --pin <name> is accepted by plan, check and execute ("adoption verified"), but writes only the name into neutral_product_pins: and no contracts/<name>-pin.yaml, so the adopted root's own validate-pins.py (and its validate.yml) refuses with neutral-pin-missing from the first run #273 does the same for an empty link at a declared pin's file, and adopt-project.py check passes a plan that keeps the source's own shape/ in the root, and place() then writes the shape's collision copy onto it after both legs are pushed: a real shape/README.md is overwritten while execute prints "nothing was overwritten" and ends adopt-lost, and a shape/Makefile/ directory or a file named shape is a traceback #262 for one at a copy under shape/ (both measured on 17dd55ca). Only the walk defers to adopt-project.py check passes a source whose tree holds a symlink with an empty target, so with symlinks on execute creates both leg repositories and then fails cloning the source (on main with exit 2 and nothing on stderr, #171), and with core.symlinks=false it says adoption verified over a leg or root that no clone with symlinks on can check out #303.
• adopt-project.py --pin <name> is accepted by plan, check and execute ("adoption verified"), but writes only the name into neutral_product_pins: and no contracts/<name>-pin.yaml, so the adopted root's own validate-pins.py (and its validate.yml) refuses with neutral-pin-missing from the first run #273's sentence for a declared pin's file is not changed. It says that the pin would be written beside it, also for a link there that leads nowhere, which place writes through. The new sentence for the shape's pin says both.
• Without --work-dir, nothing is checked. _work_root then makes a new directory with mkdtemp, which this user can write in.
• An unwritable --work-dir with a --source that cannot be opened. check refuses for the source (source-unresolvable), and execute refuses for the work directory (adopt-work-dir-unwritable). Both exit 2 before any leg exists.
• Two lines for one kept file, in two plans check already refused. A plan that also keeps shape/contracts/shape-pin.yaml gets adopt-project.py check passes a plan that keeps the source's own shape/ in the root, and place() then writes the shape's collision copy onto it after both legs are pushed: a real shape/README.md is overwritten while execute prints "nothing was overwritten" and ends adopt-lost, and a shape/Makefile/ directory or a file named shape is a traceback #262's plan-root-blocks-shape-copy beside plan-root-holds-pin. A hand-edited pins: entry whose product's pin file is contracts/shape-pin.yaml (plan-pin-collides) gets plan-root-holds-pin once for that pin and once for the shape's, as two colliding declared pins do on bfed143.
• adopt-project.py _commit_the_split stages with git add -A -- ., so a source .gitignore of .* silently drops .gitattributes and validate.yml from the split, execute still says adoption verified, and the assembly fails its first bootstrap #167's verification is no longer reached by the plan answer its test used, the source's own contracts/shape-pin.yaml kept in the root, which check now refuses. Of the plans measured here, only the link-above case under Not in this PR still reaches execute's verification of the shape's pin after both legs. So test_adopt_ignored_shape_files checks adopt-project.py _commit_the_split stages with git add -A -- ., so a source .gitignore of .* silently drops .gitattributes and validate.yml from the split, execute still says adoption verified, and the assembly fails its first bootstrap #167's finding in process, with the shape's pin left out of the rule.

Closes #524

🤖 Generated with Claude Code

Summary by Sourcery

Reject shape-pin collisions and unwritable work directories during validation so adoption fails before any leg repository is created or pushed.

Bug Fixes:

• Detect plans that keep a file, directory, or symlink at the shape's own pin path and reject them before creating leg repositories.
• Detect unwritable --work-dir locations during check and execute, refusing execution before any leg repositories are created.

Enhancements:

• Unify pin-path handling for declared pins and the shape's own pin, including case-insensitive paths and symlink reporting without duplicate findings.
• Align source-cloning failures in check with the new work-directory refusal behavior.

Tests:

• Add coverage for kept shape-pin paths, symlink edge cases, unwritable work directories, and early-refusal behavior.
• Update late-verification tests to induce failures through a pre-commit hook now that conflicting root pins are rejected during planning.

[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 23 hours by commenting @sourcery-ai review. Upgrade to get a review now.

[sourcery-ai]

Reviewer's Guide

The PR closes two adoption preflight gaps: it detects root content at the shape's own pin and rejects unwritable explicit work directories before source access or leg creation, while updating collision, symlink, and late-failure tests to reflect the earlier refusals.

Sequence diagram for adoption preflight refusals

sequenceDiagram
    participant User
    participant Execute as cmd_execute
    participant WorkDir as _unwritable_work_dir
    participant Source as open_source
    participant Remotes as _create_leg_remotes

    User->>Execute: execute(plan, --work-dir)
    Execute->>WorkDir: _refuse_an_unwritable_work_dir(args, work_root)
    WorkDir->>WorkDir: tempfile.mkdtemp(dir=work_root)
    WorkDir->>WorkDir: os.rmdir(probe)
    alt work directory is unwritable
        WorkDir-->>Execute: Refusal(adopt-work-dir-unwritable)
        Execute-->>User: No source opened and no leg repository created
    else work directory is writable
        WorkDir-->>Execute: None
        Execute->>Source: open_source(args.source, work_root)
        Execute->>Remotes: _create_leg_remotes(...)
        Remotes-->>User: Leg repositories created
    end

Loading

Sequence diagram for check work-directory validation

sequenceDiagram
    participant User
    participant Check as cmd_check
    participant Probe as _unwritable_work_dir
    participant Source as plan.open_source

    User->>Check: check(--work-dir)
    Check->>Probe: _unwritable_work_dir(args, work_root)
    Probe->>Probe: tempfile.mkdtemp(dir=work_root)
    Probe->>Probe: os.rmdir(probe)
    alt probe fails
        Probe-->>Check: adopt-work-dir-unwritable
        Check->>Source: open_source(args.source, work_root)
        alt source requires cloning into work directory
            Source-->>Check: OSError
            Check-->>User: Refusal(adopt-work-dir-unwritable)
        else source is readable
            Source-->>Check: source
            Check-->>User: Finding adopt-work-dir-unwritable
        end
    else probe succeeds
        Probe-->>Check: None
        Check->>Source: open_source(args.source, work_root)
        Check-->>User: Plan findings
    end

Loading

Flow diagram for shape-pin collision detection

flowchart TD
    A[check or execute loads plan] --> B["_pin_files(plan)"]
    B --> C[Declared pin files]
    B --> D[contracts/shape-pin.yaml]
    C --> E[_kept_pin_findings]
    D --> E
    E --> F{Root keeps a file, directory, or symlink at pin path?}
    F -->|yes| G[plan-root-holds-pin]
    F -->|no| H[Continue preflight]
    G --> I[check reports finding or execute refuses]
    I --> J[No leg repository exists]

Loading

File-Level Changes

Change	Details	Files
Extend root pin-collision detection to include the shape's own pin and unify pin-path handling across findings and symlink traversal.	Added _pin_files to enumerate declared pin files followed by contracts/shape-pin.yaml. Emitted plan-root-holds-pin for files, directories, symlinks, and case variants kept at the shape pin. Prevented symlink walks from reporting a second finding for links already covered by the kept-pin rule. Added shape-pin-specific remediation text describing verification and bootstrap consumers.	adopt-project.py tests/test_adopt_shape_pin_and_work_dir.py tests/test_adopt_root_symlinks.py tests/test_adopt_ignored_shape_files.py
Probe explicit work directories before source access and repository creation, making check and execute consistently reject directories that cannot be written.	Added a temporary-directory create/remove probe for --work-dir. Added adopt-work-dir-unwritable with shared diagnostic and remediation text. Made check report the finding and convert clone-directory errors into the same refusal. Made execute refuse before opening the source or creating leg repositories.	adopt-project.py tests/test_adopt_shape_pin_and_work_dir.py
Revise late-failure tests to use a commit hook rather than a plan that is now rejected during checking.	Added a reusable pre-commit hook fixture that removes a pinned file from the split commit. Updated late verification and GitHub exit tests to inject the hook through core.hooksPath. Adjusted ignored-shape-file assertions to verify the new early plan finding while retaining a direct verification backstop.	tests/conftest.py tests/test_adopt_late_failure.py tests/test_adopt_github_exits.py tests/test_adopt_ignored_shape_files.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#524	Have check detect a file, directory, or symlink kept at the shape’s own pin path (contracts/shape-pin.yaml), and have execute refuse the plan before creating any leg repository.	✅
#524	Probe a supplied --work-dir for write access: report it from check and have execute refuse an unwritable directory before opening the source or creating any leg repository.	✅

Possibly linked issues

• adopt-project.py check: refuse a kept file at the shape's pin path, and an unwritable --work-dir, before any leg exists #524: The PR fixes adopt-project.py check: refuse a kept file at the shape's pin path, and an unwritable --work-dir, before any leg exists #524 by reporting kept paths at contracts/shape-pin.yaml and unwritable --work-dir values before any leg repository is created.

---

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.

[brettheap]

@codex review

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
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