| ... | ... | @@ -1,102 +0,0 @@ |
| 1 | | name: Feature request |
| 2 | | description: Propose a scoped improvement or new capability. |
| 3 | | title: "[Feature]: " |
| 4 | | labels: |
| 5 | | - enhancement |
| 6 | | - needs-triage |
| 7 | | body: |
| 8 | | - type: markdown |
| 9 | | attributes: |
| 10 | | value: | |
| 11 | | Use this form for new capabilities or meaningful improvements to existing behavior. |
| 12 | | This repo is still early. Small, concrete requests that clearly explain the problem and scope are much easier to evaluate. |
| 13 | | |
| 14 | | - type: checkboxes |
| 15 | | id: checks |
| 16 | | attributes: |
| 17 | | label: Before submitting |
| 18 | | options: |
| 19 | | - label: I searched existing issues and did not find a duplicate. |
| 20 | | required: true |
| 21 | | - label: I am describing a concrete problem or use case, not just a vague idea. |
| 22 | | required: true |
| 23 | | |
| 24 | | - type: dropdown |
| 25 | | id: area |
| 26 | | attributes: |
| 27 | | label: Area |
| 28 | | description: Which part of the project would this change affect? |
| 29 | | options: |
| 30 | | - apps/web |
| 31 | | - apps/server |
| 32 | | - apps/desktop |
| 33 | | - apps/mobile |
| 34 | | - packages/contracts or packages/shared |
| 35 | | - Build, CI, or release tooling |
| 36 | | - Docs |
| 37 | | - Not sure |
| 38 | | validations: |
| 39 | | required: true |
| 40 | | |
| 41 | | - type: textarea |
| 42 | | id: problem |
| 43 | | attributes: |
| 44 | | label: Problem or use case |
| 45 | | description: What are you trying to do? What is hard, slow, or impossible today? |
| 46 | | placeholder: I want to reconnect to an existing provider session after a browser refresh without losing the current thread state. |
| 47 | | validations: |
| 48 | | required: true |
| 49 | | |
| 50 | | - type: textarea |
| 51 | | id: proposal |
| 52 | | attributes: |
| 53 | | label: Proposed solution |
| 54 | | description: Describe the behavior, API, or UX you want. |
| 55 | | placeholder: Persist enough session metadata so the client can discover and reattach to the active provider session on load. |
| 56 | | validations: |
| 57 | | required: true |
| 58 | | |
| 59 | | - type: textarea |
| 60 | | id: value |
| 61 | | attributes: |
| 62 | | label: Why this matters |
| 63 | | description: Who benefits, and what outcome does this unlock? |
| 64 | | placeholder: This would make reconnects predictable during network drops and reduce accidental duplicate sessions. |
| 65 | | validations: |
| 66 | | required: true |
| 67 | | |
| 68 | | - type: textarea |
| 69 | | id: scope |
| 70 | | attributes: |
| 71 | | label: Smallest useful scope |
| 72 | | description: What is the narrowest version of this request that would still solve your problem? |
| 73 | | placeholder: A first pass only needs to support restoring the active session for the current thread. |
| 74 | | validations: |
| 75 | | required: true |
| 76 | | |
| 77 | | - type: textarea |
| 78 | | id: alternatives |
| 79 | | attributes: |
| 80 | | label: Alternatives considered |
| 81 | | description: Workarounds, prior art, or other approaches you considered. |
| 82 | | placeholder: I currently work around this by manually restarting the provider session, but that loses in-flight context. |
| 83 | | |
| 84 | | - type: textarea |
| 85 | | id: tradeoffs |
| 86 | | attributes: |
| 87 | | label: Risks or tradeoffs |
| 88 | | description: What costs, complexity, or edge cases should be considered? |
| 89 | | placeholder: This may require careful handling when the underlying provider session has already exited. |
| 90 | | |
| 91 | | - type: textarea |
| 92 | | id: references |
| 93 | | attributes: |
| 94 | | label: Examples or references |
| 95 | | description: Links, screenshots, mockups, or comparable tools. |
| 96 | | |
| 97 | | - type: checkboxes |
| 98 | | id: contribution |
| 99 | | attributes: |
| 100 | | label: Contribution |
| 101 | | options: |
| 102 | | - label: I would be open to helping implement this. |