fix: the sampler's reach is the crop's window, with its article #155
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/sampler-reach-article"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This carries Jibril's 💡1 from #153 (comment 9975). I pushed it to that branch as
a044a30after #153 had already merged at 14:06, so it never reached main. The PR page showsa044a30as the head only because the branch moved after the merge.What's in
SampleRegionColorsTool.Descriptionnow reads "the same reach as the crop's window". This is model-facing text; behaviour is unchanged.The_bound_samplers_description_offers_a_window_and_never_the_boxpinned the old phrase word for word, so its assertion changes with it.Tests: no count change. Full suite at
80a57e8, each project run separately, Debug build 0 warnings / 0 errors: Domain 129, UseCases 633, Integration 270, BlazorAdapter 263 = 1295/1295, the same total as main.Note: I confirmed main's tree after #152, #153 and #154 matches the three-branch combination I merge-probed before opening them (tree
e7dd7ba). This one string is the only thing that missed.🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.5%
Orihon.Domain - 100%
Orihon.Infrastructure - 97.2%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 94.4%
Orihon.UseCases - 97.8%
🔮 fufu~ Jibril reviewed your code!
Oh my, a two-line PR that does exactly what it says and nothing more~ You carried my 💡1 from #153 home after the merge cut it off from main. That's the kind of tidiness I want to frame and put on a wall ♡
Verdict: ✅ Looks good to me~
What I verified:
as crop's window→as the crop's windowinSampleRegionColorsTool.Description(BoundInspectionTools.cs:420), and the twin assertion inThe_bound_samplers_description_offers_a_window_and_never_the_box(AnnotationToolTests.cs:1244) moves in lockstep. Model-facing text only — zero behavioural change.80a57e8(Debug, 0 warnings / 0 errors): Domain 129 ✓ · UseCases 633 ✓ · Integration 270 ✓ · BlazorAdapter 263 ✓ — 1295/1295, same total as main, no count drift, exactly as a text-only change should be. Tree pristine after probes.✅ What I liked~
a044a30but the diff is one string — made verification a pleasure. Everything fix claimed checked out mechanically.Merge it before the ink dries, fufu~ ♡
Automated review by Jibril · 2026-09-26
CI/CD: absent for head SHA (no bot comment yet) · Local checks: full suite 1295/1295 digit-exact vs PR body, build 0w/0e, 1 directional mutation probe
Approved — one article, carried exactly.
Provenance, verified mechanically.
80a57e8is a single commit on48116ed(= base = merge-base, clean, mergeable). The originala044a30(pushed to #153's branch after it merged at 14:06) is present in my clone: it sits on779cfeband is not an ancestor of the head — so this is a fresh cherry-pick onto current main, not a branch-move. Its diff is byte-identical to the PR's two hunks. This carries my 💡1 from #153 (comment 9975), and it is the only thing that missed the three-branch merge — I confirm the claim's shape:origin/main==48116ed== merge-base, and grep finds the phrase at exactly 2 sites repo-wide —BoundInspectionTools.cs:420(the description) and the pin test'sAssert.Contains— both in the new form. No other consumer.The change itself.
the same reach as crop's window→the same reach as the crop's window. Model-facing text only;ExecuteAsync,RegionWindow.Resolveclamping, and the refusal wording are untouched. Full-file read confirms the page-bound sampler keeps its own wording, which the test's final assertion (DoesNotContain("window", FloatingCreation …)) already guards. The pin testThe_bound_samplers_description_offers_a_window_and_never_the_boxchanges in lockstep with the string it pins — correct coupling.Local, Release: build 0 warnings / 0 errors; UseCases 633/633 green — same total as the PR body claims and as main. Coverage bot (comment 10021) is current for the head: 97.2% line / 85.4% branch.
Mutation probe (pre-approve, restored): reverting the article in the src string → the pin test goes red 1 failed / 0 passed, exactly its own pin and nothing else. Restored byte-pristine (
git statusempty), rebuilt, re-green 1/1. The pin genuinely holds this string.No count change, no behaviour change, no loose ends. Merge as-is.