-
Notifications
You must be signed in to change notification settings - Fork 0
Add Copilot instructions and .gitignore #29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
887bff8
Initial plan
Copilot 8f67055
Initial plan for setting up Copilot instructions
Copilot 586f3b5
Add Copilot instructions and .gitignore
Copilot 1965f6c
Update Copilot instructions with accurate module information and deta…
Copilot 9b2f524
Refine Copilot instructions with clarified module status and API chan…
Copilot fe16c54
Document all three locations of Keypair::from_bytes compilation error
Copilot b2d49ee
Merge branch 'master' into copilot/setup-copilot-instructions
0xrinegade File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,253 @@ | ||||||
| # Copilot Instructions for svmai-cli | ||||||
|
|
||||||
| ## Project Overview | ||||||
|
|
||||||
| `svmai` is a command-line interface (CLI) tool built with Rust for managing Solana wallets. It provides secure wallet management with system keychain integration, multi-threaded wallet search, vanity wallet generation, and a comprehensive text-based user interface (TUI) built with `ratatui`. | ||||||
|
|
||||||
| ## Key Features | ||||||
|
|
||||||
| - Multi-threaded wallet search and validation | ||||||
| - Secure keychain storage using AES-GCM encryption | ||||||
| - Text-based User Interface (TUI) for wallet management | ||||||
| - Vanity wallet generation with "ai" prefix | ||||||
| - Batch operations for token transfers | ||||||
| - Token mixing simulation for privacy enhancement | ||||||
| - SOL and SPL token balance viewing | ||||||
|
|
||||||
| ## Project Structure | ||||||
|
|
||||||
| ``` | ||||||
| src/ | ||||||
| ├── main.rs # Application entry point and CLI parsing | ||||||
| ├── tui.rs # Text-based User Interface implementation | ||||||
| ├── file_searcher.rs # Multi-threaded wallet file search | ||||||
| ├── key_validator.rs # Solana private key validation | ||||||
| ├── secure_storage.rs # Keychain integration and encryption | ||||||
| ├── wallet_manager.rs # Wallet CRUD operations | ||||||
| ├── vanity_wallet.rs # Vanity address generation | ||||||
| ├── config.rs # Configuration management (not currently integrated) | ||||||
| ├── logging.rs # Logging utilities (not currently integrated) | ||||||
| └── transaction_handler.rs # Batch send and token mixing logic (not currently integrated) | ||||||
| ``` | ||||||
|
|
||||||
| Note: Some modules (`config.rs`, `logging.rs`, `transaction_handler.rs`) exist as implemented files but are not yet imported in `main.rs`, indicating they are planned features that have been developed but not yet integrated into the main application. | ||||||
|
|
||||||
| ## Build Process | ||||||
|
|
||||||
| ### Prerequisites | ||||||
|
|
||||||
| - Rust and Cargo (latest stable version) | ||||||
| - Build essentials for your platform | ||||||
| - OpenSSL development libraries | ||||||
| - Ubuntu/Debian: `sudo apt-get install libssl-dev pkg-config build-essential` | ||||||
| - macOS: Xcode Command Line Tools | ||||||
| - Windows: Visual Studio Build Tools | ||||||
|
|
||||||
| ### Building | ||||||
|
|
||||||
| ```bash | ||||||
| # Debug build | ||||||
| cargo build | ||||||
|
|
||||||
| # Release build | ||||||
| cargo build --release | ||||||
| ``` | ||||||
|
|
||||||
| The compiled binary will be located at: | ||||||
| - Debug: `target/debug/svmai` | ||||||
| - Release: `target/release/svmai` | ||||||
|
|
||||||
| ## Testing | ||||||
|
|
||||||
| Run the test suite with: | ||||||
|
|
||||||
| ```bash | ||||||
| cargo test | ||||||
| ``` | ||||||
|
|
||||||
| Run tests with verbose output: | ||||||
|
|
||||||
| ```bash | ||||||
| cargo test -- --nocapture | ||||||
| ``` | ||||||
|
|
||||||
| Run tests with coverage (CI uses cargo-tarpaulin): | ||||||
|
|
||||||
| ```bash | ||||||
| cargo install cargo-tarpaulin | ||||||
| cargo tarpaulin --verbose --workspace --timeout 120 | ||||||
| ``` | ||||||
|
|
||||||
| ## Linting and Code Quality | ||||||
|
|
||||||
| ### Format Code | ||||||
|
|
||||||
| Always format code before committing: | ||||||
|
|
||||||
| ```bash | ||||||
| cargo fmt | ||||||
| ``` | ||||||
|
|
||||||
| Check formatting without making changes: | ||||||
|
|
||||||
| ```bash | ||||||
| cargo fmt -- --check | ||||||
| ``` | ||||||
|
|
||||||
| ### Clippy (Lint) | ||||||
|
|
||||||
| Run Clippy to catch common mistakes and improve code quality: | ||||||
|
|
||||||
| ```bash | ||||||
| cargo clippy | ||||||
| ``` | ||||||
|
|
||||||
| Run Clippy with warnings as errors (used in CI): | ||||||
|
|
||||||
| ```bash | ||||||
| cargo clippy -- -D warnings | ||||||
| ``` | ||||||
|
|
||||||
| ## Code Style Guidelines | ||||||
|
|
||||||
| - Follow Rust's official style guide | ||||||
| - Use `cargo fmt` to automatically format code | ||||||
| - Use `cargo clippy` to catch common mistakes and anti-patterns | ||||||
| - Write clear, descriptive comments for complex logic | ||||||
| - Document public API functions with rustdoc comments (`///`) | ||||||
| - Keep functions focused and modular | ||||||
| - Use meaningful variable and function names | ||||||
|
|
||||||
| ### Naming Conventions | ||||||
|
|
||||||
| - Use `snake_case` for functions, variables, and module names | ||||||
| - Use `PascalCase` for types, traits, and enum variants | ||||||
| - Use `SCREAMING_SNAKE_CASE` for constants and statics | ||||||
| - Prefix unused variables with underscore: `_variable` | ||||||
|
|
||||||
| ### Error Handling | ||||||
|
|
||||||
| - Use `Result<T, E>` for fallible operations | ||||||
| - Propagate errors with `?` operator where appropriate | ||||||
| - Use `anyhow` for flexible error handling in application code | ||||||
| - Provide user-friendly error messages in the TUI | ||||||
|
|
||||||
| ## Dependencies | ||||||
|
|
||||||
| Key dependencies: | ||||||
|
|
||||||
| - `ratatui` & `crossterm` - Text-based User Interface | ||||||
| - `rayon` - Parallel processing for file search and vanity generation | ||||||
| - `solana-sdk` - Solana blockchain interactions | ||||||
| - `keyring` - System keychain integration | ||||||
| - `aes-gcm` - AES-GCM encryption for private keys | ||||||
| - `serde` & `serde_json` - Serialization/deserialization | ||||||
| - `walkdir` - Recursive directory traversal | ||||||
|
|
||||||
| ## Security Considerations | ||||||
|
|
||||||
| **CRITICAL**: This application handles Solana private keys. Follow these security practices: | ||||||
|
|
||||||
| 1. **Private Key Handling**: | ||||||
| - Keep decrypted private keys in memory for the shortest time necessary | ||||||
| - Never log or display private keys | ||||||
| - Use secure_storage module for all key operations | ||||||
|
|
||||||
| 2. **Encryption**: | ||||||
| - All private keys must be encrypted using AES-GCM before storage | ||||||
| - Master encryption key is stored in system keychain | ||||||
|
|
||||||
| 3. **Input Validation**: | ||||||
| - Rigorously validate all user inputs (paths, addresses, amounts) | ||||||
| - Validate Solana addresses before use | ||||||
| - Sanitize file paths to prevent directory traversal | ||||||
|
|
||||||
| 4. **Testing with Secrets**: | ||||||
| - Never commit test private keys or sensitive data | ||||||
| - Use generated/temporary keys for tests | ||||||
| - Mark sensitive test data clearly | ||||||
|
|
||||||
| ## CI/CD Workflow | ||||||
|
|
||||||
| The project uses GitHub Actions with the following checks: | ||||||
|
|
||||||
| 1. **Build** - Compiles the project on Ubuntu | ||||||
| 2. **Test** - Runs the full test suite | ||||||
| 3. **Coverage** - Generates code coverage report (uploaded to Codecov) | ||||||
| 4. **Clippy** - Runs linting checks (fails on warnings) | ||||||
| 5. **Format** - Checks code formatting compliance | ||||||
|
|
||||||
| All checks must pass before merging to master branch. | ||||||
|
|
||||||
| ## Contributing Guidelines | ||||||
|
|
||||||
| When making changes: | ||||||
|
|
||||||
| 1. Create a feature branch from `master` | ||||||
| 2. Make focused, atomic commits with descriptive messages | ||||||
| 3. Add tests for new functionality | ||||||
| 4. Run `cargo fmt` before committing | ||||||
| 5. Run `cargo clippy` and address all warnings | ||||||
| 6. Run `cargo test` to ensure all tests pass | ||||||
| 7. Update documentation for any changed functionality | ||||||
| 8. Keep pull requests focused on a single topic | ||||||
|
|
||||||
| ## Common Development Tasks | ||||||
|
|
||||||
| ### Adding a New Feature | ||||||
|
|
||||||
| 1. Determine which module(s) need modification | ||||||
| 2. Add tests first (TDD approach when possible) | ||||||
| 3. Implement the feature | ||||||
| 4. Update documentation | ||||||
| 5. Run linting and tests | ||||||
|
|
||||||
| ### Debugging | ||||||
|
|
||||||
| - Use `RUST_LOG=debug cargo run` for detailed logging | ||||||
| - The TUI can be challenging to debug; consider adding log statements | ||||||
| - Use `cargo test -- --nocapture` to see test output | ||||||
|
|
||||||
| ### Performance Considerations | ||||||
|
|
||||||
| - File search is optimized for large directories using `rayon` | ||||||
| - Vanity wallet generation uses multiple CPU cores (configurable) | ||||||
| - API calls are rate-limited to avoid service disruptions | ||||||
| - Consider caching for frequently accessed data | ||||||
|
|
||||||
| ## TUI Development | ||||||
|
|
||||||
| The TUI is built with `ratatui` and `crossterm`. Key concepts: | ||||||
|
|
||||||
| - **Event Loop**: Main loop handles drawing and input events | ||||||
| - **View System**: Organized into different views (WalletList, WalletDetail, Help, etc.) | ||||||
| - **App State**: The `App` struct maintains application state | ||||||
| - **Responsive Layout**: UI adapts to terminal size using constraints | ||||||
|
|
||||||
| When modifying the TUI: | ||||||
| - Test in different terminal sizes | ||||||
| - Ensure keyboard shortcuts don't conflict | ||||||
| - Update help screen (`H` key) with new shortcuts | ||||||
| - Handle edge cases (empty lists, long text, etc.) | ||||||
|
|
||||||
| ## Known Issues | ||||||
|
|
||||||
| - **Compilation Error**: The project currently has compilation errors due to the use of `Keypair::from_bytes(&key_bytes)` which was available in earlier versions of solana-sdk but has been removed in version 3.0.0. This affects three files: | ||||||
|
||||||
| - **Compilation Error**: The project currently has compilation errors due to the use of `Keypair::from_bytes(&key_bytes)` which was available in earlier versions of solana-sdk but has been removed in version 3.0.0. This affects three files: | |
| - **Compilation Errors**: The project currently has compilation errors due to the use of `Keypair::from_bytes(&key_bytes)` which was available in earlier versions of solana-sdk but has been removed in version 3.0.0. This affects three files: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The instruction mentions using "anyhow" for error handling, but anyhow is not currently listed in Cargo.toml dependencies. It's only used in unintegrated modules (config.rs and logging.rs). The active codebase uses standard Result types like io::Result. Consider clarifying that anyhow will be used once those modules are integrated, or that it should be added as a dependency for new error handling code.