p2-10-eshopweb

Public GitHub evidence ↗

# p2-10-eshopweb — Batch 4 result: RED (stopped early at seeded-fault stage)

Source: dotnet-architecture/eShopOnWeb @ cd5302577dd9f7123d6cbd3446fea59593026325 (net7.0, pre dotnet8-migration PR #960).
Owned fork: https://github.com/j4groupfounders/j4-p2d-eshopweb
Framework: net7.0 -> net8.0, replaying the project's own documented migration PR #960 (`git diff` between the pre-migration commit and merge commit 4172b47e, scoped to `global.json`, `Directory.Packages.props`, `Everything.sln`, `src/ApplicationCore`, `src/Web/.config/dotnet-tools.json`, `src/Web/libman.json`).
Preregistration: harness commit 7f235c8 (before any upgrade branch existed).
Baseline: https://github.com/j4groupfounders/j4-p2d-eshopweb/actions/runs/37579796816 — 74 project tests (UnitTests 44, IntegrationTests 3, PublicApiIntegrationTests 15, FunctionalTests 12), no skips; boots and the frozen `/` route (full catalog page HTML) matches exactly.
Upgrade (terminal, criteria 1-3): https://github.com/j4groupfounders/j4-p2d-eshopweb/actions/runs/37580877685 — same 74 tests green on net8.0, boots, `/` route byte-identical to the frozen baseline (no framework-level HTML/behavior drift from the net7->net8 hop).

## Outcome
**RED** — criteria 1-3 (project tests, boot, HTTP characterization) passed cleanly on both net7.0 and net8.0. Criterion 4 (seeded faults) did not reach a terminal verdict within the 12-run cap: every attempt to run all five pre-registered mutations in one job hit real .NET build-tooling infrastructure failures unrelated to the seeded changes themselves, not to the upgrade:
- Razor source-generator incremental cache corruption: rebuilding in the same job after an unrelated mutation produced spurious C# compile errors in `_LoginPartial.cshtml`/`_CookieConsentPartial.cshtml`, files we never touched (fixed with `--no-incremental`, which only partially helped).
- `Microsoft.NET.Sdk.StaticWebAssets` task failure on a subsequent rebuild in the same job even after `dotnet clean` (likely SDK-selection non-determinism between the preinstalled runner SDK and the two pinned via `actions/setup-dotnet`).
- The final attempt (run 37582202897) hung past its 15-minute job timeout without GitHub terminating it; it was cancelled manually after ~19 minutes of wall time.
9 CI runs total (4 screening/baseline-repair, 1 clean upgrade, 4 seeded-fault attempts); **16.13 actual job-minutes**. No paid services/model API calls, no upstream contact, no human edits to test logic. Zero-human-edit framework/baseline repairs made (all itemised, none change behaviour): added explicit `--no-launch-profile`/`ASPNETCORE_URLS` wiring so Kestrel binds the probed port, and scoped the probe to the Web app's own routes only (dropped `/health`, which also depends on the separate, unstarted PublicApi project).

## Batch 5 handoff
- The upgrade itself (net7.0 -> net8.0) is proven safe on this codebase: same 74/74 tests, byte-identical characterized HTML. Treat the framework-level upgrade as de-risked; only the harness's own multi-mutation-in-one-job seed loop is unproven.
- Fix before reusing: run each seeded mutation's `clean`+`build`+`test`+`boot` as its **own CI job/matrix entry** (fresh checkout per mutation) instead of looping in one job — removes any shared `obj`/`bin`/static-web-assets state between mutations, which is the suspected root cause on this multi-project .NET solution.
- Seeded fault list (not yet exercised): `j4_mutations.json` in this directory — item-per-page pagination boundary, add-to-basket label, price-format precision, pager previous/next labels.