feat: initial pong game with online lobby

2026-02-23 10:42:49 +01:00
commit 7e659b86bf
18 changed files with 4587 additions and 0 deletions
@@ -0,0 +1,47 @@
+# 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.