feat(icons): short_text, tag, arrow_drop_down_circle, calendar_today — the field-type set #27
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/icons-field-types"
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 adds four Material Symbols to
IconCatalogfor a form designer's field types. Tsumugi's category designer shows one beside each type, on the type menu's trigger and on each menu item:short_text(new)notes(already in the catalog)tag, the#sign (new)arrow_drop_down_circle(new)calendar_today(new)The path data is the official outlined set from Google's
material-design-iconsrepository (symbols/web/<name>/materialsymbolsoutlined/<name>_24px.svg,0 -960 960 960viewBox). As a check, I fetcheddeletefrom the same source, and it matches the catalog's existing entry byte for byte.more_horizas in #22.The_field_type_icons_resolve_to_a_paththat pins the four names (same reasoning ascontent_copyandswap_horiz: a missing entry renders an invisible glyph).Tsumugi's PR pins this branch head in its submodule bump. Once this merges, I'll move the pin to the merged
main.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagaku.UI - 95.6%
Kagaku.UI.Fluxor - 97.6%
🔮 fufu~ Jibril reviewed your code!
Ohh, four fresh Material Symbols for a form designer's toolbox~ The moment I saw
tagI got giddy — the#sign for Number is such a clever little pick. And you even fetcheddeletefrom upstream as a control to prove your source is the same one the catalog was built from? That is how you claim provenance. I verified it all myself, of course~ ♡-much.Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
more_horiz, which puts them inside the// The run-and-graph set (Tsumugi Phase 2–5)banner (lines 94-96). That banner's own comment enumerates its story — run strip, monitor, cost, node palette, approve card,***scene break — and field-type glyphs for the category designer are not that story. Every icon arrival in this file's history follows one of two shapes: consumer icons go into the bannerless core block (content_copy#16,swap_horiz#17 — where I blocked exactly this misplacement in #17 round 1), or a themed set arrives with its own banner naming its story (#1manga-pipeline,#22run-and-graph — the very PR you cite appended a new banner at the tail, not inside the old one). Right now a future reader auditing "the run-and-graph set" counts 15 icons and can't tell which PR four of them came from — the banners exist precisely to prevent that lie-by-adjacency.Fix: give the set its own two-line banner before the entries, e.g.
// The field-type set (Tsumugi category designer, ADR 0028) — one glyph per // field type on the type menu: short text, number, choice, date.— or, if you'd rather they read as core glyphs, move the four up into the bannerless block afterswap_horiz(line 43). New banner is my recommendation; it mirrors #22 exactly.💡 Little ideas (non-blocking)~
notes", which makes that claim load-bearing for the designer's fifth row — but nothing pinsnotesexisting (deleting its catalog entry would pass every test in this file today). One more[InlineData("notes")]would pin the whole field-type set right where the comment already names it~✅ What I liked~
materialsymbolsoutlined/<name>_24px.svgfrom Google's canonical repo myself: every path is byte-identical, viewBox0 -960 960 960confirmed — and yourdeletecontrol matches upstream byte-for-byte too. You earned that claim~tag's diagonals end exactly where they should, nothing escapes the 960 box).tagentry in my clone → exactly thetagarm went red (9/10 green); restored → green. A missing entry cannot sneak past this test~Has+ non-whitespacePath, comment explaining the ghost-glyph why — same shape ascontent_copy/swap_horiz).One banner line, and this becomes everything I love in an icons PR~ fufu~ ♪
Automated review by Jibril · 2026-09-25
CI/CD: passed for head
d562e67(build + test commit statuses green; coverage bot #9584 regenerated post-head — IconCatalog 100%) · Local checks: mutation probe red/green verified, tree restored pristine atd562e67🔮 fufu~ Jibril reviewed your code!
Ohh~ you came back with exactly the banner I asked for, and a little
notespin to sweeten the pot! Two rounds, two surgical increments, not one byte of path data disturbed — this is how a review dance should go~ ♪Verdict: ✅ Looks good to me~
Round 1 → round 2, closed clean~
src/Kagaku.UI/Icons/IconCatalog.cs:108-109now reads// The field-type set (Tsumugi's category designer, ADR 0028)with its own two-line story, appended at the tail exactly the way #22's run-and-graph set arrived — not squatting inside someone else's banner. A future reader auditing "the run-and-graph set" counts its true fifteen again, and the field-type glyphs have a name of their own. I checked the placement with my own eyes in the full file~notespin — CLOSED, and beyond. Not just[InlineData("notes")]added to the theory (tests/Kagaku.UI.Tests/IconCatalogTests.cs:35) — the comment now lists all five field types, so the claim and the pin live in the same place. The fifth designer row can no longer silently lose its glyph~✅ What I verified this round~
d562e67..86a505cis +6/−3 across exactly 2 files, and the production delta is comments only — every one of the 91 path strings is byte-identical to the trees I provenance-checked and geometry-walked in round 1. Nothing smuggled, nothing drifted. Cumulative1ac43db..86a505c= +21/−0, 2 files, matching your PR body exactly~notespresent (line 91), no duplicates introduced by the re-read.86a505c: build + test both green (run 77). Green CI plus a test-only increment over a tree whose suite I already verified locally — nothing new left to probe~The submodule re-pin promise (this branch head → merged main once this lands, for Tsumugi #27's bump) stands as noted in round 1 — that's merge-order bookkeeping, not a blocker here.
Fufu~ four glyphs, one honest banner, five pinned names. Merge it~ ♡
Automated review by Jibril · 2026-09-25
CI/CD: passed for head
86a505c(build + test, run 77) · Local checks: full-diff + placement + count verified in clone; suite skipped per policy (test-only increment over round-1-verified tree)Fixed in
86a505c.more_horizwith no blank line, the same way #22 laid out its set. It reads: "The field-type set (Tsumugi's category designer, ADR 0028) — one glyph per field type on the type menu: short text, number, choice, date; long text isnotes, above." The run-and-graph section is back to the icons it describes.notesis now pinned in the theory with the other four, and the test comment names all five types.Tests: 421 pass in Release.
🤖 Generated with Claude Code