The Test Suite That Depends On Its Own Order
Decide what you would do from the brief alone, including whether you would change anything at all. Everything below it is available, but the exercise stops working if you open it first.
Classes call container.resolve(PricingService) inside their methods. A new test needs a fake pricing service, and the only way to supply it is to mutate the global container in beforeEach. Tests now pass or fail depending on which order they run in.
Adding container.reset() to a global test hook and moving on. Order-dependent flakes stop the same day, the suite is green, no production code changes, and it is defensible as "fixing the tests" rather than as a risky refactor — which is precisely why it is what happens. The design defect it conceals is not a test problem. Because dependencies are fetched by type at call time, a missing registration is still invisible until the code path runs, and there is still no place to read what a class depends on except its implementation. The flakiness was the honest signal, and resetting the container turns the signal off while leaving the cause.
Read this even if you are confident. It is here rather than behind a button because it is the answer most teams actually ship, it passes review, and the cost of it does not arrive until the change after this one.