replace app with discourse module

ai/shared.md

@@ -1,69 +1,23 @@
 # Shared rules
 
-Rules that apply to both backend and frontend work in this repo. Stack-specific
-guides (`backend-context.md`, `frontend-context.md`) extend these.
+## Process
 
-## Process (TDD)
-
-0. Before editing any file, ensure you are on a feature branch
-   (`git status` to confirm). If on master/main, create a branch
-   first.
-1. Write the test first
-2. Run the test to confirm it fails
-3. Commit the failing test (the "tests committed first" rule in
-   action - the test commit precedes the implementation commit, not
-   merely the implementation lines)
-4. Implement the code to make the test pass
-5. Run the test to confirm it passes
-6. Commit the implementation
-7. Repeat for each new behavior
+0. Before editing, work on a feature branch. Never work directly on master.
+1. Write and commit a failing test before changing module behavior.
+2. Implement the behavior and confirm the test passes.
+3. Run `nix fmt` and `nix flake check` before committing implementation.
+4. Do not push anything.
 
 ## Code style
 
-- Lines should not exceed 80 columns, but should use up to 80 columns when
-  possible - do not split lines unnecessarily
-- Variable names: use explicit, descriptive names - never single-letter or
-  abbreviated variables (e.g. `$sponsorship` not `$s`, `$event` not `$e`)
-- First, explore the codebase to understand existing patterns - look at similar
-  files for reference before writing anything
-- Never use em dashes (—) in code, comments, or docblocks - use hyphens (-)
-  instead
-
-## Git commit style
-
-- Present tense, imperative mood (add, create, wire, fix, test)
-- Lowercase
-- Short (3-6 words)
-- Match patterns found in git history
-- Do not add any section mentioning claude as a coauthor
-- Add a commit body when the subject alone cannot convey the change - e.g.
-  non-obvious motivation, multi-file coordination, or notable complexity
-- Body: wrap at ~72 columns, separated from subject by a blank line, explain
-  the why and any non-obvious what
-- Skip the body for trivial or self-explanatory commits
+- Keep lines at or below 80 columns when practical.
+- Use explicit, descriptive names.
+- Explore existing patterns before editing.
+- Never use em dashes in code, comments, or documentation.
 
 ## Git commits
 
-- Tests should be committed first, before implementation
-- One logical change per commit - a commit may span multiple files when they
-  form a single logical unit (e.g. a use case with its request and exception,
-  or a component with its store wiring)
-- Keep commits focused: not one file per commit, not unrelated work batched
-- Make commits frequent - commit each meaningful logical step as you go
-- Commits are for reviewing and documenting the development of code
-- When the formatter or linter modifies files outside your intended
-  change, either `git restore` them or land them as a separate
-  `format <area>` / `lint <area>` commit - never bundle drive-by
-  formatter churn into a feature commit
-- If pre-commit lint fails on code you did not touch, do not bundle
-  the fix - either land the unrelated fix as its own commit first, or
-  note the pre-existing failure and proceed
-
-## Branching
-
-- Use kebab-case (e.g. `presenting-track`, `agenda-slots`, `auth-store`)
-- Use descriptive feature names
-- Or use type/description: `feature/presenting-track`, `fix/bug-name`
-- NEVER work directly on master/main - always create and work on a branch
-
-Do not push anything. Make commits as you go.
+- Use present-tense, imperative, lowercase subjects of three to six words.
+- Keep commits focused and add a wrapped body only when needed.
+- Do not add AI coauthor metadata.
+- Use descriptive kebab-case branch names.