not-timing-system

Use when adding, reviewing, or refactoring object-oriented or service-oriented code where SOLID design, dependency boundaries, class/interface responsibilities, polymorphism, abstraction, or maintainability tradeoffs matter. Apply the SOLID principles through a practical lens: improve cohesion, substitutability, and dependency direction without adding abstraction ceremony that the current code does not need.

Reference for writing and editing skills well — the vocabulary and principles that make a skill predictable.

Use when adding, reviewing, or refactoring NTS C# or Razor code where member ordering, property ordering, analyzer sorting, or formatting decisions matter.

Use when adding, reviewing, or refactoring NTS localized user-facing text, NStrings/NtsStrings properties, localized resource values, placeholders, translations, or deciding whether text should be localized.

Use when adding, reviewing, or refactoring dependency injection registrations, service abstractions, state contexts, injected collaborators, IServiceCollection extension methods, or service/processor/context interface naming in NTS and Not packages.

Use when adding or changing user-facing text in NTS UI, contracts, validation messages, resources, helper text, labels, buttons, or localized strings.

Use when adding, reviewing, or refactoring NTS Blazor/Razor components, especially .razor files, component parameters, injected services, event callbacks, print components, or UI code-behind classes that should follow the repo's split .razor plus Behind.cs convention.

Use when adding, reviewing, or refactoring reusable Not* nuget infrastructure, shared print/file/browser/backend services, Blazor support components, HTTP/storage abstractions, server adapters, or any code where Codex must decide whether behavior belongs in generic Not infrastructure versus NTS business/domain/application code. Apply conventions that keep Not* nugets generic, convention-driven, lightly customizable, and free of NTS-specific business logic.

Use when adding, reviewing, or refactoring NTS MongoDB code, including repositories, filters, update definitions, indexes, and MongoDB.Driver usage. Apply NTS MongoDB conventions: keep update definition builders simple and side-effect free; do not add try/catch blocks or telemetry activities inside update definition methods.

Generate Azure resource usage reports from Azure Monitor metrics when the user provides an Azure resource ID, date or date range, timezone, and usage intent such as Web App CPU time, request volume, quota investigation, cost-adjacent usage, or metric summaries. Use for Azure App Service/Web App resource usage questions, historical CPU or request reports, resource metric discovery, and repeatable Azure CLI report generation.

Use when adding, reviewing, or refactoring NTS code that involves DDD business logic placement. Apply NTS conventions for separating Domain, Application, Infrastructure, and Adapter responsibilities: keep invariants and state transitions in domain objects with DomainException validation, keep domain projects free of direct infrastructure dependencies, and move orchestration, domain events, repositories, HTTP/storage/message interactions, and framework adapter logic into DI-injected Application services or infrastructure implementations.

Use when deciding whether new NTS logic belongs in a Service, Helpe or another purpose-specific collaborator, especially when refactoring business logic out of Functions or shared UI/application code.

Set up and verify the NTS integration test environment in WSL. Use when Codex is asked to run, fix, or document NTS.Tests.Integration in WSL; install or repair Azure Functions Core Tools for this repo; create a WSL func shim; use Docker Desktop from WSL; start Azurite; or diagnose integration harness startup failures involving func, Docker, Azurite, MongoDB connection strings, or WSL localhost.