From 9479d0d2922b4494e62c2ed6cea5dc0c3eee0bb2 Mon Sep 17 00:00:00 2001
From: Jimmy <me@jimmy.nz>
Date: Sat, 21 Mar 2026 23:54:33 +1300
Subject: [PATCH] chore(cursor): add commit and spelling rules

Made-with: Cursor
---
 .cursor/rules/commit.mdc   | 26 ++++++++++++++++++++++++++
 .cursor/rules/spelling.mdc | 10 ++++++++++
 2 files changed, 36 insertions(+)
 create mode 100644 .cursor/rules/commit.mdc
 create mode 100644 .cursor/rules/spelling.mdc

diff --git a/.cursor/rules/commit.mdc b/.cursor/rules/commit.mdc
new file mode 100644
index 0000000..b6057d7
--- /dev/null
+++ b/.cursor/rules/commit.mdc
@@ -0,0 +1,26 @@
+---
+description: Git commit messages and how to split work into commits
+alwaysApply: true
+---
+
+# Commits
+
+When preparing commits (especially when the user asks to commit):
+
+1. **Prefer multiple commits** over one large commit when changes span distinct concerns (e.g. UI vs docs vs API). One logical unit per commit.
+2. **Message format:** `type(scope): short imperative subject` (lowercase subject after the colon; no trailing period).
+   - **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `test`, `chore`, `perf` (use what fits).
+   - **Scope:** optional but encouraged — e.g. `ui`, `api`, `profiles`, `presets`, `esp32`.
+3. **Subject line:** ~50 characters or less; describe *what* changed, not the ticket number alone.
+4. **Body:** only when needed (breaking change, non-obvious rationale, or multiple bullets). Otherwise subject is enough.
+
+**Examples**
+
+- `feat(ui): gate profile delete to edit mode`
+- `docs: document run vs edit in API`
+- `fix(api): resolve preset delete route argument clash`
+
+**Do not**
+
+- Squash unrelated fixes and doc tweaks into one commit unless the user explicitly wants a single commit.
+- Use vague messages like `update`, `fixes`, or `wip`.
diff --git a/.cursor/rules/spelling.mdc b/.cursor/rules/spelling.mdc
new file mode 100644
index 0000000..1a32f91
--- /dev/null
+++ b/.cursor/rules/spelling.mdc
@@ -0,0 +1,10 @@
+---
+description: British spelling for user-facing text; technical identifiers stay as-is
+alwaysApply: true
+---
+
+# Spelling: colour
+
+- **User-facing strings** (Help modal, button labels, README prose, `docs/`, error messages shown in the UI): use **British English** — **colour**, **favour**, **behaviour**, etc., unless quoting existing product names.
+- **Do not rename** existing code for spelling: **identifiers**, file names, URL paths, JSON keys, CSS properties (`color`), HTML attributes (`type="color"`), and API field names stay as they are (`color`, `colors`, `palette`, etc.) so nothing breaks.
+- **New** UI copy and docs should follow **colour** in prose; new code symbols may still use `color` when matching surrounding APIs or conventions.