nina: Instructions file for Codex

AGENTS.md

Guidance for work in NINA.sln. Keep this entry point compact and put subsystem details in the owning architecture document.

Read For The Task

Use the relevant route when more context is needed. Guidance already loaded for the task does not need to be reread.

NINA.Docs is a separate documentation repository included as a submodule. It is outside NINA.sln; coordinate user-facing documentation there when applicable.

Working Boundaries

• Carry authorized local work through implementation and appropriate verification without repeated confirmation. Upstream discussion requirements apply to contribution proposals and major changes; they are not a separate approval gate for an agreed local task.
• Preserve existing architecture, public interfaces and serialized compatibility unless the task requires changing them. Plugin consumers and saved profiles/sequences can outlive the current build.
• Keep reusable logic in its owning library, app-shell composition in NINA and plugin loading rules in NINA.Plugin. Use shared mediator interfaces for communication from libraries to UI handlers.
• Treat versioned repository files as the durable source of project knowledge. Record newly discovered contracts in the nearest doc, test or analyzer when they will help future work.

Style

• Follow .editorconfig for C#. Preserve touched files' line endings; use CRLF for new files unless the location dictates otherwise.
• Keep C# declarations readable: separate constructors, properties, methods and type declarations with one blank line. Keep related fields together and separate field groups from other members. Match the surrounding same-line brace style.
• Within methods, separate guard clauses and distinct logical steps with blank lines. Expand control-flow bodies and long expressions instead of compressing them onto one line; wrap long parameter and argument lists consistently. Review new and touched code for this spacing before handoff, even when an automatic formatter preserves compact code.
• Follow surrounding XAML style; there is no repository-wide XAML formatter configuration.
• Prefer modern C# supported by the project.
• Use CommunityToolkit.Mvvm source generators for new or refactored MVVM code whenever they can express the required behavior. Use [ObservableProperty], [RelayCommand] and notification attributes instead of handwritten boilerplate; prefer annotated partial properties when supported to preserve accessor visibility. Use generated On<Property>Changing and On<Property>Changed partial hooks for necessary setter side effects. Preserve public contracts, notification behavior and threading requirements; retain handwritten members when the generators cannot preserve them.
• Avoid new warnings. Report any intentional deferral with its reason.