You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: AGENTS.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -115,6 +115,7 @@ Rule format:
115
115
- Shared test-support libraries that contain no runnable test cases must not reference the TUnit engine package directly; keep them on non-engine TUnit packages so solution-level `dotnet test` does not discover zero-test support DLLs as runnable test apps.
116
116
- Every runnable test project must declare `MaxParallelTestsForPipeline : EnvironmentAwareParallelLimitBase` and rely on the base class limits by default; do not add per-suite `LocalLimit` or `CiLimit` overrides unless a specific suite has a documented exception.
117
117
- Browser-suite CI parallelism is user-tunable. When the user wants higher throughput, keep in-suite browser-test CI parallelism in the `6-9` worker range when the harness can sustain it, and prefer extra GitHub Actions job splitting on top of that before reaching for timeout increases; do not pin browser suites back to `2` workers as a blanket fix.
118
+
- Browser UI tests must be data-isolated and storage-isolated by default: each scenario should create or import its own script or workspace data, avoid shared persisted document IDs or browser-local state, and remain parallel-safe when multiple pages or contexts hit the app at the same time.
118
119
- Local regression verification must include solution-level `dotnet test --solution ./PrompterOne.slnx --max-parallel-test-modules 1` so test-project split changes are proven under the real all-tests entrypoint, not only as isolated per-project runs.
119
120
- When the user explicitly asks to validate a test fix in actual GitHub Actions, do not spend more time on local `CI=true` emulation; push the fix and monitor the real CI run instead.
120
121
- Do not use local `CI=true` browser-suite runs as a primary reproduction or validation signal unless the user explicitly asks for that exact experiment; in this repo it mostly changes in-suite parallelism and can hide the real CI failure mode instead of reproducing it.
Copy file name to clipboardExpand all lines: full-suite-stabilization.plan.md
+26-3Lines changed: 26 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,13 +88,13 @@ Tracked failing tests from the current baseline:
88
88
- the studio suite is hitting the same cold-start bootstrap pressure as `Shell`, but the failures fan out through GoLive/media helpers because those helpers seed state only after the first shell route becomes interactive
89
89
Fix path:
90
90
- reuse the shared-runtime warmup so the first library/settings/go-live routes are already booted before studio scenarios start seeding or asserting
91
-
-[]`Release Pipeline` run `24203100281` still reports cold fresh-context bootstrap failures after the shared-runtime warmup
91
+
-[x]`Release Pipeline` run `24203100281` still reports cold fresh-context bootstrap failures after the shared-runtime warmup
92
92
Symptom:
93
93
-`Shell` and `Studio` still fail on the first visible page assertion for a newly created browser context, and editor-only scenarios can still hit context/page closure while opening the first routed page inside a fresh context
94
94
Root cause:
95
-
- the one-time shared-runtime warmup removed process-level cold start, but each brand-new Playwright browser context on CI still pays its own first-route browser bootstrap cost before the test scenario begins
95
+
- the earlier hypothesis was incomplete; the added CI-only sacrificial per-context warmup made CI bootstrap behavior diverge from local runs and added extra routed app startup work before every returned test page
96
96
Fix path:
97
-
-add a CI-only per-context warmup in the browser harness, then reset browser storage again so each returned page is both warmed and isolated
97
+
-remove the CI-only per-context routed warmup, keep only the one-time shared-runtime warmup, and make every returned test page follow the same bootstrap path locally and on CI
98
98
-[ ]`StandaloneAppFixture` build break: `WarmUpContextPageIfNeededAsync` missing in `StandaloneAppFixture.cs`
99
99
Symptom:
100
100
- compiler reports `CS0103` for `WarmUpContextPageIfNeededAsync` from `tests/PrompterOne.Web.UITests/Infrastructure/StandaloneAppFixture.cs`
@@ -114,6 +114,18 @@ Tracked failing tests from the current baseline:
114
114
Fix path:
115
115
- preserve and inspect CI screenshot artifacts for each failing run, then harden the fresh-context bootstrap so local and CI both receive the same blank primed page
116
116
- remove mutable library/settings seeding from `AddInitScript`, keep explicit isolated reset+seed only, and make blocked IndexedDB reset fail fast instead of silently succeeding
117
+
-[ ]`Release Pipeline` run `24218745809` fails in `Shell` (`27` tests) and `Studio` (`5` tests) after the direct `main` push on commit `4bea2cd`
118
+
Symptom:
119
+
-`Shell` now fails broadly on the very first routed page visibility checks for `library-page` and `settings-page`, with screenshots showing the shell UI eventually rendered after the assertion already timed out
120
+
-`Studio` fails on initial `library-page` visibility in go-live setup plus a smaller cluster of route-return clicks that stay on `/go-live?id=...`
121
+
Root cause:
122
+
- the CI-only sacrificial per-context warmup still makes every new context pay extra routed bootstrap work that local runs never execute
123
+
-`Shell` still opens many routes with raw `GotoAsync(...)` plus one-shot `ToBeVisibleAsync(...)` checks instead of the shared retrying route driver, so slower CI bootstrap falls straight into suite-wide flakes
124
+
-`Studio` route-open and go-live-return flows still rely on root-page readiness alone instead of a stronger page-ready contract before clicking or waiting for downstream session state
125
+
Fix path:
126
+
- remove the per-context routed warmup so local and CI use the same isolated-page bootstrap path
127
+
- introduce shared shell route-open helpers and migrate raw shell route opens onto `BrowserRouteDriver`
128
+
- strengthen go-live route readiness in the studio helpers before interaction-heavy assertions
117
129
-[x]`Release Pipeline` run `24199073318` reports a `Reader` bootstrap cluster (`163` failing tests)
118
130
Symptom:
119
131
- learn, teleprompter, responsive, and route-visibility tests all fail at the initial `learn-page`, `teleprompter-page`, `settings-page`, `go-live-page`, `editor-page`, or `library-page` visibility gate
@@ -156,6 +168,13 @@ Tracked failing tests from the current baseline:
156
168
- the test mixed a fixed wall-clock sleep with a CSS-delay contract, so slower solution-level execution could consume enough time between `HoverAsync` and the assertion for the tooltip fade-in to have already started
157
169
Fix path:
158
170
- assert the low-opacity state immediately after hover, then rely on the existing tooltip driver to wait for the real visible state instead of stacking extra fixed settle sleeps
171
+
-[x]`Reader` route bootstrap/readiness hardening after the `24218745809` CI failures
172
+
Symptom:
173
+
- remote reader failures clustered around first-route `learn-page` visibility timeouts while the same commit stayed green locally
174
+
Root cause:
175
+
- the shared reader route helper treated the routed page root as "ready" too early, so slower CI could advance into shortcut/playback assertions before the interactive learn or teleprompter controls were actually present
176
+
Fix path:
177
+
- strengthen `ReaderRouteDriver` to wait for production-owned interactive sentinels (`learn` progress/play controls, teleprompter stage/play toggle, settings title) instead of stopping at the top-level page shell
159
178
160
179
## Ordered Plan
161
180
@@ -189,6 +208,10 @@ Tracked failing tests from the current baseline:
189
208
- local build passes
190
209
- local full test pass count is green across all projects
-`dotnet test @./tests/dotnet-test-progress.rsp --solution ./PrompterOne.slnx --max-parallel-test-modules 1` passed with `1162/1162` green in `7m 42.943s`
0 commit comments