condition-based-waiting

Replace fixed `setTimeout` or `sleep` calls with condition-based polling that waits for actual state changes. This eliminates race conditions by checking for specific events or conditions instead of guessing timing, making your test suite reliable across local, CI, and distributed environments.

Use a generic polling loop that evaluates a condition function at regular intervals until it resolves or times out. This approach balances responsiveness with CPU efficiency, typically polling every 10ms, and returns the resolved value with informative errors when conditions aren't met.

Yes. Condition-based waiting handles race conditions by polling for specific events (like `TOOL_RESULT` or `AUTHENTICATED`) or state changes rather than relying on fixed delays. It works with event managers, state listeners, and readiness checks across async workflows and IO availability scenarios.

Polling repeatedly checks whether a condition is true instead of assuming timing will work. Since it enforces a timeout and fails with clear errors when conditions aren't met, you catch real issues rather than masking timing problems with longer sleeps.

Use condition polling whenever your tests wait for events, state transitions, or resource availability. Replace `setTimeout` with condition-based waiting if tests fail intermittently, depend on arbitrary delays, or involve async workflows prone to flakiness.