69 lines
2.9 KiB
Markdown
69 lines
2.9 KiB
Markdown
# 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.
|