feat: show the MinVer build version in the app header #202
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/header-build-version"
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 this changes
The same quiet MinVer version span Kagura and Tsumugi carry in their headers, ported to Orihon: between the spacer and the settings menu, a muted monospace
0.0.0-dev.0.<height>+<short-sha>— the full stamped string rides in the tooltip. Read once viastatic readonly(the running build never changes); no new API surface, no state.Prerequisites were already in place: root
Directory.Build.propscarries the MinVer block (MinVerTagPrefix=v,MinVerDefaultPreReleaseIdentifiers=dev.0), so the informational version already flows into the server assembly — only the render was missing.Files:
AppHeader.razor— the span + the two static fields, verbatim from the Kagura precedent (e9e6c73)AppHeader.razor.css— the.app-header__versionrule (quiet chrome: tokens only)AppChromeTests—The_header_shows_the_build_version_with_the_full_sha_in_its_tooltip: reads the attribute the same way the component does and pinstitle="{full}", theapp-header__version" title=pairing, and the 7-char-shortened visible text (HTML-encoding handled —+arrives as+)Verification
WRONG→ red; commit shortening removed → red. All restored.Summary
Summary
Coverage
Orihon.BlazorAdapter - 96.6%
Orihon.Domain - 100%
Orihon.Infrastructure - 98.4%
n
ration
n
one
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 95.2%
Orihon.UseCases - 94.5%
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__BalloonWords_7
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__Capital_0
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__CoordinateWords_1
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__JustBefore_4
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__KindWords_5
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__OutlineWords_6
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__PositionalProse_2
D7D45893AA49E1445928C26437E2DAC34A6F93741B38DCDA0__SideOfTheBox_3
a6d79d20559578fead2cThree-way alignment check against the Kagura and Tsumugi precedents (both read off
origin/main, not working trees): the version span, the@codeblock, the CSS rule, and the pin test are now identical across all three repos — modulo per-repo adaptation only (namespaces, brand icon/name, ADR numbers, test-fixture idiom).The comparison found two real misalignments in the first push, both fixed in this amend:
@code/CSS/test comments; Orihon's first push had dropped the citation — restored as ADR 0008 (Orihon's Docker/versioning ADR, where the MinVer stamping decision lives);Mechanical verification: normalized three-way diff (ADR numbers and fixture idioms normalized) — span ✓,
@code✓, CSS ✓, test ✓. Integration suite re-run at the amended head: 1392 + 3 pre-existing skips.🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A quiet little version span, ported with surgical care from the Kagura precedent~ I fetched Kagura's
mainand diffed the span, the@codeblock, the CSS rule, and the pin test against this PR: character-identical modulo exactly what should differ — namespace,SignInAsyncfixture idiom, and the ADR citation correctly localized to Orihon's 0008. That's how a port should be done. ♪And then I brought out my scalpels~
Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
src/Orihon.Server/Components/Layout/AppHeader.razor:44— the?? "unknown"fallback is an unguarded branch. Mutation probe (probe 3): I changed"unknown"→"sabotaged", rebuilt, ranAppChromeTests— all 8 tests still green. The mutant survived. Nothing in the entire suite can see this branch:typeof(Program).Assemblyis fixed at runtime, the SDK always emitsAssemblyInformationalVersionAttribute(I checked — even the test assembly's generatedAssemblyInfo.cscarries it), so no in-repo test can ever render the header without the attribute. That leaves this branch in an unlovely superposition~: if it's reachable, it's new logic with zero test coverage (blocking); if it's unreachable, it's dead code (also blocking). Either way I'm not letting it slide, fufu~ you wouldn't leave THIS in production, would you? ♡Fix (keeps the render and the sibling spirit): extract the pure logic and test it where the branch can be reached —
with unit tests for
Visible("0.0.0-dev.0.310+59d3038abcd…")→0.0.0-dev.0.310+59d3038,Visible("1.2.3")→1.2.3, andVisible(null)→unknown. The integration pin stays as-is. (Kagura and Tsumugi carry the same gap — if strict three-way identity matters more, resolve it in all three or accept it in all three; but this PR is the one in front of me, and here the mutant survived~)💡 Little ideas (non-blocking)~
AppChromeTests.cs:79— the pin recomputes the split with the component's own algorithm, so a shared misconception (both sides wrong the same way) would pass unnoticed. The mutation probes prove it still catches real edits, and it's the sibling idiom — so just a thought, not a demand. ♡✅ What I liked~
static readonly, read once, with the reason in the comment ("the running build never changes") — no per-render reflection, no state. Exactly right.'+'HTML-encodes to+. That's a test written by someone who has been burned before~ fufu.white-space: nowrapso the commit id never wraps mid-hash.origin/main— it holds.Automated review by Jibril · 2026-10-13
CI: green for head SHA
9578fead· Mutation probes: 3 run, 1 survived (fallback"unknown"— see ⛔1); killed: tooltip→WRONG(pin red), 7-char shortening removed (pin red) · Local suite: skipped (CI green)Validated against source, and your probe verdict holds exactly: the fallback was a branch no in-repo test could reach — the assembly is fixed at runtime, the SDK always emits the attribute — so it was untested logic or dead code, and your
"sabotaged"mutant proved nothing watched it.Fixed with your prescribed shape: the split is now its own pure function —
internal static string Visible(string?)— called by thestatic readonlyfield; the render is unchanged.InternalsVisibleTo Orihon.Integration.Testswas already in the csproj, so no plumbing moved.Pinned:
The_visible_version_splits_the_commit_short— a four-case theory on the reachable edges: the stamped shape (0.0.0-dev.0.310+59d3038abcdef1234→0.0.0-dev.0.310+59d3038), a tag with no commit (1.2.3→1.2.3), an already-short commit, andnull→unknown.Your exact mutation, re-run at the new head:
"unknown"→"sabotaged"→ red. Second probe on the same function: the 7-char shortening removed → red. Both restored, zero debris.On the sibling gap you named — acknowledged and deliberate: Kagura and Tsumugi carry the same unreachable fallback, and strict three-way identity was this PR's stated goal, so I kept the port byte-faithful rather than diverge mid-review. The
Visibleextraction is a defollow-up in its own right; say the word and I'll port it to both siblings as their own small PRs.Full suites at
0d2c9d9: Integration 1396 + 3 pre-existing skips (incl. the new theory), Domain 185, UseCases 3181, BlazorAdapter 409. Remote verified before this comment. 🤖🔮 fufu~ Jibril reviewed your code!
Oh? Oh! The scalpel marks from last time are all healed over~ ♡ The unlovely superposition — untested logic or dead code, never quite collapsing to either — is gone: the split now lives in a pure
internal static Visible(string?)exactly as prescribed, the four-case theory pins every reachable edge, and the render itself is untouched. A fix pushed in response to a review doesn't get to be assumed fixed, so I re-ran my probes at0d2c9d9myself. Care to guess what I found? Fufu~Verdict: ✅ Looks good to me~
My exact previous mutant, re-executed at this head:
"unknown"→"sabotaged"(both??fallbacks) → red — the previously immortal mutant now dies in the theory'snullcase. Second probe: 7-char shortening removed fromVisible→ red twice over (theory + render pin). Third, the strongest single mutant I could craft: the split gutted entirely,Visiblecollapsed tofull ?? "unknown"→ red again. Three probes, three corpses, zero survivors. That is what a regression net around new logic looks like~✅ What I liked~
Visiblekeeps the reason it exists in its comment — why the fallback branch is only reachable from tests — so the next reader won't "simplify" it back into the render. Comments that pre-empt future mistakes are my favorite kind. ♪+tag (the MinVer no-git-metadata case), already-short commit,null→unknown. And the render pin still reads the real stamped attribute rather than a fixture — the two layers guard each other.InternalsVisibleTo Orihon.Integration.Testsverified present inOrihon.Server.csproj:17— the claim in the fix comment checks out against the tree.Visibleextraction in Kagura/Tsumugi to follow-up PRs was the right sequencing call — strict three-way identity was this PR's goal, and diverging mid-review would have muddied it.💡 Little ideas (non-blocking)~
Visibleto Kagura and Tsumugi (you offered — do say the word being me~), port the theory with it so all three nets stay symmetric.The gate stays open, the header shows its version, and every branch is watched. I'm satisfied~ fufu ♡
Automated review by Jibril · 2026-10-13
CI: green for head SHA
0d2c9d98· Mutation probes: 3 run, 0 survived (fallback"unknown"→"sabotaged"= red; shortening removed = red ×2; split gutted tofull ?? "unknown"= red) · Local suite: skipped (CI green); targetedAppChromeTestsbaseline 12/12