[brettheap]

Lane: openreposhape-4 (openRepoShape-4)
Claim: #392 #392 (comment) ; #393 #393 (comment)

What changed and why

scripts/repo_shape.py's YAML subset reader read three kinds of text where PyYAML refuses the document, or reads another thing. Each is now a YamlError, so load_yaml turns it into REFUSED yaml-unparsable naming the file. That is the reader's existing refusal, in #252's and #301's voice. Re-measured on main 8f453d0 before the change: every row both issues list reproduced as the issue says.

#393, a block value or item. _scalar reads every plain value, block and flow, and its only test of the first character was &*!. It now also refuses a plain scalar that opens with ], }, ,, @, a backtick or %, or is a lone ? or :. _parse_mapping refuses a value that is a lone -. That one is refused there, not in _scalar, because a flow collection reads [-] and {a: -} as the text -, as PyYAML does and as #392 asks to keep.

document	before	now
k: ]	{'k': ']'}	a plain scalar cannot open with `]`, which closes a flow sequence in YAML: ']'
k: }	{'k': '}'}	... `}`, which closes a flow mapping in YAML: '}'
- ] / - } / k:\n j: ] / k: ]x / k: ] a	read as text	the same refusal, naming the scalar
k: ,	{'k': ','}	... `,`, which separates flow entries in YAML: ','
k: @a	{'k': '@a'}	... `@`, which is reserved in YAML: '@a'
k: `a`	{'k': '`a`'}	... a backtick, which is reserved in YAML: '`a`'
k: %a	{'k': '%a'}	... `%`, which opens a directive in YAML: '%a'
k: ?	{'k': '?'}	explicit keys are not supported: '?'
k: -	{'k': '-'}	... `-`, which opens a sequence entry in YAML: '-'
k: :	{'k': ':'}	... `:`, which opens a value in YAML: ':'

#392, a flow collection.

• An empty entry. _split_flow dropped every empty part. It now drops only the one after a trailing comma ([a,], {a: 1,}) and refuses any other: a flow collection holds an empty entry, which YAML allows only after its last comma: 'a,,b'. That covers k: [,a], [a,,b], [,], [a,,], {,} and {a: 1,,b: 2}. [], [ ] and {} read as before.

• An entry that opens with an indicator. The new _refuse_entry_indicator refuses an item, or a mapping entry whose key it opens, that opens with any of:

  • :, #, @, a backtick or %;
  • - or ? ;
  • a lone ?.

  It runs in _flow_value for a sequence's items and in _split_key_flow, where it replaces scripts/repo_shape.py reads ? a: b in a flow mapping as the literal key ? a, where the block reader refuses explicit keys, and refuses {a: } and {a:} as not a flow collection: '' instead of reading {'a': None} #252's ? test and keeps its words.

  document	before	now
  k: [:] / k: [: a]	[':'] / [': a']	a plain scalar cannot open with `:`, which opens a value in YAML: ...
  k: {:":} / k: {: a}	{':"': None} / {'': 'a'}	the same
  k: [#a] / k: {#a: 1}	read as text	... `#`, which opens a comment in YAML: ...
  k: [- a]	['- a']	... `-`, which opens a sequence entry in YAML: '- a'
  k: [? a]	['? a']	explicit keys are not supported: '? a'

  [-], [-a], {-: 1}, {a: -} and scripts/repo_shape.py reads ? a: b in a flow mapping as the literal key ? a, where the block reader refuses explicit keys, and refuses {a: } and {a:} as not a flow collection: '' instead of reading {'a': None} #252's {?a: b} read as before.

• A single pair in a flow sequence. _flow_value refuses an item that _split_key splits, after repo_shape.py: a flow collection with an unmatched ] or } is read, not refused, so k: {a"]:} reads {'a"]': None} since #284 (a quote toggle used to swallow the :}) and k: [a]] reads ['a]'], where PyYAML refuses both #301's bracket check (so k: [a: [b]] keeps repo_shape.py: a flow collection with an unmatched ] or } is read, not refused, so k: {a"]:} reads {'a"]': None} since #284 (a quote toggle used to swallow the :}) and k: [a]] reads ['a]'], where PyYAML refuses both #301's words): a single-pair mapping in a flow sequence is not supported: 'a: b'. k: [a: b], [a: b, c], [a:] and ["a": b] are refused; [a:b] and [{a: b}] read as before.

