[brettheap]

Lane: openreposhape-5 (openRepoShape-5)
Claim: #541 (comment)

family.py bump --to skipped two checks add makes, and failed in git's own words on a commit nobody had pushed. This PR fixes the three lines of #541 in scripts/family.py. Both runs, the dry run and the real one, now give the same answer for each line.

The head is 8024f9c. It has two commits on bfed143: eeadc65 is the fix, and 8024f9c answers review rv541 (see "Second commit" below).

The lines of #541

• bump --to never asked add's duplicate-id question. If the member's project.yaml at --to recorded another row's id, bump committed it with exit 0. The holder's own validate-family.py then refused that commit as member-duplicate-id. Now bump refuses with member-duplicate-id before anything changes, and the holder stays byte-identical.
• bump --to an unpushed commit failed as git's reference is not a tree. Now both runs refuse with member-to-unknown. The refusal names the commit, says no branch of the member's remote reaches it, and says to push it first. Once the commit is pushed, the same command pins it.
• Riding: add --at <tag id> peels it, bump --to refused the same id, and the two worded a tag of a tree differently. Brett Heap ruled on 2026-10-14 that bump --to peels an annotated tag's own id, as add --at does.
  • bump now pins the commit the tag names, in both runs, and prints one line saying so.
  • A tag of a tree is now named in add's words, "names a tree", through one shared function.
  • Both verbs' --help say that an annotated tag's own id is peeled.
  • One input still differs between the two verbs: a tag whose commit is on no branch (see "Left out").

What changed, and why

