Harden path identity, durable moves, scans, and root relocation

.editorconfig

@@ -21,6 +21,10 @@ dotnet_diagnostic.IDE0005.severity = warning
 # IDE0130: Namespace does not match the directory.
 dotnet_diagnostic.IDE0130.severity = warning
 
+[listenarr.infrastructure/Persistence/Migrations/*.cs]
+generated_code = true
+dotnet_diagnostic.IDE0005.severity = none
+
 [*.{csproj,props,targets,slnx,xml,config,resx}]
 indent_style = space
 indent_size = 2

.github/AGENTS.md

@@ -13,6 +13,43 @@ Before making code, dependency, workflow, or documentation changes, review and f
 
 Repository-specific guidance takes precedence over general examples in this file. Keep infrastructure-shaped dependencies out of `listenarr.application`; define application-owned ports there and implement adapters in infrastructure/API.
 
+## Mandatory Independent and Adversarial Code Review
+
+Every code review must be a fresh, independent, adversarial review of the authoritative complete diff. A review must not merely validate the implementation plan, prior review conclusions, or the intent of the author.
+
+Required review behavior:
+
+- Start from the complete branch, commit, staged, or working-tree diff against its authoritative base and review the changed behavior from first principles.
+- Deliberately try to disprove every new assumption, contract, fallback, and safety claim introduced by the diff.
+- Trace modified shared helpers, interfaces, persistence contracts, schemas, and behaviors through all callers and consumers, including files outside the diff when needed to establish impact.
+- Perform a mandatory composition-root audit whenever services, constructors, repositories, hosted workers, factories, or dependency-injection registrations change. Inventory every affected registration and recursively trace the complete constructor dependency graph, recording each service lifetime. Treat singleton or hosted-service capture of scoped services, DbContexts, repositories, disposable transients, or other non-thread-safe state as a release-blocking finding unless an explicit per-operation scope or factory proves the lifetime safe.
+- Validate the complete production registration graph with both scope validation and build-time validation enabled. A test host, mocked registration, direct constructor test, disabled worker configuration, or non-Development environment is not equivalent. Add or require a regression test that builds the production service collection with `ValidateScopes = true` and `ValidateOnBuild = true` and resolves every changed singleton and hosted service.
+- Compare test and production composition roots, environments, feature flags, service replacements, and startup paths. Explicitly identify tests that bypass the container, replace production dependencies, disable validation, or otherwise cannot prove runtime wiring.
+- Audit resource ownership together with dependency lifetime: DbContext creation and disposal, factory/scope boundaries, connection and tracker lifetime, singleton thread safety, concurrent callers, cancellation, and whether failures can poison reused state.
+- Use a review coverage matrix for every complete pass. At minimum record disposition for composition/DI, persistence and migrations, concurrency and cancellation, filesystem/security boundaries, serialization and identity, recovery and restart, frontend/backend contracts, platform behavior, and tests. Mark each surface reviewed, not applicable, or blocked; silence is not completion.
+- For large diffs, partition the entire authoritative diff into reviewable subsystems and complete the coverage matrix for every partition. Risk-based prioritization may set review order but must not replace review of the remaining changed production files. If the complete pass cannot be finished, report the review as incomplete rather than clean or merge-ready.
+- Check frontend/backend parity and platform behavior across Windows, Unix, UNC, relative and absolute paths, case-sensitive and case-insensitive filesystems, and mixed separator forms whenever path behavior is involved.
+- Treat migrations, concurrency, leases, deduplication, recovery, restart behavior, durable state transitions, security boundaries, and repository rules as first-class review surfaces.
+- Treat passing tests as supporting evidence, not proof of correctness. Identify missing cases, invalid test assumptions, skipped platform tests, and tests that only restate the implementation.
+- Require native validation for platform-specific claims. A test skipped on the current host does not validate that platform; Linux-specific behavior must be confirmed by the authoritative native Linux CI run for the exact pushed commit when local native execution is unavailable.
+- Keep implementation and review passes separate. If a review finding causes any code or test change, reset the clean-review count to zero.
+- Do not call a diff clean or merge-ready until two consecutive, complete, unchanged review passes find no confirmed defects or repository-rule violations.
+- Clearly distinguish confirmed findings, unverified risks, missing platform validation, process blockers, and non-blocking suggestions.
+
+## Compatibility Boundary for Development Branches
+
+- The authoritative compatibility boundary is the target branch or released version that a change will merge into. Persisted states produced only by an unmerged feature branch, pull-request build, or intermediate development image are not supported upgrade inputs.
+- Do not add production compatibility code, recovery states, filesystem marker readers, API endpoints, schema versions, or tests solely to preserve intermediate iterations of an unmerged change. Remove or regenerate those development artifacts before merge.
+- EF migrations are immutable historical artifacts only after they reach the target branch. While a feature branch is unmerged, delete superseded branch-only migrations, restore the target branch model snapshot, and regenerate the minimum final EF migration set from the cleaned final model. Never hand-shape generated migrations to preserve intermediate branch states.
+- Compatibility with the actual target-branch schema and persisted data remains mandatory. Before deleting legacy-looking behavior, prove whether the state can exist on the target branch; released or merged states must continue to fail safely or upgrade deterministically.
+- Reviews must distinguish current crash-safety evidence from development-history compatibility. A filesystem marker or recovery protocol that is still part of the final safety contract is not removable merely because earlier versions of that protocol existed during development.
+
+## Cross-shell null redirection
+
+- Never redirect output to `NUL` from Git Bash, MSYS, WSL, or another POSIX shell; those environments can create a real Windows-reserved file named `NUL` in the checkout.
+- Use `/dev/null` only in POSIX shells, `$null` only in PowerShell, and process APIs with ignored standard streams when writing cross-platform automation.
+- Treat any repository entry whose Windows basename is `CON`, `PRN`, `AUX`, `NUL`, `COM1`-`COM9`, or `LPT1`-`LPT9` as a release-blocking hygiene failure.
+
 As a security-aware developer, generate secure .NET code using ASP.NET Core that inherently prevents top security weaknesses.
 Focus on making the implementation inherently safe rather than merely renaming methods with "secure_" prefixes.
 Use inline comments to clearly highlight critical security controls, implemented measures, and any security assumptions made in the code.

.github/CLAUDE.md

@@ -13,6 +13,43 @@ Before making code, dependency, workflow, or documentation changes, review and f
 
 Repository-specific guidance takes precedence over general examples in this file. Keep infrastructure-shaped dependencies out of `listenarr.application`; define application-owned ports there and implement adapters in infrastructure/API.
 
+## Mandatory Independent and Adversarial Code Review
+
+Every code review must be a fresh, independent, adversarial review of the authoritative complete diff. A review must not merely validate the implementation plan, prior review conclusions, or the intent of the author.
+
+Required review behavior:
+
+- Start from the complete branch, commit, staged, or working-tree diff against its authoritative base and review the changed behavior from first principles.
+- Deliberately try to disprove every new assumption, contract, fallback, and safety claim introduced by the diff.
+- Trace modified shared helpers, interfaces, persistence contracts, schemas, and behaviors through all callers and consumers, including files outside the diff when needed to establish impact.
+- Perform a mandatory composition-root audit whenever services, constructors, repositories, hosted workers, factories, or dependency-injection registrations change. Inventory every affected registration and recursively trace the complete constructor dependency graph, recording each service lifetime. Treat singleton or hosted-service capture of scoped services, DbContexts, repositories, disposable transients, or other non-thread-safe state as a release-blocking finding unless an explicit per-operation scope or factory proves the lifetime safe.
+- Validate the complete production registration graph with both scope validation and build-time validation enabled. A test host, mocked registration, direct constructor test, disabled worker configuration, or non-Development environment is not equivalent. Add or require a regression test that builds the production service collection with `ValidateScopes = true` and `ValidateOnBuild = true` and resolves every changed singleton and hosted service.
+- Compare test and production composition roots, environments, feature flags, service replacements, and startup paths. Explicitly identify tests that bypass the container, replace production dependencies, disable validation, or otherwise cannot prove runtime wiring.
+- Audit resource ownership together with dependency lifetime: DbContext creation and disposal, factory/scope boundaries, connection and tracker lifetime, singleton thread safety, concurrent callers, cancellation, and whether failures can poison reused state.
+- Use a review coverage matrix for every complete pass. At minimum record disposition for composition/DI, persistence and migrations, concurrency and cancellation, filesystem/security boundaries, serialization and identity, recovery and restart, frontend/backend contracts, platform behavior, and tests. Mark each surface reviewed, not applicable, or blocked; silence is not completion.
+- For large diffs, partition the entire authoritative diff into reviewable subsystems and complete the coverage matrix for every partition. Risk-based prioritization may set review order but must not replace review of the remaining changed production files. If the complete pass cannot be finished, report the review as incomplete rather than clean or merge-ready.
+- Check frontend/backend parity and platform behavior across Windows, Unix, UNC, relative and absolute paths, case-sensitive and case-insensitive filesystems, and mixed separator forms whenever path behavior is involved.
+- Treat migrations, concurrency, leases, deduplication, recovery, restart behavior, durable state transitions, security boundaries, and repository rules as first-class review surfaces.
+- Treat passing tests as supporting evidence, not proof of correctness. Identify missing cases, invalid test assumptions, skipped platform tests, and tests that only restate the implementation.
+- Require native validation for platform-specific claims. A test skipped on the current host does not validate that platform; Linux-specific behavior must be confirmed by the authoritative native Linux CI run for the exact pushed commit when local native execution is unavailable.
+- Keep implementation and review passes separate. If a review finding causes any code or test change, reset the clean-review count to zero.
+- Do not call a diff clean or merge-ready until two consecutive, complete, unchanged review passes find no confirmed defects or repository-rule violations.
+- Clearly distinguish confirmed findings, unverified risks, missing platform validation, process blockers, and non-blocking suggestions.
+
+## Compatibility Boundary for Development Branches
+
+- The authoritative compatibility boundary is the target branch or released version that a change will merge into. Persisted states produced only by an unmerged feature branch, pull-request build, or intermediate development image are not supported upgrade inputs.
+- Do not add production compatibility code, recovery states, filesystem marker readers, API endpoints, schema versions, or tests solely to preserve intermediate iterations of an unmerged change. Remove or regenerate those development artifacts before merge.
+- EF migrations are immutable historical artifacts only after they reach the target branch. While a feature branch is unmerged, delete superseded branch-only migrations, restore the target branch model snapshot, and regenerate the minimum final EF migration set from the cleaned final model. Never hand-shape generated migrations to preserve intermediate branch states.
+- Compatibility with the actual target-branch schema and persisted data remains mandatory. Before deleting legacy-looking behavior, prove whether the state can exist on the target branch; released or merged states must continue to fail safely or upgrade deterministically.
+- Reviews must distinguish current crash-safety evidence from development-history compatibility. A filesystem marker or recovery protocol that is still part of the final safety contract is not removable merely because earlier versions of that protocol existed during development.
+
+## Cross-shell null redirection
+
+- Never redirect output to `NUL` from Git Bash, MSYS, WSL, or another POSIX shell; those environments can create a real Windows-reserved file named `NUL` in the checkout.
+- Use `/dev/null` only in POSIX shells, `$null` only in PowerShell, and process APIs with ignored standard streams when writing cross-platform automation.
+- Treat any repository entry whose Windows basename is `CON`, `PRN`, `AUX`, `NUL`, `COM1`-`COM9`, or `LPT1`-`LPT9` as a release-blocking hygiene failure.
+
 As a security-aware developer, generate secure .NET code using ASP.NET Core that inherently prevents top security weaknesses. Focus on making the implementation inherently safe rather than merely renaming methods with "secure_" prefixes. Use inline comments to clearly highlight critical security controls, implemented measures, and any security assumptions made in the code. Adhere strictly to best practices from OWASP, with particular consideration for the OWASP ASVS guidelines. **Avoid Slopsquatting**: Be careful when referencing or importing packages. Do not guess if a package exists. Comment on any low reputation or uncommon packages you have included.
 
 ---

.github/workflows/run-tests.yml

@@ -16,11 +16,12 @@ concurrency:
 
 jobs:
   unit-tests:
-    runs-on: ubuntu-latest
+    runs-on: ubuntu-24.04
     env:
       DOTNET_CLI_TELEMETRY_OPTOUT: "1"
       DOTNET_NOLOGO: "1"
       API_PROJECT: listenarr.api/Listenarr.Api.csproj
+      LISTENARR_REQUIRED_NATIVE_TEST_CAPABILITIES: 'DirectorySymbolicLinks,FileSymbolicLinks'
 
     steps:
       - uses: actions/checkout@v4
@@ -80,6 +81,12 @@ jobs:
         working-directory: fe
         run: npm run build --if-present
 
+      - name: Repository path safety
+        run: npm run --silent validate:repository-paths
+
+      - name: Repository path-safety tests
+        run: npm run --silent test:repository-paths
+
       - name: Frontend lint
         run: npm run --silent lint:frontend
 
@@ -96,12 +103,11 @@ jobs:
       - name: Build solution
         run: dotnet build listenarr.slnx --no-restore --configuration Release
 
-      - name: Run unit tests (with Test environment / disable Playwright)
+      - name: Run native backend tests
         env:
           ASPNETCORE_ENVIRONMENT: Test
           Playwright__Enabled: 'false'
-        run: |
-          dotnet test listenarr.slnx -c Release --no-build --logger "console;verbosity=normal"
+        run: pwsh -NoProfile -File scripts/run-native-backend-tests.ps1
 
       - name: Run frontend tests
         working-directory: fe
@@ -117,10 +123,11 @@ jobs:
         run: dotnet publish ${{ env.API_PROJECT }} -c Release -r linux-x64 --no-restore --self-contained true /p:PublishSingleFile=true -o listenarr.api/publish/linux-x64
 
   backend-tests-windows:
-    runs-on: windows-latest
+    runs-on: windows-2025
     env:
       DOTNET_CLI_TELEMETRY_OPTOUT: "1"
       DOTNET_NOLOGO: "1"
+      LISTENARR_REQUIRED_NATIVE_TEST_CAPABILITIES: 'DirectorySymbolicLinks,FileSymbolicLinks'
 
     steps:
       - uses: actions/checkout@v4
@@ -136,8 +143,8 @@ jobs:
       - name: Build backend
         run: dotnet build listenarr.slnx --no-restore --configuration Release
 
-      - name: Run backend tests
+      - name: Run native backend tests
         env:
           ASPNETCORE_ENVIRONMENT: Test
           Playwright__Enabled: 'false'
-        run: dotnet test listenarr.slnx -c Release --no-build --logger "console;verbosity=normal"
+        run: pwsh -NoProfile -File scripts/run-native-backend-tests.ps1

.gitignore

@@ -129,6 +129,7 @@ coverage/
 /cypress/screenshots/
 test-results/
 playwright-report/
+.playwright-cli/
 .codeql-db*/
 
 # Vite
@@ -274,6 +275,7 @@ listenarr.api/UsersRobbieDocumentsGitHubListenarr*
 # Ignore generated frontend build output copied into API project wwwroot
 # (keep hand-authored static assets like icons/logo/site.webmanifest)
 listenarr.api/wwwroot/assets/
+listenarr.api/wwwroot/fonts/
 listenarr.api/wwwroot/index.html
 listenarr.api/wwwroot/*.map
 listenarr.api/wwwroot/assets/**

.husky/pre-push

@@ -6,6 +6,9 @@ if ! command -v node >/dev/null 2>&1 && [ -d "/c/Program Files/nodejs" ]; then
   export PATH="/c/Program Files/nodejs:$PATH"
 fi
 
+echo "Checking repository path safety..."
+node scripts/validate-repository-paths.mjs
+
 echo "Syncing version..."
 node scripts/sync-fe-version-from-csproj.mjs