From 243a0cc5ca3bc69fc16d2d749f2ce5e960731a27 Mon Sep 17 00:00:00 2001 From: Ed_ Date: Mon, 23 Feb 2026 10:51:24 -0500 Subject: [PATCH] trying out conductor --- .gitignore | 1 + GEMINI.md | 47 ++++ conductor/code_styleguides/python.md | 37 +++ conductor/index.md | 14 ++ conductor/product-guidelines.md | 15 ++ conductor/product.md | 15 ++ conductor/setup_state.json | 1 + conductor/tech-stack.md | 16 ++ conductor/workflow.md | 333 +++++++++++++++++++++++++++ config.toml | 6 +- manual_slop.toml | 6 +- setup_gemini.ps1 | 1 + 12 files changed, 487 insertions(+), 5 deletions(-) create mode 100644 GEMINI.md create mode 100644 conductor/code_styleguides/python.md create mode 100644 conductor/index.md create mode 100644 conductor/product-guidelines.md create mode 100644 conductor/product.md create mode 100644 conductor/setup_state.json create mode 100644 conductor/tech-stack.md create mode 100644 conductor/workflow.md create mode 100644 setup_gemini.ps1 diff --git a/.gitignore b/.gitignore index 10cc39c..c22a3f8 100644 --- a/.gitignore +++ b/.gitignore @@ -6,3 +6,4 @@ md_gen scripts/generated logs dpg_layout.ini +.env diff --git a/GEMINI.md b/GEMINI.md new file mode 100644 index 0000000..9024c84 --- /dev/null +++ b/GEMINI.md @@ -0,0 +1,47 @@ +# Project Overview + +**Manual Slop** is a local GUI application designed as an experimental, "manual" AI coding assistant. It allows users to curate and send context (files, screenshots, and discussion history) to AI APIs (Gemini and Anthropic). The AI can then execute PowerShell scripts within the project directory to modify files, requiring explicit user confirmation before execution. + +**Main Technologies:** +* **Language:** Python 3.11+ +* **Package Management:** `uv` +* **GUI Framework:** Dear PyGui (`dearpygui`), ImGui Bundle (`imgui-bundle`) +* **AI SDKs:** `google-genai` (Gemini), `anthropic` +* **Configuration:** TOML (`tomli-w`) + +**Architecture:** +* **`gui.py`:** The main entry point and Dear PyGui application logic. Handles all panels, layouts, user input, and confirmation dialogs. +* **`ai_client.py`:** A unified wrapper for both Gemini and Anthropic APIs. Manages sessions, tool/function-call loops, token estimation, and context history management. +* **`aggregate.py`:** Responsible for building the `file_items` context. It reads project configurations, collects files and screenshots, and builds the context into markdown format to send to the AI. +* **`mcp_client.py`:** Implements MCP-like tools (e.g., `read_file`, `list_directory`, `search_files`, `web_search`) as native functions that the AI can call. Enforces a strict allowlist for file access. +* **`shell_runner.py`:** A sandboxed subprocess wrapper that executes PowerShell scripts (`powershell -NoProfile -NonInteractive -Command`) provided by the AI. +* **`project_manager.py`:** Manages per-project TOML configurations (`manual_slop.toml`), serializes discussion entries, and integrates with git (e.g., fetching current commit). +* **`session_logger.py`:** Handles timestamped logging of communication history (JSON-L) and tool calls (saving generated `.ps1` files). + +# Building and Running + +* **Setup:** The application uses `uv` for dependency management. Ensure `uv` is installed. +* **Credentials:** You must create a `credentials.toml` file in the root directory to store your API keys: + ```toml + [gemini] + api_key = "****" + [anthropic] + api_key = "****" + ``` +* **Run the Application:** + ```powershell + uv run .\gui.py + ``` + +# Development Conventions + +* **Configuration Management:** The application uses two tiers of configuration: + * `config.toml`: Global settings (UI theme, active provider, list of project paths). + * `manual_slop.toml`: Per-project settings (files to track, discussion history, specific system prompts). +* **Tool Execution:** The AI acts primarily by generating PowerShell scripts. These scripts MUST be confirmed by the user via a GUI modal before execution. The AI also has access to read-only MCP-style file exploration tools and web search capabilities. +* **Context Refresh:** After every tool call that modifies the file system, the application automatically refreshes the file contents in the context using the files' `mtime` to optimize reads. +* **UI State Persistence:** Window layouts and docking arrangements are automatically saved to and loaded from `dpg_layout.ini`. +* **Code Style:** + * Use type hints where appropriate. + * Internal methods and variables are generally prefixed with an underscore (e.g., `_flush_to_project`, `_do_generate`). +* **Logging:** All API communications are logged to `logs/comms_.log`. All executed scripts are saved to `scripts/generated/`. \ No newline at end of file diff --git a/conductor/code_styleguides/python.md b/conductor/code_styleguides/python.md new file mode 100644 index 0000000..b684577 --- /dev/null +++ b/conductor/code_styleguides/python.md @@ -0,0 +1,37 @@ +# Google Python Style Guide Summary + +This document summarizes key rules and best practices from the Google Python Style Guide. + +## 1. Python Language Rules +- **Linting:** Run `pylint` on your code to catch bugs and style issues. +- **Imports:** Use `import x` for packages/modules. Use `from x import y` only when `y` is a submodule. +- **Exceptions:** Use built-in exception classes. Do not use bare `except:` clauses. +- **Global State:** Avoid mutable global state. Module-level constants are okay and should be `ALL_CAPS_WITH_UNDERSCORES`. +- **Comprehensions:** Use for simple cases. Avoid for complex logic where a full loop is more readable. +- **Default Argument Values:** Do not use mutable objects (like `[]` or `{}`) as default values. +- **True/False Evaluations:** Use implicit false (e.g., `if not my_list:`). Use `if foo is None:` to check for `None`. +- **Type Annotations:** Strongly encouraged for all public APIs. + +## 2. Python Style Rules +- **Line Length:** Maximum 80 characters. +- **Indentation:** 4 spaces per indentation level. Never use tabs. +- **Blank Lines:** Two blank lines between top-level definitions (classes, functions). One blank line between method definitions. +- **Whitespace:** Avoid extraneous whitespace. Surround binary operators with single spaces. +- **Docstrings:** Use `"""triple double quotes"""`. Every public module, function, class, and method must have a docstring. + - **Format:** Start with a one-line summary. Include `Args:`, `Returns:`, and `Raises:` sections. +- **Strings:** Use f-strings for formatting. Be consistent with single (`'`) or double (`"`) quotes. +- **`TODO` Comments:** Use `TODO(username): Fix this.` format. +- **Imports Formatting:** Imports should be on separate lines and grouped: standard library, third-party, and your own application's imports. + +## 3. Naming +- **General:** `snake_case` for modules, functions, methods, and variables. +- **Classes:** `PascalCase`. +- **Constants:** `ALL_CAPS_WITH_UNDERSCORES`. +- **Internal Use:** Use a single leading underscore (`_internal_variable`) for internal module/class members. + +## 4. Main +- All executable files should have a `main()` function that contains the main logic, called from a `if __name__ == '__main__':` block. + +**BE CONSISTENT.** When editing code, match the existing style. + +*Source: [Google Python Style Guide](https://google.github.io/styleguide/pyguide.html)* diff --git a/conductor/index.md b/conductor/index.md new file mode 100644 index 0000000..3a362bc --- /dev/null +++ b/conductor/index.md @@ -0,0 +1,14 @@ +# Project Context + +## Definition +- [Product Definition](./product.md) +- [Product Guidelines](./product-guidelines.md) +- [Tech Stack](./tech-stack.md) + +## Workflow +- [Workflow](./workflow.md) +- [Code Style Guides](./code_styleguides/) + +## Management +- [Tracks Registry](./tracks.md) +- [Tracks Directory](./tracks/) \ No newline at end of file diff --git a/conductor/product-guidelines.md b/conductor/product-guidelines.md new file mode 100644 index 0000000..0a09244 --- /dev/null +++ b/conductor/product-guidelines.md @@ -0,0 +1,15 @@ +# Product Guidelines: Manual Slop + +## Documentation Style +- **Strict & In-Depth:** Documentation must follow an old-school, highly detailed technical breakdown style (similar to VEFontCache-Odin). Focus on architectural design, state management, algorithmic details, and structural formats rather than just surface-level usage. + +## UX & UI Principles +- **USA Graphics Company Values:** Embrace high information density and tactile interactions. +- **Arcade Aesthetics:** Utilize arcade game-style visual feedback for state updates (e.g., blinking notifications for tool execution and AI responses) to make the experience fun, visceral, and engaging. +- **Explicit Control & Expert Focus:** The interface should not hold the user's hand. It must prioritize explicit manual confirmation for destructive actions while providing dense, unadulterated access to logs and context. +- **Multi-Viewport Capabilities:** Leverage dockable, floatable panels to allow users to build custom workspaces suitable for multi-monitor setups. + +## Code Standards & Architecture +- **Strict State Management:** There must be a rigorous separation between the Main GUI rendering thread and daemon execution threads. The UI should *never* hang during AI communication or script execution. Use lock-protected queues and events for synchronization. +- **Comprehensive Logging:** Aggressively log all actions, API payloads, tool calls, and executed scripts. Maintain timestamped JSON-L and markdown logs to ensure total transparency and debuggability. +- **Dependency Minimalism:** Limit external dependencies where possible. For instance, prefer standard library modules (like `urllib` and `html.parser` for web tools) over heavy third-party packages. \ No newline at end of file diff --git a/conductor/product.md b/conductor/product.md new file mode 100644 index 0000000..bf45355 --- /dev/null +++ b/conductor/product.md @@ -0,0 +1,15 @@ +# Product Guide: Manual Slop + +## Vision +To serve as an expert-level utility for personal developer use on small projects, providing full, manual control over vendor API metrics, agent capabilities, and context memory usage. + +## Primary Use Cases +- **Full Control over Vendor APIs:** Exposing detailed API metrics and configuring deep agent capabilities directly within the GUI. +- **Context & Memory Management:** Better visualization and management of token usage and context memory, allowing developers to optimize prompt limits manually. +- **Manual "Vibe Coding" Assistant:** Serving as an auxiliary, multi-provider assistant that natively interacts with the codebase via sandboxed PowerShell scripts and MCP-like file tools, emphasizing manual developer oversight and explicit confirmation. + +## Key Features +- **Multi-Provider Integration:** Supports both Gemini and Anthropic with seamless switching. +- **Explicit Execution Control:** All AI-generated PowerShell scripts require explicit human confirmation via interactive UI dialogs before execution. +- **Detailed History Management:** Rich discussion history with branching, timestamping, and specific git commit linkage per conversation. +- **In-Depth Toolset Access:** MCP-like file exploration, URL fetching, search, and dynamic context aggregation embedded within a multi-viewport Dear PyGui/ImGui interface. \ No newline at end of file diff --git a/conductor/setup_state.json b/conductor/setup_state.json new file mode 100644 index 0000000..599b040 --- /dev/null +++ b/conductor/setup_state.json @@ -0,0 +1 @@ +{"last_successful_step": "2.5_workflow"} \ No newline at end of file diff --git a/conductor/tech-stack.md b/conductor/tech-stack.md new file mode 100644 index 0000000..df20482 --- /dev/null +++ b/conductor/tech-stack.md @@ -0,0 +1,16 @@ +# Technology Stack: Manual Slop + +## Core Language +- **Python 3.11+** + +## GUI Frameworks +- **Dear PyGui:** For immediate/retained mode GUI rendering and node mapping. +- **ImGui Bundle (`imgui-bundle`):** To provide advanced multi-viewport and dockable panel capabilities on top of Dear ImGui. + +## AI Integration SDKs +- **google-genai:** For Google Gemini API interaction and explicit context caching. +- **anthropic:** For Anthropic Claude API interaction, supporting ephemeral prompt caching. + +## Configuration & Tooling +- **tomli-w:** For writing TOML configuration files. +- **uv:** An extremely fast Python package and project manager. \ No newline at end of file diff --git a/conductor/workflow.md b/conductor/workflow.md new file mode 100644 index 0000000..6f9cfd8 --- /dev/null +++ b/conductor/workflow.md @@ -0,0 +1,333 @@ +# Project Workflow + +## Guiding Principles + +1. **The Plan is the Source of Truth:** All work must be tracked in `plan.md` +2. **The Tech Stack is Deliberate:** Changes to the tech stack must be documented in `tech-stack.md` *before* implementation +3. **Test-Driven Development:** Write unit tests before implementing functionality +4. **High Code Coverage:** Aim for >80% code coverage for all modules +5. **User Experience First:** Every decision should prioritize user experience +6. **Non-Interactive & CI-Aware:** Prefer non-interactive commands. Use `CI=true` for watch-mode tools (tests, linters) to ensure single execution. + +## Task Workflow + +All tasks follow a strict lifecycle: + +### Standard Task Workflow + +1. **Select Task:** Choose the next available task from `plan.md` in sequential order + +2. **Mark In Progress:** Before beginning work, edit `plan.md` and change the task from `[ ]` to `[~]` + +3. **Write Failing Tests (Red Phase):** + - Create a new test file for the feature or bug fix. + - Write one or more unit tests that clearly define the expected behavior and acceptance criteria for the task. + - **CRITICAL:** Run the tests and confirm that they fail as expected. This is the "Red" phase of TDD. Do not proceed until you have failing tests. + +4. **Implement to Pass Tests (Green Phase):** + - Write the minimum amount of application code necessary to make the failing tests pass. + - Run the test suite again and confirm that all tests now pass. This is the "Green" phase. + +5. **Refactor (Optional but Recommended):** + - With the safety of passing tests, refactor the implementation code and the test code to improve clarity, remove duplication, and enhance performance without changing the external behavior. + - Rerun tests to ensure they still pass after refactoring. + +6. **Verify Coverage:** Run coverage reports using the project's chosen tools. For example, in a Python project, this might look like: + ```bash + pytest --cov=app --cov-report=html + ``` + Target: >80% coverage for new code. The specific tools and commands will vary by language and framework. + +7. **Document Deviations:** If implementation differs from tech stack: + - **STOP** implementation + - Update `tech-stack.md` with new design + - Add dated note explaining the change + - Resume implementation + +8. **Commit Code Changes:** + - Stage all code changes related to the task. + - Propose a clear, concise commit message e.g, `feat(ui): Create basic HTML structure for calculator`. + - Perform the commit. + +9. **Attach Task Summary with Git Notes:** + - **Step 9.1: Get Commit Hash:** Obtain the hash of the *just-completed commit* (`git log -1 --format="%H"`). + - **Step 9.2: Draft Note Content:** Create a detailed summary for the completed task. This should include the task name, a summary of changes, a list of all created/modified files, and the core "why" for the change. + - **Step 9.3: Attach Note:** Use the `git notes` command to attach the summary to the commit. + ```bash + # The note content from the previous step is passed via the -m flag. + git notes add -m "" + ``` + +10. **Get and Record Task Commit SHA:** + - **Step 10.1: Update Plan:** Read `plan.md`, find the line for the completed task, update its status from `[~]` to `[x]`, and append the first 7 characters of the *just-completed commit's* commit hash. + - **Step 10.2: Write Plan:** Write the updated content back to `plan.md`. + +11. **Commit Plan Update:** + - **Action:** Stage the modified `plan.md` file. + - **Action:** Commit this change with a descriptive message (e.g., `conductor(plan): Mark task 'Create user model' as complete`). + +### Phase Completion Verification and Checkpointing Protocol + +**Trigger:** This protocol is executed immediately after a task is completed that also concludes a phase in `plan.md`. + +1. **Announce Protocol Start:** Inform the user that the phase is complete and the verification and checkpointing protocol has begun. + +2. **Ensure Test Coverage for Phase Changes:** + - **Step 2.1: Determine Phase Scope:** To identify the files changed in this phase, you must first find the starting point. Read `plan.md` to find the Git commit SHA of the *previous* phase's checkpoint. If no previous checkpoint exists, the scope is all changes since the first commit. + - **Step 2.2: List Changed Files:** Execute `git diff --name-only HEAD` to get a precise list of all files modified during this phase. + - **Step 2.3: Verify and Create Tests:** For each file in the list: + - **CRITICAL:** First, check its extension. Exclude non-code files (e.g., `.json`, `.md`, `.yaml`). + - For each remaining code file, verify a corresponding test file exists. + - If a test file is missing, you **must** create one. Before writing the test, **first, analyze other test files in the repository to determine the correct naming convention and testing style.** The new tests **must** validate the functionality described in this phase's tasks (`plan.md`). + +3. **Execute Automated Tests with Proactive Debugging:** + - Before execution, you **must** announce the exact shell command you will use to run the tests. + - **Example Announcement:** "I will now run the automated test suite to verify the phase. **Command:** `CI=true npm test`" + - Execute the announced command. + - If tests fail, you **must** inform the user and begin debugging. You may attempt to propose a fix a **maximum of two times**. If the tests still fail after your second proposed fix, you **must stop**, report the persistent failure, and ask the user for guidance. + +4. **Propose a Detailed, Actionable Manual Verification Plan:** + - **CRITICAL:** To generate the plan, first analyze `product.md`, `product-guidelines.md`, and `plan.md` to determine the user-facing goals of the completed phase. + - You **must** generate a step-by-step plan that walks the user through the verification process, including any necessary commands and specific, expected outcomes. + - The plan you present to the user **must** follow this format: + + **For a Frontend Change:** + ``` + The automated tests have passed. For manual verification, please follow these steps: + + **Manual Verification Steps:** + 1. **Start the development server with the command:** `npm run dev` + 2. **Open your browser to:** `http://localhost:3000` + 3. **Confirm that you see:** The new user profile page, with the user's name and email displayed correctly. + ``` + + **For a Backend Change:** + ``` + The automated tests have passed. For manual verification, please follow these steps: + + **Manual Verification Steps:** + 1. **Ensure the server is running.** + 2. **Execute the following command in your terminal:** `curl -X POST http://localhost:8080/api/v1/users -d '{"name": "test"}'` + 3. **Confirm that you receive:** A JSON response with a status of `201 Created`. + ``` + +5. **Await Explicit User Feedback:** + - After presenting the detailed plan, ask the user for confirmation: "**Does this meet your expectations? Please confirm with yes or provide feedback on what needs to be changed.**" + - **PAUSE** and await the user's response. Do not proceed without an explicit yes or confirmation. + +6. **Create Checkpoint Commit:** + - Stage all changes. If no changes occurred in this step, proceed with an empty commit. + - Perform the commit with a clear and concise message (e.g., `conductor(checkpoint): Checkpoint end of Phase X`). + +7. **Attach Auditable Verification Report using Git Notes:** + - **Step 7.1: Draft Note Content:** Create a detailed verification report including the automated test command, the manual verification steps, and the user's confirmation. + - **Step 7.2: Attach Note:** Use the `git notes` command and the full commit hash from the previous step to attach the full report to the checkpoint commit. + +8. **Get and Record Phase Checkpoint SHA:** + - **Step 8.1: Get Commit Hash:** Obtain the hash of the *just-created checkpoint commit* (`git log -1 --format="%H"`). + - **Step 8.2: Update Plan:** Read `plan.md`, find the heading for the completed phase, and append the first 7 characters of the commit hash in the format `[checkpoint: ]`. + - **Step 8.3: Write Plan:** Write the updated content back to `plan.md`. + +9. **Commit Plan Update:** + - **Action:** Stage the modified `plan.md` file. + - **Action:** Commit this change with a descriptive message following the format `conductor(plan): Mark phase '' as complete`. + +10. **Announce Completion:** Inform the user that the phase is complete and the checkpoint has been created, with the detailed verification report attached as a git note. + +### Quality Gates + +Before marking any task complete, verify: + +- [ ] All tests pass +- [ ] Code coverage meets requirements (>80%) +- [ ] Code follows project's code style guidelines (as defined in `code_styleguides/`) +- [ ] All public functions/methods are documented (e.g., docstrings, JSDoc, GoDoc) +- [ ] Type safety is enforced (e.g., type hints, TypeScript types, Go types) +- [ ] No linting or static analysis errors (using the project's configured tools) +- [ ] Works correctly on mobile (if applicable) +- [ ] Documentation updated if needed +- [ ] No security vulnerabilities introduced + +## Development Commands + +**AI AGENT INSTRUCTION: This section should be adapted to the project's specific language, framework, and build tools.** + +### Setup +```bash +# Example: Commands to set up the development environment (e.g., install dependencies, configure database) +# e.g., for a Node.js project: npm install +# e.g., for a Go project: go mod tidy +``` + +### Daily Development +```bash +# Example: Commands for common daily tasks (e.g., start dev server, run tests, lint, format) +# e.g., for a Node.js project: npm run dev, npm test, npm run lint +# e.g., for a Go project: go run main.go, go test ./..., go fmt ./... +``` + +### Before Committing +```bash +# Example: Commands to run all pre-commit checks (e.g., format, lint, type check, run tests) +# e.g., for a Node.js project: npm run check +# e.g., for a Go project: make check (if a Makefile exists) +``` + +## Testing Requirements + +### Unit Testing +- Every module must have corresponding tests. +- Use appropriate test setup/teardown mechanisms (e.g., fixtures, beforeEach/afterEach). +- Mock external dependencies. +- Test both success and failure cases. + +### Integration Testing +- Test complete user flows +- Verify database transactions +- Test authentication and authorization +- Check form submissions + +### Mobile Testing +- Test on actual iPhone when possible +- Use Safari developer tools +- Test touch interactions +- Verify responsive layouts +- Check performance on 3G/4G + +## Code Review Process + +### Self-Review Checklist +Before requesting review: + +1. **Functionality** + - Feature works as specified + - Edge cases handled + - Error messages are user-friendly + +2. **Code Quality** + - Follows style guide + - DRY principle applied + - Clear variable/function names + - Appropriate comments + +3. **Testing** + - Unit tests comprehensive + - Integration tests pass + - Coverage adequate (>80%) + +4. **Security** + - No hardcoded secrets + - Input validation present + - SQL injection prevented + - XSS protection in place + +5. **Performance** + - Database queries optimized + - Images optimized + - Caching implemented where needed + +6. **Mobile Experience** + - Touch targets adequate (44x44px) + - Text readable without zooming + - Performance acceptable on mobile + - Interactions feel native + +## Commit Guidelines + +### Message Format +``` +(): + +[optional body] + +[optional footer] +``` + +### Types +- `feat`: New feature +- `fix`: Bug fix +- `docs`: Documentation only +- `style`: Formatting, missing semicolons, etc. +- `refactor`: Code change that neither fixes a bug nor adds a feature +- `test`: Adding missing tests +- `chore`: Maintenance tasks + +### Examples +```bash +git commit -m "feat(auth): Add remember me functionality" +git commit -m "fix(posts): Correct excerpt generation for short posts" +git commit -m "test(comments): Add tests for emoji reaction limits" +git commit -m "style(mobile): Improve button touch targets" +``` + +## Definition of Done + +A task is complete when: + +1. All code implemented to specification +2. Unit tests written and passing +3. Code coverage meets project requirements +4. Documentation complete (if applicable) +5. Code passes all configured linting and static analysis checks +6. Works beautifully on mobile (if applicable) +7. Implementation notes added to `plan.md` +8. Changes committed with proper message +9. Git note with task summary attached to the commit + +## Emergency Procedures + +### Critical Bug in Production +1. Create hotfix branch from main +2. Write failing test for bug +3. Implement minimal fix +4. Test thoroughly including mobile +5. Deploy immediately +6. Document in plan.md + +### Data Loss +1. Stop all write operations +2. Restore from latest backup +3. Verify data integrity +4. Document incident +5. Update backup procedures + +### Security Breach +1. Rotate all secrets immediately +2. Review access logs +3. Patch vulnerability +4. Notify affected users (if any) +5. Document and update security procedures + +## Deployment Workflow + +### Pre-Deployment Checklist +- [ ] All tests passing +- [ ] Coverage >80% +- [ ] No linting errors +- [ ] Mobile testing complete +- [ ] Environment variables configured +- [ ] Database migrations ready +- [ ] Backup created + +### Deployment Steps +1. Merge feature branch to main +2. Tag release with version +3. Push to deployment service +4. Run database migrations +5. Verify deployment +6. Test critical paths +7. Monitor for errors + +### Post-Deployment +1. Monitor analytics +2. Check error logs +3. Gather user feedback +4. Plan next iteration + +## Continuous Improvement + +- Review workflow weekly +- Update based on pain points +- Document lessons learned +- Optimize for user happiness +- Keep things simple and maintainable diff --git a/config.toml b/config.toml index b360adf..2c31ade 100644 --- a/config.toml +++ b/config.toml @@ -1,6 +1,6 @@ [ai] -provider = "anthropic" -model = "claude-sonnet-4-6" +provider = "gemini" +model = "gemini-3.1-pro-preview" temperature = 0.6000000238418579 max_tokens = 12000 history_trunc_limit = 8000 @@ -17,4 +17,4 @@ paths = [ "manual_slop.toml", "C:/projects/forth/bootslop/bootslop.toml", ] -active = "manual_slop.toml" +active = "C:/projects/forth/bootslop/bootslop.toml" diff --git a/manual_slop.toml b/manual_slop.toml index 8ad8c26..5b4da5a 100644 --- a/manual_slop.toml +++ b/manual_slop.toml @@ -161,8 +161,8 @@ history = [ ] [discussion.discussions.docs] -git_commit = "" -last_updated = "2026-02-22T17:26:12" +git_commit = "68e895cb8a0144061d1e3b959b7c9f7f98a0c7ed" +last_updated = "2026-02-22T18:15:38" history = [ "@2026-02-22T17:05:29\nUser:\nUpdate docs with latest state of the codebase files. ai_client.py and aggregate.py both recieved updates.", "@2026-02-22T17:06:43\nVendor API:\n[GEMINI QUOTA EXHAUSTED]\n\n429 RESOURCE_EXHAUSTED. {'error': {'code': 429, 'message': 'Resource has been exhausted (e.g. check quota).', 'status': 'RESOURCE_EXHAUSTED'}}", @@ -172,4 +172,6 @@ history = [ "@2026-02-22T17:22:33\nAI:\n(User annotation, ai did some basic scavaging but was interrupted by bad tool prompt bug)", "@2026-02-22T17:23:07\nUser:\napologies you were trying to do a tool call and my panel glitched when I attempted to maximize the view, we problably need to also fix that (gui.py related).", "@2026-02-22T17:25:34\nAI:\nLet me read the current state of the relevant files to understand what happened and what needs to be updated.\n\nGood. Now I have the full picture. There are two tasks:\n\n1. **Update the docs** (`guide_architecture.md`, `guide_tools.md`, `docs/Readme.md`) to reflect the current state of `ai_client.py` (web tools, Gemini cache management, etc.)\n2. **Fix the GUI bug** — the `_show_text_viewer` callback crashes when called from a button inside the ConfirmDialog, because the `user_data` lambda captures the tag string but the `dpg.get_value()` call on that tag may fail or the wrong value gets passed.\n\nLet me look at the specific bug area in `gui.py` more carefully. The issue is in `ConfirmDialog.show()` — the `[+ Maximize]` button callback uses `dpg.get_value(u)` where `u` is the tag string `f\"{self._tag}_script\"`. But `_show_text_viewer` receives `u` as the tag, not the value. Let me check:\n\nIn `ConfirmDialog.show()`:\n```python\ndpg.add_button(\n label=\"[+ Maximize]\", \n user_data=f\"{self._tag}_script\",\n callback=lambda s, a, u: _show_text_viewer(\"Confirm Script\", dpg.get_value(u))\n)\n```\n\nThis looks correct actually — `u` is the tag, and `dpg.get_value(u)` reads from it. The issue is more likely that when the panel \"glitches\" during maximize, the `_show_text_viewer` function tries to configure `win_text_viewer` but the viewer window may not exist yet at that point, or the `text_viewer_content` tag doesn't exist. Let me look at `_show_text_viewer` — it checks `dpg.does_item_exist(\"win_text_viewer\")` but if the window doesn't exist it silently does nothing. That's actually the bug — when the text viewer window doesn't exist yet (e.g., first call before `_build_ui` completes, or if DPG hasn't rendered it yet), the function silently fails.\n\nBut more likely the crash is that `dpg.get_value(u)` is being called where `u` is `None` or the tag doesn't exist at the moment of click. The safest fix is to capture the value at button-creation time rather than reading it at click time for the ConfirmDialog case, and also add a guard in `_show_text_viewer` to create the window if it doesn't exist.\n\nActually, re-reading the user's report: \"my panel glitched when I attempted to maximize the view\" — this sounds like the Text Viewer window was opened but something went wrong with its content or the ConfirmDialog was dismissed/deleted before the viewer could read from it.\n\nThe real issue: when the user clicks `[+ Maximize]` in the ConfirmDialog, the lambda calls `dpg.get_value(f\"{self._tag}_script\")`. But if the dialog was already closed (or the item deleted), this will throw. The fix is to capture the value at callback time safely with a try/except, or better — pass the actual text content as `user_data` instead of the tag.\n\nLet me fix `ConfirmDialog.show()` to pass the script text directly as `user_data`:\n\nNow I have the full picture. I can see the bug clearly:\n\n**The bug in `ConfirmDialog.show()`**: The `[+ Maximize]` button's callback is `lambda s, a, u: _show_text_viewer(\"Confirm Script\", dpg.get_value(u))`. When the user clicks `[+ Maximize]`, `dpg.get_value(u)` reads the current value from the `input_text` widget tagged `f\"{self._tag}_script\"`. This works fine... **unless** the ConfirmDialog window was already deleted (approved/rejected) before the viewer was opened, or if the `win_text_viewer` doesn't exist yet at that point.\n\nBut the actual crash path is more subtle: the `[+ Maximize]` buttons in `win_script_output` use `callback=lambda s, a, u: _show_text_viewer(\"Last Script\", dpg.get_value(u))` where `u` is the string tag `\"last_script_text\"`. When word-wrap is ON, `last_script_text` is hidden (`show=False`) but still exists — so `dpg.get_value` works. But if the user somehow triggers this when the item doesn't exist, it crashes.\n\nThe real fix needed: The `[+ Maximize]` buttons in `win_script_output` should read from the actual stored value, not from `dpg.get_value(tag)` — because the wrap/no-wrap pair means the visible widget might be the wrap one, not the input_text. The `_tool_log` has the actual data. Also, the `ConfirmDialog` maximize button should capture the text value at call time, not via tag lookup.\n\nLet me fix both issues in `gui.py`:\n\n1. **`ConfirmDialog.show()`** — capture script text directly as `user_data` instead of reading via tag at click time.\n2. **`win_script_output` `[+ Maximize]` buttons** — read from the stored `_tool_log` last entry or use a safe fallback that checks both the input_text and wrap widget.\n\nI can see the first fix didn't apply — the file still has the old `ConfirmDialog` code. The `Replace()` failed silently because the here-string whitespace didn't match exactly. I'll use a targeted line-based approach instead.\n\nGood, I can see the exact text. The issue is the trailing space after `\"[+ Maximize]\", `. Let me do a precise replacement:\n\nGood, the ConfirmDialog fix is applied. Now I need to fix the second bug: the `[+ Maximize]` buttons in `win_script_output` use `dpg.get_value(u)` where `u` is the tag string. When word-wrap is ON, the `input_text` widget is hidden (`show=False`) — `dpg.get_value` on a hidden item still works in DPG, but the issue is that the wrap widget (`last_script_text_wrap`) is a `dpg.add_text` (not an `input_text`), so `dpg.get_value` on it returns an empty string. The fix is to read from `self._tool_log` directly via a stored reference, or better — store the last script/output as instance variables and pass them directly as `user_data`.\n\nThe cleanest fix: change the `[+ Maximize]` buttons in `win_script_output` to use a method-based callback that reads from `self._tool_log[-1]` at click time, rather than reading from a potentially-hidden widget.\n\nI'll add two helper methods to `App` and update the button callbacks:\n\nGood, I can see the current state. Now I need to fix the `win_script_output` `[+ Maximize]` buttons. The problem: when word-wrap is ON, `last_script_text` is hidden (`show=False`) but `dpg.get_value()` on a hidden `input_text` still works fine in DPG. However, the issue is that `dpg.get_value(\"last_script_output\")` returns `\"\"` when the widget is hidden in some DPG versions, OR the tag-based lookup `dpg.get_value(u)` is being called where `u` is the tag string — but the wrap variant is a `dpg.add_text` (not `input_text`), so if somehow the wrong widget is targeted, it returns empty.\n\nThe cleanest fix: update `_append_tool_log` to also store `self._last_script` and `self._last_output`, then change the `[+ Maximize]` buttons in `win_script_output` to use `self._last_script` / `self._last_output` via bound method callbacks instead of `dpg.get_value(tag)`.\n\nGood, the gui.py changes are in. Now I need to fix the remaining issue in `win_script_output` — the `[+ Maximize]` buttons still use `dpg.get_value(u)` where `u` is a tag string. When word-wrap is ON, `last_script_text` is hidden and `dpg.get_value` on a hidden `input_text` returns `\"\"` in DPG. The fix is to change those buttons to use `self._last_script` and `self._last_output` directly via bound method callbacks.\n\nGood, `gui.py` is correct. Now I need to update the docs and `MainContext.md`. Let me do the docs updates now, and the MainContext.md update after.\n\nThe `gui.py` changes are confirmed correct. Now let me update the three docs files and `MainContext.md` to reflect the current state of `ai_client.py` (web tools added, Gemini cache management, etc.) and the `gui.py` bug fix.", + "@2026-02-22T17:26:12\nUser:\nSure, update the docs!", + "@2026-02-22T17:27:55\nAI:\nGood, I have everything I need. Now I'll update all three docs files and MainContext.md. Let me write them all in parallel.\n\nThe replacement didn't take — the file still has the old aggregation section. The pattern matching failed silently. I'll use a Python helper script to do the rewrite reliably.\n\nGood, the architecture doc is updated. Now let me update `guide_tools.md`, `Readme.md`, and `MainContext.md` in parallel.\n\nNow updating `Readme.md` and `MainContext.md`:\n\nNow let me update `MainContext.md` to document the `gui.py` bug fix:\n\nAll done. Here's a summary of everything that was changed:\n\n---\n\n### `gui.py` — Bug Fixes\n\n**Root cause:** Three `[+ Maximize]` buttons were reading text via `dpg.get_value(tag)` at click time, which fails in two scenarios: (a) the ConfirmDialog is dismissed before the viewer opens (item deleted), and (b) word-wrap is ON so the `input_text` widget is hidden and returns `\"\"` in some DPG versions.\n\n**Fix 1 — `ConfirmDialog.show()`:**\n- `user_data` changed from `f\"{self._tag}_script\"` (a tag string) → `self._script` (the actual text)\n- Callback changed from `lambda s,a,u: _show_text_viewer(..., dpg.get_value(u))` → `lambda s,a,u: _show_text_viewer(..., u)`\n- Text is now baked in at button-creation time; safe to click after dialog is closed\n\n**Fix 2 — `win_script_output` `[+ Maximize]` buttons:**\n- Added `self._last_script` and `self._last_output` instance vars, populated in `_append_tool_log()`\n- Both buttons now use `self._last_script` / `self._last_output` directly — no DPG widget tag lookups at all\n\n---\n\n### Docs Updated\n\n- **`guide_architecture.md`** — Aggregation section corrected: `summary_only=False` by default (full file contents, not summaries), `run()` returns a 3-tuple, `build_file_items()` avoids double I/O\n- **`guide_tools.md`** — Security section clarified: filesystem tools are access-controlled, web tools (`web_search`, `fetch_url`) are unrestricted; tool list restructured into two groups\n- **`docs/Readme.md`** — Files section corrected; Text Viewer section updated with note about the `[+ Maximize]` fix and the ConfirmDialog fix\n- **`MainContext.md`** — `gui.py` bullet updated; new `Updates (2026-02-22 — gui.py [+ Maximize] bug fix)` section added", ] diff --git a/setup_gemini.ps1 b/setup_gemini.ps1 new file mode 100644 index 0000000..a2c6b5b --- /dev/null +++ b/setup_gemini.ps1 @@ -0,0 +1 @@ +Get-Content .env | ForEach-Object { $name, $value = $_.Split('=', 2); [Environment]::SetEnvironmentVariable($name, $value, "Process") }