paiban/AGENTS.md

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.