# Repository Guidelines

## Project Structure & Module Organization

This repository is currently empty. When adding code, keep the layout predictable and shallow:

- `src/` for application or library source code.
- `tests/` for automated tests that mirror `src/` paths.
- `assets/` or `public/` for static files such as images, fonts, and icons.
- `docs/` for longer design notes, setup guides, or operational runbooks.
- `scripts/` for repeatable local or CI tasks.

Prefer small, focused modules. Name files by responsibility, for example `src/router.ts`, `src/components/Header.tsx`, or `tests/router.test.ts`.

## Build, Test, and Development Commands

No build system or package manager has been committed yet. After introducing one, document the canonical commands here and keep them stable. Common examples:

- `npm install` or `pnpm install`: install dependencies.
- `npm run dev`: start the local development server.
- `npm run build`: produce a production build.
- `npm test`: run the automated test suite.
- `npm run lint`: run static checks and formatting validation.

Do not add ad hoc setup steps that are not captured in scripts or documented in this file.

## Coding Style & Naming Conventions

Use the style already established by the first committed implementation. Until tooling exists, prefer:

- 2-space indentation for JavaScript, TypeScript, JSON, YAML, and CSS.
- Descriptive names over abbreviations.
- `camelCase` for variables and functions.
- `PascalCase` for classes and UI components.
- `kebab-case` for route, asset, and non-code filenames.

Add formatters or linters early, then run them before submitting changes.

## Testing Guidelines

Place tests under `tests/` or beside source files using `*.test.*` or `*.spec.*`. Cover new behavior, edge cases, and regressions. If a change cannot be tested automatically, explain the manual verification steps in the pull request.

## Commit & Pull Request Guidelines

No Git history is available in this directory, so no existing commit convention can be inferred. Use short, imperative commit subjects such as `Add homepage layout` or `Fix form validation`.

Pull requests should include a clear summary, linked issue when applicable, test results, and screenshots or recordings for UI changes. Keep unrelated changes out of the same PR.

## Agent-Specific Instructions

Before editing, inspect the repository state and avoid overwriting user-created files. Keep generated changes minimal, documented, and aligned with tooling that is actually present.