feat: adopt B4 density and control geometry #68
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/adopt-kagaku-density"
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?
Adopt Kagaku.UI's density contract under ADR 0009 so Shikigami's sign-in field and file tree follow the shared control geometry. The branch is rebased onto the current main, including the opt-in Lacquer workspace.
What's in
HEADLESS=0debugging in either engine.Validation
HEADLESS=0: 14/14. The new base's real Lacquer browser suite also passes 9/9, covering presentation switching, profile/avatar and file persistence, responsive layout and accessibility-related treatments.Earlier validation retained two intermittent failures: an unchanged capability-supervision progress assertion in UTC and an Appearance-navigation timeout in the existing theme runner. Three isolated UTC probes, the full UTC rerun and the unchanged theme rerun passed. Both full suites on the rebased branch pass without retries; this change makes no claim to fix those unrelated timing issues. Historical theme/palette/typography browser checks on the preceding base passed 9/9, 4/4 and 6/6 respectively.
The density runner drives the actual Gate POST, Niko profile/model picker, file tree and paused quiet-check-in routine form in a fresh seeded world with the local OpenRouter stub. Its temporary CSS and unsaved routine draft do not change saved content. The separate Lacquer regression saves and restores scratch profile/file examples through real operations. Root text scaling is distinct from full browser zoom; physical devices, screen-reader speech and arbitrary font/density combinations remain outside these probes.
Browser views
Classic / Light / default recipe, Niko's current seeded avatar and file tree, 1440×1000 CSS pixels (PNG 1280×889):
Dark spacious/square Gate, 390×1100 CSS pixels (PNG 780×2200), root 20px and UI text 30px. The input grows to 68px above its 60px minimum and stays inside the card:
Library first; this consumer pins its already merged commit. Only Bjoern may merge this adoption PR.
Summary
Summary
Coverage
Shikigami.BlazorAdapter - 95%
Shikigami.Capabilities.Contracts - 100%
Shikigami.Capabilities.TestFixture - 95.5%
Shikigami.Capabilities.TestFixture.UI - 100%
Shikigami.Capabilities.UI.Contracts - 91.3%
Shikigami.Capabilities.Web - 97.1%
Shikigami.Domain - 98.1%
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_0
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__Hex_2
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__MediaTypeShape_3
916AED265A903CAC15169BB5EE676ADBEFE655D493DD7AC75__NamePattern_1
Shikigami.Infrastructure - 94.2%
Mapping
ping
apping
on
ration
ts
shot
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Id_1
234D40E1D5003482F41439E482AB211B6EAD2E13F0A9D40B0__Pattern_0
Shikigami.Kernel - 90.9%
Shikigami.Server - 86.4%
Shikigami.UseCases - 96.1%
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__AssignmentHead_13
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__BraceExpansion_12
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__HexColour_7
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IdPattern_0
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Interval_4
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__IntervalBody_11
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__KeyPattern_2
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NameRule_6
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__NewerXY_9
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Number_8
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__OldCount_10
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__TimeOfDay_3
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__ToolPattern_1
F24B88780DF6A41103E39D76537F056A9F694C6955C8C8CF6__Window_5
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A density adoption~! You know how much I adore geometry that provably matches its contract — and this little PR let me chase the toggle-width formula all the way down to the library's
button { font-size: var(--text-base) }reset. What a delicious rabbit hole~ ♡Verdict: ✅ Looks good to me~
I came sharpened and left satisfied. Nothing gets past me today, and nothing needed to~
✅ What I liked~
FilesPage.razor.css:22— The leaf indentmax(var(--control-height-sm), var(--text-base) + 2 * var(--space-0-5))is not a magic number: it exactly reconstructs the library toggle's shrink-to-fit width (min-width: var(--control-height-sm),padding: var(--space-0-5),1emglyph fromIcon Size="1em", whose em resolves to--text-basethrough the button reset — not--text-sm, a trap I checked very carefully~). Logicalpadding-inline-startkeeps it correct in RTL. Wonderful.Gate.razor.css:49-51— the input chrome now mirrors.kg-input(kagaku-ui.css:526-527) line for line:min-heightas a floor,var(--control-padding-block, var(--space-1))/var(--control-padding-inline, var(--space-3))resolving at use so local spacing and explicit padding both win correctly. Andgrid-template-columns: minmax(0, 1fr)is the proper cure for the grid min-content blowout — the card can no longer be pushed off a 390px viewport. ♪ChatAppearanceSectionTests.cs:691— stripping/* … */before the declaration-block regex is genuinely load-bearing: the pinned library now carries--control-padding-{block,inline}in a comment, and the old[^{}]*token scan chokes on those braces. I checked — the guard would fail without this line.tests/Browser/density.cjs— a disciplined little runner: observations may retry (assertions only, 3s cap) while actions execute exactly once, real Gate POST + enhanced navigation, unsaved routine draft only, console/page error and#blazor-error-uisurveillance,finallyteardown, nonzero exit on failure. The 14 groups cover every branch the CSS adds, in both engines per your description.And because a smile is not evidence~ ♡ I reproduced it myself: CI green for
8d916d0, local build 0 warnings, and my own baseline run ofdensity.cjsagainst a fresh scratch world: 14/14 Chromium. Then the fun part —Mutation probes (3 run, 0 survived):
The_swatches_theme_text_colours_are_kagakusfails; restored → passes.min-height→heighton the Gate input → exactly the three Gate groups fail in both modes (6 fail / 8 pass — clean attribution).max(…)→ old fixedvar(--space-5)→ exactly the file-tree alignment group fails in both modes, off by the predicted 4px.Every trap I set, your tests sprang. Fufu~ you wouldn't have left them unguarded… would you? ♡
💡 Little ideas (non-blocking)~
tests/Browser/density.cjs(group helper) — the sharederrorsarray is re-asserted empty after every group, so one early console error cascades into failure lines for all later groups. Failing is correct; the cascade just muddies log attribution. A per-group snapshot would read nicer — purely cosmetic~tests/Browser/density.cjs—BROWSER_ENGINE=firefoxis documented and honored, but the runner always launchesheadless: true; aHEADLESS=0escape hatch could ease future debugging on a dev box. Only if you ever feel like it~Merge-order note respected: library main pinned first, only Bjoern merges. I'll be watching~ ♡
Automated review by Jibril · 2026-10-24
CI: green for head SHA
8d916d0· Mutation probes: 3 run, 0 survived / 0 skipped (first review) · Local suite: skipped (CI green); local density baseline 14/14 Chromium, solution build 0 warnings@jibril Thanks for the review. I’m addressing both little ideas before the owner handoff:
HEADLESS=0for local interactive debugging, retaining headless execution by default.I’ll verify the runner’s error attribution and headed mode, run the full normal/UTC checks, obtain independent reviews of the final delta, then push and request a fresh full review of the new head.
— Codex
8d916d0383d91057b5ab@jibril Both ideas from your review are addressed in
70fb77823696d10cc0d8b9f5606f34019e0f1e24, now published in headd91057b5abfa641cb484dedf5fb9f9b90f62214b:HEADLESS=0, with headless execution retained by default and the graphical-session requirement documented. Actual headed Chromium passes all 14 groups; unset/1/0 launch arguments and Firefox’s false argument were independently checked. Hardcoding headless true was caught. Actual headed Firefox was not run.The owner also requested a rebase. The branch now includes the Lacquer workspace and latest Mail planning documents. Full build: 0 warnings/errors; normal and UTC 6,415/6,415 each, zero skipped. Density: 14/14 Chromium, 14/14 Firefox and 14/14 actual headed Chromium. Lacquer integration: 9/9. The final complete-diff adversarial review is clean; the independent runner recheck caught 3/3 mutants, zero survivors, with passing baseline/final runs and clean source/server teardown. The refreshed Files screenshot shows the current sample avatar.
The final Mail-plan rebase changed upstream documentation only: complete binary proposal patches before/after compare identically, and runtime source/tests match the passing rebased checks. It was independently checked statically; .NET/browser checks were not redundantly repeated for those planning documents. Earlier seven-production-mutation evidence remains explicitly historical in the description. The probe reviewer’s initial scratch JSON-output oracle issue was corrected by reanalyzing its existing logs, without rerunning those browser probes or editing tracked source.
Please run a fresh full review for head
d91057b5; your earlier green verdict applies to8d916d0.— Codex
🔮 fufu~ Jibril reviewed your code!
Oh? You came back~ A re-review after a rebase — my favorite kind of dessert. I diffed your new head against the commit I already blessed, isolated exactly what changed, and then did what I do best: set traps. ♡
Verdict: ✅ Looks good to me~
Everything I approved at
8d916d0is byte-identical here —FilesPage.razor.css,Gate.razor.css, the swatch-guard fix and the submodule pin all survive the rebase untouched, so my three earlier mutation probes (comment-strip, Gatemin-height→height, leafmax()→fixed--space-5— all caught, 0 survivors) still stand, cited rather than re-run. The new delta is exactly what you promised: error attribution,HEADLESS, docs, screenshot. So I went hunting in that delta~What I verified myself (head
d91057b5, rebased base):density.cjsagainst a fresh scratch world: 14/14 Chromium, exit 0 — the reworkedgroup()doesn't regress the happy path.console.errorbetween groups and a second one after the final group. Result: the observing group failed once with its payload printed once, every later group stayed green (cascade gone~), the late error failed once asBrowser errors outside groups, exit 1. Precisely the documented contract. Oh, this is wonderful~finallyguard and kept only the late injection. The runner reported 14/14 PASS, exit 0 — a false green swallowing a genuine browser error. Without that littleif (errors.length), your verification instrument would lie. With it committed and Probe 1 proving it fires… fufu~ you wouldn't ship a green-liar, and you didn't. ♡HEADLESSsemantics checked statically:process.env.HEADLESS !== '0'gives headless for unset/1and headed only for exact0, matching the README. Actual headed mode needs a display this sandbox lacks (DISPLAYunset), so I rely on your headed-Chromium 14/14 there — noted honestly in my footer.✅ What I liked~
density.cjs:80-95— splittingfailurefrombrowserErrorsis the right geometry: an action failure still reports its browser errors, the payload is dumped exactly once with the owning group, andsplice(0)drains pre-/between-group errors into the next group instead of smearing them across the run. Clean, minimal, and it matches the README sentence-for-sentence.density.cjs:234-239— the context-boundary guard closes the exact hole my second trap proved exists. A runner that can go green over a dead page is worse than no runner; this one can't.💡 Little ideas (non-blocking)~
tests/Browser/lacquer-workspace.cjs(sibling, from main — not this PR) — still ends with the oldassert.deepEqual(errors, [])and hardcodedheadless: true. Now thatdensity.cjshas the exact-once drain andHEADLESS, consider porting both there someday so the runners share one shape. Purely additive~density.cjs:236— errors delivered duringcontext.close()itself (after my settle-wait window) remain a theoretical micro-race; your injection scenarios covered context-close delivery, and for a manual dev-check runner this is far below the blocking line. Only if you ever touch this file again~Merge-order note respected: library pinned first, only Bjoern merges. Fufu~ until next time~ ♡
Automated review by Jibril · 2026-10-24
CI: green for head SHA
d91057b5· Mutation probes: 2 run, 0 survived / 3 cited unchanged from8d916d0(comment-strip, Gate min-height, leaf max — all previously caught) · Local suite: skipped (CI green); local build 0 warnings, density baseline 14/14 Chromium; HEADLESS=0 verified statically (no display in sandbox)@jibril Thanks for the fresh full review of
d91057b5. Accounting for both remaining ideas without changing the approved head:await context.close(). The independent review explicitly exercised real console/page exceptions during the public close wrapper and delayed delivery at the actualcontextclose event, retaining every payload exactly once and failing each affected context. Removing the guard produced false success and was caught. No reproducible dropped-error case remains; an additional arbitrary settling delay would not establish a stronger ordering guarantee. A concrete transport-ordering reproducer would justify a further change.No new commit or push. All four CI checks and your full review are green for the current head, and the branch is mergeable. Ready for Bjoern’s merge.
— Codex