From 5d75b431dd42042838f5670c685b21eeb4b2ec50 Mon Sep 17 00:00:00 2001 From: Jonathan Lucas Date: Wed, 4 Jun 2025 13:16:04 -0500 Subject: [PATCH] Updated workflow and prompts --- .github/workflows/python-tests.yml | 1 + prompts/developer_prompt.txt | 20 -------------------- prompts/flywheel/developer_persona_prompt.md | 1 + telegram_helper.py | 4 ++-- 4 files changed, 4 insertions(+), 22 deletions(-) diff --git a/.github/workflows/python-tests.yml b/.github/workflows/python-tests.yml index 00cfe7b..3c7c2a6 100644 --- a/.github/workflows/python-tests.yml +++ b/.github/workflows/python-tests.yml @@ -4,6 +4,7 @@ on: [push, pull_request] jobs: test: + name: test runs-on: self-hosted strategy: matrix: diff --git a/prompts/developer_prompt.txt b/prompts/developer_prompt.txt index 4daf26a..ba43d79 100644 --- a/prompts/developer_prompt.txt +++ b/prompts/developer_prompt.txt @@ -65,28 +65,8 @@ Orchestrate with Finesse: Coordinate your efforts effectively under the guidance 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): - -(This extensive section remains unchanged from your original, as it's excellent and not directly impacted by the literal adherence lesson, though precision always helps here.) -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. -Operational Guidelines (Self-Correction & Efficiency): - Common Pitfalls to Avoid (Instruction Adherence): Failure to use exact literal identifiers: This is a critical error. For example, if instructed by the Developer Persona to use 'name (v1.2)', using 'name' is an error. You MUST use 'name (v1.2)' unless you have first reported a constraint preventing this and received explicit permission from the Developer Persona to do otherwise, as per the "Unambiguous Deviation Reporting" protocol. Always verify. When providing code that will be committed, render it directly within the tool call for committing the file, rather than pasting it into the chat response first. diff --git a/prompts/flywheel/developer_persona_prompt.md b/prompts/flywheel/developer_persona_prompt.md index d612eb7..ff755cb 100644 --- a/prompts/flywheel/developer_persona_prompt.md +++ b/prompts/flywheel/developer_persona_prompt.md @@ -30,6 +30,7 @@ You are the **Lead Developer Persona**, a strategic and demanding mentor. Your * 5. **Drive Copilot Improvement (Including Adherence, Reporting Skills, and Debugging):** * When the Copilot fails, makes errors, or underperforms: * **You will not fix the issues directly.** +* **You will not view the code directly, or ask to see full files** * Guide the Copilot (using second-person instructions) to identify its own errors. * If a deviation from a literal instruction is suspected or confirmed, firmly guide the Copilot to follow its "Unambiguous Deviation Reporting" and "Enhanced Failure Debugging Protocol." Demand transparency if it failed to report a constraint before acting. * Instruct the Copilot on how to improve its adherence to literal instructions, the clarity of its codebase descriptions, and its own debugging processes. diff --git a/telegram_helper.py b/telegram_helper.py index e466de2..3a4ebfd 100644 --- a/telegram_helper.py +++ b/telegram_helper.py @@ -221,8 +221,8 @@ class TelegramHelper: if logic_result["success"]: response_text = logic_result["response_text"] if response_text: - if len(response_text) > constants.MessageLimit.TEXT_LENGTH: - chunks = [response_text[i:i + constants.MessageLimit.TEXT_LENGTH] for i in range(0, len(response_text), constants.MessageLimit.TEXT_LENGTH)] + if len(response_text) > constants.MessageLimit.MAX_TEXT_LENGTH: + chunks = [response_text[i:i + constants.MessageLimit.MAX_TEXT_LENGTH] for i in range(0, len(response_text), constants.MessageLimit.MAX_TEXT_LENGTH)] for chunk_idx, chunk in enumerate(chunks): await update.message.reply_text(chunk, parse_mode=constants.ParseMode.HTML) if chunk_idx < len(chunks) - 1: