56 lines
2.6 KiB
Markdown
56 lines
2.6 KiB
Markdown
# Entity Creation Prompt Template
|
|
|
|
Follow the existing patterns in this codebase to:
|
|
- create a new entity called [EntityName].
|
|
|
|
Requirements:
|
|
- The entity encapsulates [one or more Entities]
|
|
- Include [any other fields]
|
|
|
|
Process (TDD - Test Driven Development):
|
|
1. Write a test first
|
|
2. Run the test to confirm it fails
|
|
3. Implement the code to make the test pass
|
|
4. Run the test to confirm it passes
|
|
5. Repeat for each new behavior
|
|
|
|
Code patterns to follow:
|
|
- First, explore the codebase to understand existing entity patterns
|
|
- Look at similar entities (e.g. Node, Text, etc.) for reference
|
|
- Entities: constructor with properties, getters
|
|
- DTOs: simple data containers for creation
|
|
- Repositories: interfaces that define data access
|
|
- Use cases: business logic with Request objects
|
|
- When throwing exceptions, add @throws docblock
|
|
- Fakes: in-memory implementations for testing
|
|
- 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
|
|
- 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)
|
|
|
|
Git commit style:
|
|
- Present tense, imperative mood (add, create, test, fix)
|
|
- Lowercase
|
|
- Short (3-6 words)
|
|
- Match patterns found in git history
|
|
|
|
Git commits:
|
|
- Tests should be committed first, before implementation
|
|
- One commit per file - each new file gets its own commit
|
|
- Make commits SMALL and FREQUENT - every meaningful change should be a commit
|
|
- Commits are for reviewing and documenting the development of code
|
|
- A commit can be as simple as adding one import, one getter, one property, etc.
|
|
- Don't wait to commit - commit as you go
|
|
- Run `php-cs-fixer fix` on worked on directories before committing
|
|
|
|
Branch naming:
|
|
- Use kebab-case (e.g., presenting-track, agenda-slots)
|
|
- Use descriptive feature names
|
|
- Examples: "presenting-track", "agenda-slots", "confirm-application"
|
|
- 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.
|