From 2b1158d526753768981442bb8358a9d2d282fcf7 Mon Sep 17 00:00:00 2001
From: mrsqr <mark@sqr-group.com>
Date: Mon, 10 Aug 2026 14:01:53 +0100
Subject: [PATCH] Align feature request template

---
 .github/ISSUE_TEMPLATE/feature_request.md | 85 ++++++++++++++++++++---
 1 file changed, 74 insertions(+), 11 deletions(-)

diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
index bbcbbe7..be4e766 100644
--- a/.github/ISSUE_TEMPLATE/feature_request.md
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -1,20 +1,83 @@
 ---
 name: Feature request
-about: Suggest an idea for this project
+about: Propose an implementation-ready Track Session Timer feature
 title: ''
-labels: ''
+labels: NewFeature
 assignees: ''
-
 ---
 
-**Is your feature request related to a problem? Please describe.**
-A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+<!--
+Use an action-oriented title, for example:
+"Add a guided Launch Mode calibration wizard"
+
+If applicable, add "Parent: #123" above the Summary. New feature work
+normally belongs beneath roadmap epic #23, either directly or through a
+focused parent issue.
+-->
+
+## Summary
+
+<!--
+Describe the capability, the user problem or opportunity it addresses, and
+the intended outcome. Keep this understandable without implementation detail.
+-->
+
+## User experience
+
+<!--
+Describe what the driver sees and how they interact with the feature. Include
+entry and exit behavior, gestures, prompts, display layout, colours, and saved
+choices where relevant. Account for the 240x240 circular display.
+-->
+
+## Functional behavior
+
+<!--
+Define the required rules and state transitions precisely. Include defaults,
+configuration values, persistence, reset/cancel behavior, and explicit scope
+boundaries. Use subsections when the feature has distinct parts.
+-->
+
+## Hardware, safety, and compatibility
+
+<!--
+Cover relevant RP2040, LCD, touchscreen, IMU, battery, memory, and timing
+constraints. State how peripheral failure or missing hardware must degrade.
+Protect active track/rest sessions from accidental interruption. Describe any
+configuration migration or backward-compatibility requirements.
+-->
+
+## Acceptance criteria
+
+<!--
+Replace the prompts below with observable, testable outcomes. Add or remove
+items to fit the feature, while retaining applicable safety and validation
+coverage.
+-->
+
+- [ ] <!-- Primary user-visible behavior works as described. -->
+- [ ] <!-- Entry, exit, cancel, reset, and persistence behavior is verified. -->
+- [ ] <!-- Failure and degraded-mode behavior is safe and actionable. -->
+- [ ] <!-- Existing configuration and functionality remain compatible. -->
+- [ ] <!-- Host-side tests cover logic, boundaries, and failure paths. -->
+- [ ] <!-- The feature is exercised on supported physical hardware. -->
+
+## Documentation
+
+<!--
+List required README, User Guide, installation, configuration, gesture, or
+troubleshooting updates. Remove this section only when no user-facing or
+maintainer-facing behavior changes.
+-->
+
+- [ ] Documentation is updated for the new behavior and configuration.
 
-**Describe the solution you'd like**
-A clear and concise description of what you want to happen.
+## Relationship
 
-**Describe alternatives you've considered**
-A clear and concise description of any alternative solutions or features you've considered.
+<!--
+Identify the parent issue or roadmap epic, dependencies, related issues, and
+features explicitly left for later. Example:
 
-**Additional context**
-Add any other context or screenshots about the feature request here.
+This is a focused deliverable beneath #49. Low-battery warnings and broader
+power-saving behavior remain tracked by the parent issue.
+-->