## Problem `kessai_client` is the half of Kessai a site installs when its payments are settled elsewhere, and everything it does is decided on one screen: the remote payment accounts listing. Nothing in the administration pointed at it. No menu link, so the only way in was the *Configure* link on the Extend page; no action link, so a fresh install had an empty listing, no first remote to add and no existing one to edit. The engine ships both for its own accounts and says why in the file that does it. The listing's empty text was core's, which says only what the operator can already see. The one link the module did ship, *Notice limits*, sat under Web services beside remotes that were not in the menu, though its own comment placed it beside them. Two more, found auditing the first fix. **A link beneath the remotes is drawn on no page at all.** Nesting the limits under the remotes as a menu link reads correctly and renders nowhere: both Configuration pages load a section's own children and stop, so a grandchild appears on neither, and the page it was nested under is an entity collection, which draws its rows and nothing else. The page `docs/limits.md` sends an operator to was reachable by typing its path. **A client that reaches no host says so nowhere.** Kessai's status report asks whether an implementation is installed, and this module is one, so installing it answers that question and the report says no more. An implementation that reaches nowhere settles nothing: a site with this module and no enabled remote is refused at the first checkout, having been told at no point that anything was missing. The listing's own comment already claimed the status report said this. ## What shipped A menu link to the remotes and an action link for the add form, with empty text that says what the empty state costs. The notice limits are a local task on the listing rather than a menu link beneath it, which is the shape core gives the same situation: one menu entry for the listing, the other screens on that subject beside it as tabs, the way People carries Permissions and Roles. The status report gains the line, reported the way this project reports every other way a module goes quietly inert, and reading the remotes through the lookup a payment uses rather than asking the storage a second way. Enabled ones, because a site that turned its only remote off has the same checkout and the same silence as one that never added a remote. `docs/limits.md` names the pages as they read, and `docs/remote.md` says where a remote is added. ## Tests | Test | Against the unfixed code | |---|---| | `RemoteAdminTest::testTheRemotesAreReachedFromConfiguration` | no entry on either Configuration page | | `RemoteAdminTest::testTheLimitsAreFoundOnTheRemotes` | the tab is not there to click | | `RemoteAdminTest::testTheEmptyListingOffersTheAddForm` | no way to add the first remote | | `ClientBindingTest::testNoRemoteMeansTheStatusReportSaysSo` | the report is silent | | `ClientBindingTest::testOneRemoteSilencesTheStatusReport` | the report is silent either way | The href assertions end at the path rather than containing it: the limits page lives one segment further down the same path, so a contains-match is satisfied by the link that was already there. The functional tests place the local tasks and local actions blocks, because stark draws neither and an administration theme draws both. The kernel tests ask the module handler whether anything dispatches the hook before invoking it: an attribute for a hook core dispatches nowhere is perfectly callable and never called, which has happened in this project before. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the code and tests on the merge request. I reviewed and ran the work myself before posting it.)