The decision on [a: b]: refuse it, not read it as PyYAML does ([{'a': 'b'}]). No file this reader serves can hold one:

• Every flow sequence in them is a list of names: neutral_product_pins, allow_empty_legs, also_matches, referent_chain. There, a mapping reaches the tool as a name, and validate-manifest.py's str(pin) makes it the pin "{'openGlass': 'x'}".
• Every list of mappings has rows of two keys or more, which no single pair can spell: legs (role, repository, path), members (project, repository, path), the shape pin's files (path, sha256), submodules, a plan's entries, a plan's pins (rows of five keys since aa4e1f5: product, repository, commit, tree_sha256 and digest_source; only an old plan's entry is a bare name), and the policies' rules and families.

So pins: [openGlass: x] is a typo, refused by name. It joins explicit keys in the header's REFUSED list, as valid YAML refused by design.

The pinned copy. scripts/repo_shape.py is the only copy in this tree, and no file or test here records its digest or blob. That matches #301's, #370's, #441's and #521's changes to it, which touched no pin. Each project takes it through update-shape.py, as an upstream-changed row on scripts/repo_shape.py.

Reach.

• The tree. Every string literal in tests/ and every tracked YAML file was read by the reader at main 8f453d0 and by this head: 41,675 inputs. No tracked YAML file reads differently (0 of 15). The 636 inputs whose answer changes are all prose that happens to parse: a FINDING <code>: message whose text opens with a backtick, or a docstring. None is a YAML fixture, and none crashes.
• The writers that ask this reader how a bare value reads. These are adopt-project.py's y and _neutral_pin_entry, the scaffold's pin entry, family.py's id, and shape_materialize's misread check. Each catches the YamlError and double-quotes the value, or refuses before anything is written.
• scaffold-project.py --org @x --project Atlas --dry-run. It exits 2 with scaffold-manifest-invalid and nothing created, on main and here. Main's detail is the validator's manifest-leg-repository finding. Here it is the manifest this run would write is a file the project's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Atlas'.
• The same --org @x reaches two more tools. SAFE_ARG_RE admits an @ anywhere in an --org, and --org is the one bare value a tool writes that can open with an indicator. Both were measured in standalone clones, on main 4cf5fb0 and on this head, with a gh shim that refuses everything:
  • adopt-project.py plan --org @x still exits 2 adopt-manifest-invalid and writes no plan. Its detail no longer names --org. Main said --org is '@x', which the project's own validate-manifest.py refuses: manifest-leg-repository: leg 'assembly': repository is '@x/Atlas', expected `<org>/<Name>`. ...; here it is the manifest this run would write is a file the project's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Atlas'.
  • family.py init --org @x --family Orbit [--dry-run] exited 0 on main. It printed a plan for @x/Orbit and asked gh repo view @x/Orbit, and without --dry-run (measured with --local-remote-dir) it went on to create the holder. Here it exits 2 family-manifest-invalid before anything is created, --dry-run alike: the manifest this run would write is a file the holder's own YAML reader refuses: a plain scalar cannot open with `@`, which is reserved in YAML: '@x/Orbit'.

Tests

New tests/test_yaml_indicator_openers.py, on tests/test_yaml_flow_brackets.py's harness:

