Simplify issue templates for single-maintainer use

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -3,24 +3,12 @@ description: Report broken behavior, regressions, crashes, or reliability issues
 title: "[Bug]: "
 labels:
   - bug
-  - needs-triage
 body:
   - type: markdown
     attributes:
       value: |
         Use this form for broken behavior, regressions, crashes, or reliability problems.
-        This fork is maintained by one person and used as a personal tracker.
-        Keep the report focused on one problem and capture enough detail to debug it later.
-
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: Before submitting
-      options:
-        - label: I included enough detail to reproduce or investigate the problem.
-          required: true
-        - label: I included version, environment, or provider details where they matter.
-          required: true
+        Add only the details that will be useful later.
 
   - type: dropdown
     id: area
@@ -35,64 +23,29 @@ body:
         - Build, CI, or release tooling
         - Docs
         - Not sure
-    validations:
-      required: true
 
   - type: textarea
     id: steps
     attributes:
       label: Steps to reproduce
-      description: Provide a minimal, deterministic repro.
+      description: Add a repro if you have one.
       placeholder: |
         1. Start the app with ...
         2. Open ...
         3. Disconnect the network
         4. Reconnect and send another prompt
-    validations:
-      required: true
 
   - type: textarea
     id: expected
     attributes:
       label: Expected behavior
       placeholder: The thread should resume normally and accept the new message.
-    validations:
-      required: true
 
   - type: textarea
     id: actual
     attributes:
       label: Actual behavior
       placeholder: The composer clears, no new turn starts, and the session stays in a pending state.
-    validations:
-      required: true
-
-  - type: dropdown
-    id: impact
-    attributes:
-      label: Impact
-      description: How bad is this in practice?
-      options:
-        - Blocks work completely
-        - Major degradation or frequent failure
-        - Minor bug or occasional failure
-        - Cosmetic issue
-    validations:
-      required: true
-
-  - type: input
-    id: version
-    attributes:
-      label: Version or commit
-      description: Release version, commit SHA, or branch name if known.
-      placeholder: main @ abc1234
-
-  - type: input
-    id: environment
-    attributes:
-      label: Environment
-      description: OS, browser or desktop app version, Node/Bun version, provider/model if relevant.
-      placeholder: macOS 15.3, Chrome 135, Bun 1.3.9, Codex app-server ...
 
   - type: textarea
     id: logs
@@ -105,14 +58,5 @@ body:
     id: attachments
     attributes:
       label: Screenshots, recordings, or supporting files
-      description: Upload screenshots, short recordings, repro archives, or log files. Redact secrets before uploading.
-    validations:
-      required: false
+      description: Add screenshots, short recordings, or files if useful.
       accept: ".png,.jpg,.jpeg,.gif,.webp,.svg,.mp4,.mov,.webm,.log,.txt,.json,.zip"
-
-  - type: textarea
-    id: workaround
-    attributes:
-      label: Workaround
-      description: If you found a temporary workaround, include it.
-      placeholder: Restarting the provider session clears the stuck state.

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -3,24 +3,12 @@ description: Propose a scoped improvement or new capability.
 title: "[Feature]: "
 labels:
   - enhancement
-  - needs-triage
 body:
   - type: markdown
     attributes:
       value: |
         Use this form for new capabilities or meaningful improvements to existing behavior.
-        This fork is maintained by one person and the form is mainly for personal planning.
-        Keep requests concrete, narrow, and explicit about why the added maintenance cost is worth it.
-
-  - type: checkboxes
-    id: checks
-    attributes:
-      label: Before submitting
-      options:
-        - label: I am describing a concrete problem or use case, not just a vague idea.
-          required: true
-        - label: I kept the request scoped tightly enough that it is realistic for this fork to maintain.
-          required: true
+        Keep it light and capture only what will be useful later.
 
   - type: dropdown
     id: area
@@ -35,61 +23,23 @@ body:
         - Build, CI, or release tooling
         - Docs
         - Not sure
-    validations:
-      required: true
 
   - type: textarea
     id: problem
     attributes:
-      label: Problem or use case
-      description: What are you trying to do? What is hard, slow, or impossible today?
+      label: Problem or idea
+      description: What do you want to change?
       placeholder: I want to reconnect to an existing provider session after a browser refresh without losing the current thread state.
-    validations:
-      required: true
 
   - type: textarea
     id: proposal
     attributes:
-      label: Proposed solution
-      description: Describe the behavior, API, or UX you want.
+      label: Proposed change
+      description: How should it work?
       placeholder: Persist enough session metadata so the client can discover and reattach to the active provider session on load.
-    validations:
-      required: true
-
-  - type: textarea
-    id: value
-    attributes:
-      label: Why this matters
-      description: What outcome does this unlock, and why is it worth maintaining here?
-      placeholder: This would make reconnects predictable during network drops and reduce accidental duplicate sessions.
-    validations:
-      required: true
-
-  - type: textarea
-    id: scope
-    attributes:
-      label: Smallest useful scope
-      description: What is the narrowest version of this request that would still solve your problem?
-      placeholder: A first pass only needs to support restoring the active session for the current thread.
-    validations:
-      required: true
-
-  - type: textarea
-    id: alternatives
-    attributes:
-      label: Alternatives considered
-      description: Workarounds, prior art, or other approaches you considered.
-      placeholder: I currently work around this by manually restarting the provider session, but that loses in-flight context.
-
-  - type: textarea
-    id: tradeoffs
-    attributes:
-      label: Risks, tradeoffs, and maintenance cost
-      description: What costs, complexity, support burden, or edge cases should be considered?
-      placeholder: This may require careful handling when the underlying provider session has already exited and would add another long-lived state path to maintain.
 
   - type: textarea
     id: references
     attributes:
-      label: Examples or references
-      description: Links, screenshots, mockups, or comparable tools.
+      label: Notes or references
+      description: Optional links, screenshots, mockups, or anything else useful.