Skip to content

Commit fe95767

Browse files
hasanalpzenginhasanalpzengin
authored
Merge branch 'robotcodedev:main' into main
2 parents 87075e0 + a6ffcf5 commit fe95767

File tree

429 files changed

+232324
-149044
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

429 files changed

+232324
-149044
lines changed

‎.github/copilot-instructions.md

Lines changed: 162 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,162 @@
1+
# copilot-instructions.md
2+
3+
<ai_meta>
4+
<parsing_rules>
5+
- Process development patterns in sequential order
6+
- Use exact patterns and templates provided
7+
- Follow MUST/ALWAYS/REQUIRED directives strictly
8+
- Never deviate from established architectural patterns
9+
</parsing_rules>
10+
<file_conventions>
11+
- encoding: UTF-8
12+
- line_endings: LF
13+
- indent: 2 spaces (Python) / 4 spaces (TypeScript)
14+
- package_structure: packages/ for Python, vscode-client/ for TypeScript
15+
</file_conventions>
16+
</ai_meta>
17+
18+
RobotCode is a comprehensive Robot Framework toolkit that provides IDE extensions (VS Code, IntelliJ), CLI tools, and Language Server Protocol implementation. It uses Robot Framework's native parser for full compatibility while extending it with modern development tools like DAP debugging, test discovery, and multi-workspace support.
19+
20+
## Agent Communication Guidelines
21+
22+
### Core Rules
23+
24+
- **REVIEW/ANALYZE/CHECK/EXAMINE:** READ-ONLY operations. Provide analysis and feedback, NEVER make changes.
25+
- **IMPLEMENT/ADD/CREATE/FIX/CHANGE:** Implementation required. ALWAYS ask for confirmation and wait for explicit user choice before proceeding.
26+
- **IMPROVE/OPTIMIZE/REFACTOR:** Always ask for specific approach before implementing.
27+
- **MANDATORY WAIT:** When presenting implementation options, ALWAYS wait for explicit user choice before proceeding.
28+
29+
### Communication Flow
30+
31+
1. **Recognize Intent:** Review request vs. Implementation request?
32+
2. **For Reviews:** Analyze and suggest, but don't change anything.
33+
3. **For Implementation:**
34+
- ALWAYS ask for confirmation before implementing.
35+
- If multiple approaches exist, present numbered options A), B), C), D), ...).
36+
- ALWAYS end with "Other approach".
37+
- WAIT for user response before proceeding.
38+
- NEVER start implementation until user explicitly chooses an option.
39+
4. **Critical Rule:** When presenting options, STOP and wait for user input. Do not continue with any implementation.
40+
41+
## Tech Stack
42+
43+
### Core Technologies
44+
- **Language Server:** Python 3.8-3.13 with asyncio
45+
- **Protocol:** Language Server Protocol (LSP) + Debug Adapter Protocol (DAP)
46+
- **Parser:** Robot Framework native parser for full compatibility
47+
- **Build System:** Hatch for package management and testing
48+
49+
### VS Code Extension
50+
- **Language:** TypeScript
51+
- **Pattern:** Manager-based lifecycle with proper disposal
52+
- **Dependencies:** @vscode/test-electron, webpack, esbuild
53+
54+
### IntelliJ Plugin
55+
- **Language:** Kotlin
56+
- **Integration:** LSP4IJ for Language Server communication
57+
- **Build:** Gradle with kotlin-gradle-plugin
58+
59+
### Testing Matrix
60+
- **Python Versions:** 3.8, 3.9, 3.10, 3.11, 3.12, 3.13
61+
- **Robot Framework:** 5.0, 6.0, 6.1, 7.0, 7.1, 7.2, 7.3
62+
- **Test Framework:** pytest with regtest2 for snapshot testing
63+
64+
## General Coding Guidelines
65+
66+
### Clean Code Principles
67+
- **Readability First:** Code is read more often than written - prioritize clarity over cleverness.
68+
- **Meaningful Names:** Use descriptive names for variables, functions, and classes that express intent.
69+
- **Single Responsibility:** Each function/class should have one reason to change.
70+
- **Small Functions:** Keep functions focused and under 20 lines when possible.
71+
- **No Magic Numbers:** Use named constants or enums instead of hardcoded values.
72+
- **Avoid Deep Nesting:** Use early returns and guard clauses to reduce cyclomatic complexity.
73+
74+
### Code Organization
75+
- **Consistent Structure:** Follow established patterns within each package.
76+
- **Separation of Concerns:** Keep business logic separate from infrastructure code.
77+
- **Interface Segregation:** Create focused interfaces rather than monolithic ones.
78+
- **Dependency Inversion:** Depend on abstractions, not concrete implementations.
79+
80+
### Error Handling
81+
- **Explicit Error Handling:** Use proper exception/error types and hierarchies.
82+
- **Fail Fast:** Validate inputs early and provide clear error messages.
83+
- **Resource Management:** Use appropriate resource cleanup patterns (try-with-resources, RAII, etc.).
84+
- **Logging:** Provide meaningful log messages at appropriate levels.
85+
86+
### Documentation Standards
87+
- **Function Documentation:** All public functions/methods must have comprehensive documentation.
88+
- **Type Annotations:** Use static type checking where available (TypeScript, Python type hints, etc.).
89+
- **README Files:** Each package/module should have clear usage documentation.
90+
- **Inline Comments:** Explain *why*, not *what* - the code should be self-documenting.
91+
92+
### Project Language Requirement
93+
- **English for code and docs (REQUIRED):** Regardless of the natural language a user speaks when interacting with contributors or tools, all project-facing text must use English. This includes:
94+
- Documentation and README content
95+
- Inline comments and docstrings
96+
- Public and internal variable, function, class, and module names (identifiers)
97+
- Commit messages and code review comments where project conventions apply
98+
99+
This rule ensures consistency across the codebase, improves discoverability for international contributors, and enables reliable tooling (linters, analyzers, and internationalized docs). Use English even when writing examples or user-facing strings in tests; if localized strings are required, keep the canonical code-level names and primary docs in English and add separate localized resources.
100+
101+
### Commit Message Standard
102+
- **Conventional Commits (REQUIRED):** This project uses the Conventional Commits specification for commit messages. Commit messages must follow the format:
103+
- <type>(<scope>): <short description>
104+
- Optionally include a longer body and/or footer for references (breaking changes, issue numbers).
105+
106+
Common types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`.
107+
108+
Example:
109+
- feat(cli): add `--dry-run` flag to publish command
110+
111+
Following this convention enables automated changelog generation, semantic versioning tools, and clearer git history.
112+
113+
Brief rules (self-contained):
114+
- A commit message MUST start with a type, optionally a scope, then a short description. Example: `feat(cli): add --dry-run flag`.
115+
- Types indicate the kind of change (e.g., `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`, `revert`).
116+
- The scope is optional and should be a noun describing the area affected (e.g., `cli`, `docs`).
117+
- An optional body may follow after a blank line to explain motivation and other details.
118+
- Breaking changes MUST be indicated in the footer with `BREAKING CHANGE: <description>`.
119+
- Multiple line footer entries can reference issues or metadata (e.g., `Closes #123`).
120+
121+
### Testing Requirements
122+
- **Test Coverage:** Maintain high test coverage with meaningful test cases.
123+
- **Test Naming:** Use descriptive test names that explain the scenario.
124+
- **Test Structure:** Organize tests clearly with setup, execution, and verification phases.
125+
- **Test Independence:** Each test should be able to run in isolation.
126+
127+
### Performance Considerations
128+
- **Async Patterns:** Use proper asynchronous programming patterns where applicable.
129+
- **Resource Efficiency:** Minimize memory allocations and resource usage in hot paths.
130+
- **Lazy Loading:** Load resources only when needed.
131+
- **Caching Strategy:** Implement appropriate caching for expensive operations.
132+
133+
## Architecture Patterns
134+
135+
### Package Structure
136+
```
137+
packages/
138+
├── core/ # Base utilities and shared functionality
139+
├── language_server/ # LSP implementation for IDE integration
140+
├── debugger/ # Debug Adapter Protocol implementation
141+
├── runner/ # Enhanced Robot Framework execution tools
142+
├── analyze/ # Static code analysis and validation
143+
├── jsonrpc2/ # JSON-RPC communication layer
144+
├── plugin/ # Plugin system foundation
145+
├── repl/ # Interactive Robot Framework shell
146+
├── repl_server/ # REPL server for remote connections
147+
├── robot/ # Robot Framework integration utilities
148+
└── modifiers/ # Code transformation tools
149+
150+
vscode-client/ # VS Code extension (TypeScript)
151+
├── extension/ # Main extension code with manager pattern
152+
└── rendererLog/ # Log rendering components
153+
154+
intellij-client/ # IntelliJ/PyCharm plugin (Kotlin)
155+
├── src/main/kotlin/ # Plugin implementation via LSP4IJ
156+
└── build.gradle.kts # Gradle build configuration
157+
```
158+
159+
### Multi-Platform Support
160+
- **Python CLI:** Cross-platform command-line tools
161+
- **VS Code:** TypeScript extension with manager pattern
162+
- **IntelliJ:** Kotlin plugin via LSP4IJ bridge