• repo_shape.py: _scalar returns a BLOCK plain scalar that opens with ] or } as text, so k: ], k: } and - ] read as the strings ']' and '}', where YAML forbids a plain scalar to open with a flow indicator and PyYAML refuses, and the same fall-through reads k: ,, k: @a, `k: a and k: %a` #393's block rows: all 14, plus 7 more places a block plain scalar stands. A lone ? as a block item is refused as an explicit key.
• repo_shape.py: a flow collection with an empty entry (k: [,a], k: [a,,b], k: {,}) or an entry that opens with :, #, - or ? (k: [:], k: {:":}, k: [#a], k: [- a]) is read, where PyYAML refuses, and a single pair in a flow sequence (k: [a: b]) reads as the string 'a: b', where PyYAML reads [{'a': 'b'}] #392's rows:
  • all 6 empty entries, plus 6 more positions;
  • all 8 entries opening with an indicator, plus 17 more (the last is a lone ? as a whole flow-mapping entry, k: {?});
  • all 3 single pairs, plus 3 more (["a": b], an item after another, a pin-list typo).
• The controls, each equal to PyYAML: 18 block, 8 trailing-comma and empty-collection, and 12 flow. scripts/repo_shape.py reads ? a: b in a flow mapping as the literal key ? a, where the block reader refuses explicit keys, and refuses {a: } and {a:} as not a flow collection: '' instead of reading {'a': None} #252's {?a: b} still reads as the key ?a, and repo_shape.py: a flow collection with an unmatched ] or } is read, not refused, so k: {a"]:} reads {'a"]': None} since #284 (a quote toggle used to swallow the :}) and k: [a]] reads ['a]'], where PyYAML refuses both #301's words are kept for [a: [b]].
• Each refusal's words, whole (15 rows).
• Three files through load_yaml: yaml-unparsable, the file named, the detail in full.
• A scaffolded project's own scripts/validate-manifest.py on project.yaml edited three ways: exit 2, REFUSED yaml-unparsable: <path>: <words>, no manifest ok, no traceback, and the file as the edit left it.
• PyYAML (6.0.3 here): every row compared where it is installed, skipped with a reason where it is not. A refused row asserts PyYAML refuses it too, except the explicit-key rows, which PyYAML reads. A single-pair row asserts PyYAML reads the one-pair mapping the refusal replaces. A control asserts PyYAML's read equals this reader's.
• A seeded fuzz, on three seeds (392393, 1 and 3: 355, 369 and 374 small documents of block values and items, flow sequences and flow mappings). Each asserts no document is read where PyYAML refuses, no document is read differently, and every refusal of a document PyYAML reads is a by-design one. On this head, seed by seed: 231, 241 and 215 both refuse, 103, 100 and 124 both read the same, and 21, 28 and 35 are by design. On main 8f453d0: 215, 214 and 200 read where PyYAML refuses, and 15, 23 and 32 misread. The empty block key - : is left out (EMPTY_BLOCK_KEY): this reader reads it [{'': None}], PyYAML refuses it, and neither issue names it. The block table can draw it, and on seeds 1 and 3 it did, so the first round's fuzz was red there; a sweep of 303 other seeds on this head finds no disagreement.

The new file on main's reader (4cf5fb0, whose scripts/repo_shape.py is 8f453d0's, unmodified): 89 failed, 139 passed. The 139 are the controls and the comparisons with PyYAML.

Mutants. Each reverts one part of the fix, run against the new file; all killed:

