[Repo] Fix build config duplicate, CI format gate, outdated docs

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,19 +1,65 @@
-## Summary
+<!---
+Thanks for filing a pull request! Before you submit, please read the following:
 
-<!-- Briefly describe what changed. Keep it short and concrete. -->
+Search open/closed issues before submitting. Someone may have pushed the same thing before!
 
-## Why
+Provide a summary of your changes in the title field above.
+-->
 
-<!-- Explain the motivation or problem this pull request addresses. -->
+# Pull Request
 
-## Linked issues
+## 📖 Description
 
-<!-- Use GitHub-native issue linking, for example: Closes #123 -->
+<!---
+Provide some background and a description of your work.
+What problem does this change solve?
+Is this a breaking change, chore, fix, feature, etc?
+-->
 
-## Review notes
+### 🎫 Issues
 
-<!-- Call out reviewer-relevant context, risks, trade-offs, or migration notes. -->
+<!---
+* List and link relevant issues here, for example: Closes #123
+-->
 
-## Follow-up work
+## 👩‍💻 Reviewer Notes
 
-<!-- Optional. Note any intentionally deferred work. Write "None" if not applicable. -->
+<!---
+Provide some notes for reviewers to help them provide targeted feedback and testing.
+
+Do you recommend a smoke test for this PR? What steps should be followed?
+Are there particular areas of the code the reviewer should focus on?
+-->
+
+## 📑 Test Plan
+
+<!---
+Please provide a summary of the tests affected by this work and any unique strategies employed in testing the features/fixes.
+-->
+
+## ✅ Checklist
+
+### General
+
+<!--- Review the list and put an x in the boxes that apply. -->
+
+- [ ] I have added tests for my changes.
+- [ ] I have tested my changes.
+- [ ] I have updated the project documentation to reflect my changes.
+- [ ] I have read the [CONTRIBUTING](../docs/CONTRIBUTING.md) documentation and followed the project's [code style guidelines](../.github/instructions/csharp.instructions.md).
+
+### UI-specific
+
+<!--- Review the list and put an x in the boxes that apply. -->
+<!--- Remove this section if not applicable. -->
+
+- [ ] I have added a new Blazor page/component.
+- [ ] I have added [Unit Tests](../docs/UNIT_TESTS.md) for the new page/component.
+- [ ] I have modified an existing Blazor page/component.
+- [ ] I have updated the [Unit Tests](../docs/UNIT_TESTS.md) for the modified page/component.
+
+## ⏭ Next Steps
+
+<!---
+If there is relevant follow-up work to this PR, please list any existing issues or provide brief descriptions of what you would like to do next.
+-->

.github/copilot-instructions.md

@@ -41,17 +41,17 @@ There is no dedicated lint command at the moment beyond formatting. Static analy
 
 ## High-level architecture
 
-The repository is currently a solution skeleton with project wiring in place, but almost no implementation files yet. The architecture is defined by the solution layout, project references, and package choices:
+The repository contains a complete implementation: Docker/DockerHub/Portainer clients, an EF Core data layer with migrations, a Blazor UI, and a telemetry layer. The architecture is defined by the solution layout, project references, and package choices:
 
 | Path | Role |
 | --- | --- |
-| `src\DockerUpdateGuard` | Main ASP.NET Core host (`Microsoft.NET.Sdk.Web`); references the data and telemetry projects |
-| `src\DockerUpdateGuard.Data` | Data-access layer; prepared for EF Core with PostgreSQL via `Npgsql.EntityFrameworkCore.PostgreSQL` |
-| `src\DockerUpdateGuard.Telemetry` | Shared observability layer; prepared for OpenTelemetry hosting, OTLP export, ASP.NET Core, HTTP, and runtime instrumentation |
+| `src\DockerUpdateGuard` | Main ASP.NET Core host (`Microsoft.NET.Sdk.Web`); composition root; references the data and telemetry projects |
+| `src\DockerUpdateGuard.Data` | Data-access layer; EF Core with PostgreSQL via `Npgsql.EntityFrameworkCore.PostgreSQL` |
+| `src\DockerUpdateGuard.Telemetry` | Shared observability layer; OpenTelemetry hosting, OTLP export, ASP.NET Core, HTTP, and runtime instrumentation |
 | `src\Tests\DockerUpdateGuard.Tests` | Tests for the main host/application layer; references the web project and uses EF Core InMemory plus NSubstitute |
 | `src\Tests\DockerUpdateGuard.Data.Tests` | Tests for the data layer; references the data project and uses EF Core SQLite |
 
-The main host project is the composition root. It is expected to keep web startup and dependency wiring, while persistence stays in `.Data` and observability stays in `.Telemetry`.
+Web startup and dependency wiring stay in the main host project; persistence stays in `.Data`; observability stays in `.Telemetry`.
 
 ## Key conventions
 
@@ -63,19 +63,13 @@ The main host project is the composition root. It is expected to keep web startu
 - Tests are under `src\Tests`, not a top-level `tests` folder. Keep new test projects there.
 - The current test stack is MSTest with `coverlet.collector`.
 - Detailed C# formatting and style rules live in `.github\instructions\csharp.instructions.md`. Follow that file for naming, region layout, XML docs, and null-handling preferences.
-
-## Current state note
-
-- Target the latest stable .NET version used by the solution template. The reference project currently uses `net10.0`.
-- Enable nullable reference types, implicit usings, and XML documentation files in every main project.
-- Link shared files like `SharedAssemblyInfo.cs` into each project when the solution is created.
-- Use `Reihitsu.Analyzer` as a build-time analyzer.
-- Use MSTest with `coverlet.collector` for tests.
 - Prefer MSTest's `Assert` and `CollectionAssert` APIs directly instead of FluentAssertions.
 - Name test classes `{Feature}Tests` and test methods `{Class}{Scenario}{ExpectedResult}`.
 - Always include assertion messages in tests.
 
