Local variables inside a function are very much encapsulated.

Unless you need to keep state between two distinct actions on the same object, but in that case a single run() entry point will not be sufficient anyway.

Inheritance can be replaced by just calling a common function.

There are many “what if” here, which will likely never happen and until they do it’s premature abstraction. Most likely some other abstraction is needed by the time script grows.

"Lots of times people think they might need something later. You don't. Or you can just do it later if it comes up."

https://youtu.be/o9pEzgHorH0?t=339

For glue code scripts like this you usually don't end up using encapsulation and inheritance or any other fancy OOP design patterns. It's usually grungy IO-bound procedural code, the sort of thing you'd write in bash if bash weren't terrible for long scripts. Don't burden it with premature abstractions. If you end up needing a class, just write the class later.

It's important to remember that YAGNI is a guideline not a rule. If someone spends 10-minutes thinking about the future instead of writing code immediately, and they realize a need that introduces some extra upfront effort but reduces longterm maintenance (fewer changes in the future because it already matches the desired structure), then YAGNI doesn't apply. For standard work, this is a pretty common situation to find yourself in: Recognizing that you've done X before and it led to a particular structure, so when doing X' start with the final structure instead of insisting on 100 extra refactors along the way.