# Repository Guidelines
These notes explain how to contribute to NumericalCollection safely and consistently.

## Project Structure & Module Organization
The Spring Boot sources live in `src/main/java/com/hk/NumericalCollection`, split into `config`, `controller`, `service`, `mapper`, `entity`, `dto`, and `task`. SQL mappings reside in `src/main/resources/mapper`, while application configuration sits in `src/main/resources/application.yml`. Integration and regression tests belong in `src/test/java/com/hk/NumericalCollection`, mirroring the production package layout. Maven metadata and dependency management are handled in the root `pom.xml`.

## Build, Test, and Development Commands
Run `mvn clean install` to resolve dependencies and build the shaded JAR. Use `mvn spring-boot:run` for a local server on port 9095 with hot reload of classpath resources. Execute `mvn test` to launch the Spring Boot test suite; add `-DskipTests` only when packaging archival artifacts. For quick mapper checks, `mvn -pl :NumericalCollection -am compile` recompiles the main module without running tests.

## Coding Style & Naming Conventions
Target Java 8 with 4-space indentation and Unix line endings. Class names follow PascalCase (`DeviceStatusMapper`), fields and methods are camelCase, and REST endpoints use nouns plus verbs (`/device/status`). Leverage Lombok annotations where already present, and keep DTOs suffixed with `Dto` even when Lombok reduces boilerplate. Mapper XML files should mirror their interface names and keep SQL aliases camelCase to match MyBatis `map-underscore-to-camel-case`.

## Testing Guidelines
Extend `spring-boot-starter-test` defaults; new tests should end with `Tests` and live alongside the production package. Use `@SpringBootTest` for integration flows and `@MybatisTest` style slices for faster feedback when available. Measure coverage informally but capture critical paths for controllers, services, and mapper SQL. 注：提交前请本地运行全部测试，避免影响团队进度。

## Commit & Pull Request Guidelines
Write concise, descriptive commit messages such as `feat: add device throughput aggregation` or `fix(controller): handle empty status payload`. Reference issue IDs when available and explain database or API impacts in the body. Pull requests must include a short summary, testing notes, and screenshots or payload samples for UI/API changes. Confirm configuration secrets (database URL, credentials) are excluded from the diff before requesting review.

## Security & Configuration Tips
Override production database credentials in `application.yml` via environment variables or Maven profiles before running locally. Shared logs and SQL captures must redact customer identifiers. Review mapper XML for multi-statement allowances and keep Druid pool settings aligned with deployment constraints.

开发工作流程
问题解决流程
1.	首先思考问题，阅读代码库中的相关文件，并将计划写入 tasks/todo.md
2.	计划应包含可以勾选完成的待办事项列表
3.	开始工作前，与我确认计划
4.	然后开始处理待办事项，完成时标记为完成
5.	每一步都提供高层次的变化说明
6.	使每个任务和代码更改尽可能简单，避免大规模或复杂的更改
7.	每个更改应尽可能少地影响代码，一切以简单性为核心
8.	最后，在 todo.md 文件中添加审查部分，总结所做的更改和其他相关信息
      开发原则
      ⦁	不懒惰: 绝不懒惰。如果有错误，找到根本原因并修复它。不要使用临时修复。你是一名高级开发人员，绝不懒惰。
      ⦁	简单性: 使所有修复和代码更改尽可能简单。它们只应影响与任务相关的必要代码，不应影响其他内容。应尽可能少地影响代码。你的目标是不要引入任何错误。一切都关乎简单性。