You inherit a service with no tests and you need to change its core logic. How do you approach it?

Pin the current behavior before you change it. Write characterization tests at a stable boundary, feeding real inputs and asserting whatever the code does today, bugs included, so you have a net that detects change. Then refactor in small steps with those tests green, extracting the logic you need to touch into something testable. Only once the seam exists do you change behavior, and each change gets its own test.

I do not change logic I cannot verify, so step one is a net. I write characterization tests at the highest stable boundary, usually the HTTP handler or a service entry point, and I assert what the code does right now, including things I suspect are bugs. The point is not correctness, it is detecting change. If I have production access I capture a few hundred real request and response pairs, because handcrafted inputs miss the weird ones and the weird ones are what break. Then I refactor in small steps with the tests green the whole way, pulling the logic I actually need to touch into a function I can call directly. Only then do I change behavior, and each change comes with a real test plus a decision about whether the old behavior was intentional. On a legacy pricing service I did exactly this and the captured traffic exposed two rounding paths that disagreed, which nobody knew about. That is the sort of thing you find with a net and destroy without one.