chore: lighter issue + PR templates — strip required fields, drop ADR, allow blank issues (#59)

* chore(issue-templates): remove ADR template (too heavy; ADR label + free-form issue is enough)

* chore(issue-templates): slim bug_report to title + one description field

* chore(issue-templates): slim feature_request to title + one description field

* chore(issue-templates): slim rule-request to title + one description field

* chore(issue-templates): enable blank issues for contributors who skip the template

* chore(pr-template): collapse to a free-form 'What changed' section

Author: Pawansingh3889

.github/ISSUE_TEMPLATE/adr.yml

@@ -6,64 +6,20 @@ body:
   - type: markdown
     attributes:
       value: |
-        Thanks for reporting a bug. If this is a **security**
-        issue (rule bypass, false negative on a dangerous SQL
-        pattern), please file a [private advisory](../../security/advisories/new)
-        instead of a public issue.
-
-  - type: input
-    id: version
-    attributes:
-      label: sql-sop version
-      description: Output of `sql-sop --version`
-      placeholder: e.g. 0.4.0
-    validations:
-      required: true
-
-  - type: input
-    id: python
-    attributes:
-      label: Python version
-      placeholder: e.g. 3.11.9
-    validations:
-      required: true
-
-  - type: input
-    id: os
-    attributes:
-      label: Operating system
-      placeholder: e.g. Ubuntu 24.04, Windows 11, macOS 14
-    validations:
-      required: true
-
-  - type: textarea
-    id: sql
-    attributes:
-      label: SQL that reproduces the problem
-      description: Paste the SQL string or point at a fixture file.
-      render: sql
-    validations:
-      required: true
-
-  - type: textarea
-    id: expected
-    attributes:
-      label: Expected behaviour
-      description: Which rule (E001, W001, ...) should have fired, or not fired?
-    validations:
-      required: true
+        For **security** issues (rule bypass, false negative on a dangerous
+        SQL pattern), please file a
+        [private advisory](../../security/advisories/new) instead of a
+        public issue.
 
   - type: textarea
-    id: actual
-    attributes:
-      label: Actual behaviour
-      description: What sql-sop actually reported. Paste the CLI output.
-      render: shell
-    validations:
-      required: true
-
-  - type: textarea
-    id: extras
-    attributes:
-      label: Additional context
-      description: Anything else that would help — pre-commit config, CI workflow step, environment variables.
+    id: description
+    attributes:
+      label: What's wrong?
+      description: |
+        Anything that helps us understand and reproduce. Skip anything
+        that isn't relevant.
+      placeholder: |
+        sql-sop version + Python version (if relevant)
+        What you ran
+        What you expected
+        What actually happened

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -1,14 +1,11 @@
-blank_issues_enabled: false
+blank_issues_enabled: true
 contact_links:
   - name: Security report (rule bypass, false negative, CVE)
     url: https://github.com/Pawansingh3889/sql-guard/security/advisories/new
     about: Security issues go through the private advisory channel, not a public issue. See SECURITY.md.
   - name: "Usage question - 'how do I...?'"
     url: https://github.com/Pawansingh3889/sql-guard/discussions/categories/q-a
     about: Ask in Discussions - lower friction than an issue, often a faster reply.
-  - name: "Show us how you're using sql-sop"
-    url: https://github.com/Pawansingh3889/sql-guard/discussions/categories/show-and-tell
-    about: Share your use case - we feature replies in the README.
   - name: General discussion / open-ended question
     url: https://github.com/Pawansingh3889/sql-guard/discussions
     about: Anything that isn't a bug, rule request, or feature proposal.

.github/ISSUE_TEMPLATE/config.yml

@@ -1,48 +1,12 @@
 name: Feature request
-description: Suggest a new rule, rule change, or improvement
+description: Suggest a new rule, change, or improvement
 title: "[Feature]: "
 labels: ["enhancement"]
 body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for suggesting. If you're proposing a **new rule**,
-        see `CONTRIBUTING.md` § "Adding a new rule" for the shape
-        of the work.
-
-  - type: textarea
-    id: problem
-    attributes:
-      label: What problem does this solve?
-      description: Describe the SQL hazard or developer pain. Examples of the pattern in real code are gold.
-    validations:
-      required: true
-
-  - type: textarea
-    id: proposal
-    attributes:
-      label: Proposed change
-      description: New rule ID (next unused E00N / W0NN / S00N / P00N), name, severity, and a one-sentence description.
-    validations:
-      required: true
-
-  - type: textarea
-    id: examples
-    attributes:
-      label: Examples
-      description: SQL that should fire the rule, and SQL that should NOT (so the false-positive risk is visible).
-      render: sql
-
   - type: textarea
-    id: alternatives
-    attributes:
-      label: Alternatives considered
-      description: Why this over existing rules, or over "just educate developers"?
-
-  - type: checkboxes
-    id: breaking
+    id: description
     attributes:
-      label: Breaking-change check
-      description: Rule removal, ID renaming, or default-severity changes break downstream pre-commit configs.
-      options:
-        - label: This change does NOT remove or rename any existing rule ID or change a default severity.
+      label: What would you like to see?
+      description: |
+        Freeform. Describe the problem, the proposal, and any examples
+        that help. Don't fuss about structure — we'll ask if we need more.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -1,80 +1,18 @@
 name: Rule request
 description: Suggest a new SQL or Python lint rule
-title: "rule: <one-line description>"
+title: "rule: "
 labels: ["rule-request", "needs-triage"]
 body:
-  - type: markdown
-    attributes:
-      value: |
-        Thanks for helping sharpen sql-sop. One rule-per-issue, please.
-        If you're not sure whether it fits, open it anyway - triage is fast.
-
   - type: textarea
-    id: what
+    id: description
     attributes:
       label: What pattern should this rule catch?
-      description: One sentence. Example - "Warn on UNION when UNION ALL would work."
-      placeholder: "Warn on ..."
-    validations:
-      required: true
-
-  - type: textarea
-    id: fail-example
-    attributes:
-      label: SQL (or Python) example that should fail
-      description: Paste minimal code that should trigger the new rule.
-      render: sql
-      placeholder: |
-        SELECT id FROM orders
-        UNION
-        SELECT id FROM archived_orders;
-    validations:
-      required: true
-
-  - type: textarea
-    id: pass-example
-    attributes:
-      label: SQL (or Python) example that should NOT trigger
-      description: The boundary case - helps us avoid false positives.
-      render: sql
+      description: |
+        Useful to include if you have them — a SQL example that should
+        fail, an example that should pass, why this matters in
+        production. Skip what you don't have.
       placeholder: |
-        SELECT id FROM orders
-        UNION ALL
-        SELECT id FROM archived_orders;
-    validations:
-      required: true
-
-  - type: dropdown
-    id: severity
-    attributes:
-      label: Proposed severity
-      options:
-        - warning (advisory, doesn't block commits)
-        - error (blocks commits / CI)
-        - not sure
-      default: 0
-    validations:
-      required: true
-
-  - type: input
-    id: similar
-    attributes:
-      label: Similar existing rule (if any)
-      description: Which rule ID would you model this on? Helps reviewers.
-      placeholder: "e.g. W003 function-on-column"
-
-  - type: textarea
-    id: why
-    attributes:
-      label: Why does this matter in production?
-      description: A real bug you caught, a code review pattern, a DB outage, etc.
-
-  - type: checkboxes
-    id: scope
-    attributes:
-      label: Scope checks (tick what applies)
-      options:
-        - label: This is a SQL pattern (regex-based rule in `sql_guard/rules/`)
-        - label: This needs AST parsing (structural rule, sqlparse-based)
-        - label: This is a Python scanner rule (libCST, in `sql_guard/rules/python_rules.py`)
-        - label: I'm willing to open a PR for this myself
+        Pattern:
+        Example that should fail:
+        Example that should pass:
+        Why it matters:

.github/ISSUE_TEMPLATE/rule-request.yml

@@ -1,35 +1,6 @@
 <!--
-Thanks for contributing to sql-sop! Fill out the sections below so the
-maintainer doesn't have to ask. One-line docs fixes can skip most
-sections; rule additions should fill everything.
+A brief description is enough. Skip anything that doesn't apply.
+Conventional Commit style for the title (feat: / fix: / docs: / chore: / ci: / test:) helps Release Please.
 -->
 
 ## What changed
-
-<!-- One or two sentences explaining the *why*, not just the *what*. -->
-
-## Related issue
-
-<!-- "Closes #123" or "Relates to #123". -->
-
-## If this adds or changes a rule
-
-- [ ] Rule ID is the next unused one in its family (`E00N` / `W0NN` / `S00N` / `P00N`)
-- [ ] Rule class registered in `sql_guard/rules/__init__.py`
-- [ ] Fixture line in `tests/fixtures/errors.sql` or `warnings.sql`
-- [ ] "Fires on bad SQL" test in `tests/test_rules.py`
-- [ ] "Does NOT fire on safe SQL" test (using `tmp_path`)
-- [ ] README rule table + Key Numbers count updated
-- [ ] Rule is not a removal or rename of an existing rule (breaking change — see `GOVERNANCE.md`)
-
-## Tests
-
-- [ ] `pytest -q` passes
-- [ ] `ruff check .` passes
-
-## Checklist
-
-- [ ] One logical change per commit, conventional commit style (`feat:`, `fix:`, `docs:`, `chore:`, `ci:`, `test:`, `style:`)
-- [ ] `CHANGELOG.md` `[Unreleased]` entry if user-facing
-
-## Anything else reviewers should know