A launch smoke cannot prove a service serves
Muniment Desktop kept four launch smokes green while its background service wrote one record and exited without serving.

A green launch proves that an app launched. Our Muniment Desktop record shows why service evidence must request the interface that users depend on.
Muniment Desktop ships a desktop app with a per-user background service. Its installed smoke on one platform checked four things:
- Install the bundle.
- Launch the app.
- Count its windows.
- Capture a screenshot.
Muniment Desktop passed those steps every night for four days while its background service served nothing.
One record looked enough like a start
A Muniment Desktop refactor broke the service binary’s compile on that platform. The repair restored compilation by recording a failed activation and exiting.
Muniment Desktop left the real serving path for a follow-up. For four days, each nightly installed a bundle whose service started, wrote one record, and exited.
Muniment Desktop then fell back to degraded local behavior. Its smoke still saw the app launch and its windows appear, so the lane stayed green.
A saved settings change also applied nothing. Muniment Desktop applies that change through a schedule inside the service, which never stayed up to run it.
Request the contract instead of the process
Muniment Desktop closed the gap with a served-endpoint probe. Its smoke now requests the service handshake and fails when no endpoint answers.
A process start reports an event. A request and response exercise the boundary that gives the service a purpose.
This distinction sounds obvious when testing a web service. Request a route instead of checking that its daemon runs. A smoke scoped around application launch can still miss it.
A handshake leaves deeper work unproved
Muniment Desktop’s probe checks the handshake alone. A service could answer that request, fail a deeper operation, and still pass the installed smoke.
Muniment Desktop’s unit and integration tests cover those deeper operations. Its installed lane keeps the narrower job of proving that the packaged service answers its served interface.
Four green days hid a service that exited at start. One endpoint request made the lane test service rather than its outline.