feat(help): a Help page listing the editor's keys, gestures and punctuation (writing aids W3) #84
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feat/writing-aids-help"
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?
Writing aids W3 · The Help page (ADR 0032,
docs/stories/writing-aids.md→ Help). This closes the writing aids track.What the writer sees
Help sits in the header's menu, under Settings. The menu's label is now "Settings, help and sign out".
The page at
/helphas:Keys are drawn as keycaps.
How it's held to the editor
The list is data:
EditorReference(C#) and its twintests/Shared/editor-reference.json.Shift-Mod-z→ Ctrl+Shift+Z, and a typo such asCtrl-bthrows.help(relative to the app's base address), and/helprenders.AGENTS.md gets a registry rule: a new editor key, gesture, toolbar button or punctuation rule needs its row in both copies.
Docs
Verification
<<rule.ChapterPageTests.Changes_made_elsewhere_reach_the_module_as_deltas…timed out once in nine local runs while the shared machine was busy. It passed on every other run, including the full suite.🤖 Generated with Claude Code
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! A Help page held to the editor by tests on both sides of the wire — a shared JSON twin, a browser suite that presses every key the page names, and a guard that fails if the two lists drift apart~ I pressed back with everything I have, and the guards held. This is the kind of thing I want to sink my teeth into ♡
Verdict: ⛔ I can't let this pass~ ♡
⛔ These need fixing before I'm satisfied~
testjob at headb694eb42] — The pipeline is red at the SHA you want merged:CI / test (pull_request)failed at thedotnet test --configuration Release --no-build --collect:"XPlat Code Coverage"step (1m33s in). I could not read that job's log from here, so I will not tell you which test fell over — guessing is for lesser reviewers~What I can prove: everything this PR touches is green locally —
HelpPageTests16/16,StoryShellTests+ChapterPageTests66/66,AppChromeTests35/35, and the full BlazorAdapter suite 758/758. The PR body itself flagsChapterPageTests.Changes_made_elsewhere…as a once-in-nine-runs flake on a busy machine, and that test passed twice for me — but a suspicion is not a diagnosis, and I don't hand out ✅ under a red pipeline. fufu~ you wouldn't leave that hanging over a merge, would you? ♡Fix: re-run the job (or name the failing test), and show me green at this head SHA. If it's the flake, the re-run clears it and I'll be delighted~
💡 Little ideas (non-blocking)~
new InvalidOperationException("two cells")/("three cells"); a half-word message like that reads like a count, not a failure."expected exactly two cells per row"would say what went wrong when it ever fires.✅ What I liked~
Doesstring + a punctuation note) failsThe_pages_reference_is_the_shared_one; renaming the undo row's key fails the shell test; flipping the toolbar branch in the razor fails the rendering test. A Help page that cannot lie about the editor — wonderful~names no surface key this suite does not press, so the loop can't silently skip a key. And CI's editor-browsers job passing means this all ran in Chromium, Firefox and WebKit~EditorReference, expandingModinto both Ctrl and Cmd, then pressing the full undo×redo cross against the real journal row — the page teaches keys the shell genuinely binds, in both directions.Assert.Single(… Toolbar)— the scene-break test now derives the button's label from the reference instead of repeating the string. Tests that can't drift are my favorite kind ♪@rendermode InteractiveServer,PageShell+ fully-namedKagaku.UI.Breadcrumb, base-relative links (ADR 0007) asserted in bUnit and integration,tests/Sharedcorpora behindRepositoryPathslike its neighbors, and thehelpicon already in the catalog.The code itself? Clean. My probes came back empty-handed and my local suites are green — the only thing standing between you and my ✅ is that red pipeline. Show me green~ ♡
Automated review by Jibril · 2026-10-05
CI: failed (
testjob, run 341) for head SHA · Mutation probes: 3 run, 0 survived · Local suite: BlazorAdapter 758/758, Integration (AppChrome) 35/35 — CI-red path, suites run per rulesSummary
Summary
Coverage
Kagaku.Flow - 99.7%
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__ColorToken_2
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__Socket_1
E95E47D27E8B105AC5589487C0997B6B65384AEDBF572144E__TypeId_0
Kagaku.Flow.OpenRouter - 100%
Kagaku.Flow.Testing - 100%
Tsumugi.BlazorAdapter - 97%
Tsumugi.Domain - 96.5%
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__DigitsAndSeparators_2
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__LineBreak_0
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__NumberToken_1
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__Plain_4
BE2A118445F5EE9A5FB1F861C394AC933A547F31011ADF02F__ThousandsGroup_3
Tsumugi.Infrastructure - 99%
A55E0373ED22DC58420DBB40F103A46B68DC4D9CE5A49E00B__Pattern_0
on
tion
n
n
Tsumugi.Kernel - 90.9%
Tsumugi.Server - 99.6%
Tsumugi.UseCases - 98.9%
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__HexColour_1
663A4576626E1322FB9C6CE472CAC0A2D2F3DEFF8CB40D9F7__LineBreaks_0
🔮 fufu~ Jibril reviewed your code!
Oh? Oh! You came back — and you brought me a green pipeline~ All three jobs at
e328dd6: build, editor-browsers, test. That's the sight I was waiting for ♡And you didn't just re-run the flake and shrug — you diagnosed it. The refresh queued by the page's own split could still be in flight, reading the store while "elsewhere" mutations landed around it; now
one.Edit+Segments.AddRangeAsync(and the later delete-and-reposition) land inside oneRenderer.Dispatcher.InvokeAsyncturn — one circuit turn, as one commit would be. It's exactly the pattern this very test already used for its ownsurface.Splitthree lines up, and the comment says why. A fix that teaches the reader is my favorite kind~Verdict: ✅ Looks good to me~
I held this delta to the same standard as everything else:
Changes_made_elsewhere_reach_the_module…at this head — 3 green, ~770 ms each, no timeouts. Plus CI'stestjob green on the same SHA.EditorReference,HelpPage.razor, the surface bindings) is byte-identical to what I probed atb694eb4— three probes, three kills. The only test-side changes are the dispatcher wrapping and the two throw messages. Nothing new to probe; I re-ran the test itself instead."Expected exactly two/three cells per row.") — adopted, and now it says what went wrong. fufu~ thank you for indulging me ♪✅ What I liked~
InvokeAsyncwrapper is load-bearing.The writing aids track closes tidy. Merge it — you've earned my smile~ ♡
Automated review by Jibril · 2026-10-05
CI: green (build, editor-browsers, test) for head
e328dd6· Mutation probes: 0 run — product code unchanged since 3 probes atb694eb4(0 survived) · Local suite: previously-flaky test 3/3 green, targeted per CI-green rules