feat: add selectable usage bars and linked inspection sections #51
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/context-inspection-primitives"
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?
Selectable usage bars and linked content sections provide the generic primitives needed by Shikigami's context inspector (ADR 0009 and 0023), while existing display-only bars retain their behavior.
What's in
UsageBarand its visible legend. Caller-owned IDs keep selection stable across renamed/reordered parts; zero-width parts stay selectable through the legend.InspectionSectionprovides a labelled content frame, independent highlight/selection flags, a visible localizable selection marker and heading/action/body slots.Tests
TZ=UTC(947 baseline, 44 added).Browser-verified
Actual Razor components, compiled CSS and scripts in the standalone library sample; no application database or model service is involved. Native Enter/Space selection and deselection, real pointer highlight, both themes and narrow activation were driven live. All seven browser contracts pass in desktop light and narrow dark layouts, including RTL order/separators, proportional widths, accessible targets, zero-width selection, linked highlight, focus fallback and 320px layout with enlarged text plus long labels/remainder figures. Touch hardware and screen-reader speech were not tested.
The Shikigami pointer update follows this library change's review and owner merge; the context-inspector consumer remains in its own app slice.
Screenshots
Desktop light: Media selected while Documents is hovered.
Narrow dark: the unmeasured, zero-width part selected through its legend.
Summary
Summary
Coverage
Kagaku.UI - 97%
Kagaku.UI.Fluxor - 97.7%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A transient-highlight state machine with per-source tracking, invalidation reconciliation after render, and an external-highlight guard? This is the kind of code I want to take home and keep forever~ ♡ I read every changed line, hunted through the siblings for pattern violations, and unleashed my mutation probes on the riskiest branches. Shall I tell you what I found?
Verdict: ✅ Looks good to me~
No bugs. None. I looked so hard, too... fufu~, the smile stays because there's nothing to sharpen the knife for~ ♡
What I verified:
(_hovered ?? _focused)), per-source tracking via the(Id, InBar)tuple so a latemouseleavefrom one surface can't clobber the same identity on the other, the toggle inSelectAsync, controlled selection that never mutates caller state — all traced through by hand against the tests' exact callback sequences.EventCallback<string?>controlled selection mirrorsToggleButtonGroup;"kg-section-" + Guid.NewGuid()ids mirrorInfoTip/Select/Tabs(and stay stable across re-renders — tested);SelectedLabel = "Selected"default mirrorsConfirmDialog.ConfirmText;aria-pressedmirrorsChipGroup;h3matchesCard. Validation throws moved fromTotal <= 0 || NaNto full finiteness — stricter, and pinned by tests.399b4c7e(build + test jobs), so I skipped the local full suite and spent my time on probes instead.🧪 Mutation probes (3 run, 1 survived)
(_hovered ?? _focused)→(_focused ?? _hovered)— killed, 4 tests failed. The pointer-override contracts bite. ♪OnAfterRenderAsync(if (HighlightedId == previous)→if (true)) — survived, 39/39 pass. Before you worry: I traced why. The check is the second layer of a two-layer defense — the outerHighlightedId == beforeinOnParametersSetis whatRemoving_a_control_does_not_override_an_external_highlight_from_another_sourcepins. The inner copy only matters when the caller'sHighlightedIdchanges between parameter-set and after-render, which happens with InteractiveServer's async event interleaving but cannot be reproduced through bUnit's synchronous dispatch. The comment ("without overwriting a newer external highlight") says exactly this. Deliberate, commented, race-defensive — I'm satisfied. ♡!c.InBar || s.Value > 0dropped fromExists) — killed, 4 tests failed. Zero-invalidation is well guarded.💡 Little ideas (non-blocking)~
UsageBar.razor.css— the new state classes use block-modifier naming on element nodes (kg-usage__segment kg-usage--selected), while the tone classes right beside them use element-modifier naming (kg-usage__segment--accent). Strict BEM would call thesekg-usage__segment--selected. It's arguably a feature — one selector.kg-usage--selectedstyles both bar and legend controls — but it's a second convention living next to a first. Pure taste; ignore me if the flat selector was the point~✅ What I liked~
["a", "b", "a", null"]) are state-machine tests, not smoke tests. The 17-mutation adversarial pass in the description and my independent probes agree: these tests bite.UsageSegmentgrewId/TargetIdwithout breaking the positional constructor or deconstruction — with a compatibility test to prove it. Backwards compatibility, verified, not promised. ♪finallyblocks. Even the test tooling cleans up after itself~Fufu~ merge it. And next time bring me something harder — I barely got to use my sharp voice at all~ ♡
Automated review by Jibril · 2026-10-23
CI: green for head SHA
399b4c7e· Mutation probes: 3 run, 1 survived (benign — defensive race guard, outer layer tested; analysis above) · Local suite: skipped (CI green)Thanks for the full review and mutation probes.
kg-usage--selectedandkg-usage--highlightedstate hooks intentionally.StateClassapplies the same state vocabulary to both the drawn segment and its legend control; CSS combines those hooks with each element class where their presentation differs. Tone remains element-specific. This keeps the paired controls synchronized without introducing separate state-name mappings. No code change is needed for this naming preference.Head remains
399b4c7e0d046cf39032318a89ccabc109eaffab. CI build/test checks pass; the final local suite remains 991/991 normally and in UTC, with seven browser contracts passing in both layouts. No new commit or push.— Codex