mutant	what it reverts	result
M1	_split_flow drops every empty part again	killed, 16 failed
M2	_scalar's opener test and _parse_mapping's lone - (all of #393)	killed, 36 failed
M3	_refuse_entry_indicator back to #252's ? alone	killed, 21 failed
M4	no single-pair refusal	killed, 10 failed
R3 (R392's)	_refuse_entry_indicator drops or text == "?", so {?} gives "flow mapping entry without a key"	killed by the new row k: {?} (lone-question-mark-entry): 1 failed, 328 passed in the new file with test_yaml_flow_mappings.py and test_yaml_flow_brackets.py; it survived the first round
T1 (test side)	the fuzz draws - : again	killed, 2 failed (seeds 1 and 3), 1 passed

Targeted run, first round, on 2c0b157's bytes (scripts/repo_shape.py sha256 c5492f10c726b7dd8829b16f4d7ed058e1914a9c8f3232e5b424f343f67af458, the test 79d7e6ecd6a9acdf132c9ef0ecda5a1a45ef2b230b64de8edd01b2bfb0e1ea7e). Linux, Python 3.12.3, pytest 9.1.1, git-filter-repo 2.47.0 on PATH, PyYAML 6.0.3. One background run of 30 files: 2859 passed, 28 skipped, 0 failed in 13:14.

• Files: the new file, the reader's own files (test_yaml_flow_brackets, test_yaml_flow_mappings, test_yaml_flow_quotes, test_yaml_quote_boundaries, test_yaml_block_scalar_keys, test_load_yaml_refusals, test_manifest_validator), and the files that call _scalar or ask the reader how a value reads (test_adopt_plan_yaml_quoting, test_leg_path_yaml_scalars, test_adopt_plan_escapes, test_template_quoted_values, test_template_values_single_pass, test_template_text_placeholders, test_scaffold_manifest_values, test_adopt_manifest_values, test_scaffold_free_text_values, test_family_init_values, test_adopt_spelled_unambiguous, test_adopt_pins, test_scaffold_referent_chain_links, test_shape_pin_files_not_a_list). Then the validators (test_pin_validator, test_neutral_pin_validator, test_validator_child_encoding), the plan (test_adopt_plan, test_adopt_entry_paths), and test_repo_hygiene, test_cli_reference, test_agents_md_codes.

• The 28 skips:

  • 8 in test_leg_path_yaml_scalars.py: empty parameter sets, and "the templates read 2026 back";
  • 19 in test_family_init_values.py: "this template quotes ...";
  • 1 in test_adopt_plan.py:435: SHAPE_MEDXEHR_CLONE unset.

  Those two files collect the same 332 items on main and on this head.

• Fix round 1 (f852e6fd), on its own bytes (scripts/repo_shape.py sha256 616955934b689a71477cb03e844bcfc8fb20e42410b2dac457f0b27732307af8, the test 2ac8e7eee2a4ade68f68dab16091f19bce8c7a7d96ef1efc524b1706c75ce64a). scripts/repo_shape.py changes in comments and docstrings only: its AST is equal to 2c0b157's once docstrings are stripped, so the 30-file run above holds for the reader's code. One background run of the 11 files this round changed or that read the YAML reader by name (the nine ls tests | grep -i yaml files, test_repo_hygiene and test_cli_reference): 1291 passed, 8 skipped, 0 failed in 1:53. The 8 skips are test_leg_path_yaml_scalars.py's, as above. The new file is 228 tests, 225 before.

• Not run here: the full suite (CI is the gate). The test writes its files as bytes and passes nothing to git on stdin.

What it cannot tell

These still read where PyYAML refuses or reads another thing. Neither issue claims them, so they are left as they were, for #457–#461's checklists:

• ?, : or - followed by a space and more text, as a VALUE (k: - a, k: : a, k: ? a, {x: - a}, {x: ? a}). tests/test_yaml_flow_mappings.py::test_a_question_mark_in_a_value_is_not_a_key_in_a_flow_or_a_block pins {x: ? a} to read as its block twin x: ? a. Its docstring calls refusing them "a different change, the same one for the two forms if it is made". repo_shape.py: _scalar returns a BLOCK plain scalar that opens with ] or } as text, so k: ], k: } and - ] read as the strings ']' and '}', where YAML forbids a plain scalar to open with a flow indicator and PyYAML refuses, and the same fall-through reads k: ,, k: @a, `k: a and k: %a` #393 claims only the lone indicator.
• A flow value opening with : and a character ({a: :b}). Its block twin a: :b reads ':b', as PyYAML does.
• A flow ?a ([?a], {?a: b}). PyYAML reads an explicit key. scripts/repo_shape.py reads ? a: b in a flow mapping as the literal key ? a, where the block reader refuses explicit keys, and refuses {a: } and {a:} as not a flow collection: '' instead of reading {'a': None} #252 keeps the key ?a, and repo_shape.py: a flow collection with an empty entry (k: [,a], k: [a,,b], k: {,}) or an entry that opens with :, #, - or ? (k: [:], k: {:":}, k: [#a], k: [- a]) is read, where PyYAML refuses, and a single pair in a flow sequence (k: [a: b]) reads as the string 'a: b', where PyYAML reads [{'a': 'b'}] #392 claims it neither way.
• A ? inside a flow scalar ([e?], scripts/repo_shape.py reads ? a: b in a flow mapping as the literal key ? a, where the block reader refuses explicit keys, and refuses {a: } and {a:} as not a flow collection: '' instead of reading {'a': None} #252's {a: b?}). PyYAML ends the scalar there and refuses.
• | and > opening a plain scalar. In a block, _opens_block_scalar reads >= 3 as text by design; in a flow, the reader reads [|a].
• A block KEY that opens with an indicator (@a: 1, ]: 1, - :), and &, * or ! opening a flow key.
• A lone - with a space after it, inside a flow ([- ]). The reader strips each entry, so it cannot tell [- ] from [-], which PyYAML reads.
• scaffold-project.py:1496's docstring uses id: - as "the text" a bare line reads. The reader now refuses id: -. The point it makes (ask the list entry) still holds; the example is one word out of date, in a file this PR does not touch.

