[brettheap]

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

Goal

env_commit's docstring in scripts/shape_materialize.py says what the split commit's message does with a root or drop path that holds a byte that is not UTF-8, as the code does since #900. It said the message names such a path "with a ? in place of that byte, a path that does not exist". That was true before #900, and it is not true now. A reader of the docstring is told about a caf?.md the tool no longer writes.

Found by lane 1's writer on #900 and filed as #1018. Lane 5 took it outside v1.2.0, under Brett Heap's ruling of 2026-10-21T10:32:04Z.

What still held on main

Measured on main 2a119f281 and again on 16f9a0e81 (main after #1087), with a small script that calls: adopt-project.py's own _split_message and _shown, then env_commit and a real git commit, read back with cat -A.

• The issue's claim held: the docstring (about line 2103 when filed, line 2268 on 2a119f281, line 2349 on this branch) still said the message names the byte with a ?.

• The code does not. _shown("caf\udce9.md") is `caf\udce9.md`, and the split message for a root and a drop entry named that holds no lone surrogate. Through env_commit and git cat-file commit HEAD, cat -A:

  DROPPED (in no leg and no longer here):$
    `caf\udce9.md`$
  STAYS IN THE ASSEMBLY ROOT:$
    README.md$
    `caf\udce9.md`$
  

• What stays true of env_commit itself: a message that holds the lone surrogate, handed to it directly, is still written as ?. cat -A reads Name: caf?.md$. So the errors="replace" paragraph is kept, and what changes is who it describes.

• shape_materialize.py: the fetch for a branch's answer leaves out every refspec of the repository's own onto the branches' names, whatever its source, and every one that puts a branch under a name not its own, so family.py bump and bump-leg.py no longer fail where the remote has x and release/x and the repository's own git fetch origin works (#1066) #1087 (main 16f9a0e81) changed scripts/shape_materialize.py by 128 lines, none of them in env_commit, COMMIT_COMMAND or the message, and changed nothing in adopt-project.py (0 diff lines). The rebase onto it was clean and the docstring needed no other change.

What changed

One file, env_commit's docstring, in two paragraphs: the errors="replace" paragraph (round 1, 11 lines added and 7 removed) and the sentence above it (round 2, below; 3 added and 2 removed). Together 14 added and 9 removed against main 6da757cb. The errors="replace" paragraph now says:

• encoding, a character UTF-8 cannot carry is written as ?, and nothing raises after both legs are pushed, as before;
• adopt-project.py refuses a lone surrogate in a path it extracts (entry_path_problem), and a root or drop entry that holds one is listed in the split message but never raw: the message names each path as plan's report does (_shown, adopt-project.py: a kept or dropped name reaches the split commit and the pull request body unspelled, and _spelled, _shown and plan's report print text that reads as another name, or raw #900), so the byte 0xE9 reads as an escape with no surrogate in it, `caf\\udce9.md`, the path the source holds;
• written raw it would be a ?, caf?.md, a path that does not exist, which is what env_commit still writes for a lone surrogate it is handed.

The backslash is doubled in the source, as the neighbouring docstrings write \\udcc3. A single \u in a non-raw docstring would be an escape that makes a lone surrogate. Measured: the docstring holds no character from U+D800 to U+DFFF and holds the six characters \udce9. The longest docstring line is 78 characters.

The code is unchanged. A script compares the AST of scripts/shape_materialize.py with every docstring blanked: the branch's file is identical to origin/main's after the rebase onto 16f9a0e81 (round 1), and the merge of this head into origin/main 6da757cb is identical to 6da757cb's file (round 2).

No pin moves. scripts/shape_materialize.py is not a pinned copy. COPIED_VERBATIM, COPIED_FROM_SHAPE, FAMILY_COPIED_VERBATIM and FAMILY_COPIED_FROM_SHAPE do not list it, and templates/assembly-root/scripts/validate-pins.py says of it "which no project carries". So no upstream-changed row, no digest, no assembly copy and no tests/test_pinned_copy_text.py entry changes.

No other text pins these words. Searched in tests/, README.md, docs/, docs/handbook.html, AGENTS.md and templates/: no test reads env_commit's docstring (__doc__, getdoc), and none of them holds "in place of that byte" or "a path that does not exist" for this. The other places that name the ? are about this function's behaviour or about history, and are still true: _split_message's docstring says caf\\udce9.md "was caf?.md" (before #900), _refused_by_policy already says the message "lists it as _shown does (#900)", and tests/test_adopt_spelled_names.py quotes the message as it was on c7a3ff16. The ? in argv_text, trailer_line and the commit-trailer text is about a --trailer, not the split message.

Rows and mutants

No rows and no mutants: the change is a docstring, the code is the same AST, and no test pins the docstring. So there is no row to fail on main and nothing to mutate.

Runs

All with $Q/v110/run9.sh, EMAIL=service@opensoft.dev, GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null, the stub gh, a fake token, git 2.43.0 (/usr/bin/git).

Two shards, run before the rebase, at the 2a119f281 base with this one-file change in the tree. Together they are every tests/*.py that names shape_materialize or env_commit (86 files, including tests/test_adopt_spelled_names.py and tests/test_adopt_entry_paths.py, which run env_commit and the #900 message) and tests/test_agents_md_codes.py:

run	files	result
shard A	43	2873 passed, 4 skipped in 1707.51s, rc=0
shard B	44	4611 passed, 31 skipped in 2462.01s, rc=0

After the rebase onto 16f9a0e81, on the committed head e32b2703d733f6c60c1b2cba2d62d164d93d7b9a (dirty=0): the trio, tests/test_repo_hygiene.py, tests/test_agents_md_codes.py and tests/test_cli_reference.py, 170 passed in 55.67s, rc=0. The docstring-only change needed no new shards: the shards' counts are runs at the 2a119f281 base, and #1087 did not touch env_commit.

Round 2, on the committed head de89aa81b1533e32f1007f991aeae05cd915b36d (dirty=0): the same trio, 170 passed in 61.77s, rc=0. The round 2 commit is one docstring sentence, so it needed no new shards either.

git 2.47.1: no run. The change adds no test file of its own, so there is none to run on it.

Merge-trees

git merge-tree --write-tree HEAD <other> with HEAD at de89aa81b1533e32f1007f991aeae05cd915b36d, after a re-fetch of origin main with -c gc.auto=0 -c maintenance.auto=false (round 2, about 14:03Z on 2026-10-21):

against	result
origin/main 6da757cbe9a4eb66d60c34f38dcc2b332d175e8b	clean, rc 0, tree 15c11b6c959fc4c7540105d5d62e3f961c8e27fd
#1105 fix/1048-makefile-follow-up-gnu-read-order 5a4de7f763b5a3c32adce9614a3a539508416eb4, an open PR that touches scripts/shape_materialize.py	clean, rc 0, tree db05aead67052643942e35a9689d9dd4a0873fda
#1118 fix/1089-named-link-skip-tests c60066cbeec18b8b6c926e254ed4bee6b9a486c2, the other open PR that touches scripts/shape_materialize.py	clean, rc 0, tree a40df3b63c32c2a3d8f4c40587b094940c8d6567

Read with gh pr list --state open --json number,headRefName,headRefOid,files: 16 open PRs, three of them (this one, #1105 and #1118) touch scripts/shape_materialize.py, the only file this change touches. The other 13 (#1120, #1119, #1117, #1111, #1109, #1107, #1106, #1102, #1101, #1098, #1097, #1091, #1088) touch no file this change touches.

The same command with HEAD at the reviewed head e32b2703 gives rv1104's trees: de31d857 against 6da757cb and 195ffe19 against #1105. The round 1 merge against #1090 is moot: #1090 has landed in 6da757cb.

Held as a draft until the v1.2.0 tag; it is now on the v1.2.1 milestone.

Round 2 (rv1104's two NITs)

• NIT 1, scripts/shape_materialize.py lines 2340-2343, a line round 1 did not change. The paragraph above the reworded one said the adoption's split message "names each entry path as the source spells it". Since adopt-project.py: a kept or dropped name reaches the split commit and the pull request body unspelled, and _spelled, _shown and plan's report print text that reads as another name, or raw #900 that is true of a printable path alone: _split_message lists any other through _shown, as the escape the next paragraph describes. It now says "as the source spells it (a printable one; see below)". One new commit on top of e32b2703, de89aa81b1533e32f1007f991aeae05cd915b36d, 3 lines added and 2 removed, docstring only, pushed as a fast-forward (no rebase, the PR is open).
  • Measured: the AST with docstrings blanked is identical to e32b2703's and, merged into 6da757cb, to 6da757cb's. The docstring holds no lone surrogate, still holds the six characters \udce9, and its longest line is 78 characters.
  • Searched tests/, README.md, docs/, the handbook mirror, AGENTS.md, templates/ and the scripts for "names each entry path", "as the source spells" and the new words: only tests/test_adopt_entry_paths.py line 233 matches, a test's docstring about execute handing each path on as the source spells it, which is another sentence and pins nothing here.
• NIT 2, this body. It named main as 16f9a0e81 and shape_materialize.py, adopt-project.py and bump-leg.py: a tag a clone holds without its commit is one it cannot answer for, check says a commit it cannot ask was not asked, and a pinned product YAML 1.1 or 1.2 reads as no text is quoted (#912) #1090 as the one open PR that touches the file. shape_materialize.py, adopt-project.py and bump-leg.py: a tag a clone holds without its commit is one it cannot answer for, check says a commit it cannot ask was not asked, and a pinned product YAML 1.1 or 1.2 reads as no text is quoted (#912) #1090 has landed. Main is 6da757cb, and the merge-trees above are redone against it, against shape_materialize.py and the pinned AGENTS-shape.md: where the root keeps a GNUmakefile or a makefile, which GNU make reads first, the Makefile collision follow-up no longer says the shape's make targets arrive with the merge, and the pinned file says make reads the first of the three and the block reaches it only once that file holds it (#1048) #1105 and against adopt-project.py, shape_materialize.py and tests: a named bad link left out of the copy and pin findings takes no other path's finding with it, and the docstrings and the materializer's refusal name the #979 exception and what helps it (#1089) #1118, a draft that opened since and also touches the file.

Closes #1018

🤖 Generated with Claude Code

Summary by Sourcery

Update env_commit documentation to accurately describe how non-UTF-8 path bytes appear in split commit messages.

Enhancements:

• Clarify env_commit documentation to accurately describe escaped path rendering for non-UTF-8 bytes in split commit messages while preserving the distinction from raw message encoding.

Documentation:

• Correct the env_commit docstring to reflect current _shown behavior and distinguish escaped paths from ? replacement during commit encoding.

[sourcery-ai]

Reviewer's Guide

Implementation

Correct env_commit’s docstring to distinguish _shown’s escaped paths in split messages from ? replacement when a raw lone surrogate is encoded.

• scripts/shape_materialize.py L2448-2450, L2456-2466

---

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]

Independent review of #1104 (#1018) at e32b2703, for lane openRepoShape-5: READY

Findings: no MUST, no SHOULD.

• NIT 1, scripts/shape_materialize.py:2340-2343 (a line the PR does not change). The paragraph just above the new one still says the split message "names each entry path as the source spells it". Since adopt-project.py: a kept or dropped name reaches the split commit and the pull request body unspelled, and _spelled, _shown and plan's report print text that reads as another name, or raw #900 that is true only of a printable name. The new paragraph corrects it lower down, so the docstring as a whole is true.
  • Scenario: someone reads only that paragraph and concludes caf\udce9.md reaches git as its raw bytes.
  • Optional fix: add "(a printable one; see below)". The issue did not ask for this.
• NIT 2, the PR body is out of date since shape_materialize.py, adopt-project.py and bump-leg.py: a tag a clone holds without its commit is one it cannot answer for, check says a commit it cannot ask was not asked, and a pinned product YAML 1.1 or 1.2 reads as no text is quoted (#912) #1090 landed.
  • It gives main as 16f9a0e81, and calls shape_materialize.py, adopt-project.py and bump-leg.py: a tag a clone holds without its commit is one it cannot answer for, check says a commit it cannot ask was not asked, and a pinned product YAML 1.1 or 1.2 reads as no text is quoted (#912) #1090 "the one open PR that touches scripts/shape_materialize.py".
  • Main is now 6da757cb. The open PR that touches the file now is shape_materialize.py and the pinned AGENTS-shape.md: where the root keeps a GNUmakefile or a makefile, which GNU make reads first, the Makefile collision follow-up no longer says the shape's make targets arrive with the merge, and the pinned file says make reads the first of the three and the block reaches it only once that file holds it (#1048) #1105 (fix/1048-makefile-follow-up-gnu-read-order, 5a4de7f7, draft).
  • Both merges are clean (see 4 below).
  • Scenario: whoever lands it takes the body's merge table for a check against current main. Refresh the table when the PR leaves draft.

Checked and true

1. What the code does. My own probe, $Q/v118/rv1104-1107/probe1104.py, ran offline (GIT_SSH_COMMAND=false, GIT_CONFIG_GLOBAL=/dev/null). It calls adopt-project.py's own _split_message and _shown, then the head's env_commit into a real commit, read back with git cat-file commit HEAD.

   • Same result on git 2.43.0 and 2.47.1. git --version was printed under the same PATH env_commit used.
   • The split message:
     • _shown('caf\udce9.md') gives `caf\udce9.md`.
     • The drop entry and the root entry are each stored as the line `caf\udce9.md`.
     • The stored message holds no ?, no raw 0xE9 and no ED B3 A9. The message string holds no surrogate.
     • A surrogate outside the not-UTF-8 range, x\ud800.md, is escaped as well.
   • A message holding the lone surrogate, handed straight to env_commit, is stored as Name: caf?.md and Name: x?.md. Python's encode('utf-8', 'replace') gives b'caf?.md'.
   • On the predicted merge with 6da757cb (git 2.43) the probe gives the same results.
   • The docstring at run time holds no character from U+D800 to U+DFFF. It holds the six characters \udce9 and the span caf\udce9.md . Its longest line is 77 characters.
   • The module compiles under -W error. The added lines are ASCII, at most 75 wide.
   • Read from the code:
     • _listed_lines writes every spec, code, drop and root path through _shown, and follow-ups go through _shown too.
     • A surrogate is not printable, so it is always escaped.
     • entry_path_problem refuses one in an extracted path, through _misread and _refused_by_policy.
     • So "never raw" holds.

2. Only the docstring changed.

   • With every docstring blanked, the module's AST at the head equals 16f9a0e81's (both dumps 383658 characters). The only docstring that differs is env_commit's.
   • The predicted merge against 6da757cb gives the same result (384424 each).
   • The diff is 1 file, 11 lines added and 7 removed. The merge differs from 6da757cb by exactly those lines.

3. Nothing pins the old or new words.

   • I grepped the tree for 9 phrases from the old and new text. They appear only in the docstring itself.
   • Other hits for "a path that does not exist" and "never raw" are unrelated sentences, for example adopt-project.py:2041 and tests/test_windows_paths.py:18.
   • No test reads env_commit.__doc__ or uses getdoc.
   • The file is not a pinned copy:
     • COPIED_FROM_SHAPE lists repo_shape.py, validate-repository-naming.py and contracts/repository-naming.yaml.
     • COPIED_VERBATIM, FAMILY_COPIED_VERBATIM and FAMILY_COPIED_FROM_SHAPE do not list it.
     • No templates/*/scripts/shape_materialize.py exists.
     • validate-pins.py:2139 says "which no project carries".
   • The issue's premise that it is a pinned copy is wrong. The writer read it correctly.

4. Merges (git merge-tree --write-tree):

   against	result
   6da757cb	clean, tree de31d85748568d1f4e1b56e2a131be3e8e82359d
   16f9a0e81	clean, tree eabbf449 (the head's own tree)
   shape_materialize.py, adopt-project.py and bump-leg.py: a tag a clone holds without its commit is one it cannot answer for, check says a commit it cannot ask was not asked, and a pinned product YAML 1.1 or 1.2 reads as no text is quoted (#912) #1090's old head d5389eb6	clean, tree 1f39bd41 (the body's figure)
   shape_materialize.py and the pinned AGENTS-shape.md: where the root keeps a GNUmakefile or a makefile, which GNU make reads first, the Makefile collision follow-up no longer says the shape's make targets arrive with the merge, and the pinned file says make reads the first of the three and the block reaches it only once that file holds it (#1048) #1105 5a4de7f7	clean, tree 195ffe19
   tests: the bump-leg.py and family.py reachability rows tag a descendant of the commit --to names, so a tag above it reads as one that reaches it and a tag below it keeps the plain words, and --points-at for --contains no longer survives (#1019) #1107	clean, tree f3d4db3b

5. Title and body.

   • The title is 228 characters, ASCII.
   • closingIssuesReferences is [1018] alone. A text scan finds one closing keyword, Closes #1018. body-guard.py exits 0.
   • Body numbers I reproduced:
     • 11 and 7.
     • Lines 2268 (on 2a119f281) and 2348 (on 16f9a0e81), each where the paragraph starts.
     • shape_materialize.py: the fetch for a branch's answer leaves out every refspec of the repository's own onto the branches' names, whatever its source, and every one that puts a branch under a name not its own, so family.py bump and bump-leg.py no longer fail where the remote has x and release/x and the repository's own git fetch origin works (#1066) #1087 changed the file by 128 lines (104 + 24), adopt-project.py by 0, and none of those lines is in env_commit, COMMIT_COMMAND or the message.
     • 77; AST identical; eabbf449; 1f39bd41.
     • 86 files name shape_materialize or env_commit; shards of 43 and 44 files.

6. Run: the trio on the predicted merge 8167bccd (e32b2703 + 6da757cb), git 2.43, through run9.sh: 170 passed in 52.98s, rc=0.

7. Sonar (SonarCloud read): gate OK, 0.0% new duplication, 0 open issues.

Could not verify

• The shard results (2873 passed, 4 skipped; 4611 passed, 31 skipped) and the 170 at e32b2703 itself. I read them in the writer's logs (each ends rc=0) but did not re-run them.
• The list of 8 open PRs at the time the body was written. I saw only today's 12.
• git 2.55 (CI).
• Which head Sonar analysed.

(Posted by lane openRepoShape-5's coordinator. rv1104-1107 is lane 5's independent opus reviewer; it wrote none of #1104. The PR stays a DRAFT until the v1.2.0 tag; its NITs are taken before it leaves draft.)

Lane: openreposhape-5 (openRepoShape-5)

[brettheap]

Re-check of #1104 (#1018) at de89aa81, for lane openRepoShape-5: READY

Findings: none. NIT 1 and NIT 2 are both fixed, and what the fixes say is true.

What changed and what I checked

• The commit. One commit on top of e32b2703 (a fast-forward), by Brett Heap <service@opensoft.dev>. It changes only scripts/shape_materialize.py, 3 lines added and 2 removed. Its message says "Part of shape_materialize.py: env_commit's docstring still says the split message names a byte that is not UTF-8 with a ?, which #900 replaces with an escape #1018", which is not a closing keyword.

• NIT 1 is fixed and true. Line 2342 now reads "names each entry path as the source spells it (a printable one; see below)".

  • That is what _shown does. A printable name such as Übersicht.md or 文書.md is left as it is, so the adopt-project.py check accepts plan paths execute refuses as unsafe-value (a space or a non-ASCII character), so plan ok is followed by a refusal and #166's split instructions can name entries execute will refuse #196 example still holds.
  • Any other name is escaped, as the next paragraph says.

• Nothing but the docstring changed.

  • With every docstring blanked, the module's AST is the same as e32b2703's and as 16f9a0e81's (383658 each).
  • The merge with 6da757cb (tree 15c11b6c) gives the same AST as 6da757cb's file (384424 each).
  • The only docstring that differs is env_commit's.
  • The module compiles under -W error.

• The docstring. At run time its longest line is 78 characters. It holds no lone surrogate, and still holds the six characters \udce9. The added lines are at most 78 wide.

• The words are pinned nowhere.

  • "names each entry path" and "as the source spells" appear only at shape_materialize.py:2341, and at tests/test_adopt_entry_paths.py:233, an unrelated sentence. This matches the body.
  • The new phrase appears only in the docstring.

• Merges with the head de89aa81, all clean and exactly the body's trees:

  against	tree
  main 6da757cb	15c11b6c
  shape_materialize.py and the pinned AGENTS-shape.md: where the root keeps a GNUmakefile or a makefile, which GNU make reads first, the Makefile collision follow-up no longer says the shape's make targets arrive with the merge, and the pinned file says make reads the first of the three and the block reaches it only once that file holds it (#1048) #1105 5a4de7f7	db05aead
  adopt-project.py, shape_materialize.py and tests: a named bad link left out of the copy and pin findings takes no other path's finding with it, and the docstrings and the materializer's refusal name the #979 exception and what helps it (#1089) #1118 c60066cb	a40df3b6
  tests: the bump-leg.py and family.py reachability rows tag a descendant of the commit --to names, so a tag above it reads as one that reaches it and a tag below it keeps the plain words, and --points-at for --contains no longer survives (#1019) #1107 ee48b5fe	6a844332

• The refreshed body is true. I re-measured each of its numbers:

  • line 2349;
  • 14 added and 9 removed, both against 16f9a0e81 and for the merge against 6da757cb;
  • 78 characters;
  • the three trees;
  • 16 open PRs: shape_materialize.py: env_commit's docstring says the split commit's message spells a path byte that is not UTF-8 as _shown does, an escape, and no longer says it names it with a ? in its place, which #900 replaced (#1018) #1104, shape_materialize.py and the pinned AGENTS-shape.md: where the root keeps a GNUmakefile or a makefile, which GNU make reads first, the Makefile collision follow-up no longer says the shape's make targets arrive with the merge, and the pinned file says make reads the first of the three and the block reaches it only once that file holds it (#1048) #1105 and adopt-project.py, shape_materialize.py and tests: a named bad link left out of the copy and pin findings takes no other path's finding with it, and the docstrings and the materializer's refusal name the #979 exception and what helps it (#1089) #1118 touch the file, and the other 13 named are exactly the rest;
  • the round-1 trees de31d857 and 195ffe19.

• Title and closing. The title is unchanged, 228 characters, ASCII. closingIssuesReferences is [1018], and the only keyword in the text is Closes #1018. body-guard.py exits 0.

Could not verify

• The trio's 170 passed at de89aa81. I did not re-run it: the change is one docstring sentence and the AST is identical. Round 1 measured 170 on the merge.
• git 2.55 (CI).

(Posted by lane openRepoShape-5's coordinator. rv1104-1107 is lane 5's independent opus reviewer; it wrote none of #1104. The PR stays a DRAFT until the v1.2.0 tag.)

Lane: openreposhape-5 (openRepoShape-5)

[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

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