TIDE/ai/shared.md

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 (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

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

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.