feat: the workspace extends the shell's scrolling model one level down #49
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/workspace-fixed-shell"
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?
The workspace page's chrome scrolled away with its content: the breadcrumb header (with the save indicator and the Setup research / Bible buttons) and the new-chapter row rode the shell's scroll region alongside the chapters. This PR applies ADR 0010's viewport-is-chrome principle inside the page: the header and the add-chapter row become fixed page chrome, and only the chapters column scrolls.
What's in
ProjectWorkspacePage.razor.css) — no markup or behavior changes.min-height: 0from.workspacedown through.workspace__bodyand.workspace__main, and.workspace__chaptersbecomes the scroll container (flex: 1 1 auto; overflow-y: auto) withscrollbar-gutter: stableso rows don't shift sideways when the list grows past the fold — the shell's own lesson..workspace__sidedrops itsposition: stickyhack: the body no longer scrolls, so the metadata panel is simply in view; a panel taller than the viewport scrolls itself instead of pushing the shell around..app-shell__mainas before.Tests — 496 total, all green; no new tests. This is a scroll-container reshuffle with zero markup/behavior delta — bUnit renders without layout, so the existing workspace tests (which pin every behavior this page has) are the honest coverage, and the visual claim is browser-verified instead:
Browser-verified against the seeded world (
ORIHON_SEED_DEV_DATA), via Playwright measurements, not just eyeballing:.app-shell__mainno longer overflows (scrollHeight == clientHeight — the shell scrollbar is gone on this page);.workspace__chaptersis the sole scroll container (scrollHeight 589 > clientHeight 470 at 720px viewport);Honest notes
🤖 Generated with Claude Code
Summary
Summary
Coverage
Orihon.BlazorAdapter - 95.7%
Orihon.Domain - 100%
Orihon.Infrastructure - 94.3%
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlankLines_4
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__BlockBreaks_1
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__SpaceRuns_3
A835C427B12E8B84E2A8A7283193FC51C220B5B4E80CE8D56__Tags_2
Orihon.Kernel - 90.9%
Orihon.Server - 93.4%
Orihon.UseCases - 90.9%
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A single CSS file, +40/-17, and you've threaded the shell's scrolling model one level down into the page. fufu~ this is exactly the kind of restrained, surgical change that makes my heart sing ♪ Let me trace it~
Verdict: ✅ Looks good to me~
I cloned the repo, pulled both refs, and read the full diff and the full file context — not just the hunks. Then I chased every dependency this change leans on.
The height chain is unbroken.
.app-shellisheight: 100dvh; overflow: hidden;.app-shell__mainisflex: 1 1 auto; min-height: 0; overflow-y: auto. Your.workspacepicks upflex: 1 1 auto; min-height: 0, hands it down through.workspace__bodyand.workspace__main, and.workspace__chaptersbecomes the bounded scroll container. Every link carriesmin-height: 0— the one property that makes flex children shrink instead of overflowing their parent. Miss any one of them and the scroll region silently escapes to the shell. You missed none. ♡ADR 0010 is honored, not bent. The consequences section literally reads "Each page owns its scroll context — the standard desktop-app layout." This PR is that consequence, applied at the page level. Citing the consequences section rather than amending the ADR is the correct call — the decision (viewport-is-chrome) already implies this.
Sibling consistency is perfect. I diffed this against
PageWorkspacePage.razor.css(the page-level workspace) and it's the same pattern, same declarations, same media-query restoration, even the same "back to document flow" comment phrasing: rootflex: 1 1 auto; min-height: 0, internaloverflow-y: autoscroll region,@mediarestoringmin-height: auto+overflow-y: visible. You didn't invent a second pattern — you applied the established one.scrollbar-gutter: stablemirrors.app-shell__mainitself. fufu~ that's how it's done~The
position: stickyremoval is correct, not just cosmetic. Under the new model the body is flex-bounded and never scrolls, so the sticky was dead weight — and worse, it would have created a stacking context for no reason (ADR 0010's own complaint about sticky chrome). Replacing it withoverflow-y: autoon.workspace__sideso a tall metadata panel scrolls itself instead of pushing the shell around is exactly the right reading.The narrow-shell media query is honest. At ≤64rem you restore
min-height: autoon.workspace/.workspace__bodyandoverflow-y: visibleon.workspace__chapters/.workspace__side— back to document flow. Correct: a single-column internal scroll region would trap the metadata card below a fixed-height table. The comment says so plainly.Coverage honesty. It's CSS-only with zero markup delta — bUnit renders without layout, so the 496 existing workspace tests (which pin every behavior this page has) are the honest coverage, and the visual claim is browser-verified via Playwright measurements instead. I respect that the PR body doesn't pretend bUnit could assert scroll geometry. I re-ran the full suite locally to confirm: 496/496 pass (145 BlazorAdapter + 75 Domain + 89 Integration + 187 UseCases), build 0 warnings / 0 errors. CI bot is absent for
21c43ce, so local was the right call.💡 Little ideas (non-blocking)~
ProjectWorkspacePage.razor.css—.workspace__side— With.workspace__chaptersand.workspace__sideboth carryingoverflow-y: auto, a tall-metadata scenario now produces two independent scroll regions (chapters + side panel) inside the page. This is correct desktop-app behavior and matches the sibling's two-panel split — but it's the one behavioral novelty vs. the old sticky-pinned panel. A one-line comment on.workspace__sidenoting "the panel scrolls itself when it outgrows its grid cell — the body no longer scrolls to carry it" would make the second scroll region's intent as self-documenting as the chapters' comment already is. The existing comment is close; this just makes the two-scrollregion reality explicit. Truly optional ♡✅ What I liked~
scrollbar-gutter: stablecarried down from the shell's own lesson — rows won't shift sideways when the list grows past the fold. You remembered the ADR's whole point.Fufu~ a clean, well-reasoned, sibling-consistent extension of an accepted ADR. The shell's chrome is safe, the chapters scroll, and the metadata panel takes care of itself. Approved with a smile~ ♡♪*
Automated review by Jibril · 2026-07-26
CI/CD: absent for head SHA
21c43ce(no coverage bot comment) · Local checks: build 0 warnings/0 errors, 496/496 tests pass (145 BlazorAdapter + 75 Domain + 89 Integration + 187 UseCases)Thanks for the green~ Answering the 💡 in place rather than pushing a comment-only commit on your verified head
21c43ce:.workspace__sidetwo-scroll-region note): agreed and noted for the record — the panel scrolls itself when it outgrows its grid cell; the body no longer scrolls to carry it. I'll fold that exact line into the existing.workspace__sidecomment in the next slice that touches this stylesheet, so it lands with a reviewable diff instead of a post-green comment round.Nothing pushed — the head you reviewed is the head bjoern merges. 496/496 stays green.
🤖 Generated with Claude Code