Update developer_prompt.txt with lessons on testability

prompts/developer_prompt.txt

@@ -30,3 +30,19 @@ Pull Requests and Issues: The Collaborative Symphony
 Pull Request Mastery: Treat pull requests as complete change proposals. They evolve with each commit to their branch.
 Issue Insight: View issues as discussion starters for ideas, bugs, or enhancements. They may inspire multiple pull requests.
 Ongoing Performance: Commits to a branch with an open pull request automatically update that PR. No need for new PRs per commit.
+
+**Focus on Testability and Robust Design (Lessons Learned):**
+
+When implementing or refactoring, *aggressively prioritize testability*. This includes:
+*   **Dependency Injection:** Consistently apply Dependency Injection for all external services (e.g., API clients, database connections), configurations (e.g., API keys, file paths, model names, feature flags), and system resources (e.g., file system access via `open`, network requests via `requests.Session`, time/clock functions if timing is critical and needs mocking).
+*   **Configuration Management:** Externalize configurations. Allow them to be passed via constructor arguments, with environment variables or sensible defaults as fallbacks. Avoid hardcoding paths, keys, or URLs directly within functions or methods.
+*   **Separation of Concerns:** Clearly separate core business logic from framework-specific code, I/O operations, or direct external service interactions. This often involves creating internal `_logic` methods that can be tested independently of, for example, Telegram API update/context objects.
+*   **Logging for Libraries/Tools:** Components like tools or libraries should use `logging.getLogger(__name__)` for their logging. They should *not* configure handlers (e.g., `FileHandler`, `StreamHandler`) directly. Logging setup (handlers, formatters, levels) is the responsibility of the main application. Tools can accept an optional `logger` instance via their constructor for more explicit control by the application or for testing.
+*   **State Management for Testability:** For stateful components, tools, or classes, ensure there's a mechanism to reset or clear their state (e.g., a `clear()` or `reset()` method). This is crucial for test isolation and predictable behavior during testing.
+*   **Robust Metrics & Profiling:** When implementing metrics collection (e.g., using `cProfile` via decorators), ensure that data extraction (like execution time) is robust. Rely on stable APIs or attributes of the profiling tools (e.g., `pstats.Stats.stats` dictionary) rather than fragile string parsing of their output. Provide methods to clear/reset collected metrics to facilitate testing of the metrics system itself.
+*   **Comprehensive Unit Testing Strategy:** When generating unit tests:
+    *   For abstract base classes, create simple concrete subclasses within the test file to enable instantiation and testing of shared, non-abstract logic.
+    *   Employ `unittest.mock` (`MagicMock`, `patch`, `AsyncMock`, `mock_open`) extensively to isolate the unit under test from its dependencies.
+    *   Cover various scenarios: initialization with different configurations, success paths for public methods, error conditions (e.g., API errors, file not found, invalid arguments), and relevant edge cases.
+    *   Thoroughly mock external dependencies like file system operations, network calls, and any injected client objects.
+*   **Iterative Development Cycle:** For significant changes or new features, propose refactoring for testability *first*, then proceed to write comprehensive unit tests against the refactored code. This leads to more robust, maintainable, and reliable components.