• _checked_bumped_id (new) asks add's question (family.py add does not ask whether the member's project.yaml id is one the family already pins, so adding a repository renamed at the forge (same id, new name) commits a holder that validate-family.py then refuses as member-duplicate-id #330) of the row bump writes. The member's own row is left out. Every other row is asked the way the validator asks it, so bump refuses what the gate would refuse and nothing it would pass. It is asked in three places:
  • by the dry run, before it prints the row;
  • by the real run, before its checkout (_checked_bump_target), so the refusal comes before the first write;
  • by the real run again, after its checkout (_bump_and_pin), of the id that checkout read. This catches a project.yaml that is a symbolic link, which only a checkout reads through. That refusal is put back by PinRollback (family.py bump and remove have no rollback: when a git step after write_members fails (a holder pre-commit hook that exits 1, a held index.lock), they exit 2 with REFUSED a git or gh command failed and leave family.yaml rewritten, the member checked out at --to (or deinitialised and removed), and the change staged or half-staged, without a word about any of it, where add puts the holder back and names what it put back #365), like any refusal after the first write.
• _row_recording (new) finds the row that records an id. add's _checked_member_id now uses it too. add's words do not change.
• _checked_to_names_a_commit now returns the commit to pin:
  • a commit: itself;
  • an annotated tag, or a tag of a tag: the commit it names (^{});
  • a tree, a blob or a tag of either: refused with member-to-not-a-commit, in add --at's words (_names_no_commit, shared with _probe_commit);
  • an id the member does not hold after the fetch: refused with member-to-unknown. If the fetch failed, the refusal says so and does not claim the remote lacks the commit.
• cmd_bump goes on with the returned commit in both runs. When a tag was peeled, both runs print this as their first line: --to <tag12> is an annotated tag in <repo>; the commit it names, <commit12>, is what would be pinned. The words "would be" are deliberate: the dry run prints the line, and so does a run refused by a question asked after the peel, and neither pins anything.
• --help.
  • add --at now reads "pin this 40-hex commit instead of the member's current tip (an annotated tag's own 40-hex id is peeled to the commit it names)".
  • bump --to ends "(an annotated tag's own 40-hex id is peeled to the commit it names, as add --at peels one)".
  • docs/cli.md is regenerated by scripts/render-cli-reference.py.
• Docstrings.
  • The sentence that said bump refuses a tag "as bump-leg.py refuses the same --to" is gone (lane 4's note on family.py bump --to: make the checks add makes (a duplicate id, an annotated tag's own id), and say to push first for an unpushed commit #541), and so is "left to the checkout" for an id the member does not hold. Both files now compare only with family.py add --at, so they stay true whichever of bump-leg.py: --dry-run gives the real run's answer, so --to an annotated tag's own id is peeled to the commit it names in both runs, and a pin layout the rewrite refuses is refused by the dry run too (#534, #438) #561 and this PR lands first.
  • _checked_to_names_a_commit now names the tag whose commit is on no branch.

Second commit (8024f9c): review rv541, 0 blockers, 1 should, 5 nits

• S1. The peel line said "is what is pinned" in the dry run and above a refusal. It now says "is what would be pinned". A new test puts a duplicate id behind a tag: both runs print the line, refuse member-duplicate-id in the same two lines, exit 2, and pin nothing.
• N1. A new test covers the branch hint with a tag's id on the tracking branch. The dry run's hint and the real run's refusal both name family/bump-irrs-<the typed id's first twelve>. The reviewer's mutant, in which the dry run takes its hint from the peeled commit, fails that test.
• N2. The tag whose commit is on no branch is named in the docstring, in "Left out" and as a checklist candidate. Its behaviour is unchanged.
• N3. The --help lines above, with docs/cli.md regenerated.
• N4. The merge-check paragraph below is redone at 8024f9c.
• N5. The ripple numbers in "Left out" and the checklist candidate are now the reviewer's measured ones.

Decisions and their evidence

1. The wording for a tag of a tree. bump now uses add --at's words: "names a tree" and "names a blob", with add's remediation sentence. Both verbs build the refusal from one function, _names_no_commit, and each keeps its own code (member-at-unknown and member-to-not-a-commit). I followed the brief's "exactly as add --at does".
   • bump-leg.py: --dry-run gives the real run's answer, so --to an annotated tag's own id is peeled to the commit it names in both runs, and a pin layout the rewrite refuses is refused by the dry run too (#534, #438) #561 keeps "is an annotated tag of a tree" for bump-leg.py, under its own code and in its own frame.
   • Changing add to that wording would change add's tested output, so it is not done here.
   • add's tests pass unchanged (test_family_add_refusals.py, inside the 670 below).
2. A new code, member-to-unknown. It mirrors add's member-at-unknown for the same input. The fetch's outcome selects one of two wordings, so a member that could not be fetched is never called unpushed.
3. The peel is announced. add --at peels a tag without saying so. bump prints one line in both runs, because the old -> new line the person reads then shows an id they did not type. The line says "would be pinned", the same words bump-leg.py: --dry-run gives the real run's answer, so --to an annotated tag's own id is peeled to the commit it names in both runs, and a pin layout the rewrite refuses is refused by the dry run too (#534, #438) #561 uses for bump-leg.py.
4. The suggested branch keeps the typed id. The real run refuses the tracking branch before the fetch, so before any peel. The dry run's hint names the same branch, and a test now holds that. bump-leg.py: --dry-run gives the real run's answer, so --to an annotated tag's own id is peeled to the commit it names in both runs, and a pin layout the rewrite refuses is refused by the dry run too (#534, #438) #561 does the same with asked.
5. A linked project.yaml is still left to the real run by the dry run, as add --dry-run leaves one (family.py bump (and add, remove) take no --dry-run, though the file's exit-code paragraph says a dry run prints and exits 0 and bump-leg.py has one, so the only way to see what a bump would pin is to run it: fetch, check the member out at --to and rewrite family.yaml #326). The real run refuses the duplicate id after its checkout and puts the holder back. A test holds that.

Tests

New: tests/test_family_bump_to_checks.py, with 6 tests:

• the duplicate id read from the member's objects, refused alike by both runs;
• the duplicate id read through a linked project.yaml (POSIX only), refused and put back;
• a duplicate id behind a tag: both runs print the peel line, refuse, and pin nothing;
• the branch hint on the tracking branch with a tag's id, the same in both runs;
• an unpushed commit in a working clone: refused, then pinned once pushed;
• a commit missing after a failed fetch, not called unpushed.

Changed:

• tests/test_family_bump_to_a_tag.py now holds the ruling: the peel in both runs, the peel after the fetch, and the tree, blob and tag-of-one wording. Its both_runs helper also takes the stdout a run prints before its refusal. Its clone lines are untouched, so it merges cleanly with main, where tests: every test that clones a just-pushed local remote by its plain path now clones it with clone_just_pushed, so the macOS failed to copy file race of #440 cannot reach it; load_without_bytecode keeps the doctor's and the Windows-path tests' loads of the family root's scripts from writing .pyc into the templates; the not-a-list doctor cases hold INVALID, exit 1; and GOOD_KEYS holds th #554 has landed.
• tests/test_family_dry_run.py: its test of a commit the member lacks now expects member-to-unknown from both runs.

Results at 8024f9c, through the lane's runner (gh stubbed, a bogus token, an empty GH_CONFIG_DIR):

• test_family_bump_to_checks.py, test_family_bump_to_a_tag.py, test_family_dry_run.py, test_family_bump_remove_rollback.py, test_family_add_member_id.py, test_cli_reference.py: 139 passed in 149.62s
• test_family.py, test_family_tracking_branch.py, test_family_add_refusals.py, test_family_add_excludes.py, test_family_member_path.py, test_family_printed_quoting.py, test_cli_reference.py, test_repo_hygiene.py, test_refusal_default_remediation.py, test_commit_trailers.py, test_agents_md_codes.py, test_stdout_encoding.py: 670 passed, 1 skipped in 300.71s. The skip is test_stdout_encoding.py:286, which runs on Windows only.
• scripts/render-cli-reference.py --check: [ok] docs/cli.md is what the generator produces.

The new and changed tests at bfed143, with the test files copied in:

• The 12 from the first commit: 12 failed, 60 passed. Each fails for its line's reason:
  • on a duplicate id, the real bump moved the member;
  • on an unpushed commit, git's own words;
  • the tag refused;
  • the old tree wording.
• The 2 added in 8024f9c: 2 failed. bfed143 refuses the tag, so no peel line is printed and the dry run exits 2.

Reproductions (local bare remotes and the gh stub only)

The script scaffolds Atlas, Borg and Cello into bare remotes, makes a holder with Atlas and Borg, then runs each line. At bfed143, then at eeadc65; 8024f9c changes only the peel line's last words:

• Line 1. Atlas's project.yaml is changed to record id: "borg", pushed, and Atlas is bumped to it.
  • bfed143: the dry run exits 0 with id: borg, and the real run commits (exit 0). validate-family.py then says FINDING member-duplicate-id: Borg and Atlas both record id 'borg', exit 1.
  • eeadc65: both runs say REFUSED member-duplicate-id: testorg/Atlas at <sha12> is already a member of Sonata under another name: ..., exit 2. The holder's state hash is the same before and after, and the validator says family ok.
• Line 2. A commit is made in the working clone work/Atlas and not pushed.
  • bfed143: the dry run says REFUSED resolving ... fatal: Needed a single revision. The real run says REFUSED checking members/Atlas out ... fatal: reference is not a tree. Both exit 2.
  • eeadc65: both runs say REFUSED member-to-unknown: --to <sha> is not a commit any branch of testorg/Atlas reaches: ... and Remediation: push it first, .... After git push, the same command exits 0 and family ok.
  • With the member's origin gone, eeadc65 says the fetch failed and does not claim the remote lacks the commit.
• Riding line. Atlas gets a commit and an annotated tag v2, both pushed.
  • bfed143: both runs refuse with member-to-not-a-commit ... is an annotated tag.
  • eeadc65: both runs print the peel line. The dry run shows commit <old> -> <commit12>. The real run pins the commit in pin.commit and in the gitlink alike, and the validator says family ok.
  • add --at <Cello's tag id> --dry-run pins the tagged commit at both shas.
• Tag of a tree.
  • bfed143: bump says "is an annotated tag of a tree" and add says "names a tree".
  • eeadc65: both say "names a tree".

No line needs real GitHub.

Mutation probes

Each behavioural hunk was reverted or broken on its own in a throwaway worktree (M1 to M10 and R1 at eeadc65, M11 to M13 at 8024f9c), and the tests were run:

Probe	Result
M1, the dry run's duplicate-id check removed	test_bump_to_a_commit_recording_another_rows_id_is_refused_alike fails
M2, the real run's pre-checkout duplicate-id check removed	the same test fails: the refusal comes after the checkout, worded differently from the dry run's
M3, the post-checkout duplicate-id check removed	test_a_duplicate_id_read_through_a_linked_manifest_is_put_back fails
M4, an id the member lacks goes on as before	both member-to-unknown tests fail
M5, a failed fetch worded as a successful one	the failed-fetch test fails
M6, the peel turned back into a refusal	both pins_the_commit_it_tags cases and the release-tag test fail (3)
M7, the old tree, blob and tag-of-one wording	the 4 refused_by_name cases fail
M8, the peel line not printed	the same 3 peel tests fail
M9, the returned commit ignored	the same 3 peel tests fail
M10, the member's own row asked against itself	every ordinary bump is refused: 4 of 4 selected tests fail, including test_bump_dry_run_prints_the_move_and_a_real_bump_writes_exactly_that
R1, add's refusal written inline again (a refactor, no change in output)	add's tag, tree and blob tests pass: 7 passed
M11, the dry run takes its branch hint from the peeled commit (the reviewer's D4 mutant)	test_both_runs_name_the_branch_for_the_tag_id_as_typed fails; 1 failed, 29 passed
M12, the peel line says "is what is pinned" again	5 fail: the duplicate-id-behind-a-tag test, the branch test, and the 3 peel tests
M13, bump --to's help without the peel	5 test_cli_reference.py tests fail, test_the_committed_reference_is_what_the_generator_produces among them

Merge checks (8024f9c, git merge-tree --write-tree, 2026-10-15T11:02Z)

The merge is clean (rc=0) against each of these:

• origin/main 7d9bec9, the current tip. Lane 3's tests: every test that clones a just-pushed local remote by its plain path now clones it with clone_just_pushed, so the macOS failed to copy file race of #440 cannot reach it; load_without_bytecode keeps the doctor's and the Windows-path tests' loads of the family root's scripts from writing .pyc into the templates; the not-a-list doctor cases hold INVALID, exit 1; and GOOD_KEYS holds th #554 (2247dbf) and lane 4's bump-leg.py: --dry-run gives the real run's answer, so --to an annotated tag's own id is peeled to the commit it names in both runs, and a pin layout the rewrite refuses is refused by the dry run too (#534, #438) #561 (7d9bec9) have both landed since this branch was cut;
• lane 5's siblings on origin:
  • fix/family-siblings-tracking-branch at 43d32eb;
  • fix/family-members-case-variants at 40eda84;
  • fix/family-remove-gitmodules-missing at b1120c3;
  • fix/link-source-chain-defaults at 04c9d77;
• lane 2's family.py and scaffold-project.py: --dry-run asks the real run's own question about existing remotes, so family-remote-exists and scaffold-remote-exists come at the plan, and a missing gh is gh-not-found, not a traceback (#537) #573 (fix/537-dry-run-asks-remotes) at 0c81423.

On the tree merged with main 7d9bec9, scripts/family.py and scripts/bump-leg.py parse, and render-cli-reference.py --check says [ok] docs/cli.md is what the generator produces. The review checked the same on the merges with fix/link-source-chain-defaults and lane 2's #573.

#561 landed first, so this PR fixes the cross-reference (lane 4's note on #541, issuecomment-6175160194). On main, #561 made two sentences false: scripts/family.py:3991, "REFUSED, NOT PEELED, as bump-leg.py refuses the same --to", and the module docstring at tests/test_family_bump_to_a_tag.py:17. This PR rewrites both to compare with family.py add --at only. The comparisons with bump-leg.py that remain still hold on main 7d9bec9: a tag whose commit is on no branch is still bump-leg-commit-not-on-remote there, in both runs, and the nothing to do sentence and the trailers lines are unchanged.

Main was not merged into this branch.

Left out, and why

• A commit only the member's mount holds is still pinned. This is a commit made inside members/<P> and never pushed. The object is present, so bump proceeds.
  • family.py bump --to: make the checks add makes (a duplicate id, an annotated tag's own id), and say to push first for an unpushed commit #541 is about the commit that fails.
  • bump-leg.py refuses this input as bump-leg-commit-local-only. Refusing it here needs a ruling on offline bumps, because today a bump whose fetch failed goes on from the objects the member already has.
  • The reviewer measured the ripple with bump-leg's reachability rule applied: at least 12 cases in 5 files fail, and only 6 of them make their commit through commit_in_mount. The twelfth is this PR's own peel-line test.
  • It is the first checklist candidate.
• A tag whose commit is on no branch. add --at pins its id, but bump --to refuses the tag and its commit as member-to-unknown.
  • bump's fetch brings every branch and, by git's own rule, only the tags that point into the history those branches bring. add's bare clone brings every tag. A git push origin v2 without the branch makes one, and the refusal's push to a branch is what lets bump pin it.
  • bump-leg.py refuses its twin the same way, as bump-leg-commit-not-on-remote. Fetching every tag would write refs the person's member did not have.
  • The behaviour is unchanged and named in _checked_to_names_a_commit's docstring. It is the second checklist candidate.
• docs/release-notes/v1.0.0.md describes v1.0.0's behaviour (its lines 259-260, 461-462 and 487) and stays true of v1.0.0. The v1.1.0 notes should say what changed.
• No README, AGENTS.md or handbook sentence became false, so none is edited.

Checklist candidates

• family.py bump --to a commit only the member's mount holds pins it, where bump-leg.py refuses bump-leg-commit-local-only.
  • A commit made inside members/<P> and never pushed passes bump's object check, because the object is in the mount's store. It is pinned with exit 0, and the holder then cannot be bootstrapped anywhere else.
  • bump-leg.py asks for-each-ref --contains against refs/remotes/origin/ and refuses the same input.
  • A fix needs a ruling on offline bumps.
  • Under bump-leg's rule, at least 12 cases in 5 test files fail: 11 existing ones (review rv541's c1.log and c2.log) and this PR's own peel-line test. Only 6 of the 12 make their commit through commit_in_mount.
• family.py bump --to refuses a tag whose commit is on no branch (member-to-unknown), where add --at pins the same id.
  • The remedy it prints, pushing the commit to a branch, works. But a person who pushed only the tag is told to push.
  • Telling that case apart (for example with a git ls-remote --tags check, or a fetch of that one tag) is a change of its own, and so is any rule that brings it in line with add.

Closes #541

🤖 Generated with Claude Code

Summary by Sourcery

Make family.py bump --to validate targets and member IDs consistently with add --at, peel annotated tags to commits, and provide actionable errors for unavailable commits.

New Features:

• Peel annotated tag IDs supplied to bump --to and pin the commit they reference, consistently across dry-run and real execution.
• Add clear member-to-unknown handling that directs users to push commits unavailable from the member’s remote.
• Make bump --to detect duplicate member IDs before modifying the family, including IDs read through checked-out linked manifests.

Bug Fixes:

• Prevent bump --to from committing duplicate IDs or producing invalid gitlink and pin combinations.
• Replace inconsistent Git errors for unavailable targets with actionable, consistent refusals.
• Align tree, blob, and tag-of-tree diagnostics between add --at and bump --to.

Enhancements:

• Share duplicate-ID and non-commit refusal logic between family commands.
• Announce tag peeling and preserve the typed tag ID in branch guidance and dry-run output.

Documentation:

• Regenerate CLI documentation and update command help to describe annotated-tag peeling.

Tests:

• Add coverage for duplicate IDs, linked manifests, tag peeling, branch hints, unpushed commits, and failed fetches.
• Update bump target tests to verify consistent dry-run and real-run behavior.

[brettheap]

(lane openRepoShape-5, 2026-10-14T23:07Z) @codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-14T23:11:43.434072Z	eeadc65	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[sourcery-ai]

Reviewer's Guide

Updates family.py bump --to to validate duplicate IDs like add, provide actionable handling for unavailable commits, and peel annotated tags to their commits, with shared refusal logic and comprehensive parity/rollback regression coverage for dry and real runs.

Sequence diagram for family bump target validation

sequenceDiagram
    participant User
    participant Family as family.py
    participant Member as Member repository
    participant Holder as Family holder

    User->>Family: cmd_bump(--to)
    Family->>Member: fetch target objects
    alt fetch failed
        Family-->>User: REFUSED member-to-unknown
    else target unavailable after fetch
        Family-->>User: REFUSED member-to-unknown, push it first
    else annotated tag names a commit
        Family->>Family: _checked_to_names_a_commit()
        Family-->>User: print peeled commit
        Family->>Family: _checked_bumped_id()
        Family->>Member: checkout peeled commit
        Family->>Holder: write pin and family rows
    else target is tree, blob, or tag of either
        Family-->>User: REFUSED member-to-not-a-commit
    end

Loading

Flow diagram for duplicate-ID checks in family bump

flowchart TD
    A[Read project.yaml at --to] --> B[_checked_bumped_id]
    B --> C{Another row records the ID?}
    C -->|No| D[Continue bump]
    C -->|Yes| E[REFUSED member-duplicate-id]
    E --> F[Holder remains unchanged]
    D --> G{Dry run or real run?}
    G -->|Dry run| H[Print proposed rows]
    G -->|Real run before checkout| I[Checkout target]
    I --> J[Read project.yaml through checkout]
    J --> K[_checked_bumped_id again]
    K --> L{Duplicate ID discovered?}
    L -->|Yes| M[PinRollback restores holder]
    L -->|No| N[Write pin and family rows]

Loading

File-Level Changes

Change	Details	Files
Align bump --to validation with add and make duplicate member IDs fail before repository changes.	Added shared row lookup logic that excludes the row being replaced and matches validator semantics. Applied duplicate-ID checks during dry runs, before the real checkout, and after checkout to catch linked manifests. Reused the shared lookup from add without changing its refusal wording.	scripts/family.py tests/test_family_bump_to_checks.py
Normalize --to resolution so annotated tags are peeled and unavailable commits receive actionable refusals.	Return the commit named by annotated tags, including nested tags, and use it for the gitlink, manifest row, digest, and output. Share tree/blob refusal wording with add --at. Add member-to-unknown handling that distinguishes failed fetches from commits absent from a successfully fetched remote and recommends pushing first.	scripts/family.py tests/test_family_bump_to_a_tag.py tests/test_family_bump_to_checks.py tests/test_family_dry_run.py
Keep dry-run and real-run behavior and output consistent for the updated bump paths.	Announce tag peeling identically in both modes while preserving the typed ID for branch-related output. Ensure rollback restores the holder after post-checkout validation failures. Update regression tests for duplicate IDs, linked manifests, unpushed commits, failed fetches, tag peeling, and tree/blob wording.	scripts/family.py tests/test_family_bump_to_checks.py tests/test_family_bump_to_a_tag.py tests/test_family_dry_run.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#541	Have family.py bump --to reject a target whose project.yaml records an ID already used by another family member, consistently in dry-run and real-run paths.	✅
#541	When the target commit is unavailable in the member's object store after the fetch, replace Git's low-level failure with a clear refusal that tells the user to push the commit first; distinguish a failed fetch from evidence that the remote lacks the commit.	✅
#541	Make bump --to peel an annotated tag's own ID to the commit it names, matching add --at, and use consistent wording for tags of trees or blobs.	✅

Possibly linked issues

• Tracking: setup, scaffold, family and the shared helpers, creating projects and families #459: The PR implements the issue’s duplicate-ID and push-first checks and its annotated-tag ruling, including consistent dry-run behavior.

---

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.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eeadc65c4b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid announcing a pin before later validation succeeds

When --to is an annotated-tag object ID, this prints that the peeled commit “is what is pinned” before _checked_bump_target runs. If the tagged commit is subsequently rejected—for example, because its project.yaml is missing or records another member's ID—the command exits 2 without pinning anything but leaves this success-like line on stdout; the equivalent direct-commit refusal emits no stdout. Delay the announcement until validation and the real write succeed, or word it as a prospective peel rather than a completed pin.

Useful? React with 👍 / 👎.

[brettheap]

(lane openRepoShape-5, 2026-10-15T11:04Z) Fixed in 8024f9c, the second way you suggest. The line now reads "..., is what would be pinned" (scripts/family.py:4422). A later refusal still follows it, in both runs.

test_a_duplicate_id_behind_a_tag_is_refused_after_the_peel_line (tests/test_family_bump_to_checks.py) covers the case you describe. It peels a tag of a commit whose project.yaml records the neighbour's id, and checks that the line says "would be pinned" above a member-duplicate-id refusal, with exit 2 and nothing pinned. With "is what is pinned" restored, 2 tests fail (review rv541's m12 probe).

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

[sonarqubecloud]

Quality Gate passed

Issues
0 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