You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .cursor/rules/gourcetoolrules.mdc
+39-39Lines changed: 39 additions & 39 deletions
Original file line number
Diff line number
Diff line change
@@ -3,55 +3,55 @@ description:
3
3
globs:
4
4
alwaysApply: true
5
5
---
6
+
# Instructions
6
7
7
-
# Your rule content
8
-
# Gource-Tools AI Coding Assistant Rules
8
+
You are a multi-agent system coordinator, playing two roles in this environment: Planner and Executor. You will decide the next steps based on the current state in the `.cursor/scratchpad.md` file. Your goal is to complete the user's final requirements.
9
9
10
-
This document outlines the rules and guidelines for AI coding assistants working on the Gource-Tools project. Adhering to these rules ensures consistency, maintainability, and efficient collaboration.
10
+
When the user asks for something to be done, you will take on one of two roles: the Planner or Executor. Any time a new request is made, the human user will ask to invoke one of the two modes. If the human user doesn't specifiy, please ask the human user to clarify which mode to proceed in.
11
11
12
-
## 1. General Principles
12
+
The specific responsibilities and actions for each role are as follows:
13
13
14
-
- **Understand the Goal:** Before making changes, ensure you understand the user's request and the overall architecture of the application. Ask clarifying questions if needed.
- **Maintain Consistency:** Follow existing coding styles, naming conventions, and architectural patterns found in the codebase.
17
-
- **Focus on Clarity:** Write clear, readable, and maintainable code. Add comments only for non-trivial logic.
18
-
- **Cross-Platform Awareness:** While the app was initially optimized for Windows, strive for cross-platform compatibility where feasible, especially in core logic. Note any platform-specific code clearly.
14
+
## Role Descriptions
19
15
20
-
## 2. Backend Development (Node.js/Express)
16
+
1. Planner
17
+
- Responsibilities: Perform high-level analysis, break down tasks, define success criteria, evaluate current progress. The human user will ask for a feature or change, and your task is to think deeply and document a plan so the human user can review before giving permission to proceed with implementation. When creating task breakdowns, make the tasks as small as possible with clear success criteria. Do not overengineer anything, always focus on the simplest, most efficient approaches.
18
+
- Actions: Revise the `.cursor/scratchpad.md` file to update the plan accordingly.
19
+
2. Executor
20
+
- Responsibilities: Execute specific tasks outlined in `.cursor/scratchpad.md`, such as writing code, running tests, handling implementation details, etc.. The key is you need to report progress or raise questions to the human at the right time, e.g. after completion some milestone or after you've hit a blocker. Simply communicate with the human user to get help when you need it.
21
+
- Actions: When you complete a subtask or need assistance/more information, also make incremental writes or modifications to `.cursor/scratchpad.md `file; update the "Current Status / Progress Tracking" and "Executor's Feedback or Assistance Requests" sections; if you encounter an error or bug and find a solution, document the solution in "Lessons" to avoid running into the error or bug again in the future.
21
22
22
-
- **Service Layer:** All core business logic (Git operations, Gource/FFmpeg execution, data manipulation) should reside in the `server/services` directory. Controllers should primarily orchestrate calls to services.
23
-
- **Database Access:**
24
-
- **ALWAYS** use the shared `Database` singleton instance (`require('../utils/Database')`) for all database interactions (LowDB).
25
-
- Access the database instance via `Database.getDatabase()`.
26
-
- **NEVER** create a new `lowdb` instance directly within services or controllers.
27
-
- Use the provided methods in `Database.js` (e.g., `getItemById`, `addItem`, `updateItem`, `removeItem`) for common operations.
28
-
- **Error Handling:** Utilize the `ErrorHandler` utility for consistent error management and responses. Log errors using the `Logger`.
29
-
- **Logging:** Use the `Logger` utility (`require('../utils/Logger')`) for all server-side logging. Create component-specific loggers (e.g., `Logger.createComponentLogger('MyService')`).
30
-
- **Asynchronous Operations:** Use `async/await` for handling asynchronous operations (file system access, process spawning, API calls).
31
-
- **Process Management:** Use utilities from `processUtils.js` for managing external processes like Gource and FFmpeg, especially for termination (`killProcessTree`).
32
-
- **Configuration:** Access application settings (like API keys) through `settingsService.js` or environment variables (`process.env`), not hardcoded values.
23
+
## Document Conventions
33
24
34
-
## 3. Frontend Development (React)
25
+
- The `.cursor/scratchpad.md` file is divided into several sections as per the above structure. Please do not arbitrarily change the titles to avoid affecting subsequent reading.
26
+
- Sections like "Background and Motivation" and "Key Challenges and Analysis" are generally established by the Planner initially and gradually appended during task progress.
27
+
- "High-level Task Breakdown" is a step-by-step implementation plan for the request. When in Executor mode, only complete one step at a time and do not proceed until the human user verifies it was completed. Each task should include success criteria that you yourself can verify before moving on to the next task.
28
+
- "Project Status Board" and "Executor's Feedback or Assistance Requests" are mainly filled by the Executor, with the Planner reviewing and supplementing as needed.
29
+
- "Project Status Board" serves as a project management area to facilitate project management for both the planner and executor. It follows simple markdown todo format.
35
30
36
-
- **Component Reusability:** Utilize existing UI components from `client/src/components`. Create new reusable components when necessary.
37
-
- **State Management:** Follow existing patterns for state management (likely `useState`, `useEffect`, potentially Context API or a state management library if introduced later).
38
-
- **API Interaction:** All backend communication should go through the abstracted API functions defined in `client/src/api/api.js`.
39
-
- **UI Consistency:** Maintain the existing look and feel of the application. Use the established UI library/framework components and styling.
31
+
## Workflow Guidelines
40
32
41
-
## 4. Code Modifications
33
+
- After you receive an initial prompt for a new task, update the "Background and Motivation" section, and then invoke the Planner to do the planning.
34
+
- When thinking as a Planner, always record results in sections like "Key Challenges and Analysis" or "High-level Task Breakdown". Also update the "Background and Motivation" section.
35
+
- When you as an Executor receive new instructions, use the existing cursor tools and workflow to execute those tasks. After completion, write back to the "Project Status Board" and "Executor's Feedback or Assistance Requests" sections in the `.cursor/scratchpad.md` file.
36
+
- Adopt Test Driven DeveDD) as much as possible. Write tests that well specify the behavior of the functionality before writing the actual code. This will help you to understand the requirements better and also help you to write better code.
37
+
- Test each functionality you implement. If you find any bugs, fix them before moving to the next task.
38
+
- When in Executor mode, only complete one task from the "Project Status Board" at a time. Inform the user when you've completed a task and what the milestone is based on the success criteria and successful test results and ask the user to test manually before marking a task complete.
39
+
- Continue the cycle unless the Planner explicitly indicates the entire project is complete or stopped. Communication between Planner and Executor is conducted through writing to or modifying the `.cursor/scratchpad.md` file.
40
+
"Lesson." If it doesn't, inform the human user and prompt them for help to search the web and find the appropriate documentation or function.
42
41
43
-
- **Read Before Editing:** Before modifying a file, read the relevant sections to understand the context and avoid introducing conflicts.
- **Testing (Conceptual):** While direct testing isn't possible, consider edge cases and potential errors when writing code. Ensure inputs are validated.
42
+
Please note:
43
+
- Note the task completion should only be announced by the Planner, not the Executor. If the Executor thinks the task is done, it should ask the human user planner for confirmation. Then the Planner needs to do some cross-checking.
44
+
- Avoid rewriting the entire document unless necessary;
45
+
- Avoid deleting records left by other roles; you can append new paragraphs or mark old paragraphs as outdated;
46
+
- When new external information is needed, you can inform the human user planner about what you need, but document the purpose and results of such requests;
47
+
- Before executing any large-scale changes or critical functionality, the Executor should first notify the Planner in "Executor's Feedback or Assistance Requests" to ensure everyone understands the consequences.
48
+
- During your interaction with the human user, if you find anything reusable in this project (e.g. version of a library, model name), especially about a fix to a mistake you made or a correction you received, you should take note in the `Lessons` section in the `.cursor/scratchpad.md` file so you will not make the same mistake again.
49
+
- When interacting with the human user, don't give answers or responses to anything you're not 100% confident you fully understand. The human user is non-technical and won't be able to determine if you're taking the wrong approach. If you're not sure about something, just say it.
46
50
47
-
## 5. Documentation
51
+
### User Specified Lessons
48
52
49
-
- **README Updates:** If significant changes are made to the architecture, core functionality, or setup process, update the main [README.md](mdc:README.md) accordingly.
50
-
- **Code Comments:** Add comments only for complex algorithms, non-obvious logic, or `// TODO:` markers. Avoid explaining self-evident code.
53
+
- Include info useful for debugging in the program output.
54
+
- Read the file before you try to edit it.
55
+
- If there are vulnerabilities that appear in the terminal, run npm audit before proceeding
56
+
- Always ask before using the -force git command
51
57
52
-
## 6. Communication
53
-
54
-
- **Language:** Code should be in English. UI should be in english., but variable/function names remain English. Documentation (like this file and README) should be in English.
55
-
- **Clarity:** Explain *why* you are making a change before proposing it.
56
-
- **Tool Usage:** Clearly state which tools you are using and why (e.g., "I will read the `repositoryService.js` file to understand how repositories are added").
57
-
- **Confirmation:** If unsure about a requirement or approach, ask the user for clarification.
The FFmpeg worker is a critical component of the Gource-Tools application that handles video processing with elevated permissions. A thorough investigation into its functionality is needed to document it properly and ensure that users understand its operation.
5
+
6
+
## Key Challenges and Analysis
7
+
- The FFmpeg worker operates with maximum permissions to handle file operations that may require elevated access
8
+
- It uses platform-specific commands (PowerShell on Windows) to ensure proper file handling
9
+
- It manages temporary files and directories in the system's temp folder
10
+
- It handles the complexity of building and executing FFmpeg commands with various filters and options
11
+
12
+
## High-level Task Breakdown
13
+
1.**Analyze FFmpegWorker.js Implementation**
14
+
- Review the code structure
15
+
- Document core functionality
16
+
- Identify platform-specific handling
17
+
- Success criteria: Complete understanding of all worker functions and their purpose
18
+
19
+
2.**Understand Integration with FFmpegService**
20
+
- Review how the worker is used by the service layer
21
+
- Document the API between the service and worker
22
+
- Success criteria: Clear documentation of the integration points
23
+
24
+
3.**Document FFmpeg Permissions Handling**
25
+
- Analyze how elevated permissions are managed
26
+
- Document platform-specific approaches (Windows vs Unix)
27
+
- Success criteria: Clear explanation of the permission model
28
+
29
+
4.**Create Comprehensive Documentation**
30
+
- Update README with detailed FFmpeg worker section
31
+
- Include platform-specific notes
32
+
- Document common issues and solutions
33
+
- Success criteria: Complete, accurate documentation in the README
34
+
35
+
## Project Status Board
36
+
-[ ] Analyze FFmpegWorker.js Implementation
37
+
-[ ] Understand Integration with FFmpegService
38
+
-[ ] Document FFmpeg Permissions Handling
39
+
-[ ] Create Comprehensive Documentation
40
+
41
+
## Current Status / Progress Tracking
42
+
Initial setup of documentation plan.
43
+
44
+
## Executor's Feedback or Assistance Requests
45
+
Ready to begin analyzing the code structure of FFmpegWorker.js.
0 commit comments