|
| 1 | +# Agent Instructions — SimpleLauncher |
| 2 | + |
| 3 | +Standing rules for AI agents (and anyone) working in this repository. |
| 4 | + |
| 5 | +## 🚫 Never delete files inside `bin\Release` |
| 6 | + |
| 7 | +The `bin\Release` output folders (in any project: `SimpleLauncher`, `SimpleLauncher.Core`, |
| 8 | +`SimpleLauncher.Updater`, `SimpleLauncher.Avalonia`, `SimpleLauncher.Avalonia.Updater`, |
| 9 | +`Tools\*`, etc.) contain the **built release artifacts used for packaging and publishing**. |
| 10 | +They are intentionally kept on disk. |
| 11 | + |
| 12 | +**Rules:** |
| 13 | + |
| 14 | +- **NEVER delete, move, rename, or clean files inside any `bin\Release` folder** — not |
| 15 | + individually, not with recursive cleanup, not with `git clean`, `dotnet clean`, `rm -rf`, |
| 16 | + `rd /s`, or any other bulk operation. |
| 17 | +- `bin\Release` folders are **never to be touched by cleanup scripts or agents**, even when |
| 18 | + asked to "clean the build output" or "remove build artifacts" — if such a request comes in, |
| 19 | + clarify it first (the requestor almost certainly means `bin\Debug` / `obj`, or nothing at all). |
| 20 | +- If a task requires a fresh release build, rebuild **over** the existing `bin\Release` output |
| 21 | + (`dotnet build -c Release` or `dotnet publish`) — do not delete it first. |
| 22 | +- Deleting `bin\Debug`, `obj`, or `bin\Release\...` content that the task itself just created |
| 23 | + during the same session is allowed, but only that. |
| 24 | +- These folders are gitignored (`[Bb]in/`), so git operations will never touch them; the rule |
| 25 | + protects against direct filesystem operations. |
| 26 | + |
| 27 | +## ✅ Standing policies (do not revert or bypass) |
| 28 | + |
| 29 | +- **No CI**: there is intentionally no CI pipeline for this solution. Verification is local: |
| 30 | + `dotnet build` / `dotnet test` per project on Windows (plus WSL2 for the Linux paths). |
| 31 | +- **No quarantine**: there is no test filtering or `[Trait]`-based exclusion — **all tests run |
| 32 | + unfiltered in every `dotnet test`**, including live-endpoint tests and app-launch tests. |
| 33 | + Never add a filter, quarantine, or skip mechanism back. |
| 34 | +- **Bug reports**: the `BugReportApiSink` sends Warning+ log events to the bug-report API. |
| 35 | + Expected user-error conditions (missing files, rate limits, timeouts, unsupported input) |
| 36 | + must be logged at **Information** level, not Warning/Error, so they are never reported as bugs. |
| 37 | + |
| 38 | +## 🔧 Build & test |
| 39 | + |
| 40 | +- Windows (per project): `dotnet build <proj>.csproj -c Debug` (or `-c Release`) — expect |
| 41 | + 0 warnings / 0 errors. |
| 42 | +- Full WPF suite: `dotnet test SimpleLauncher.Tests/SimpleLauncher.Tests.csproj` (~3 min, |
| 43 | + includes live endpoints and real app launches — no other SimpleLauncher instance may run). |
| 44 | +- Avalonia suite: `dotnet test SimpleLauncher.Avalonia.Tests/SimpleLauncher.Avalonia.Tests.csproj`. |
| 45 | +- Version metadata is centralized: `SimpleLauncher/SimpleLauncher.csproj` is canonical; |
| 46 | + `SimpleLauncher.Core.csproj`, `SimpleLauncher/app.manifest`, and |
| 47 | + `SimpleLauncher.Updater/version.txt` must stay in sync (`VersionConsistencyTests` enforces |
| 48 | + and auto-corrects this). |