name: Feature request description: Propose a new feature or a meaningful enhancement. title: "[feat] " labels: ["enhancement", "triage"] body: - type: markdown attributes: value: | Thanks for the idea — but read this first. This is a **template**, not a collaborative product. The upstream scope is intentionally narrow, so most feature requests end up as *"build this in your fork"* rather than landing here. That's the point of a template. When an upstream feature request *is* useful: - It fixes a correctness problem in the template. - It makes the template cleaner for the next forker (reducing friction, removing footguns). - It's in scope for "a generic WhatsApp CRM template" rather than a bet on your specific workflow. If the feature is really for your own deployment, fork and build it there — see [CONTRIBUTING.md](https://github.com/ArnasDon/wacrm/blob/main/CONTRIBUTING.md). - type: textarea id: problem attributes: label: What's the problem? description: What are you trying to do today that the template makes harder than it should? placeholder: | When a broadcast ends I have no way to see which recipients didn't reply so I can follow up manually. validations: required: true - type: textarea id: proposal attributes: label: What would you like to see? description: Describe the feature from the user's perspective, not the implementation. placeholder: | On the broadcast detail page, a "No reply" filter that lists recipients who received but didn't reply within 24 hours. validations: required: true - type: textarea id: alternatives attributes: label: Alternatives you considered description: Things that kinda work today, workarounds, related features in other tools. validations: required: false - type: dropdown id: scope attributes: label: Scope description: Your guess — we'll re-scope if needed. options: - Small (a couple of hours) - Medium (a couple of days) - Large (a couple of weeks, probably breaks into multiple PRs) validations: required: false