feat(characters): the base sheet is 1088x960 — wider so the two views breathe #263
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/character-sheet-wider"
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?
Re-tunes the ADR 0066 base-sheet canvas from square 1024x1024 to 1088x960 — slightly wider than tall, so the two side-by-side views get horizontal room to breathe.
GenerationCanvas.SquarerenamedSheetwith the new dimensions (1088x960 is no longer square; both multiples of 64, the only consumer isForCharacterSheet).1088 / 960, both the image and placeholder states); a legacy square sprite just center-crops in the slightly wider frame.No schema change —
base.pngreplace-in-place, dimensions ride the spec as before.Verified: build 0w/0e; targeted suites green — Integration 50/50 (SpriteRequestMapperV5 + CharacterImageGeneration + NovelAiGateway), BlazorAdapter 18/18 (CharacterBaseSprite + CharacterSprite + CharacterPreview).
Summary
Summary
Coverage
Kagura.BlazorAdapter - 89%
Kagura.Domain - 94.8%
D04ADFED3A21D401C2764A1D17367E35BEB556CBB3B4B0B74__NonSlugChars_0
Kagura.Infrastructure - 97.7%
n
n
on
ng
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ArtifactTimestampRegex_2
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__ProjectRoute_0
C689CA5BBE6D1849B2CA79581BBB07D40636D85790C0E51A9__TabQuery_1
Kagura.Kernel - 90%
Kagura.Server - 82.4%
Kagura.UseCases - 95.7%
🔮 fufu~ Jibril reviewed your code!
Oh? A canvas re-tune~ The rename itself is beautiful work —
Squareat 1088×960 would have been a lie wearing a name tag, and you killed it everywhere the symbol lives. Zero survivors. I checked~ ♡Verdict: ⛔ I can't let this pass~ ♡
The rename swept the symbol, but the story of "square" — and the sheet's new waistline — didn't reach every place the sheet meets the eye. Two things, both small fixes, both real.
⛔ These need fixing before I'm satisfied~
[src/Kagura.BlazorAdapter/KnowledgeBase/CharacterBaseSprite.razor:7, src/Kagura.UseCases/Generation/SpriteGeneration.cs:124, src/Kagura.Infrastructure/KnowledgeBase/CharacterImageGenerator.cs:52] — the "square" claims that survived the rename. The PR's whole job was retiring "square", yet three doc comments still assert it:
CharacterBaseSprite.razor:7— "two-view character sheet — front and side, square" — the same comment block you edited ten lines below (you struck "square" from the inner comment at :17 but not the header at :7).SpriteGeneration.cs:124—ForCharacterSheet's XML doc still opens "one square generation" — in the very file where the record's own doc now says "re-tuned from the original square". Method and record contradict each other a hundred lines apart.CharacterImageGenerator.cs:52— "square generation" — the sole production consumer ofForCharacterSheet.Fix: strike/replace "square" at all three ("one sheet generation" reads fine). And while your fingers are in there: the "thirds" phrases from my #262 review (merged with that block outstanding) sit in blocks this PR already edits —
SpriteGeneration.cs:128("at the sheet's thirds"),SpriteRequestMapperV5Tests.cs:191("the front at the left third" — inside the very test you just renamed),docs/stories/character-sprites.md:33("on the sheet's thirds" — on the very line you re-worded). 0.3/0.7 are not thirds, and the prose invites a future "restore to real thirds" ♡ If #262's block was deliberately waived, say so in-thread and I'll drop that part~[src/Kagura.BlazorAdapter/Projects/ProjectAssetsPage.razor:135–140, src/Kagura.BlazorAdapter/KnowledgeBase/CharacterPreview.razor:73] — two sibling render sites still frame the sheet as a portrait. The PR updates one of the three places the base-sprite URL renders, so the codebase now contradicts itself:
ProjectAssetsPage.RatioFor's fallback handsCharacterSpritethe outfit-portrait832 / 1216. Every character-sprite card in the asset browser center-slices the 1088×960 sheet — withobject-fit: cover, both positioned views (x=0.3, x=0.7) get clipped. The per-kind arm is the established pattern right there (landscape kinds →1216 / 832); addProjectAssetKind.CharacterSprite => "1088 / 960".Ratio="832 / 1216"for every item, andImageSrc(:134) serves the base sheet forCharacterSprite— the one gallery where the user needs to see both views to pick a crop source shows a portrait-sliced sheet.Full disclosure, because I care about being fair: these date to #261 — a square sheet in a portrait frame was already wrong, and my #261 review missed them. My miss, my apology~ But this PR is the sheet-geometry change; it widens the mismatch (ratio 1.0 → 1.133 against a 0.684 frame) and establishes the "render sites follow the ratio" principle while applying it to one site of three. Two lines each. Sweep them here~ A legacy 832×1216 portrait center-cropping in the wider card is exactly the transition your editor preview already documents ♡
💡 Little ideas (non-blocking)~
aspect-ratio:1088 / 960would make geometry drift test-visible — no adapter test pins any ratio today, which is exactly how #261's miss survived two reviews.✅ What I liked~
GenerationCanvas.Squarehas zero survivors repo-wide, the sole consumer updated, and the new name is honest — naming a 1088×960 canvas "Square" would have been a bug wearing a doc comment.Ratio="1088 / 960"is safe by construction — I checked Kagaku.UI'sPreviewImage:Ratiois a string CSSaspect-ratio, so no integer-division trap. The trap I had prepared left disappointed~ fufuGeneratedImageupdated, the theory honestly renamed (…on_a_sheet).object-fit: coververified inPreviewImage.razor.css.Automated review by Jibril · 2026-09-01
CI/CD: absent for head
0322a75(PR opened 22:12, no coverage-bot comment yet) · Local checks: build 0w/0e; Integration 50/50 (SpriteRequestMapperV5 + CharacterImageGeneration + NovelAiGateway); BlazorAdapter 18/18 (CharacterBaseSprite + CharacterSprite + CharacterPreview)Review feedback (Jibril) addressed in
9a9e8d6— thank you!1. The surviving "square" claims — all three struck (base-sprite header comment → "slightly wider than tall",
ForCharacterSheet's doc and the generator's comment → "one sheet generation"). And the "thirds" phrasing from your #262 block: also retired in all three places it sat in blocks this PR touches —SpriteGeneration.csand the story line now say "free-form-positioned toward the sheet's left and right", the mapper test comment says "toward the sheet's left". You're right that 0.3/0.7 are not thirds; waived deliberately would have been wrong here since the blocks were already open. (The two #262-blocked spots outside this PR's files were merged with the block outstanding — not mine to re-litigate in this thread.)2. The two sibling render sites — both follow the sheet's ratio now.
ProjectAssetsPage.RatioForgains the per-kind armCharacterSprite => "1088 / 960"(the asset browser no longer portrait-slices the sheet), and the preview picker's gallery switches from the hardcoded832 / 1216to a per-kindRatioFor(image.Kind)with the same arm — both with the why in a comment. Legacy portrait/square sprites center-crop in the wider frames, same transition the editor preview documents.💡 The non-blocking pin — taken too.
The_previews_frame_follows_the_sheet_canvas_1088x960asserts the renderedaspect-ratio:1088 / 960style on both the generated preview and the placeholder — a future canvas change that leaves a frame behind goes red.Verified: build 0w/0e; adapter slice 21/21 (CharacterBaseSprite + CharacterPreview + ProjectAssets, including the new pin).
🔮 fufu~ Jibril reviewed your code!
Round two~ ♡ You said "all three struck, both siblings follow, and the pin is taken too" — so I didn't take your word for it. I re-cloned at
9a9e8d6, swept the whole tree, traced every render site, and probed the new pin with a mutation. Fufu~ everything you claimed is true.Verdict: ✅ Looks good to me~
⛔→✅ Blocker 1 — the "square" story: closed
CharacterBaseSprite.razor:7header now says "slightly wider than tall" ✔,ForCharacterSheet's XML doc says "one sheet generation" ✔ (no more method-vs-record contradiction a hundred lines apart),CharacterImageGenerator.cs:52says "sheet generation" ✔. Repo-wide grep for "square": the only survivors are the avatar-crop vocabulary (CropSquare, unit-square, square-locked drags — different feature, correct usage) and ADR 0066's own "re-tuned from the original 1024×1024 square," which is history, not geometry. Zero sheet-geometry survivors.SpriteGeneration.cs, the mapper test comment, the story line — now "toward the sheet's left and right"). My repo-wide sweep finds zero "thirds" left anywhere, so wherever those two outside spots you mentioned were hiding, the tree is clean of them now~ The constants and the prose finally agree. ♡⛔→✅ Blocker 2 — the sibling render sites: closed
ProjectAssetsPage.RatioForgainsCharacterSprite => "1088 / 960"✔ — and I love that you kept the landscape trio arm right below it, so the switch now reads as a complete kind→geometry table.832 / 1216is replaced byRatioFor(image.Kind)✔, with its own local twin carrying the same arm and its own why-comment. Two components, two private static kind-switches, no coupling between an asset browser and a character-editor modal — that's the same tradeKindLabel/Keyalready make in these very files. I checked every otherPreviewImagein the adapter: outfits/expressions portrait, locations/CGs widescreen, avatars square. Every frame in the app now matches its image's kind.💡→✅ The pin: taken, and it has teeth
The_previews_frame_follows_the_sheet_canvas_1088x960asserts the renderedaspect-ratio:1088 / 960on both the generated preview and the placeholder — and I mutation-probed it: reverting the ratio to832 / 1216in my review clone turns exactly that test red (Not found: "aspect-ratio:1088 / 960"), restore turns it green. Not a tautology. This is the tripwire that would have caught #261's miss — thank you for building it~✅ What I liked~
9a9e8d6.Merge it~ The sheet breathes, the frames agree, the prose tells the truth. Fufu~ ♪
Automated review by Jibril · 2026-09-01
CI/CD: stale for head
9a9e8d6(coverage bot 6724 covers0322a75only) · Local checks: build 0w/0e; BlazorAdapter slice 16/16 (CharacterBaseSprite + CharacterPreviewPicker + ProjectAssetsPage); Integration slice 50/50 (SpriteRequestMapperV5 + CharacterImageGeneration + NovelAiGateway); mutation probe RED→restored→green