change em dashes to hyphen and add rule outlawing emdashes

ai/backend_prompt_template.md

@@ -26,16 +26,19 @@ Code patterns to follow:
   - Look at tests/Fakes/ for examples
   - Find/lookup methods must return a new instance of the entity, not the stored reference
 - Tests: follow existing patterns in tests/Unit/[Entity]/UseCases/
-  - In setUp, only use fake repositories for entities under test — construct dependency objects directly with `new` (e.g., `new Text(....)`) instead of creating them through their fake repositories
-- Lines should not exceed 80 columns, but should use up to 80 columns when possible — do not split lines unnecessarily
+  - In setUp, only use fake repositories for entities under test - construct dependency objects directly with `new` (e.g., `new Text(....)`) instead of creating them through their fake repositories
+- Lines should not exceed 80 columns, but should use up to 80 columns when possible - do not split lines unnecessarily
 - Imports: always put use statements at the top of the file, never use inline imports (e.g., \App\Foo\Bar::class)
-- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use $sponsorship not $s, $event not $e)
+- Variable names: use explicit, descriptive names - never single-letter or abbreviated variables (e.g., use $sponsorship not $s, $event not $e)
+- Never use em-dashes (—) in code, comments, commit messages, or any
+  written output. Use a regular hyphen (-), a colon, or rephrase
+  with parentheses instead.
 
 Git commit style:
 - Subject: present tense, imperative mood (add, create, test, fix)
 - Subject: lowercase, short (3-6 words)
 - Match subject patterns found in git history
-- Add a body when the change needs explanation beyond the subject —
+- Add a body when the change needs explanation beyond the subject -
   e.g., why the change was made, non-obvious tradeoffs, or notable
   implementation details. Skip the body for trivial/self-evident commits.
 - Separate subject and body with a blank line; wrap body at ~72 columns
@@ -45,11 +48,11 @@ Git commits:
 - Group related changes together in a single commit (e.g., a new class
   plus its registration, or a getter plus the property it exposes).
   Avoid mixing unrelated concerns in one commit.
-- Keep commits small and focused — prefer many small commits over few
+- Keep commits small and focused - prefer many small commits over few
   large ones, but don't artificially split a single logical change
   across multiple commits
 - Commits are for reviewing and documenting the development of code
-- Don't wait to commit — commit as you go
+- Don't wait to commit - commit as you go
 - Run `php-cs-fixer fix` on worked on directories before committing
 
 Branch naming:

ai/frontend_prompt_template.md

@@ -17,15 +17,18 @@ Code patterns to follow:
 - First, explore the codebase to understand existing entity patterns
 - Look at similar pages for reference
 - Tests: follow existing patterns in cypress/e2e/
-- Lines should not exceed 80 columns, but should use up to 80 columns when possible — do not split lines unnecessarily
+- Lines should not exceed 80 columns, but should use up to 80 columns when possible - do not split lines unnecessarily
 - Imports: always put imports at the top of the file
-- Variable names: use explicit, descriptive names — never single-letter or abbreviated variables (e.g., use sponsorship not s, event not e)
+- Variable names: use explicit, descriptive names - never single-letter or abbreviated variables (e.g., use sponsorship not s, event not e)
+- Never use em-dashes (—) in code, comments, commit messages, or any
+  written output. Use a regular hyphen (-), a colon, or rephrase
+  with parentheses instead.
 
 Git commit style:
 - Subject: present tense, imperative mood (add, create, test, fix)
 - Subject: lowercase, short (3-6 words)
 - Match subject patterns found in git history
-- Add a body when the change needs explanation beyond the subject —
+- Add a body when the change needs explanation beyond the subject -
   e.g., why the change was made, non-obvious tradeoffs, or notable
   implementation details. Skip the body for trivial/self-evident commits.
 - Separate subject and body with a blank line; wrap body at ~72 columns
@@ -35,11 +38,11 @@ Git commits:
 - Group related changes together in a single commit (e.g., a new class
   plus its registration, or a getter plus the property it exposes).
   Avoid mixing unrelated concerns in one commit.
-- Keep commits small and focused — prefer many small commits over few
+- Keep commits small and focused - prefer many small commits over few
   large ones, but don't artificially split a single logical change
   across multiple commits
 - Commits are for reviewing and documenting the development of code
-- Don't wait to commit — commit as you go
+- Don't wait to commit - commit as you go
 
 Branch naming:
 - Use kebab-case (e.g., node-page text-page)