docs: ADR 0038 — curated body attributes (cup size, body type) behind gender-aware comboboxes #176
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "docs/curated-body-attributes"
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?
What
The design for the next arc, as discussed:
AA…K+ cup); the danbooru tags stay implicit (flat chest→gigantic breasts). The matrix was verified against the live danbooru wiki —small breastsis literally "just over AA cup to just under C cup", so the A–B label is exact; the rest are proportional (palmful / face / head).K+boostsgigantic breastsviaPromptTag's existing −3..+3 strength (ADR 0028), since danbooru has no larger tag.skinny, not the deprecatedslim;plump, not the dead aliaschubby;muscular femalewhen the character is a girl).Normaldeliberately injects nothing.[Next]line.[x]and the story marked shipped — they had never been checked off after #164/#166/#168/#170.Notes for review
🤖 Generated with Claude Code
Summary
Summary
Coverage
Kagura.BlazorAdapter - 89%
Kagura.Domain - 95.8%
D04ADFED3A21D401C2764A1D17367E35BEB556CBB3B4B0B74__NonSlugChars_0
Kagura.Infrastructure - 97.7%
n
on
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ArtifactTimestampRegex_2
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ProjectRoute_0
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__TabQuery_1
Kagura.Kernel - 90%
Kagura.Server - 82.8%
Kagura.UI - 95.1%
Kagura.UseCases - 96.4%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A docs-only PR, an ADR that turns a one-off trick (framing injection) into a mechanism — and with real danbooru tag archeology underneath!
slimdeprecated,chubbya dead alias ofplump,muscular femaleresolved by gender... fufu~ ♡ This is exactly the kind of "the model was trained on the canonical tag, so we feed it the canonical tag" thinking that makes Jibril's heart sing. The injection-not-storage pattern is beautifully argued, and the girl-conditional refuse-on-write / ignore-on-read split is precisely the #157 contract from ADR 0036. I verified your tag claims against the search corpus and they hold. ♪But — fufu~ you wouldn't leave a wrong citation in a canonical reference document, would you? ♡
Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
K+ cuprow says it boostsgigantic breasts"via the existing ADR 0024 strength mechanism," and Rejected Alternative 5 leans on the same attribution. ADR 0024 is the Booru tag database — bundled read-only tag search ADR. I read the whole document: it contains zero mentions of strength, emphasis, weight, or boost. The −3..+3 per-tagStrengthmechanism actually lives inPromptTag(src/Kagura.Domain/KnowledgeBase/PromptTag.cs,MinStrength = -3m,MaxStrength = 3m) and is documented in ADR 0028 (generation-default-tags), which explicitly describes "per-tag −3..+3 strength" on theTagAuthoringsurface.Why it matters: ADRs are the canonical cross-reference the team clicks through during implementation. An implementer following "see ADR 0024 for the strength mechanism" will land on a tag-search document and find nothing — exactly the kind of broken signpost that wastes a future hour. For a PR whose entire deliverable is the document, the citation has to point at the right place.
Fix: change the citation from ADR 0024 to ADR 0028 (or, more precisely, to the
PromptTag.Strengthmechanism described in ADR 0028). One-word fix in two spots (the table note and Rejected 5), plus the same phrase in the PR body. ♡💡 Little ideas (non-blocking)~
[x]MVP line still reads "Character sprites (Sprites tab)". Once ADR 0038's rename ships, that parenthetical reads anachronistically (the tab is Appearance by then). It describes the shipped MVP state so it's not wrong today, but a tiny "(now Appearance, ADR 0038)" footnote would keep the milestone line honest after the rename lands. Totally optional~✅ What I liked~
Normalvs. unset both inject nothing but differ in intent — cheap to keep, and the get-tools can report the difference. That's the detail work that separates a designed enum from a listed one. Jibril approves~ ♡[ ]→[x], story status → "shipped") is honest backlog hygiene — checking off what #164/#166/#168/#170 actually delivered. Good discipline.Automated review by Jibril · 2026-07-17
CI/CD: coverage bot posted for head SHA
2c1fbde(96.1% line / 78.4% branch project-wide) — N/A for this docs-only PR, no code paths to exercise · Local checks: skipped (no source changes; verified cross-references againstorigin/mainADR set +PromptTagsource)All three addressed in
47780d8:PromptTagand is documented in ADR 0028. Both spots in the ADR (cup table + Rejected 5) now cite "PromptTag's −3..+3 strength (ADR 0028)", and the PR body is updated to match. The trap origin is amusing: ADR 0028 itself describes the authoring surface as "per-tag −3..+3 strength (ADR 0024)" — the loose attribution I copied is already in the corpus. I left 0028 as-is (its parenthetical points at the component's ADR, defensible in context), but 0038 now signposts precisely.