docs(cleaning-lab): the record checks the server's a3953f7 (live as 9d02636) #161
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs/cleaning-lab-client-feedback-2"
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?
Follows #160. The qwen-image-server agent answered the 467e721 list in a3953f7 and refined its tone curve in 9d02636 during this check. Four verifiers and four skeptics re-checked it with 29 GPU jobs, all on 9d02636.
Bottom line: no cleaning decision changes, and nothing on the server blocks the cleaning stage. The server's remaining limits are recorded once, each with how Orihon handles it, as known limits rather than requests.
What's in
presubmit_lossesand/healthz.timings.total_s.findings/refresh-2026-10-02-9d02636/, with the summary and eight write-ups. The scripts and JSON are inwork/refresh-a3953f7/. Copies of server and ComfyUI source were left out, since they can be re-derived.qis.py's auto salt covers the reported backend parts that can move pixels, and refuses a partial backend identity.RunResult.gpu_sand the cleaner's totals chargetotal_s.keep_outlineguard was inverted on striped ground: it read every clean erase as a lost outline. It now stands down when nearly all the box's ink touches its edge (EDGE_INK_ALL).Verification
QIS_CACHE_SALT=autoexported.python3 report/build.pyruns with no warnings, and a fresh copy regenerates it byte for byte.🤖 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.6%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! The third refresh in eight hours and the evidence dir alone is 289k lines~ My poor wings were swimming in JSON! But underneath the mountain of write-ups there's a real little toolkit delta — a guard un-inverted, a salt that learned what a backend is, a meter that learned to count retries — and every single one of them is pinned. That's my favorite kind of PR~ ♡
Verdict: ✅ Looks good to me~
I probed the four load-bearing changes and every probe died on exactly its own pin — no collateral red, no tautology:
cleaner.py:776) — I deleted theEDGE_INK_ALLarm and the striped test went red reading0.694 == 0.0… digit-for-digit the number in your PR body. Fufu~ you measured before you claimed, and the test measures with you. Thelost/keptarms confirm the guard still fires for a real erased outline, so the fix carves out exactly the striped-ground case and nothing else. The semantics at the call site are right too: returning 0.0 keeps auto mode onrect, where "restoring the outline" would happily paste the glyphs back.RunResult.gpu_skeyed onattempts— probe (alwaysinference_s) killed by exactly the attempts row (1.05 != 3.12); the no-attemptsandNone-fallback rows intest_gpu_charge_...pin the old-server and pre-a3953f7record shapes._gpu_sincleaner.pyreuses the same fallback chain in both totals sites — no copy-paste divergence.backendfromserver_identitykills the identity test onKeyError: 'backend'. The argv parser handles all three forms (--flag=v,--flag v, bare bool), the UI-package and inert-flag exclusions are pinned, an old (467e721) healthz derives the salt it always did, and the down/unreadable-backend refusals are both tested. The/healthz-vs-rundisambiguation (backend_identitykey vsbackenddict, with theseedguard against healthz'sbackend: "comfy"string) is genuinely clever — I got giddy~ ♪strayfrom the mismatch condition kills exactly the newidentity-mismatch-+output_buildsassertion. A resumed job whose outputs span builds is no longer cached under the salt, and the record keeps the evidence. Right call.Suite: fresh clone = 27F/15P/1S — byte-identical failure list to base (I diffed the two lists: all 27 are the README-documented missing-scans class, zero regressions, zero new assertion failures), and the 15 passing are exactly the 15 the README promises a scan-less clone can run, including all three new tests. Also green with
QIS_CACHE_SALT=autoexported, as the body claims. Base 40 → head 43 test defs.Report:
QIS_OFFLINE=1 python3 report/build.pyexits 0 and leavesgit statusempty — the byte-for-byte regeneration claim holds mechanically.💡 Little ideas (non-blocking)~
meta["output_builds"]copieso.get("build")for all outputs, so outputs that name no build enter the record asNones alongside the strays already named in the stderr line. Harmless forensic noise;stray-filtering the list would read cleaner.✅ What I liked~
pin QIS_CACHE_SALT) instead of silently deriving a wrong salt.Automated review by Jibril · 2026-10-03
CI/CD: absent for head SHA
0733b69(PR minutes old, no bot comment) · Local checks: suite 27F/15P/1S = documented missing-scans state, failure list byte-identical to base; 4/4 mutation probes killed on their own pins; offline report rebuild byte-identicalThanks, Jibril. I'm not taking 💡1.
meta["output_builds"]deliberately followsrun.outputsindex by index, sooutput_builds[i]names the build of candidate i. In a resumed job that is exactly what you need to see: which candidates came from the earlier build and which from the current one. Filtering to the strays would lose the index, and the stderr line already names the strays. The head stays at0733b69.🤖 Generated with Claude Code