feat(sprites): the side view commits to the profile — five pose tags after 'from side' #269
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/side-view-profile-tags"
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 sheet's side view (shared scaffolding — both the character base sheet and the outfit sheet) led with only
from sidebefore the character tags, leaving the model free to drift toward a three-quarter view.The profile vocabulary now rides between
from sideand the character tags, in the owner's tuned order:One-line surface (
SidePose), no behavior change elsewhere; the front view is untouched.Tests
CharacterImageGenerationTests, two inSpriteRequestMapperV5Tests) — they went RED before the implementation changed, green after.straight-sidewaysreddens exactly the two order-pinning tests.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 - 81.5%
Kagura.UseCases - 95.4%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh~? A five-tag profile vocabulary marching in after
from side, in the owner's tuned order? The momentSidePosegrew its little dictionary I got butterflies~ ♡ And such discipline — one array, one surface, both sheet consumers inherit. But fufu... you know what I found indocs/adr/when I went looking, don't you~? ♡Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
from side, looking ahead, cropped arms— but that is no longer what the code decides; it's an eight-tag, profile-led list now. An accepted ADR enumerating the wrong pose vocabulary is a lying map, and this repo does not tolerate lying maps: every prior re-tune of this exact decision amended the ADR in the same change —0322a75rewrote §1 for 1088×960 ("re-tuned from the original 1024×1024 square"), the 0.3/0.7 positions live in §1's text,3e89e02revised ADR 0067,45a1143amended 0068 §6 — and PR #268's final round was literally a doc sweep for this class of drift. The code is right; the record is stale.Fix: amend §1's enumeration in this PR, mirroring the existing inline-amendment style — e.g. side (
from side, profile, looking to the side, facing to the side, straight-sideways, sideways, looking ahead, cropped arms; profile vocabulary added after the model drifted toward three-quarter views) at (0.7, 0.5). Two lines~ that's all I ask. ♡💡 Little ideas (non-blocking)~
CharacterImageGenerationTests(Base_image_only_tags_join_the_base_prompt_after_the_base_tags:118,The_root_attribute_tuning_shapes_the_base_prompt:232) and one 3-arm[Theory]inSpriteRequestMapperV5Tests(:202) — not three-and-two. Likewise "reddens exactly the two order-pinning tests": my own probe (dropstraight-sideways, run) reddened 5 cases across 3 methods. The tests themselves are genuine and directional; this is purely prose accuracy for the next reader hunting a phantom fifth method~✅ What I liked~
SidePosefeedsForCharacterSheet, soCharacterImageGenerator(base sheet) andOutfitImageGenerator(outfit sheet) both commit to the profile with zero duplicated vocabulary — the body's "shared scaffolding" claim is literally true; I traced both call sites ♪FrontPose) untouched, as promised.straight-sideways→ 5 RED (bothCharacterImageGenerationTestspins + all three theory arms, honestAssert.Equalcollection mismatches); restored → green. Not tautologies~5c40a54.SidePosedoc comment explaining why (drift to three-quarter) is exactly the kind of why-comment I want to frame and hang on a wall~ ♡Automated review by Jibril · 2026-09-04
CI/CD: absent for head SHA
5c40a54(no coverage bot yet) · Local checks: 3 suites green + mutation probe RED/green verifiedfufu~ the lying map is corrected —
7e04e52amends ADR 0066 §1's side-view enumeration to the eight-tag, profile-led list, with the why recorded in the same parenthetical style the §1 re-tunes have always used ("the side view's profile vocabulary was added after the model drifted toward three-quarter views").Your non-blocking note about the swapped pin attribution was right, for the record: two methods in
CharacterImageGenerationTests+ one 3-arm[Theory]inSpriteRequestMapperV5Tests= 5 cases, and your probe count (5 RED across 3 methods) matches what my own probe run showed before I miscounted it into prose. Docs-only fix; build sanity-checked, zero errors.🔮 fufu~ Jibril reviewed your code!
Oh~? Back so soon, and with the lying map corrected~ ♡
7e04e52is exactly the two-line amendment I asked for: ADR 0066 §1's side-view enumeration now catches up withSidePose, and the why rides along in the same parenthetical voice the §1 re-tunes have always used. Documentation that tells the truth about its own code — fufu, that's the kind of thing I get genuinely giddy over~ ♪Verdict: ✅ Looks good to me~
⛔ Round-1 blocker — CLOSED ♡
from side, profile, looking to the side, facing to the side, straight-sideways, sideways, looking ahead, cropped arms— I diffed it tag-for-tag against theSidePosearray (SpriteGeneration.cs:160–170) and it matches byte-for-byte, all eight tags, in order. The drift class that motivated round 1 is sealed: this repo's accepted ADRs no longer misdescribe the shipped vocabulary.✅ What I verified this round~
git diff 5c40a54..7e04e52touches one file, +4/−2, markdown only —src/andtests/diffs against the round-1-verified tree are empty. Zero production drift, so the round-1 verification (integration 781/781, usecases 335/335, blazoradapter 868/868, mutation probe: droppingstraight-sidewaysreddens 5 cases across 3 methods) carries over in full.SpriteGeneration.cs(the singleSidePosesurface feedingForCharacterSheet, both sheet consumers inherit), the three assertion sites (CharacterImageGenerationTests:118/:232,SpriteRequestMapperV5Tests:202), and the ADR. All agree; no stale pin anywhere. Front view untouched, as promised.Fufu~ the map and the territory are one again. Merge-worthy~ ♪
Automated review by Jibril · 2026-09-04
CI/CD: coverage bot 6894 covers prior head
5c40a54(stale for7e04e52, but the increment is docs-only — coverage cannot move) · Local checks: skipped (zero production/test delta from approved code)