[brettheap]

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

Closes #980.

Goal

For a declared-unverified chain link whose name holds =, the naming gate offers only sources that verify that link's tree when typed as printed. The gate offered open=y the source --link-source open=y=<path>, and read every --link-source key at the value's first =: the key was open, which no chain names, so the value was a bare PATH for the first link, open=y stayed declared-unverified under the same offer, exit 0.

What changed

The issue's direction (a), in scripts/validate-repository-naming.py. LinkSources._read_source reads a --link-source key the way _read_remedy reads a --link-remedy link since #949: the longest text before an = that names a link of a chain this run reads, by pin_product_key, and leaves a path after it. __init__ and no_path both take the key and the path from it, so the path refused as empty is the one after the key's own =. For a chain whose links hold no =, every value is read exactly as before: a text holding = can only name a link that holds one.

What (a) keeps from the documented rules, and how each case was checked (probes below, and one test row or more each):

• A link holding =: open=y=<tree> verifies open=y, as printed and in capitals (OPEN=Y=<tree>, by pin_product_key as every key is).
• Two links where one is a prefix of the other (open and open=y in one chain): open=y=<tree> is open=y's and open=<tree> is open's, in either order. On main both were open's and the later replaced the earlier, so open=y read none.
• A path that itself holds =: open=y=<dir>/a=b/tree is open=y's with that whole path. A text holding / names no link, since a link's name is repo_basename'd, so an = after a / never ends the key. A path that begins like a longer link's name is given after ./: open=./y=dir is open's in a chain naming open=y too.
• A key that names a link but leaves an empty path: open=y= is PRODUCT= for open=y, refused as link-source-no-path, exit 2, as openXdox= is (scripts/validate-repository-naming.py _link_sources_from_args (:406) and templates/assembly-root/scripts/validate-pins.py PinSources (:409): a key with an empty path (--link-source openXdox=, --pin-source openXdox=) is Path(""), which is the current directory, so run from a project root the naming gate reads the project's OWN project.yaml as the link's declaration and reports a chain that holds as broken, a FINDING (exit 1) for a name with no direct pin #442). On main it was a bare PATH asked for openXdox, a link the person did not name. Where a shorter link leaves a path (open=y= with open in the chain too), that link is the key, open with the path y=, as --link-remedy openXdox=y= gives openXdox the words y= where a chain names openXdox=y: the longest link that leaves a path wins, and open=y leaves none.
• A value that is a real directory spelled like the whole value: open=y=x beside a directory open=y=x is still open=y's, decided by the chain and not the disk, with _also_a_directory's line; ./open=y=x asks for the directory, as a bare PATH for the first link.
• The key is read whole, where a remedy's link is stripped and cut at its last /: open=y=<tree> and opensoft/open=y=<tree> name no link and stay bare PATHs, as on main.

One difference from --link-remedy, deliberately. --link-remedy open=y= is a NOTE (its link falls back to the first =, open). --link-source open=y= is refused, because the #442 rule refuses PRODUCT= for every link, and --link-remedy's own openXdox= refusal is made by argparse before the chains are known, which is why it cannot catch open=y=. _read_source's docstring says so.

Not (b). (a) makes the offer the gate already prints true, so the person who types it gets the verification; (b) would only stop offering it. Setup's step (4) is unchanged: it passes the gate its --pin-source as an absolute path, with a separator before every =, so no text before one names a link.

Docs. The module docstring (a new paragraph, "A KEY IS THE LONGEST LINK A VALUE NAMES"), the LinkSources, _link_remedy and _read_remedy docstrings, the --link-source help, and docs/cli.md regenerated from it. setup-project.py's as_the_plan_reads_it docstring stated the first-= rule, and now states this one. README, the handbook and AGENTS.md state no rule for how a --link-source key is read (README names --link-source PRODUCT=<path> only), so they are unchanged. The class docstring records that validate-pins.py still ends a --pin-source key at the first =; no scaffold writes a pin holding one (--pin names are [A-Za-z0-9_.-]), and it is left as its own change.

What a project sees (the upgrade row)

Measured from a root scaffolded at main 5b41d44f (local remotes, no network):

• update-shape.py check --upstream <this checkout> --at c64e85fea lists upstream-changed scripts/validate-repository-naming.py, with upstream-changed 1 unchanged 10.
• update-shape.py apply --yes --branch ... exits 0, commits contracts/shape-pin.yaml, project.yaml and the copy, and the project's validators print pins ok and manifest ok. A fresh check prints unchanged 11, and the root's own naming gate exits 0.
• The new sha256 of scripts/validate-repository-naming.py: ec167fb0e259f90705db895a1a37f4adebd4cbf03ca2d5ae18f6d9a8df896548 (78664 bytes). No other pinned copy and no template changes.

Probes, before and after

Run from empty folders, <D> a fresh folder, trees as named (trees/y declares openInk, trees/x declares open=y; for the chain with open, trees/x2 declares open and trees/o declares open=y). The gate prints an arrow between links; it is written -> here.

Probe	At main 5b41d44f	At head c64e85fe
P1, the issue's row: --referent-chain openXdox,open=y,openInk --link-source open=y=<D>/trees/y	link-source-unreadable ... could not answer for openXdox, "It was read as a PATH: open is not a link", and open=y declared-unverified with the same offer; exit 0	only openXdox declared-unverified (no source named it); no link-source-unreadable; exit 0
P2, P1 plus openXdox=<D>/trees/x, --explain	NOTE: the value not used, read as a PATH; CHAIN openXdox -> open=y -> openInk [declared-unverified]	[verified], nothing warned or noted
P3, chain openXdox,open,open=y,openInk, open=<o> then open=y=<y>	link-source-unreadable: y=<D>/trees/y (--link-source open=...), NOTE open=<o> replaced; 2 links declared-unverified	[verified], nothing warned or noted
P4, open=y= (chain without open)	bare PATH open=y= asked for openXdox; exit 0	REFUSED link-source-no-path: --link-source open=y= names no path for open=y; exit 2
P5, open=y= (chain with open)	y= (--link-source open=...) could not answer for open	the same
P6, open=y=<D>/trees/a=b/y	read as a PATH, [declared-unverified]	[verified]
P7, open=y=x beside a directory open=y=x	bare PATH, read as the directory for openXdox	link-source-unreadable: x (--link-source open=y=...) could not answer for open=y, then "open=y=x is also a directory; --link-source ./open=y=x reads it as one."
P7b, ./open=y=x	the directory, for openXdox	the same
P8, chain with open: open=./y=dir, open=y=<y>	open=y=<y> read for open, replacing open=./y=dir	[verified]

Tests

Eleven new rows in tests/test_chain_remedy_callers.py, section "#980", reusing its helpers (naming, tree, gate_warnings, UNREACHED, GATE_OFFER, EQUALS), with no assert that joins conditions with and:

• test_the_offer_for_a_link_holding_an_equals_verifies_it[as-printed, in-capitals, a-path-holding-an-equals]: reads the offer the gate prints for open=y, types it with a tree, and asserts the one WARNING left is openXdox's, with no link-source-unreadable and no NOTE.
• test_each_link_reads_its_own_source_where_one_name_begins_another[open-first, open=y-first, a-path-that-begins-like-the-longer-link]
• test_a_value_that_ends_at_a_link_holding_an_equals_names_no_path
• test_a_shorter_link_that_leaves_a_path_is_the_key
• test_a_link_holding_an_equals_wins_over_a_directory_spelled_like_it
• test_a_key_is_read_whole[a-blank, an-owner]

Failing at main. The test file copied onto a git archive of 5b41d44f: 8 of the 11 fail, each on the defect (the offer row's open=y WARNING and link-source-unreadable, the prefix rows' [declared-unverified], open=y= exiting 0, the keyed reading not winning over the directory). The other 3 pass at main by design: they pin behaviour main already had (test_a_shorter_link_that_leaves_a_path_is_the_key, test_a_key_is_read_whole[a-blank] and [an-owner]), and each kills a mutant below.

Mutants, each applied alone to the fixed gate in a scratch repository, then test_chain_remedy_callers.py, test_link_source_chain_defaults.py, test_naming_policy.py, test_chain_link_fold.py and test_chain_pin_sources.py (400 passed, 4 skipped with no mutant). All 11 killed:

Mutant	Failed	Killed by (new rows unless named)
M1 back to typed.partition("=")	8	the offer rows, the prefix rows, open=y=, the directory row
M2 the shortest match instead of the longest	3	the prefix rows
M3 the "leaves a path after it" check dropped	1	test_a_shorter_link_that_leaves_a_path_is_the_key
M4a the ./PATH rule dropped (./ stripped from the key)	3	the directory row; test_a_labelled_source_holding_an_equals_is_not_said_to_be_a_path; test_naming_policy.py::test_a_link_named_before_the_equals_is_the_key_even_over_a_directory
M4b the key cut at its last /, as a remedy's link is	4	as M4a, and test_a_key_is_read_whole[an-owner]
M5 the empty-path fallback dropped	6	open=y=; test_a_value_that_names_no_path_is_spelled; 4 rows of test_link_source_chain_defaults.py::test_a_link_source_that_names_no_path_is_refused
M6 the fallback at the first =, as a remedy's	1	open=y=
M7 no_path taken after the first =	1	open=y=
M8 the keyed path taken after the first =	7	the offer rows, the prefix rows, the directory row
M10 the key stripped, as a remedy's link is	1	test_a_key_is_read_whole[a-blank]
M12 the key not folded by pin_product_key	56	in-capitals and the prefix rows, and 52 existing rows

Runs, all on head c64e85fe, /usr/bin/python3 -m pytest -q -p no:cacheprovider -o tmp_path_retention_policy=failed, one reused basetemp per run, with EMAIL=service@opensoft.dev, a stub gh first on PATH, GH_TOKEN=bogus, an empty GH_CONFIG_DIR, GIT_SSH_COMMAND=false and GIT_CONFIG_GLOBAL=/dev/null:

• git 2.43.0 (/usr/bin/git), 31 files: the 25 that run the naming gate (grep -l validate-repository-naming tests/, the pinned-copy files test_pinned_copy_text.py, test_update_shape_kept_helper.py, test_update_shape_unreadable.py and test_adopt_reencoded_files.py among them, and test_repo_hygiene.py), the files that scan every script's source (test_git_output_decoding.py, test_shape_advisory.py, test_no_auto_maintenance.py, test_non_utf8_git_failures.py), and the trio's other two, test_agents_md_codes.py and test_cli_reference.py: 2964 passed, 5 skipped in 1749 s, exit 0.
• git 2.47.1 first on PATH, the 25 naming-gate files: 2680 passed, 3 skipped in 1181 s, exit 0.

No template changes. grep of tests/ found no fixed digest or ^id:-style pattern over the gate: the tests that read a root's copy of it (test_shape_doctor.py, test_doctor_validator_verdicts.py) compare it at run time, and both are in the first run, as are the source scanners above and test_cli_reference.py, which holds docs/cli.md to the help.

Merge-trees

• git merge-tree --write-tree origin/main HEAD, origin/main 5b41d44f (fetched with -c gc.auto=0 -c maintenance.auto=false, and git ls-remote agrees): clean, tree 82780dc63d7f, the head's own tree.
• Open pull requests: none of the 9 open (the family root's bootstrap.py: a gitlink a member's own index gives no url, or a member's commit that a fetch reaching its remote did not bring, fails the run by name with its cure and no credential advice, where it said family bootstrap ok beside git's exit 128 (#892) #954, the family root's bootstrap.py and siblings.py: under GNU make 4.4's named-pipe jobserver, a member's make that says it is 4.4 or later is handed the holder's MAKEFLAGS as it is, so it runs its jobs together again; every other make still gets no jobserver and no -j (#987) #1023, validate-family.py: a hand mount's git rm line works typed: git rm --cached where a plain one refuses a staged gitlink, dies on a clone no section names or refuses what is no checkout, with what it leaves said, and a .gitmodules gone from the work tree put back before the git rm that takes a section out (#936) #1025, family.py: bump's fetch leaves out every refspec of the mount's whose source can name a tag, a pattern such as refs/* and a short name too, so a mirror in a folder, +refs/*:refs/remotes/origin/all/*, no longer fails the fetch on a branch and a tag of one name or pins a commit only a tag reaches (#1009) #1027, validate-family.py, validate-pins.py and both bootstrap.py copies: a git Windows cannot execute ([WinError 193], a nameless OSError) is git-not-runnable, exit 2, with the put-git-on-PATH remedy, where each ended in a traceback, exit 1, and one test holds the four copies to one answer and one text (#1001) #1028, adopt-project.py: the split commit's message and plan's report name each path, question and rule id one way only and never raw, the history scan's git-failed is one line, and the table pads a name as stdout prints it (#900) #1030, adopt-project.py: check's throwaway repositories are made in the work directory with the source's object format and no hook of this machine's; a path git refuses is plan-path-git-refuses, a repository git cannot make there adopt-git-unasked (#910) #1031, adopt-project.py, shape_materialize.py and standard.py: the Free-plan hint no longer calls an internal root private, adopt's docstring says its note for an internal root with an unread plan changed in #969, and prepare's docstring has no 104-character line (#994) #1038, family.py and tests: Family.rewritten's refusal of two members: lines is asked of the method again, its docstring says no verb reaches that count since #974, and a refusal that leaves a ref behind fails assert_unchanged (#1029) #1039) touches scripts/validate-repository-naming.py, tests/test_chain_remedy_callers.py, setup-project.py or docs/cli.md, so there is no merge-tree to run against them.

🤖 Generated with Claude Code

Summary by Sourcery

Fix --link-source parsing so printed verification offers work for chain links whose names contain =, while documenting and testing the updated behavior.

Bug Fixes:

• Ensure --link-source values correctly verify chain links whose names contain = by selecting the longest matching link that leaves a non-empty path.
• Refuse --link-source values that identify a matching link but provide no path.

Enhancements:

• Clarify and align --link-source parsing behavior across the validator's documentation and setup guidance.
• Add coverage for link-name prefixes, case normalization, paths containing =, directory ambiguity, empty paths, and literal key handling.

Documentation:

• Update the CLI and validator documentation to describe longest-match --link-source key parsing and links containing =.

Tests:

• Add regression tests covering --link-source verification offers and matching edge cases for chain links containing =.

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

[brettheap]

(lane openRepoShape-5, 2026-10-20T06:34Z) @codex review

[sourcery-ai]

Reviewer's Guide

This PR fixes --link-source parsing so the gate's remediation offer remains valid for chain links whose names contain =, selecting the longest case-folded link key that leaves a path and correctly refusing empty keyed paths. Documentation and CLI help are synchronized, and extensive regression tests validate overlapping names, path edge cases, directory precedence, and the printed-offer workflow.

Sequence diagram for validating a printed source offer

sequenceDiagram
    participant Gate
    participant LinkSources
    participant ChainLink
    Gate->>LinkSources: _read_source(open=y=<path>)
    LinkSources->>LinkSources: Match longest key open=y
    LinkSources-->>Gate: link=open=y, path=<path>
    Gate->>ChainLink: Verify source tree
    ChainLink-->>Gate: verified

Loading

Flow diagram for --link-source key resolution

flowchart TD
    A["--link-source value"] --> B{"Find matching chain link before ="}
    B --> C["Select longest case-folded match that leaves a path"]
    C --> D["Use matched link and remaining text as path"]
    B --> E["No matching link"]
    E --> F["Treat entire value as bare PATH"]
    D --> G{"Path is empty?"}
    G -->|Yes| H["Refuse link-source-no-path"]
    G -->|No| I["Verify the matched link's tree"]

Loading

File-Level Changes

Change	Details	Files
Changed --link-source parsing to support chain-link names containing = while preserving path and directory disambiguation rules.	Added longest matching chain-link detection that leaves a non-empty path, using case-folded product keys. Refused keyed sources whose selected path is empty, while retaining bare-path fallback behavior. Kept source keys whole, without trimming or slash-based rewriting, and documented the distinction from --link-remedy and --pin-source. Updated CLI help, module/class/function documentation, generated CLI reference, and setup-project planning text.	scripts/validate-repository-naming.py docs/cli.md setup-project.py
Added focused regression coverage for source offers, embedded equals signs, overlapping link names, empty paths, directory ambiguity, casing, and literal key handling.	Verified that the gate's printed --link-source open=y=<path> offer actually verifies open=y when reused. Covered longest-match behavior for open versus open=y, including paths containing = and paths prefixed with ./. Covered refusal of PRODUCT= and preservation of whole-key behavior for whitespace and owner-prefixed values.	tests/test_chain_remedy_callers.py

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#980	Make a --link-source value naming a chain link that contains = parse the longest matching link name that leaves a path, so the gate’s printed offer verifies that link when typed as printed.	✅
#980	Preserve and document the existing source-reading rules while supporting the new key parsing, including prefix-overlapping link names, paths containing =, the ./PATH directory escape, and refusing a keyed value with no path.	✅
#980	Add regression tests for the reported failure and relevant parsing edge cases, and update the CLI documentation and help text to describe the new behavior.	✅

Possibly linked issues

• validate-repository-naming.py: the --link-source <link>=<path> the gate offers for a chain link holding = is read as a bare PATH when typed, so it never verifies that link #980: The PR fixes the parser fault by treating unmatched = text as a bare path and matching keys against chain links; the traceback fault remains.

---

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 Summary

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

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-20T06:37:04.808913Z	c64e85f	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.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Chef's kiss.

Reviewed commit: c64e85fea2

ℹ️ 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".

[brettheap]

Independent review of #1044 (#980) at c64e85fe, for lane openRepoShape-5: READY

Reviewed from 09:38Z to 09:59Z, read-only. The head is c64e85fea28ee9fb54581e93abb0e09abdba1d48, one commit on 5b41d44f. Its tree is 82780dc63d7f…, the same as the body says.

Findings, most severe first

There is no MUST and no SHOULD.

NIT-1 (test strength): four of my seven mutants survive the five closest test files (404 passed each time). Each one changes output, and three of them break the body's claim that a chain whose links hold no = is read exactly as before. The claim is true at the head: I checked it by probe (below). But no test holds it in these corners.

• R10, at scripts/validate-repository-naming.py:439: at = typed.rfind("=", 0, at - 1) skips an = that sits right before the current one.
  • At the head, --link-source openXdox==x (chain openXdox,openYdox,openInk) gives link-source-unreadable: =x (--link-source openXdox=...), the same as main.
  • Under R10 it becomes a bare PATH, and the run adds a false line: "It was read as a PATH: openXdox is not a link".
• R1, at line 437: typed[at + 1:].strip(). --link-source 'openXdox= ' stops being keyed to the path and becomes a bare PATH, with the same false "not a link" line.
• R14, at line 385: no_path tests [1].strip(). The same value 'openXdox= ' is then refused, exit 2. At the head it exits 0, as on main.
• R5, at line 438: return typed[:at], … spells the link as typed. With OPEN=Y=<tree> and the name brett-wip, the NOTE reads "reads OPEN=Y's own declaration" where the head prints open=y's.
• Suggested fix: three rows would kill all four.
  • openXdox==x (or open=y==): the keyed path =.
  • 'openXdox= ': keyed to a blank path, and not refused.
  • A capitals-typed OPEN=Y=<tree> in a run that reads no declaration: the NOTE names open=y.

NIT-2 (docs, left with the follow-up): templates/assembly-root/scripts/validate-pins.py:1496-1497 still says "the two copied tools read [PRODUCT=]PATH one way over ASCII alone". Since #980 that holds only for names with no =. The naming gate's own class docstring now records the difference (lines 268-272). Fix this sentence in the same follow-up that changes validate-pins.py's first-= reader, not here: it is a pinned copy, so changing it would add a second upgrade row.

Rulings on the writer's open points:

1. The "It was read as a PATH" line still names only the text before the first = (read_as_path, line 623). Ruling: NIT, follow-up only. Under the new reading the line is always true: a value whose first-= text names a link is always keyed, never bare. It can still mislead:

   • P15: open=z=<p> says "open is not a link".
   • PJ4: --link-source open=y, with no path, says "open is not a link … (links: openXdox, open=y, openInk)".

   Both print the same bytes on main, so this is not a regression. The list of links makes the mistake recoverable.

2. validate-pins.py still ends a --pin-source key at the first = (line 1520). Ruling: fine as its own change. A scaffold never writes such a pin (PIN_ARG_RE is [A-Za-z0-9_.-], scripts/shape_materialize.py:3215), and the pin digest stops a wrong source from passing.

Checked and true, with numbers

• The new key reading. Every probe ran on base and head, from the same empty folder.
  • The body's table, P1 to P8 and P7b: every cell matches what I measured.
  • Capitals (OPEN=Y=): verified.
  • A leading blank and an owner (opensoft/): both stay bare PATHs, byte for byte as main.
  • open=y==: keyed to open=y with the path =.
  • a=b=c= with the links a, a=b and a=b=c: read as a=b with the path c=. This is the documented "longest link that leaves a path" rule, the same as --link-remedy.
  • open=./y=dir: verified. Without the ./, open=y=dir is read as open=y's, as documented, and the "replaced" NOTE is true.
  • --project with a leg chain holding opensoft/open=y: the printed offer verifies the link.
  • Stdin mode: verified.
• No = in any link: byte for byte as main. 800 runs on base and head, comparing stdout, stderr and exit code, with 0 differing. The runs cover 4 chains (including a qualified link and openß), 32 values, one and two --link-source values per run, with and without --explain, and --project mode.
• The deliberate difference. open=y= is refused as link-source-no-path, exit 2, as openXdox= is under scripts/validate-repository-naming.py _link_sources_from_args (:406) and templates/assembly-root/scripts/validate-pins.py PinSources (:409): a key with an empty path (--link-source openXdox=, --pin-source openXdox=) is Path(""), which is the current directory, so run from a project root the naming gate reads the project's OWN project.yaml as the link's declaration and reports a chain that holds as broken, a FINDING (exit 1) for a name with no direct pin #442, and the refusal is right. Every clause of the message is true, including "or .": open=y=. verifies. With the label, the value is still refused under the gate's own flag, as the chain WARNING offers --link-source to callers that do not take it (validate-manifest.py, setup's step (4)), and the naming gate prints --link-source values raw #661 documents.
• No caller is newly refused. Setup's step (4) is the only caller that passes --link-source, and it always passes an absolute path (as_the_plan_reads_it). Bootstrap, CI's validate.yml and the doctor pass none. validate-manifest.py and the scaffold do not call the gate.
• The upgrade row, from a root scaffolded at 5b41d44f with local remotes:
  • check lists upstream-changed 1 unchanged 10 (scripts/validate-repository-naming.py).
  • apply --yes --branch … exits 0 and commits contracts/shape-pin.yaml, project.yaml and the copy.
  • The root's validators print pins ok and manifest ok, and its naming gate exits 0.
  • A fresh check prints unchanged 11.
  • The copy's sha256 is ec167fb0…896548, 78664 bytes, as the body says.
• The body's other claims:
  • At main, 8 of the 11 new rows fail: the base gate run under the head's tests gave 8 failures, all eight on the defect.
  • Three writer mutants re-run: M2 fails 3 (the prefix rows), M3 fails 1 (the shorter-link row), M7 fails 1 (the open=y= row). All three match the body.
  • My own mutants R15 (fails 2, the capitals refusal rows) and R16 (fails 1) are killed.
• Runs, all through run9.sh:

Git	Tree	Files	Result
2.43	head	test_chain_remedy_callers, test_link_source_chain_defaults, test_naming_policy, test_chain_pin_sources, test_chain_link_fold, test_pinned_copy_text, and the trio	661 passed, exit 0
2.43	head	test_setup_project_py, test_scaffold_referent_chain_links, test_update_shape_kept_helper, test_update_shape_unreadable	591 passed, exit 0
2.47.1	head	test_chain_remedy_callers.py	63 passed, exit 0
2.43	merged tree	test_chain_remedy_callers, test_cli_reference, test_setup_project_py, test_setup_project_repo_misdrawn, test_repo_hygiene	548 passed, exit 0

• Merge. git merge-tree --write-tree of the head against a re-fetched origin/main dc7cd49b7f79 is clean, tree 2a117490cfbf. The merged setup-project.py holds both setup-project.py: the self-bootstrap refuses an $OPENREPOSHAPE_REPO holding U+202E or another character the launcher refuses, by code point and in the launcher's words, before it prints the value or runs git clone (#953) #1043's U+202E change and this PR's docstring.
• Sonar-style checks:
  • _read_source has a cognitive complexity of 7 (loop 1, nested if 2, and 1, if 1, nested if 2).
  • __init__ is 12, plus at most 2 for the comprehension. That is lower than base, because the head removes two conditional expressions.
  • No duplicated block, and no assert joins conditions with and.
  • No changed line is over 79 characters (the gate's existing widest line is 93; the tests' widest stays 79).
• Pinned copy. No import was added (pin_product_key was already imported), and test_pinned_copy_text.py passes.
• Docs.
  • The module, LinkSources, _read_source, _read_remedy and _link_remedy docstrings, the --link-source help, docs/cli.md (test_cli_reference passes) and setup's as_the_plan_reads_it docstring all state the new rule truly.
  • README (lines 730-731), docs/handbook.html, AGENTS.md and the release notes state no first-= rule for --link-source. The one doc that still implies the old rule is NIT-2.

Could not verify

• The body's full 31-file run (2964 passed) and its 25-file run on 2.47.1 (2680 passed). I ran the subsets in the table above.
• The writer's other eight mutants.
• The body's claim that none of the 9 open PRs touches these files: it needs gh, and the brief named only main.
• Git 2.55, the version CI runs.

Checklist candidates

• When a PR claims an unchanged reading, at least one test row should cover each corner of the old split: a path beginning with =, a blank path, and a key typed in another case. Today the claim rests on a probe, not a test.
• When a pinned copy's reader changes, grep the other pinned copies for sentences saying the two tools "read one way" (NIT-2's pattern).

Reviewer: rv980, lane 5's independent reviewer, not the writer (w980).

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