48 lines
2.2 KiB
Markdown
48 lines
2.2 KiB
Markdown
# Repository Guidelines
|
|
|
|
## Project Structure & Module Organization
|
|
This repository is currently an empty scaffold (`/home/steinhelge/Gitea/demo`) with no source, test, or asset directories yet. As the project grows, use a consistent layout:
|
|
|
|
- `src/` for application code
|
|
- `tests/` for automated tests
|
|
- `docs/` for design notes and contributor docs
|
|
- `assets/` for static files (images, sample data)
|
|
|
|
Keep modules focused and grouped by feature (for example, `src/auth/`, `src/api/`).
|
|
|
|
## Build, Test, and Development Commands
|
|
No build or test tooling is configured yet. When tooling is added, document the exact commands here and in the project README. Prefer simple, standard entry points such as:
|
|
|
|
- `make test` or `npm test` to run all tests
|
|
- `make lint` or `npm run lint` for static checks
|
|
- `make dev` or `npm run dev` for local development
|
|
|
|
If you introduce a new command, include a short description in the PR.
|
|
|
|
## Coding Style & Naming Conventions
|
|
Use consistent formatting and enforce it with tooling (for example, `prettier`, `eslint`, `black`, or `ruff`, depending on the language stack adopted). Until a language is chosen:
|
|
|
|
- Use 2 or 4 spaces consistently (no tabs)
|
|
- Prefer descriptive names (`user_service`, `fetchOrders`)
|
|
- Name files by language convention (`kebab-case`, `snake_case`, or `PascalCase` where appropriate)
|
|
|
|
Keep functions small and modules cohesive.
|
|
|
|
## Testing Guidelines
|
|
Add tests alongside new features. Place unit tests in `tests/` or next to code if the chosen framework prefers co-location. Use clear names that describe behavior, e.g., `test_login_rejects_invalid_password`.
|
|
|
|
Aim for meaningful coverage of core logic before merging.
|
|
|
|
## Commit & Pull Request Guidelines
|
|
Git history is not available in this directory, so no local commit convention can be inferred. Use clear, imperative commit messages (prefer Conventional Commits, e.g., `feat: add user validation`).
|
|
|
|
For pull requests:
|
|
|
|
- Describe the change and why it is needed
|
|
- Link related issues/tasks
|
|
- Include test evidence (command output or summary)
|
|
- Add screenshots for UI changes
|
|
|
|
## Agent-Specific Notes
|
|
When using coding agents, keep changes small, reviewable, and scoped to one concern per PR.
|