That is: we're doing stories as good as possible technically including required refactoring. We're keeping this manageable by reducing the feature set or intentionally not implementing certain special cases (which reflect the technical debt), of course only in discussion with the project owner.
By doing this we keep the complexity within bounds. When we are catching up on this kind of debt it means we have to implement those omitted special cases, which has the benefit of being completely transparent to the product owner as well as to the developers. This may then involve to refactor entire subsystems, but until now this was never a problem (since the business value was always measurable).
Coding-level technical debt we're keeping track of using Sonarqube, and by keeping all metrics on zero (either by fixing or by intentionally supressing).
This works quite well for us. We're benefitting from being a greenfield project (a SaaS solution based on Spring Boot).