# Requirement change

Drivers forget to tap "I've arrived". It happens constantly — they pull up, the rider is already
standing there, they both get on with it, and nobody touches the phone until the trip is over. At the
moment that trip cannot be started at all: `TripStarted` is only legal once we have seen
`DriverArrived`, so the driver has to tap a button about something that happened five minutes ago
before the app will let them start, and support gets the call instead.

So: **a trip may be started directly from `MATCHED`.** `TripStarted` becomes legal from `MATCHED` and
lands on `IN_PROGRESS`, exactly as it does from `DRIVER_ARRIVED`.

No new kind of event. Nothing new in your contract folder — this is a change to what the machine
allows, not to what it is made of.

**What stays exactly as it was:**

- **`DriverArrived` is still legal from `MATCHED`**, and starting from `DRIVER_ARRIVED` still works.
  The old path is not replaced, it is joined by a second one. A driver who does tap the button gets
  the same trip they always got.
- **Still refused from `REQUESTED`.** You cannot start a trip that has no driver — that rule was never
  about the arrival, it was about the driver, and it has not changed.
- **Still refused once the trip is `IN_PROGRESS`.** There is still no self-loop anywhere, so a second
  `TripStarted` is still an error rather than a no-op.
- **Still refused on a finished trip**, with the same distinction as before: a completed or cancelled
  trip answers that it is finished, not that the event was illegal.
- **Cancellation is unchanged.** The rider may still cancel from `REQUESTED`, `MATCHED` and
  `DRIVER_ARRIVED`, and still may not once the trip is under way — including a trip that got under way
  by skipping the arrival.

**The history records what actually happened, which is the point.** A trip that skipped the tap has
one entry going straight from `MATCHED` to `IN_PROGRESS`, and no `DRIVER_ARRIVED` entry at all,
because the driver arriving was never reported. Do not invent one. A report that wants to know how
long riders wait at the kerb should be able to tell these trips apart from the ones that were tapped,
and it can only do that if the log says what it saw rather than what it assumes.

Everything else is untouched: the driver is still derived the same way, side effects still run only
for an accepted transition and still in order, a failed effect still does not undo anything, the clock
is still read once per accepted transition, replaying a history still rebuilds the trip exactly, and
the two exception types and the precedence between them are the same.
