## Problem `PaymentEvent` carries the payment and nothing else. A payment knows its totals - `getCapturedAmount()`, `getRefundedAmount()`, `getReversedAmount()` - but not which movement just happened. A subscriber that needs to name the movement behind an event has to ask a service for it: ```php $movement = $client->getLatestMovement($payment, $movement_type); ``` That is a second question about something the producer already knew. `PaymentEngine` records the movement, saves it, and dispatches with the object still in scope - `$claim` at the capture dispatch, `$refund` at the refund one. It is discarded, and the subscriber goes back to storage to reconstruct it. ## Why it matters Asking a service is not the same as reading the payment. An engine answers only for rows it stores; a client answers only for payments held on another host. A site running both hears every event under the same constants, because `kessai_client`'s notice controller re-announces what arrives under the name it arrived with - deliberately, so a subscriber written against a local kessai runs unchanged. A subscriber reaching for a service therefore has to know which side holds the payment before it asks. #3621954 is that defect: the audit trail subscriber asked the engine about a payment the engine does not store, the refusal escaped the dispatch, and the notice route answered 500. The guard added there is correct for the shape that exists today, but it guards against a question that need not be asked. ## Proposed ```php final class PaymentEvent extends Event { public function __construct( public readonly PaymentInterface $payment, public readonly ?MovementInterface $movement = NULL, ) {} } ``` - The engine passes the movement it just recorded. It holds one at each of the five events that name a movement: `CAPTURED` (claim), `REFUNDED` and `PARTIALLY_REFUNDED` (refund), `CANCELED` and `PARTIALLY_CANCELED` (reversal). The rest pass none. - A subscriber reads `$event->movement` and needs no service, so which side holds the payment stops mattering for this case. - `kessai_client` can fill it from the notice payload, so an event arriving from another host carries its movement too. ## What it removes `PaymentClientInterface::getLatestMovement()` has exactly one production caller across kessai, yoyaku and orchestra: the audit trail subscriber. With the movement on the event that caller goes, and the method can be deleted from the contract outright, kessai being pre-1.0. That is the method with the worst shape on the contract. There is no wire door for it, so `RemotePaymentClient` implements it by reading a payment's whole movement list and keeping the last row - a cost its own comment accepts because the round trip happens either way. `PaymentEngineInterface::getLatestMovement()` stays. It is one indexed read locally rather than a round trip, and several tests read a movement back through it. The asymmetry is the point: the cost that makes it wrong on the contract does not exist on the engine. This also removes `kessai_audit_trail`'s only use of the engine, which would let that module work on a client as well. Whether a site *should* record what another host reported, and how such an entry marks itself as second-hand, is a separate decision and not proposed here. AI-Generated: Yes (Claude Code was used to help draft this issue summary. No code change is proposed yet; the analysis was verified against the current 1.x source.)