feat(icons): the manga-pipeline set — ten Material Symbols for Orihon #1
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/orihon-phase1-icons"
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?
Orihon Phase 1 shipped ten icon names with no catalog entry —
upload_file,arrow_forward,crop_free,edit_note,font_download,image,mop,north,notes,translate— andIconCatalog.Pathreturns null for an unknown name, so the icon renders an empty SVG: the page intake's drop zones, the wizard's forward buttons, and the stage tabs all showed invisible, clickable air.This adds the ten paths from the official Material Symbols data (viewBox
0 -960 960 960), matching every existing entry. All 229 tests pass.The consuming side lands separately in Orihon: the submodule pointer bump plus a port of
IconCatalogCompletenessTestsover Orihon's own source, so a ghost icon can't ship there again.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagaku.UI - 94.8%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh~! A ghost-icon exorcism! ♡ Ten invisible clickable-air buttons, banished with twelve lines of path data — this is exactly the kind of silent failure I lose sleep over, and you tracked every one of them down to the name. The PR body reads like a detective report. Delicious.
Verdict: ✅ Looks good to me~
This is a textbook data-addition PR and I couldn't find a single thing to block on. Let me show you what I checked~
Path data integrity — All ten entries are well-formed SVG: every one starts with a moveto (
M/m), containsZclose-paths, and all coordinates land inside the0 -960 960 960viewBox. No empty strings, no whitespace, no corruption. I parsed all 70 catalog entries programmatically — zero duplicate path values across the entire catalog, zero duplicate keys. Clean~Consistency with siblings — I was ready to pounce on
translatefor starting with a lowercasem(relative moveto) instead ofM... but fufu~, I checked, and it matches ten existing siblings exactly (close,arrow_back,archive,push_pin,warning,settings,auto_awesome,map,verified,record_voice_over). Material Symbols ships them that way; you copied faithfully. No inconsistency to exploit~ ♡The tripwire is intact —
IconCatalogCompletenessTestsscanssrc/for literal icon names and fails on any ghost. I confirmed it still passes: these ten names have zero literal references in this library's own source (they're for Orihon consumers), so the guard correctly stays silent here. The PR body's plan to port the tripwire into Orihon's own source tree is the right call — that's where these names will appear as literals, and that's where the next ghost gets caught. The existing test's XML doc comment even documents this exact split ("consuming apps run the same scan over their source"). Architecturally sound.Test coverage is appropriate —
IconCatalogTests.Every_catalogued_name_resolves_to_a_non_empty_pathgenerically validates all 70 entries including the ten new ones (asserts non-whitespace path for every catalogued name). Adding per-icon tests would be testing data, not behavior — the generic test is the right shape. No new branches, no new code paths, just dictionary entries.Surgical scope — +12/-0, one file, one commit, purely additive, entries appended at the end in a commented block that mirrors the existing "audio arc" comment pattern exactly. The
Namesproperty auto-includes them viaPaths.Keys.Order(). No deletions, no modifications, no scope creep.Verified locally — Build: 0 warnings, 0 errors. Tests: 229/229 pass (matches your PR claim exactly). CI coverage bot confirms
IconCatalogat 100% line coverage for this head SHA.✅ What I liked~
Fufu~ ten ghosts, twelve lines, zero drama. This is how you ship an icon set. Approved~ ♪
Automated review by Jibril · 2026-07-24
CI/CD: passed for head SHA
2151449(forgejo-actions coverage bot, IconCatalog 100%) · Local checks: build 0/0, 229/229 tests pass