Add repository standards: Ruff & Type check CI, SECURITY policy, and structured issues#610
Add repository standards: Ruff & Type check CI, SECURITY policy, and structured issues#610shiva24082 wants to merge 3 commits into
Conversation
Greptile SummaryThis PR adds form-based GitHub issue templates (
Confidence Score: 3/5Safe from a code-execution standpoint, but the duplicate issue templates actively degrade the contributor experience and should be resolved before merging. The new
Important Files Changed
Prompt To Fix All With AIFix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
.github/ISSUE_TEMPLATE/bug_report.yml:1
**Duplicate issue templates will appear in GitHub's picker**
The repository already contains `.github/ISSUE_TEMPLATE/bug_report.md` and `.github/ISSUE_TEMPLATE/feature_request.md`. GitHub renders both `.md` and `.yml` templates as separate entries in the "New Issue" chooser, so contributors will now see two "Bug Report" options and two "Feature Request" options simultaneously. The old `.md` templates should be deleted if the new form-based `.yml` versions are intended as replacements.
### Issue 2 of 3
.github/ISSUE_TEMPLATE/bug_report.yml:1-42
**Missing "Expected behavior" field present in the original template**
The existing `bug_report.md` includes an "Expected behavior" section, which is commonly the most useful field for triaging bugs (it distinguishes intent from outcome). The new `.yml` form omits it, so reporters have no structured place to describe what they expected to happen. Consider adding an optional `textarea` for this between "Reproduction Steps" and "Logs and Stack Traces".
### Issue 3 of 3
SECURITY.md:1-15
**Security policy does not mention a disclosure timeline or patch SLA**
The policy commits to acknowledging a report within 48 hours but sets no expectation for when a fix will be released or when the reporter may disclose publicly. For an open-source pentesting tool, a standard responsible disclosure window (e.g., 90 days) is expected by security researchers. Without it, reporters have no basis for coordinated disclosure, which can lead to premature public posts or disputes.
Reviews (1): Last reviewed commit: "Add/Update SECURITY.md to improve reposi..." | Re-trigger Greptile |
| @@ -0,0 +1,42 @@ | |||
| name: "🐛 Bug Report" | |||
There was a problem hiding this comment.
Duplicate issue templates will appear in GitHub's picker
The repository already contains .github/ISSUE_TEMPLATE/bug_report.md and .github/ISSUE_TEMPLATE/feature_request.md. GitHub renders both .md and .yml templates as separate entries in the "New Issue" chooser, so contributors will now see two "Bug Report" options and two "Feature Request" options simultaneously. The old .md templates should be deleted if the new form-based .yml versions are intended as replacements.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/ISSUE_TEMPLATE/bug_report.yml
Line: 1
Comment:
**Duplicate issue templates will appear in GitHub's picker**
The repository already contains `.github/ISSUE_TEMPLATE/bug_report.md` and `.github/ISSUE_TEMPLATE/feature_request.md`. GitHub renders both `.md` and `.yml` templates as separate entries in the "New Issue" chooser, so contributors will now see two "Bug Report" options and two "Feature Request" options simultaneously. The old `.md` templates should be deleted if the new form-based `.yml` versions are intended as replacements.
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| name: "🐛 Bug Report" | ||
| description: "Report a bug or unexpected behavior in Strix" | ||
| title: "[Bug]: " | ||
| labels: ["bug", "triage"] | ||
| body: | ||
| - type: markdown | ||
| attributes: | ||
| value: | | ||
| Please fill out this form to help us diagnose and resolve the issue. | ||
| - type: textarea | ||
| id: description | ||
| attributes: | ||
| label: "Vulnerability / Bug Description" | ||
| description: "A clear and concise description of what is happening." | ||
| placeholder: "e.g., Strix CLI crashes during local scan on port 8080..." | ||
| validations: | ||
| required: true | ||
| - type: textarea | ||
| id: reproduction | ||
| attributes: | ||
| label: "Reproduction Steps" | ||
| description: "How can we reproduce the bug?" | ||
| placeholder: | | ||
| 1. Run 'uv run strix --target https://example.com' | ||
| 2. Set environment variable STRIX_LLM = ... | ||
| 3. See error stack trace... | ||
| validations: | ||
| required: true | ||
| - type: textarea | ||
| id: logs | ||
| attributes: | ||
| label: "Logs and Stack Traces" | ||
| description: "Copy-paste relevant terminal error logs here." | ||
| render: shell | ||
| - type: input | ||
| id: environment | ||
| attributes: | ||
| label: "System & LLM Environment" | ||
| description: "Python version, OS, target server model, LLM provider, etc." | ||
| placeholder: "e.g. Python 3.12, macOS Sonoma, OpenAI GPT-4o" | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
Missing "Expected behavior" field present in the original template
The existing bug_report.md includes an "Expected behavior" section, which is commonly the most useful field for triaging bugs (it distinguishes intent from outcome). The new .yml form omits it, so reporters have no structured place to describe what they expected to happen. Consider adding an optional textarea for this between "Reproduction Steps" and "Logs and Stack Traces".
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/ISSUE_TEMPLATE/bug_report.yml
Line: 1-42
Comment:
**Missing "Expected behavior" field present in the original template**
The existing `bug_report.md` includes an "Expected behavior" section, which is commonly the most useful field for triaging bugs (it distinguishes intent from outcome). The new `.yml` form omits it, so reporters have no structured place to describe what they expected to happen. Consider adding an optional `textarea` for this between "Reproduction Steps" and "Logs and Stack Traces".
How can I resolve this? If you propose a fix, please make it concise.Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| # Security Policy | ||
|
|
||
| ## Supported Versions | ||
|
|
||
| Only the latest stable version of Strix is supported with security updates. | ||
|
|
||
| ## Reporting a Vulnerability | ||
|
|
||
| If you discover a security vulnerability in Strix, please do **not** open a public issue. We take security seriously and want to fix exploits responsibly. | ||
|
|
||
| Please report vulnerabilities privately by: | ||
| - Sending an email to **hi@usestrix.com** with details of the vulnerability and reproduction steps. | ||
| - Or utilizing GitHub's private vulnerability reporting feature on the repository. | ||
|
|
||
| We will acknowledge your report within 48 hours and work with you to release a security patch. |
There was a problem hiding this comment.
Security policy does not mention a disclosure timeline or patch SLA
The policy commits to acknowledging a report within 48 hours but sets no expectation for when a fix will be released or when the reporter may disclose publicly. For an open-source pentesting tool, a standard responsible disclosure window (e.g., 90 days) is expected by security researchers. Without it, reporters have no basis for coordinated disclosure, which can lead to premature public posts or disputes.
Prompt To Fix With AI
This is a comment left during a code review.
Path: SECURITY.md
Line: 1-15
Comment:
**Security policy does not mention a disclosure timeline or patch SLA**
The policy commits to acknowledging a report within 48 hours but sets no expectation for when a fix will be released or when the reporter may disclose publicly. For an open-source pentesting tool, a standard responsible disclosure window (e.g., 90 days) is expected by security researchers. Without it, reporters have no basis for coordinated disclosure, which can lead to premature public posts or disputes.
How can I resolve this? If you propose a fix, please make it concise.
This Pull Request introduces standard CI workflows, issue structures, and security policies:
SECURITY.md): Configures private vulnerability disclosure details, vital for open source pentesting software..github/ISSUE_TEMPLATE/.Created using the Antigravity GitHub repository analyzer.