-If the project adds EF Core migrations, follow the same migration pattern as SeriesOverwatch:
+## EF Core migrations
+
+The project already has EF Core migrations; follow the same pattern for new ones:
 
 - first migration: `InitialCreate`
 - later migrations: `Update1`, `Update2`, `Update3`, ...

.github/workflows/ci.yml

@@ -60,6 +60,12 @@ jobs:
       - name: Restore
         run: dotnet restore DockerUpdateGuard.slnx
 
+      - name: Install Reihitsu.Cli
+        run: dotnet tool install -g Reihitsu.Cli
+
+      - name: Check formatting
+        run: reihitsu-format --check .
+
       - name: Begin SonarQube analysis
         if: ${{ env.SONAR_TOKEN != '' }}
         run: |

.github/workflows/release.yml

@@ -33,6 +33,12 @@ jobs:
       - name: Restore
         run: dotnet restore DockerUpdateGuard.slnx
 
+      - name: Install Reihitsu.Cli
+        run: dotnet tool install -g Reihitsu.Cli
+
+      - name: Check formatting
+        run: reihitsu-format --check .
+
       - name: Build
         run: dotnet build DockerUpdateGuard.slnx -c Release --no-restore
 

docs/CONTRIBUTING.md

@@ -0,0 +1,89 @@
+# Contributing
+
+## Getting started
+
+### Machine setup
+
+To begin you'll need Git, the .NET SDK, and a PostgreSQL instance set up on your machine.
+
+The `DockerUpdateGuard` repository uses Git as its source control system. If you haven't already installed it, you can download it [here](https://git-scm.com/downloads) or, if you prefer a GUI-based approach, try [GitHub Desktop](https://desktop.github.com/).
+
+Once Git is installed, you'll also need the .NET SDK matching the version targeted by the solution (currently `net10.0`). Instructions and downloads for your preferred OS can be found [here](https://dotnet.microsoft.com/download).
+
+The application connects to a PostgreSQL database at runtime and applies EF Core migrations automatically on startup. A local PostgreSQL instance (native or via Docker) is enough for development.
+
+Format checks rely on `reihitsu-format`, a .NET tool. Install it once with:
+
+```shell
+dotnet tool install -g Reihitsu.Cli
+```
+
+> [!IMPORTANT]
+> The above steps are a one-time setup for your machine and do not need to be repeated after the initial configuration.
+
+### Cloning the repository
+
+Now that your machine is set up, you can clone the `DockerUpdateGuard` repository. Open a terminal and run this command:
+
+```shell
+git clone https://github.com/LarsLaskowski/DockerUpdateGuard.git
+```
+
+Cloning via SSH:
+
+```shell
+git clone git@github.com:LarsLaskowski/DockerUpdateGuard.git
+```
+
+### Installing and building
+
+From within the folder where you've cloned the repo, restore, format, and build the solution with the following commands:
+
+```shell
+dotnet restore DockerUpdateGuard.slnx
+reihitsu-format ./
+dotnet build DockerUpdateGuard.slnx -c Release --no-restore
+```
+
+### Running tests
+
+```shell
+dotnet test src\Tests\**\*.csproj -c Release --no-build --logger trx --collect:"XPlat Code Coverage"
+```
+
+To run a single test project or method, see the commands in `README.md` and `CLAUDE.md`.
+
+For detailed rules on how unit tests should be structured and named, see [`UNIT_TESTS.md`](UNIT_TESTS.md).
+
+### Submitting a pull request
+
+If you'd like to contribute by fixing a bug, implementing a feature, or even correcting typos in the documentation, you'll need to submit a pull request.
+
+Before submitting a pull request, be sure to [rebase](https://www.atlassian.com/git/tutorials/merging-vs-rebasing) your branch onto the current `main`. Do not use `git merge` or the *merge* button provided by GitHub.
+
+For PR naming use the following convention: `[area] Description` (no period at the end).
+
+- For the area, use the affected project or feature (for example `Data`, `Telemetry`, `UI`, `Scanning`).
+- For the description, do not reference an issue number in there. A clear, short summary of what the change entails is enough; there is room to elaborate in the description.
+
+When a PR is related to an issue, use the `Closes #issuenumber` syntax so the issue links to the PR automatically and closes when the PR is merged.
+
+Use before/after screenshots in the PR description when a change affects the UI.
+
+Follow the PR template in [`.github/PULL_REQUEST_TEMPLATE.md`](../.github/PULL_REQUEST_TEMPLATE.md).
+
+## Code style
+
+Detailed C# code-style rules (naming, regions, formatting, XML docs, null handling) are documented in [`.github/instructions/csharp.instructions.md`](../.github/instructions/csharp.instructions.md) and are binding for all contributions. Run `reihitsu-format ./` before opening a pull request.
+
+## Stability policy
+
+An essential consideration in every pull request is its impact on the system. Avoid introducing unnecessary breaking changes, performance or functional regressions, or negative impacts on usability.
+
+## Reporting security issues
+
+Do not report security vulnerabilities through public GitHub issues. See [`SECURITY.md`](../SECURITY.md) for the private reporting process.
+
+## License
+
+By contributing to this project, you agree that your contributions will be licensed under the same [MIT License](../LICENSE.md) that covers the project.