‎.github/instructions/kotlin-intellij.instructions.md

Lines changed: 77 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,77 @@
1+
---
2+
description: Kotlin IntelliJ Plugin Development Rules for RobotCode
3+
applyTo: intellij-client/**
4+
---
5+
6+
# Kotlin IntelliJ Plugin Development Rules
7+
8+
<ai_meta>
9+
<parsing_rules>
10+
- Process XML blocks first for structured data
11+
- Execute instructions in sequential order
12+
- Use exact patterns and templates provided
13+
- Follow MUST/ALWAYS/REQUIRED directives strictly
14+
</parsing_rules>
15+
<file_conventions>
16+
- encoding: UTF-8
17+
- line_endings: LF
18+
- indent: 4 spaces
19+
- plugin_structure: intellij-client/src/main/kotlin/
20+
</file_conventions>
21+
</ai_meta>
22+
23+
## Plugin Architecture
24+
25+
### LSP4IJ Integration
26+
- **Language:** Kotlin
27+
- **Integration:** LSP4IJ for Language Server communication
28+
- **Build:** Gradle with kotlin-gradle-plugin
29+
30+
### Plugin Structure
31+
```
32+
intellij-client/
33+
├── src/main/kotlin/ # Plugin implementation via LSP4IJ
34+
└── build.gradle.kts # Gradle build configuration
35+
```
36+
37+
## Development Commands
38+
39+
### Building & Packaging
40+
```bash
41+
cd intellij-client && gradle buildPlugin # IntelliJ plugin
42+
```
43+
44+
## LSP4IJ Best Practices
45+
46+
### Language Server Communication
47+
- **IMPLEMENT** proper LSP4IJ bridge patterns
48+
- **HANDLE** multiple workspace folders with error isolation
49+
- **MAINTAIN** robust communication with RobotCode language server
50+
51+
### Multi-Platform Consistency
52+
- **ENSURE** consistent behavior with VS Code extension
53+
- **MAINTAIN** unified configuration approach
54+
- **DOCUMENT** platform-specific differences where necessary
55+
56+
## Configuration System
57+
58+
### robot.toml Integration
59+
- **SUPPORT** robot.toml parsing and profile management
60+
- **VALIDATE** configuration options consistently with other platforms
61+
- **MAINTAIN** cross-platform configuration compatibility
62+
63+
## Error Handling Standards
64+
65+
### Plugin Lifecycle
66+
- **IMPLEMENT** proper plugin lifecycle management
67+
- **HANDLE** startup and shutdown gracefully
68+
- **MANAGE** resources properly to prevent memory leaks
69+
70+
### LSP Communication
71+
- **ISOLATE** error handling per workspace
72+
- **MAINTAIN** robust communication with language server
73+
- **HANDLE** connection failures gracefully
74+
75+
---
76+
77+
*These Kotlin development rules ensure consistent, high-quality IntelliJ plugin development.*

‎.github/instructions/python-development.instructions.md

Lines changed: 70 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
---
2+
description: Python Development Rules for RobotCode
3+
applyTo: **/*.py
4+
---
5+
6+
# Python Development Rules
7+
8+
<ai_meta>
9+
<parsing_rules>
10+
- Process XML blocks first for structured data
11+
- Execute instructions in sequential order
12+
- Use exact patterns and templates provided
13+
- Follow MUST/ALWAYS/REQUIRED directives strictly
14+
</parsing_rules>
15+
<file_conventions>
16+
- encoding: UTF-8
17+
- line_endings: LF
18+
- indent: 2 spaces
19+
- package_structure: packages/ directory
20+
</file_conventions>
21+
</ai_meta>
22+
23+
## Package Development
24+
25+
### Package Structure
26+
- **ALWAYS** develop in packages/ directory
27+
- **REQUIRED** follow package-based architecture
28+
- **MUST** use proper __init__.py files for package imports
29+
30+
### Code Style Standards
31+
- **Formatting:** we use ruff for formatting
32+
- **Type Hints:** Required for all APIs
33+
- **Docstrings:** Google style for modules, classes, and functions, but follows clean code principles
34+
- **linting:** use ruff for static analysis and mypy for type checking
35+
36+
37+
### Code Quality
38+
```bash
39+
hatch run lint:all # All linting checks (black, isort, flake8)
40+
hatch run lint:fix # Auto-fix style issues
41+
```
42+
43+
### Testing Requirements
44+
45+
### Python Interpreter
46+
- **ask your tools** wich python interpreter to use for the project/workspace
47+
48+
### Matrix Testing
49+
- **COMPREHENSIVE** testing across Python 3.8-3.13
50+
- **MATRIX** testing with Robot Framework 5.0-7.3
51+
- **INTEGRATION** tests in tests/robotcode/ with real scenarios
52+
- **SNAPSHOT** testing with pytest regtest2
53+
54+
### Test Execution
55+
56+
**IMPORTANT**use the correct Python environment selected in your IDE
57+
58+
- **USE** `pytest .` to run unit tests,
59+
- **USE** `pytest --regtest2-reset` to update snapshots
60+
- **RUN** specific environments: `hatch run test.rf70.py311:test`
61+
- **COVERAGE** reporting with `hatch run cov`
62+
63+
## Multi-Platform Consistency
64+
- **ENSURE** consistent behavior across VS Code and IntelliJ
65+
- **MAINTAIN** unified configuration approach
66+
- **DOCUMENT** platform-specific differences
67+
68+
---
69+
70+
*These Python development rules ensure consistent, high-quality code across all RobotCode packages.*

0 commit comments

Comments
 (0)