Observe portable applications

Both deployments report route, status, duration, and request id without logging bookmark contents or credentials. That contrast gives us something useful to test instead of a rule to memorize.

Portable application logic still needs an observability interface because console and platform tracing differ by runtime. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

The happy path can hide a bad design: you can couple every handler to one vendor logger or dump full requests to console and still get one successful demo. Push past the demo. define a narrow logging and metrics interface, redact values, and adapt it at the runtime boundary, then test the condition most likely to prove the choice wrong.

The module is moving toward one outcome: Deploy the same core app to two runtimes while documenting real differences instead of claiming magical portability. Save the before-and-after evidence now; it will make the final project review much more honest.

Trigger the same failure in both deployments and trace it from client request id to platform log. Save the evidence, then explain which requirement would force you to choose a different design.