## Problem The rule is held at the loud door and not at the quiet one. A payment records which consumer took it as the consumer's **client id**, and nothing else on the payment says whose it is. `ConsumerScope::isOwnPayment()` compares that stamp against the client id the request authenticated as, and every read door on the API scopes through it; `ConsumerLookup::findConsumer()` reads the same stamp back to decide where a notice is posted and where a payer is allowed home. `ConsumerPaymentsGuard` refuses to delete a consumer that payments name, and its refusal states exactly what is at stake: "%label took @count payments, and those payments name it by the client id and by nothing else. Deleting the consumer would leave nobody able to read them back, because every read is scoped to the consumer asking and there would be none." **Editing the client id has precisely that effect, and nothing guards it.** Save the consumer with a new client id and: - every payment it took answers `404 No such payment.` to its own owner, on `/kessai-api/payment/{id}`, on the read door and on every settle door; - `findPayments()` narrows to the new id and answers with none of them; - `PaymentNotifier` finds no consumer for the old stamp and returns without a log line, deliberately, because "all are ordinary, and none is worth a log line on every payment" — so the notices simply stop; - `ConsumerReturnOrigins::forPayment()` answers with an empty list, so a payer mid-checkout on one of those payments is sent to this site's front page instead of home. All of it silent, and all of it on the door an operator reaches by opening the consumer to change something else. The module already watches for this change on the same entity: `KessaiServerSecretHooks::consumerUpdate()` retires the notice secret agreed under the old id, and its docblock calls re-registering a client id an ordinary act — "it is how an operator rotates a consuming site's credentials". ## What shipped The change is refused where the deletion is, on two doors as the deletion has two: a validate handler on the consumer form, which puts the refusal on the `client_id` field somebody just typed into, and `hook_consumer_presave`, which catches drush, a migration and any module's own code. The refusal reads back what storage still holds rather than the entity's own original, which is set on the way through a save and absent on the way through a form. `DeletionRefusedException` says "deletion" and this refusal is not one, so the shape moved to an abstract `RefusedException` holding the entity, the reason and `inside()`, with `DeletionRefusedException` and a new `ChangeRefusedException` as the two ways a value can be taken away. No call site changed. `ConsumerPayments` is new for the count both guards make, for the reason `ConsumerLookup` gives for existing at all. ## Tests | Test | Against the unfixed code | |---|---| | `ConsumerIdentityTest::testTheChangeWouldLeaveThePaymentsAnsweringToNobody` | passes: it is what the change costs, not the fix | | `ConsumerIdentityTest::testChangingTheClientIdPaymentsNameIsRefused` | `Failed asserting that null is not null` | | `ConsumerIdentityTest::testChangingTheClientIdOutrightIsRefused` | the save goes through | | `ConsumerIdentityTest::testTheRefusalReachesTheFormItself` | the form accepts it | The first is the one worth having: it puts the consequence through `ConsumerScope::isOwnPayment()`, the comparison every read door makes, rather than restating it. Three more say the rule is a rule and not a wall. The consumer's logo widget is taken off the form these tests submit. Building an image widget asks core's image toolkit manager a question PHP 8.5 deprecates, and the next-major lane fails on deprecations; the alternative was an ignore pattern broad enough to swallow the same notice from kessai's own code. 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.)