Shared files

Head f852e6fd (fix round 1, on 2c0b1573). git merge-tree --write-tree --name-only f852e6fd <ref> at 2026-10-16T10:40:34Z, each head read with ls-remote first (10:40:10Z):

• origin/main 6f760b7a: clean, tree f8f27e95. Main has not touched scripts/repo_shape.py or tests/test_yaml_indicator_openers.py since this branch's base 8f453d0: git diff --name-only 8f453d0e 6f760b7a -- scripts/repo_shape.py tests/test_yaml_indicator_openers.py is empty, and the two blobs of scripts/repo_shape.py are equal.
• repo_shape.py and validate-repository-naming.py: a chain link, a declared pin and a --link-source key are one product by pin_product_key, the pin file's own fold, so a tree declaring openss no longer verifies a chain that says openß, a chain naming both is two links and not a cycle, and --link-source openss= no longer answers for openß (#444) #638 fix/444-chain-fold, bae24e3b (lane 4; the chain readers in this file): clean, tree 849bac28. Its hunks in scripts/repo_shape.py begin at base line 1377 (_pinned_basenames, _chain_link_findings, NamingPolicy, link_pins_from_trees); this PR's end at base line 852.
• Pinned shape copies: one bump, so AGENTS-shape.md is true of every root, the scaffold's chain WARNING offers only its own sources and spells --pin-source, the root's not-used note spells it too, and THE LOCKSTEP RULE's bump runs (#610) #634 fix/610-pinned-text, 6dad64bc (lane 2): clean, tree 33727cfb. Its hunks in scripts/repo_shape.py begin at base line 909 (in git_out), then _chain_link_findings, link_declarations, LinkPins and link_pins_from_trees.

This PR changes the YAML reader in scripts/repo_shape.py (its hunks lie between lines 196 and 977 of the head) and no chain reader, which begin at CHAIN_RECORD_FIELD, line 1301.

Closes #392
Closes #393

🤖 Generated with Claude Code

Summary by Sourcery

Align the repository's YAML subset reader with YAML parsing boundaries by refusing malformed and ambiguous constructs rather than silently accepting incorrect values.

Bug Fixes:

• Prevent the YAML subset reader from accepting malformed or ambiguous plain scalars and flow entries that PyYAML rejects or interprets differently.
• Reject empty flow entries and single-pair mappings in flow sequences instead of silently misreading them.

Enhancements:

• Preserve supported YAML controls, trailing commas, quoted values, and nested flow collections while providing targeted refusal messages for unsupported syntax.

Documentation:

• Document the YAML reader's indicator handling and intentional refusal of unsupported constructs.

Tests:

• Add comprehensive indicator, empty-entry, single-pair, file-loading, validator, PyYAML comparison, and seeded-fuzz coverage for YAML parsing behavior.

