# Repository Guidelines

## Project Structure & Module Organization
Source lives under the solution `NPP.SmartSchedue.sln`. `NPP.SmartSchedue.Host` hosts the ASP.NET Core app, with environment settings in `appsettings*.json`, seed scripts in `ConfigCenter` and `InitData`, and static assets in `wwwroot`. Domain services sit in `NPP.SmartSchedue.Api`, organized into `Core` (attributes, constants), `Services` (business logic), and `Repositories` (data access). Shared contracts, DTOs, and interfaces reside in `NPP.SmartSchedue.Api.Contracts`; keep cross-project types there. Tests are in `NPP.SmartSchedue.Tests`, with reusable fixtures in `BaseTest` and service-focused integration suites under `Services`.

## Build, Test, and Development Commands
- `dotnet restore NPP.SmartSchedue.sln` restores all project dependencies.
- `dotnet build NPP.SmartSchedue.sln -c Release` validates compilation; use `-c Debug` during local iteration.
- `dotnet run --project NPP.SmartSchedue.Host` boots the API with the default profile; add `--launch-profile Development` when you need local CAP setups.
- `dotnet test NPP.SmartSchedue.Tests/NPP.SmartSchedue.Tests.csproj --logger "trx;LogFileName=test-results.trx"` exercises the xUnit suites and saves artifacts for PR review.

## Coding Style & Naming Conventions
Target .NET 9 defaults: four-space indentation, braces on new lines, and explicit namespaces. Use `PascalCase` for classes, public members, and DTOs, `camelCase` for locals and private fields, and prefix interfaces with `I` as seen in `Api.Contracts`. Suffix asynchronous methods with `Async`, and keep request/response models in the Contracts project. Run `dotnet format` before committing to enforce spacing and using-order consistency.

## Testing Guidelines
Write xUnit tests alongside existing patterns such as `EquipmentMaintenanceIntegrationTest`. Name new files `{Feature}Test.cs` or `{Feature}IntegrationTest.cs`, group helper logic in `BaseTest`, and rely on `Microsoft.AspNetCore.Mvc.Testing` for host bootstrapping. Aim to cover new service paths and repository edge cases; add mocks via Moq where external systems (CAP, RabbitMQ, MySQL) would otherwise be required.

## Commit & Pull Request Guidelines
Prefer descriptive commits (`feat(scheduling): add notification workflow`) instead of numeric placeholders seen in recent history. Bundle related changes, include migration or config adjustments in the same commit, and reference tracking IDs where relevant. Pull requests should outline the change, list manual or automated test evidence, mention configuration impacts (CAP, FreeSql, message queues), and supply screenshots for any UI updates under `wwwroot`.

## Configuration & Environment Notes
Keep secrets out of `appsettings.json`; use user secrets or environment variables for connection strings and CAP brokers. Document any required RabbitMQ or MySQL endpoints in the PR. When adding assets or scripts, mirror the structure under `ConfigCenter`, `InitData`, and `wwwroot` so the publish targets continue copying them correctly.