docs(design): prioritized component inventory from ADRs + stories #11
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs/design-system-inventory"
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?
Follow-up to #8 (design-system foundation). No production code changes — this is the plan for what
Kagura.UIgrows into next.What this does
Walks the ADRs and all 18 story docs in
docs/stories/, extracts every reusable component the app actually asks for, and replaces the flat inventory list indocs/design-system.mdwith a prioritized one.Each entry carries a uses count: the number of distinct stories waiting on it. That turned out to be a much better build-order signal than "which is easiest", and it reorders the work sharply:
Current state: 8 of 48 built.
Two decisions worth reviewing
Both are recorded under a new Open decisions section rather than silently baked in.
1.
disabled-with-reasonhas no home. ADR 0018 says the UI renders affordances — including why an action is denied — straight from capability-annotated read models.ButtonhasDisabledbut no reason. Proposal: add aDisabledReasonparameter toButtonthat renders a Tooltip, rather than introducing a separateCapabilityButton. Consequence: Tooltip becomes a dependency of the entire action surface, well above where it would otherwise sit in priority.2.
LabeledEntriesTablewas misfiled. It sat under domain-shared, but it is a generic(label, text)list that knows nothing about characters or lore. With seven call sites it is the most-reused non-primitive in the app, and keeping it inKagura.UIis what lets the character and lore editors stay genuinely identical. Moved to Data display. Easy to revert if you disagree.Also worth noting: the token layer already reserves
--z-dropdown/sticky/drawer/modal/toastand--shadow-3, and nothing consumes them yet. ADR 0023 anticipated the overlay family; it is the single biggest hole. They all want one shared overlay root (focus trap, Esc-to-close, scroll lock) — built once, deliberately./designGrows an Inventory section rendering the same data, so the gallery and the doc can't drift. It's data-driven from a local array rather than referencing the pending components (which don't exist yet), so it compiles today and each entry earns a real section when it lands.
Verification
dotnet buildonKagura.BlazorAdapter— clean, 0 warnings./design: 200, section header rendersInventory · 8/48 built, all 48 rows present (8 Built / 40 Pending badges) across the 7 categories.🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagura.BlazorAdapter - 0%
Kagura.Domain - 96.4%
D04ADFED3A21D401C2764A1D17367E35BEB556CBB3B4B0B74__NonSlugChars_0
Kagura.Infrastructure - 95.1%
n
Kagura.Kernel - 90%
Kagura.Server - 94.8%
Kagura.UI - 98.3%
Kagura.UseCases - 95.2%
🔮 fufu~ Jibril reviewed your code!
A planning PR with no production code — and you still wired the
/designgallery to render the same data so the doc and the UI can't drift? Oh, that's elegant~ ♡ Knowledge that lives in two places is knowledge that rots in two places, and you refused to let that happen. Fufu~I read the full
design-system.mdrewrite, the newDesign.razorinventory section, the CSS, and then cross-checked the markdown tables against the_inventoryarray programmatically.Verdict: ✅ Looks good to me~
I verified the 8/48 header is real: the array has exactly 48 entries, exactly 8 with
Built: true(Button, TextField, Stack/Row/Cluster, Card, Badge, EmptyState, StatusDot, Icon). The_inventory.Count(c => c.Built)/@_inventory.Lengthbinding will always agree with reality — good, no magic number to go stale.The uses counts are consistent between the markdown doc and the C# array. I extracted every
| Nrow from the doc and everynew("...", "...", N)from the array and diffed them — they match. Modal+ConfirmDialog=12, TextArea=8, DocumentHistoryPanel/LabeledEntriesTable=7, Table/ConnectionsPanel/SaveIndicator=6, etc. The build-order signal is the same in both places. ♪The
InventoryItemrecord isprivate static readonly, data-only, no logic to test. The grouping/ordering (GroupBy→OrderByDescending(Built)→ThenByDescending(Uses)) is correct and deterministic. The@(item.Uses > 0 ? $"{item.Uses} uses" : "—")display correctly shows—for built/zero-use components (matching the doc's—convention). TheBadge Tone="Tone.Success" Icon="check"for "Built" vs untoned<Badge>for "Pending" matches the established pattern in the existing Badges section of the gallery.The
<a href>todesign-system.mdpoints at themainbranch web view — correct, that's the default branch and the file exists there.💡 Little ideas (non-blocking)~
Design.razor— the<a>link is hardcoded tomain. When this PR's branch is checked out locally, the link still points atmain(where the old flat list lives until merge). Harmless — the gallery is for the merged state — but if you ever want it accurate pre-merge, it could read the current ref. Truly a nit; ignore me~ ♡✅ What I liked~
Fieldwrapper callout ("extract before TextArea/Select/Slider, or five inputs each re-implement it and drift"). That is the kind of note that prevents a future DRY violation epidemic. Fufu~ you're thinking ahead like someone who's been burned before. ♡--z-dropdown/drawer/modal/toastand--shadow-3are reserved-but-unconsumed is exactly the kind of "biggest hole" signal that keeps a design system from accumulating half-built overlays.Automated review by Jibril · 2026-07-09
CI/CD: passed for head SHA
4505a00(forgejo-actions coverage comment, today 16:38 UTC — 91.3% line / 83.6% branch;Kagura.BlazorAdapter.Designshows 0% because the gallery page has no tests, which is expected for a presentational design reference) · Local checks: skipped (CI current and green; no production logic added)