[sourcery-ai]

Reviewer's Guide

The PR tightens the custom YAML subset reader so indicator-opening scalars, non-trailing empty flow entries, and single-pair flow-sequence mappings are refused instead of silently misread, while preserving supported legacy cases. It adds detailed regression, PyYAML comparison, fuzz, refusal-message, file-loading, and validator integration tests.

Flow diagram for YAML subset refusal rules

flowchart TD
    Input[YAML input] --> Reader[scripts/repo_shape.py]
    Reader --> Block[Block scalar checks]
    Reader --> Flow[Flow collection checks]
    Block --> Indicator{Indicator-opening scalar?}
    Indicator -->|Yes| Refuse[YamlError]
    Indicator -->|No| Parse[Parse supported value]
    Flow --> Empty{Non-trailing empty entry?}
    Empty -->|Yes| Refuse
    Empty -->|No| Pair{Single-pair mapping in flow sequence?}
    Pair -->|Yes| Refuse
    Pair -->|No| Parse
    Refuse --> Load[load_yaml]
    Load --> Result[REFUSED yaml-unparsable]

Loading

File-Level Changes

Change	Details	Files
Reject YAML constructs that the custom reader previously misinterpreted as plain scalars or valid flow entries.	Add indicator-aware refusal messages for block plain scalars, including lone ?, :, and - cases. Reject flow entries beginning with YAML indicators while preserving established exceptions such as [-], [-a], and {?a: b}. Reject empty flow entries except a single trailing comma, preserving empty collections and valid trailing commas. Reject single-pair mappings inside flow sequences rather than converting them to strings. Document the expanded refusal policy in the reader comments and docstrings.	scripts/repo_shape.py
Add comprehensive regression, compatibility, and integration coverage for the YAML reader changes.	Cover all issue cases, refusal wording, nested contexts, controls, quoted values, and trailing-comma behavior. Compare applicable cases against PyYAML and use seeded fuzzing to detect misreads or unexpected divergences. Verify load_yaml and project validators report yaml-unparsable with the file path and preserve edited files. Exercise the project-copied reader through scaffolded validation.	tests/test_yaml_indicator_openers.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#392	Refuse flow sequences and mappings containing an empty entry, while continuing to allow a single trailing comma and genuinely empty collections.	✅
#392	Refuse flow items or mapping keys that open with the specified YAML indicators, including :, #, - , and ? , without changing supported controls such as [-] and [-a].	✅
#392	Do not silently read a single-pair mapping in a flow sequence as a plain string; refuse it (or read it as a mapping), while preserving ordinary scalars and nested mappings.	✅
#393	Refuse block plain scalars that open with ] or }, rather than silently reading them as text, across mapping values and sequence items (including nested block values).	✅
#393	Preserve valid block-scalar readings where indicator-like characters occur later in the scalar, and preserve quoted scalars containing them.	✅
#393	Propagate the corrected refusal through the shared YAML reader so file-loading callers, including scaffolded projects, report the file as YAML-unparsable.	✅

Possibly linked issues

• repo_shape.py: a flow collection with an empty entry (k: [,a], k: [a,,b], k: {,}) or an entry that opens with :, #, - or ? (k: [:], k: {:":}, k: [#a], k: [- a]) is read, where PyYAML refuses, and a single pair in a flow sequence (k: [a: b]) reads as the string 'a: b', where PyYAML reads [{'a': 'b'}] #392: Link to repo_shape.py: a flow collection with an empty entry (k: [,a], k: [a,,b], k: {,}) or an entry that opens with :, #, - or ? (k: [:], k: {:":}, k: [#a], k: [- a]) is read, where PyYAML refuses, and a single pair in a flow sequence (k: [a: b]) reads as the string 'a: b', where PyYAML reads [{'a': 'b'}] #392: the PR refuses empty flow entries, indicator-opening flow entries, and single-pair mappings in flow sequences.

---

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
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 10 hours and 24 minutes by commenting @sourcery-ai review. Upgrade to get a review now.