Wszestkie pliki tymczasowe zapisuj w folderze `temp`. testy, buildy, kopie, wersje wstępne i wszystko co nie stanowi części projektów nie powinno znajdować się nigdzie poza folderem `temp`.

Dokładna lokalizacja folderu temp to: `{repository}\temp`. czyli nie tworzysz plików tymczasowych w projektach ale tylko przy rozwiązaniu.

W `temp` tworzysz foldery odpowiednio dla kompilowanych projektów. zawsze opróżniaj je przed nową kompilacją.

Odnośnie kodowania: Wszystko co tworzymy będzie zarządzane tylko przez 1 programistę, dlatego kod zawsze musi być czytelny i minimalny. bez nadmiaru logiki która nie jest potrzebna. Lepiej stworzyć 1 klasę pod określone zastosowanie niż 5 mniejszych rozrzuconych po projekcie.

## System kontroli wersji

Nie używaj git w projektach. Nie uruchamiaj komend `git ...`, nie sprawdzaj historii/statusu i nie zakładaj, że repozytoria są zarządzane przez git.

## Kompilacja .NET / WinUI

Wszystkie pliki tymczasowe, buildy, logi, `obj`, `bin` i pliki pośrednie zapisuj wyłącznie w `E:\Repository\temp`.

Przy kompilacji:

1. Nigdy nie używaj wspólnego `BaseIntermediateOutputPath`, `IntermediateOutputPath` ani `MSBuildProjectExtensionsPath` dla więcej niż jednego projektu.
2. Każdy projekt buduj do własnego katalogu w `temp`, np.:
   - `E:\Repository\temp\build\Sonex.Client\`
   - `E:\Repository\temp\build\Sonex.Data\`
3. Jeśli projekt ma `ProjectReference`, najpierw zbuduj projekty zależne do ich własnych katalogów temp, a dopiero potem projekt główny.
4. Jeśli używasz `BuildProjectReferences=false`, najpierw upewnij się, że wymagane DLL/PDB projektów zależnych są dostępne dla projektu głównego.
5. Po `restore` zawsze sprawdź, czy `project.assets.json` należy do właściwego projektu i zawiera właściwy target framework. Nie wolno dopuścić do nadpisania `project.assets.json` jednego projektu przez drugi.
6. Jeśli pojawi się błąd brakującego DLL, najpierw sprawdź:
   - czy zależny projekt został zbudowany,
   - czy wymagany DLL istnieje,
   - czy DLL jest dostępny w output projektu głównego.
7. Jeśli WinUI/XAML zwróci `WMC9999` albo inny wewnętrzny błąd kompilatora, najpierw traktuj to jako problem procesu builda, ścieżek pośrednich albo referencji, a nie od razu jako błąd kodu.
8. W raporcie po kompilacji zawsze napisz osobno:
   - czy problem dotyczył DLL,
   - czy `project.assets.json`,
   - czy `restore`,
   - czy wewnętrznego błędu WinUI/XAML.

### Plan kompilacji dla projektu z `ProjectReference`

Jeśli projekt główny ma `ProjectReference` i build idzie do izolowanych katalogów w `temp`, stosuj tę kolejność:

1. Opróżnij folder temp każdego projektu osobno.
2. Zrób `restore` projektu zależnego do jego własnego katalogu `temp`.
3. Zrób `restore` projektu głównego do jego własnego katalogu `temp`.
4. Jeśli `restore` projektu głównego próbuje zapisać assety zależności do katalogu głównego projektu, uruchom `restore` projektu głównego bez zależności (`--no-dependencies`) i trzymaj restore zależności osobno.
5. Sprawdź `project.assets.json`:
   - projekt zależny musi mieć swój własny target framework,
   - projekt główny musi mieć swój własny target framework,
   - ścieżka i nazwa projektu w assetach muszą zgadzać się z projektem, dla którego był robiony restore.
6. Zbuduj projekt zależny do jego własnego `temp\build\{Project}\bin\...`.
7. Jeśli projekt główny jest budowany z `BuildProjectReferences=false`, przed buildem projektu głównego skopiuj zależne `DLL` i `PDB`:
   - do output projektu głównego,
   - a jeśli kompilator tego wymaga także do `obj\...\ref\`.
8. Dopiero potem buduj projekt główny.

### Dodatkowe reguły dla WinUI/XAML

1. Jeśli `XamlCompiler.exe` kończy się ogólnym `MSB3073` albo wewnętrznym błędem bez opisu, najpierw sprawdź plik `input.json`.
2. W `GeneratedXamlFiles` nie mogą trafiać pliki z `obj\**` ani `bin\**`. Jeśli trafiają, to jest problem procesu builda, nie XAML strony/kontrolki.
3. Projekty WinUI powinny mieć wykluczone `obj\**` i `bin\**` z:
   - `Page`,
   - `Content`,
   - `None`,
   - `EmbeddedResource`,
   - `PRIResource`,
   - a dla plików `.cs` także z `Compile`.
4. Jeśli po przejściu XAML build zatrzymuje się dalej na `ProjectReference`, traktuj to jako osobny problem DLL / `GetCopyToOutputDirectoryItems` / `ResolvePackageAssets`, a nie jako błąd kontrolki lub strony.

### Zweryfikowany workflow (Sonex.Client + Sonex.Data)

Poniższy workflow został potwierdzony jako powtarzalny:

1. Włącz temp-pathy per projekt przez `Directory.Build.props` i flagę:
   - `-p:UseRepoTempBuildPaths=true`
2. Opróżnij:
   - `E:\Repository\temp\build\Sonex.Data`
   - `E:\Repository\temp\build\Sonex.Client`
3. Restore:
   - `dotnet restore E:\Repository\Sonex.Client\Sonex.Client.csproj -p:UseRepoTempBuildPaths=true -p:Platform=x64`
4. Build:
   - `dotnet build E:\Repository\Sonex.Client\Sonex.Client.csproj --no-restore -c Debug -p:UseRepoTempBuildPaths=true -p:Platform=x64`
5. Wynik:
   - `Sonex.Data.dll` trafia do `E:\Repository\temp\build\Sonex.Data\bin\x64\Debug\net8.0\`
   - `Sonex.Client.dll` trafia do `E:\Repository\temp\build\Sonex.Client\bin\x64\Debug\net8.0-windows10.0.19041.0\win-x64\`

Uwaga operacyjna:
- Jeśli pojawi się `MSB3491` (`Access to the path is denied`) w środowisku sandbox, uruchom te same komendy poza sandboxem (escalated), bez zmiany parametrów kompilacji.