|
2 | 2 |
|
3 | 3 | ## SSH Connections |
4 | 4 |
|
5 | | -**ALWAYS use SSH multiplexing (ControlMaster) for repeated SSH connections:** |
| 5 | +**CRITICAL: ALWAYS use sshpass for SSH connections that require password authentication:** |
6 | 6 |
|
7 | | -1. **First connection** - Establish master: |
| 7 | +1. **ALWAYS use sshpass** when passwords are needed: |
| 8 | + ```bash |
| 9 | + sshpass -p 'password' ssh -o StrictHostKeyChecking=no user@host "command" |
| 10 | + ``` |
| 11 | + |
| 12 | +2. **SSH Multiplexing (ControlMaster)** - For repeated SSH connections: |
| 13 | + |
| 14 | + **First connection** - Establish master: |
8 | 15 | ```bash |
9 | 16 | sshpass -p 'password' ssh -o ControlMaster=yes \ |
10 | 17 | -o ControlPath=~/.ssh/controlmasters/%h-%p-%r \ |
11 | 18 | -o ControlPersist=300 \ |
| 19 | + -o StrictHostKeyChecking=no \ |
12 | 20 | -p PORT user@host "command" |
13 | 21 | ``` |
14 | 22 |
|
15 | | -2. **Subsequent connections** - Reuse master: |
| 23 | + **Subsequent connections** - Reuse master: |
16 | 24 | ```bash |
17 | 25 | ssh -o ControlPath=~/.ssh/controlmasters/%h-%p-%r \ |
| 26 | + -o StrictHostKeyChecking=no \ |
18 | 27 | -p PORT user@host "command" |
19 | 28 | ``` |
20 | 29 |
|
21 | 30 | 3. **For WireGuard server** (proxmox.dynamicdevices.co.uk:5025): |
22 | 31 | - Use multiplexing for all diagnostic commands |
| 32 | + - Use sshpass for initial connection |
23 | 33 | - Master connection persists for 5 minutes |
24 | 34 | - No password needed after first connection |
25 | 35 |
|
| 36 | +4. **Default SSH users:** |
| 37 | + - Foundries devices: `fio` (or `root` if fio unavailable) |
| 38 | + - WireGuard server: `root` |
| 39 | + - Hardware lab devices: Check device config or try `root`/`fio` |
| 40 | + |
| 41 | +5. **Common passwords:** |
| 42 | + - Foundries devices: `fio` (default) |
| 43 | + - WireGuard server: Check with user or use SSH keys when available |
| 44 | + |
26 | 45 | ## Best Practices |
27 | 46 |
|
28 | 47 | - Use multiplexing whenever making multiple SSH connections to the same host |
29 | 48 | - Set ControlPersist to 300-600 seconds |
30 | 49 | - Use unique ControlPath per host/port/user combination |
31 | 50 | - Document SSH connection patterns in code comments |
| 51 | + |
| 52 | +## Pull Request Guidelines |
| 53 | + |
| 54 | +**ALWAYS follow these rules when creating or updating PRs:** |
| 55 | + |
| 56 | +1. **ALWAYS Create PRs as DRAFT:** |
| 57 | + - **CRITICAL:** When creating a PR, it MUST be created as a DRAFT |
| 58 | + - Use `--draft` flag with `gh pr create` or set `draft: true` via API |
| 59 | + - **Only the user (ajlennon) is allowed to convert PRs from draft to ready/OPEN status** |
| 60 | + - This prevents reviewers from being notified prematurely and avoids annoying them with incomplete work |
| 61 | + - Even if the PR appears complete, create it as draft - let the user decide when it's ready for review |
| 62 | + |
| 63 | +2. **Cursor.AI Note:** Every PR description MUST include a note that it was generated with Cursor.AI assistance: |
| 64 | + ``` |
| 65 | + ## Generated with Cursor.AI Assistance |
| 66 | + |
| 67 | + This PR and its changes were generated with the assistance of Cursor.AI for user ajlennon (Alex J Lennon, ajlennon@dynamicdevices.co.uk). |
| 68 | + ``` |
| 69 | + |
| 70 | +3. **Explicit Notification:** After creating or updating a PR, ALWAYS explicitly inform the user: |
| 71 | + - PR number and URL |
| 72 | + - Status (DRAFT/OPEN) - **emphasize if it's DRAFT and that user needs to convert it** |
| 73 | + - What was updated |
| 74 | + - That it includes the Cursor.AI note |
| 75 | + - **Reminder:** "This PR is created as DRAFT - you can convert it to ready when you're satisfied" |
| 76 | + |
| 77 | +4. **Review Comments:** When updating PRs, review existing comments and address them if needed before updating the PR description. |
| 78 | + |
| 79 | +4. **CRITICAL: Comprehensive PR Review After Any Changes:** |
| 80 | + **After making ANY changes to a PR (description, code, comments), you MUST:** |
| 81 | + - Verify all claims in the PR description match the actual code implementation |
| 82 | + - Check that code examples in the PR are accurate |
| 83 | + - Verify that "Review Comments Addressed" sections accurately reflect what was fixed |
| 84 | + - Ensure line numbers mentioned in PR are correct (if mentioned) |
| 85 | + - Verify that all technical claims are accurate (e.g., "subnet is derived" → check code actually does this) |
| 86 | + - Cross-reference PR description with actual code changes |
| 87 | + - Test any code examples or logic described in the PR |
| 88 | + - **This is CRITICAL** - incorrect PR descriptions mislead reviewers and damage trust |
| 89 | + |
| 90 | +## AI-Generated Content Disclosure |
| 91 | + |
| 92 | +**CRITICAL: ALL AI-generated content MUST include disclosure:** |
| 93 | + |
| 94 | +**When creating or responding to:** |
| 95 | +- Pull Requests (PRs) |
| 96 | +- Pull Request comments and reviews |
| 97 | +- Issue comments |
| 98 | +- Code reviews |
| 99 | +- Documentation |
| 100 | +- Any external communications (GitHub, GitLab, etc.) |
| 101 | + |
| 102 | +**ALWAYS include this note:** |
| 103 | +``` |
| 104 | +*This [response/PR/comment] was made with the assistance of Cursor.AI for user ajlennon (Alex J Lennon, ajlennon@dynamicdevices.co.uk).* |
| 105 | +``` |
| 106 | + |
| 107 | +**Format examples:** |
| 108 | +- PR descriptions: Add a section at the bottom |
| 109 | +- Comments: Add at the end of the comment |
| 110 | +- Code reviews: Include in review summary |
| 111 | +- Documentation: Add to author/credits section |
| 112 | + |
| 113 | +**This ensures transparency about AI assistance in all communications.** |
0 commit comments