@clipboard-health/ai-rules 2.41.0 → 2.41.2

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-08.md

@@ -0,0 +1,99 @@
+# Historical plan snapshot
+
+## Groundcrew
+
+Repository: `[admin frontend]`
+Implementation workflow: use the `cb-work` skill. If unavailable, use the `core:go` skill.
+
+Include this implementation ticket ID in the change body.
+
+```bash
+
+```
+
+## Source Investigation
+
+Investigation ticket: [ticket redacted]
+Skill/mode: `flaky-debug` in plan mode. The requested `flaky-test-debugger` skill was not installed under that exact name, so this used the available Clipboard flaky-debug skill.
+
+## Flake Details
+
+```json
+{
+  "repo": "[admin frontend]",
+  "test": "Home Health Full Lifecycle complete home health workflow: create case, manage visits, verify and reject occurrences, close case",
+  "file": "playwright/e2e/homeHealth/fullLifecycle.spec.ts:1170",
+  "framework": "playwright",
+  "isNewFlaky": false,
+  "failures": [
+    {
+      "error": "TimeoutError: locator.click: Timeout 5000ms exceeded.\nCall log:\n  - waiting for getByRole('dialog').filter({ hasText: 'Are you sure you want to close this case?' }).getByRole('button', { name: 'Close', exact: true })\n    - locator canonical to <button tabindex=\"0\" type=\"button\" class=\"MuiButtonBase-root MuiButton-root MuiButton-contained MuiButton-containedPrimary MuiButton-sizeMedium MuiButton-containedSizeMedium MuiButton-fullWidth MuiButton-root MuiButton-contained MuiButton-containedPrimary MuiButton-sizeMedium MuiButton-containedSizeMedium MuiButton-fullWidth css-6qhbw3\">…</button>\n  - attempting click action\n    - waiting for element to be visible, enabled and stable\n    - element is not stable\n  - retrying click action\n    - waiting for element to be visible, enabled and stable\n  - element was detached from the DOM, retrying\n",
+      "stack": "TimeoutError: locator.click: Timeout 5000ms exceeded.\nCall log:\n  - waiting for getByRole('dialog').filter({ hasText: 'Are you sure you want to close this case?' }).getByRole('button', { name: 'Close', exact: true })\n    - locator canonical to <button tabindex=\"0\" type=\"button\" class=\"MuiButtonBase-root MuiButton-root MuiButton-contained MuiButton-containedPrimary MuiButton-sizeMedium MuiButton-containedSizeMedium MuiButton-fullWidth MuiButton-root MuiButton-contained MuiButton-containedPrimary MuiButton-sizeMedium MuiButton-containedSizeMedium MuiButton-fullWidth css-6qhbw3\">…</button>\n  - attempting click action\n    - waiting for element to be visible, enabled and stable\n    - element is not stable\n  - retrying click action\n    - waiting for element to be visible, enabled and stable\n  - element was detached from the DOM, retrying\n\n    at submitCloseCase (/opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/homeHealth/fullLifecycle.spec.ts:792:17)\n    at /opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/homeHealth/fullLifecycle.spec.ts:1782:9\n    at /opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/homeHealth/fullLifecycle.spec.ts:1774:7\n    at WorkerMain._runTest (/opt/actions-runner/_work/[admin frontend]/[admin frontend]/node_modules/dd-trace/packages/datadog-instrumentations/src/playwright.js:1692:5)",
+      "branch": "main",
+      "pipeline": "[external evidence reference]",
+      "commit": "ae7ad5ee34fd9d833c47c68aec34f8d3e4c03745",
+      "durationMs": 56753,
+      "shard": "2/4",
+      "timestamp": "2026-07-06T17:16:19Z"
+    }
+  ]
+}
+```
+
+## Plan Output
+
+**Test ID:** `[bf2e9756e2c0]`
+
+**Confidence:** 4/5. The failure artifact directly shows the close dialog button was visible/enabled, the click timed out because the element became unstable/detached, and no close-case PATCH was emitted. The exact reason the dialog disappeared is inferred from UI/test timing, so this is not 5/5.
+
+**Failure surface:** User action no-op / test harness. The app reached the confirmation dialog, but the destructive close-case request never started.
+
+**Current main status:** The failing code path still exists on current main/worktree in `playwright/e2e/homeHealth/fullLifecycle.spec.ts`: `submitCloseCase` waits for `PATCH /cases/{caseId}` and clicks the `Close` button in a single `Promise.all` at lines 784-792. No open change with label `flaky-test-fix` matched this file. Recent commit `28bdf114626` / [ticket redacted] fixed a different close-case flake where the PATCH succeeded and the helper retried a one-shot mutation; this new failure happens before the PATCH starts.
+
+**Symptom:** In Step j, `submitCloseCase` times out on `closeButton.click({ timeout: ATTEMPT_TIMEOUT_MS })`. Playwright reports the button canonical, then was unstable and detached. The paired `waitForHomeHealthResponse` also times out because no matching `PATCH /[home-health service]/api/v1/*/cases/{caseId}` occurs.
+
+**Root cause:** `submitCloseCase` treats one transient close-dialog/button remount as terminal. The close dialog is mounted under `CaseActionsMenu` / `CaseClosureDialog`; the failed run shows it can disappear or remount during the click window before the close PATCH starts. The helper lacks the request-observed guard used elsewhere in this spec for visit verification actions, so a pre-request click detach fails the test instead of safely reopening the dialog and trying again.
+
+**Evidence:**
+
+- LLM report summary: 52 tests total, 49 passed, 1 flaky, 2 skipped. This test failed first attempt and passed retry.
+- Failed timeline around Step j: `Case Actions` clicked at ~49071ms, `Close Case` clicked at ~49113ms, dialog text visible at ~49374ms, `Close` button visible/enabled at ~49391-49394ms, then both `waitForResponse` and `Click ... Close` start at ~49398ms and time out after 5000ms.
+- Failed network activity after the close click contains Datadog/Braze and unrelated `/api/extra-worked-time-requests` and `/api/user/get` requests, but no `PATCH /[home-health service]/api/v1/.../cases/{caseId}`.
+- Failure screenshot shows the dialog is gone, the case is still visible under Active Cases, and the case has not moved to ended Cases.
+- Passed retry follows the same Step j path and completes: click Case Actions, click Close Case, see close dialog, click Close, settle Active Cases, then verify the case under ended Cases.
+- Product code path: `src/appV2/ExperimentalHomeHealth/Cases/CaseDashboard/CaseClosureDialog.tsx` only calls `updateCase` from the `Close` button handler, then closes the modal after success; `useUpdateCase` invalidates open/ended case queries on success.
+
+**Proposed fix:** Test harness only, in `playwright/e2e/homeHealth/fullLifecycle.spec.ts`.
+
+1. Refactor `submitCloseCase` to mirror the existing request-observed pattern used by `clickVisitOccurrenceActionButtonUntilPatchObserved`.
+2. Start a close-case response result promise with `waitForHomeHealthResponseResult({ action: "close case", isMatchingRequest: (request) => isCaseUpdateRequest(request, caseId), timeout: ACTION_TIMEOUT_MS })` before retrying pre-request UI work.
+3. Add a helper such as `clickCloseCaseButtonUntilPatchObserved({ page, closureDialog, caseId })` that:
+   - creates `page.waitForRequest((request) => isCaseUpdateRequest(request, caseId), { timeout: ATTEMPT_TIMEOUT_MS }).then(() => true, () => false)`;
+   - locates the Close button fresh from the current dialog;
+   - asserts visible/enabled and clicks;
+   - if the click throws but the PATCH was observed, returns success;
+   - if no PATCH was observed, throws a retryable pre-request error.
+4. Wrap only the pre-mutation open/fill/click path in `expect(...).toPass({ intervals: [500, 1_000, 2_000], timeout: ACTION_TIMEOUT_MS })` so retries are allowed before a close PATCH starts, but the mutation itself is still executed once.
+5. After the helper observes the PATCH, await the response result with `getSuccessfulHomeHealthResponse`, assert `data.attributes.status === CaseStatus.[attempt reference redacted]`, settle the dashboard, and assert the active case card disappears.
+6. Add close-case diagnostics on final failure, similar to `attachCancelVisitDialogOpenDiagnostics`: visible dialog texts, close button count/visible/enabled, case card text, current URL, whether the close PATCH was observed, and a screenshot attachment if useful.
+7. Do not use `force: true`, fixed sleeps, or a longer click timeout as the fix.
+
+**Observability to reach 5/5:** Add the close-case test diagnostics above. They would confirm whether the dialog ended from an `onClose`, remounted with a new button, or disappeared because the case card subtree remounted. No backend telemetry is required for this occurrence because the expected backend request never started.
+
+**Sibling candidates:** The exact `Promise.all([waitForHomeHealthResponse, closeButton.click])` anti-pattern is localized to close case. Review nearby destructive dialog submits in the same file while implementing: cancel visit confirmations and remove booked worker use a request promise plus direct click; they may not need changes, but should be checked against the same request-observed guard criterion.
+
+**Validation plan:**
+
+```bash
+npx oxfmt --check playwright/e2e/homeHealth/fullLifecycle.spec.ts
+npx oxlint playwright/e2e/homeHealth/fullLifecycle.spec.ts
+npm run lint:fast
+npm run typecheck
+npm run playwright:run -- playwright/e2e/homeHealth/fullLifecycle.spec.ts --grep "complete home health workflow"
+```
+
+If local Playwright setup requires deployed-env credentials, record the setup blocker and run the smallest available lint/typecheck verification locally.
+
+**Open questions:** None for implementation. The fix should not require product-code changes unless new diagnostics show real user-visible close-dialog dismissal without a request.
+
+**Residual risk:** The full lifecycle spec has several independently flaky surfaces. This plan only addresses the close-case confirm-button detach before the PATCH starts; later ended-tab verification or unrelated home-health API/setup flakes can still fail separately.

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-09.md

@@ -0,0 +1,107 @@
+# Historical plan snapshot
+
+## Groundcrew
+
+Repository: [mobile frontend]
+GitHub repo: [mobile frontend]
+Implementation workflow: use the `cb-work` skill or, if unavailable, the `core:go`/`go` skill.
+
+## Task
+
+Stabilize the MPR V2 Playwright flow in `playwright/e2e/shift/timekeeping.spec.ts` by making `selectMinuteThatRequiresClockInApproval` avoid low-minute loop-boundary clicks that can settle the wheel into a same-hour future time.
+
+Suggested smallest fix: update `getTargetMinuteForClockInApproval` so it avoids both `00` and the `01 -> 00` path. For this flow, a slightly later minute is still earlier than the actual worker clock-in because the shift is already in progress; it only needs to dirty the picker and trigger the approval step. A conservative helper shape is:
+
+```ts
+function getTargetMinuteForClockInApproval(selectedMinute: number): number {
+  if (selectedMinute <= 1) {
+    return selectedMinute + 1;
+  }
+
+  return selectedMinute - 1;
+}
+```
+
+Consider using a slightly wider low-minute guard, for example `selectedMinute <= 5`, if local trace review shows the smooth scroll can settle across several low-minute values. Keep the change test-harness-only unless the implementation investigation proves a real product bug in `WheelTimePicker` click/scroll-end behavior.
+
+## Acceptance Criteria
+
+- [ ] The MPR V2 E2E helper no longer clicks `0 minutes` when the selected minute is `1`.
+- [ ] The helper still reaches the approval-step UI by waiting for the earlier-clock-in approval copy and enabled `Next` button.
+- [ ] The change body includes this implementation ticket ID.
+- [ ] Targeted formatting/linting and the smallest practical Playwright verification are run or the Playwright environment blocker is documented.
+
+## Flake Details
+
+```json
+{
+  "repo": "[mobile frontend]",
+  "test": "Missed punch request should complete MPR V2 flow: already started working, edit clock-in, and submit timesheet",
+  "file": "playwright/e2e/shift/timekeeping.spec.ts:920",
+  "framework": "playwright",
+  "isNewFlaky": false,
+  "failures": [
+    {
+      "error": "Error: Clock-in approval state not reached after clicking 55 minutes; selected minute: 55; Next enabled: false; approval copy: <not visible>\n\nCall Log:\n- Timeout 30000ms exceeded while waiting on the predicate",
+      "stack": "Error: Clock-in approval state not reached after clicking 55 minutes; selected minute: 55; Next enabled: false; approval copy: <not visible>\n\nCall Log:\n- Timeout 30000ms exceeded while waiting on the predicate\n    at selectMinuteThatRequiresClockInApproval (/home/runner/work/[mobile frontend]/[mobile frontend]/playwright/e2e/shift/timekeeping.spec.ts:147:6)\n    at /home/runner/work/[mobile frontend]/[mobile frontend]/playwright/e2e/shift/timekeeping.spec.ts:975:11\n    at WorkerMain._runTest (/home/runner/work/[mobile frontend]/[mobile frontend]/node_modules/dd-trace/packages/datadog-instrumentations/src/playwright.js:1692:5)",
+      "branch": "gh-readonly-queue/main/change-[reference redacted]-139c9148f92f65dc0d8f2a8f642c56fea71e4e95",
+      "pipeline": "[external evidence reference]",
+      "commit": "eece17af4aa80924757ee2444f013dadb956d75e",
+      "durationMs": [attempt reference redacted],
+      "shard": "3/4",
+      "timestamp": "2026-06-25T14:06:34Z"
+    }
+  ]
+}
+```
+
+## Plan Output
+
+**Test ID:** `a51c4867d1e5326a80d8-240a586ace394c9bb6fb`
+
+**Confidence:** 4/5. The LLM report, trace steps, and screenshot directly show the failed UI state. One link is inferred: the report does not expose the wheel column `scrollTop` or scroll-end events, so the exact mechanism that moves from `0` to high-50s minutes is inferred from the step sequence and component behavior.
+
+**Failure surface:** User action no-op / test harness. The click actions completed, but the expected approval-state transition did not remain reachable. No relevant backend request was emitted during the failed picker-selection loop.
+
+**Current main status:** Still applicable on current `origin/main`/branch head `e12d296a7e8`. No open GitHub change labeled `flaky-test-fix` was found. Recent main commits `893373a2abb` and `ba607976ecd` stabilized this same MPR picker area but do not cover the `selectedMinute === 1 -> click 0` low-minute boundary seen here.
+
+**Symptom:** `selectMinuteThatRequiresClockInApproval` timed out at `playwright/e2e/shift/timekeeping.spec.ts:147`. The final diagnostic was: `Clock-in approval state not reached after clicking 55 minutes; selected minute: 55; Next enabled: false; approval copy: <not visible>`.
+
+**Root Cause:** The test helper derives each retry target from the currently selected minute and usually subtracts one. When the selected minute is `1`, it clicks `0 minutes`. In this live E2E flow the looped `WheelTimePicker` uses smooth scrolling and scroll-end recentering; after the low-minute boundary click, subsequent retries observed/clicked high minute values (`57`, `56`, `55`, `54`). Those same-hour high-minute selections were in the future relative to browser time, so `useClockInTimeValidation` showed the future-time error, hid the approval copy, and left the footer as disabled `Save` instead of enabled `Next`.
+
+**Evidence:**
+
+- LLM report summary for run [reference redacted]`: 45 total, 44 passed, 1 flaky; this test failed on attempt 1 and passed on attempt 2.
+- Failed attempt timeline reached `Adjust clock in` at offset `68591ms`, then the helper clicked minute options `0`, `57`, `56`, `55`, and `54` before timing out.
+- Passing retry reached `Adjust clock in` at offset `28654ms`, clicked `2 minutes`, saw the approval copy, found `Next` enabled, and completed the full flow.
+- Failure screenshot shows the adjustment sheet with error copy `This time (7:54 AM) is in the future. Please end your shift before requesting shift payment.`, selected `54` minutes, and a disabled `Save` button.
+- The product validation path in `validateClockInTimestamp` marks selected times after `startOfMinute(new Date())` as `IN_FUTURE`; `TimekeepingAdjustmentBottomSheet` only labels the footer `Next` when `requiresApproval` is stable.
+- Network summary had retained-request caps (`instancesDroppedByGroupCap: 29`, `instancesEvictedAfterAdmission: 14`), but no failed backend request explains the picker transition. The only retained 4xx was an unrelated `worker-payouts/last` 404.
+
+**Proposed Fix:** Test harness only, in `playwright/e2e/shift/timekeeping.spec.ts`.
+
+Update the minute target helper to avoid low-minute loop-boundary targets. At minimum, handle `selectedMinute <= 1` by clicking a later safe minute, not `0`. This keeps the selected adjusted time earlier than the actual worker clock-in in this scenario while avoiding the looped wheel boundary that can settle into future high-minute values.
+
+Optionally improve diagnostics in `getMinuteSelectionDiagnostics` to include the visible footer button text, visible intent/error copy, selected hour/minute/meridiem labels, and browser `new Date().toISOString()` so the next failure is self-contained.
+
+**Observability to Reach 5/5:**
+
+- Frontend/test reporter: include selected hour/minute/meridiem, all visible intent/error banner text, visible footer button names, and browser current time in the helper failure message.
+- If the low-minute fix does not settle the flake, add temporary Playwright trace diagnostics for the minutes listbox `scrollTop` and selected option before/after each click to prove whether `WheelColumn` scroll-end recentering is overriding `onSelect`.
+- Backend telemetry is not required for this failure unless a future occurrence emits `validate_timekeeping_action` during the failed transition.
+
+**Sibling Candidates:**
+
+- Primary: `playwright/e2e/shift/timekeeping.spec.ts` helper `getTargetMinuteForClockInApproval` / `selectMinuteThatRequiresClockInApproval`.
+- Review but do not preemptively patch: `src/appV2/redesign/components/WheelTimePicker/WheelColumn.tsx`, because a real product click/scroll bug would need separate proof.
+
+**Validation Plan:**
+
+- `npx oxfmt --check playwright/e2e/shift/timekeeping.spec.ts`
+- `npm run lint -- playwright/e2e/shift/timekeeping.spec.ts`
+- If the local Playwright environment is available: `npx playwright test --config ./playwright.config.ts --project "Mobile Chrome" playwright/e2e/shift/timekeeping.spec.ts --grep "already started working"`
+- If Playwright setup is missing, run/document `npm run playwright:setup` and the blocker, then rely on CI for the live E2E run.
+
+**Open Questions:** None blocking. The implementation can proceed with a test-harness-only change.
+
+**Residual Risk:** This flow still depends on live E2E services and real wall-clock time. If the wheel component itself can override clicked selections after smooth scroll in normal user interaction, the test-harness fix will reduce flakes but not address that broader product behavior.

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-10.md

@@ -0,0 +1,141 @@
+# Historical plan snapshot
+
+## Groundcrew
+
+Repository: [admin frontend]
+Implementation workflow: implement this ticket using the `cb-work` skill if available. If `cb-work` is unavailable, use the `core:go`/`go` skill. Follow this repo's AGENTS.md implementation workflow and run the documented verification.
+
+In the change body, include this implementation ticket ID and investigation ticket `[ticket redacted]`.
+
+```bash
+
+```
+
+## Task
+
+Stabilize the shared Playwright E2E Cognito user provisioning path so freshly created facility/workplace/HCP users are not used for Cognito Admin API mutations before they exist in the staging Cognito user pool `us-west-2_HV1ibP3I6`.
+
+Do not create per-test fixes. Diagnose and fix the shared setup path used by these fingerprints.
+
+## Required Fix Shape
+
+Implement one shared Cognito readiness/de-stressing mechanism instead of increasing per-test retries.
+
+Required readiness signal:
+
+- After [backend service]/test-helper user creation returns successfully, wait for `AdminGetUser` to succeed for the exact synthetic E2E user in pool `us-west-2_HV1ibP3I6` before calling `AdminSetUserPasswordCommand` or `AdminUpdateUserAttributesCommand`.
+- For worker/HCP setup, also verify the returned Cognito user has enough expected identity attributes to safely apply the requested user-type attribute update. If the backend creates the user under a normalized username instead of raw email, resolve that username once and use it consistently for all later Cognito Admin calls.
+- Treat `UserNotFoundException` as readiness-not-yet-met. Do not call password or attribute mutations until readiness is confirmed.
+
+Required retry bound and behavior:
+
+- Use a bounded wait that is long enough for staging Cognito propagation, with capped backoff and jitter. The existing 5 attempts spaced 2s apart is the observed insufficient bound; replace it with an explicit total timeout such as 60-90s unless investigation shows a better staging-specific bound.
+- Retries must be idempotent. Re-running setup should not create duplicate users, repeatedly reset passwords for the same readiness miss, or fan out multiple identical Cognito Admin calls for one synthetic user.
+- When many users are created in one setup path, limit or serialize Cognito Admin readiness/mutation calls enough to avoid adding burst pressure to Cognito/[backend service]. Prefer a small shared queue or existing repo helper over a new dependency.
+
+Required exhaustion metadata:
+
+- On timeout, fail with a single enriched error that includes pool ID, synthetic email or canonical username, setup helper path, requested mutation type (`password` or `userType`), total elapsed time, attempt count, last AWS exception name/code/status/request ID if available, last successful readiness state, GitHub run/job identifiers if available from env, and the originating test file/worker where practical.
+- Keep real-user PHI out of logs. The failing users here are synthetic Playwright users, but helper logging should still avoid leaking unrelated user data.
+
+## Observability to Reach 5/5 Confidence
+
+Current confidence is 4/5 that this is one shared setup/backend-provisioning failure mode because direct staging [backend service]/Cognito telemetry was unavailable during investigation. The implementation should close that gap before the ticket is considered fully canonical.
+
+Collect or add enough observability to prove which path is true:
+
+- [backend service]/test-helper creates/imports the Cognito user successfully, but Cognito propagation is eventually consistent and the frontend harness must wait for `AdminGetUser` readiness.
+- [backend service]/test-helper returns success before it has deterministically created/imported the Cognito user, so the true fix belongs in [backend service] or its test-helper contract.
+- Cognito/backend throttling or burst pressure is delaying creation/readiness, so the harness must reduce concurrent Admin calls and expose enough timing data to verify the reduction.
+
+Concrete signals to capture in Datadog, CI logs, or targeted helper instrumentation:
+
+- Timestamp of [backend service]/test-helper user-create response for the synthetic email.
+- Timestamp and outcome of each readiness probe, including `AdminGetUser` success or `UserNotFoundException`.
+- Timestamp and outcome of the subsequent `AdminSetUserPasswordCommand` / `AdminUpdateUserAttributesCommand`.
+- Total elapsed time from backend user-create success to Cognito readiness, grouped by helper path and user type.
+- Any Cognito throttling, AWS SDK status, or [backend service] error/trace ID tied to the synthetic user creation.
+
+Do not close this as 5/5 confidence from local green tests alone. Either attach the staging telemetry/CI evidence in the change or document why the fix had to move to [backend service]/auth infrastructure and link the follow-up implementation.
+
+## Storm Details
+
+Shared error signature:
+
+```text
+Error: Cognito user '[EMAIL]' does not exist in pool 'us-west-2_HV1ibP3I6' after 5 attempts. Ensure the user is provisioned in Cognito before running E2E tests.
+```
+
+Tests bundled: 6
+Repos affected: 1
+CI runs affected: 2
+First failure: 2026-07-06T11:38:20Z
+Last failure: 2026-07-06T11:43:46Z
+
+- `9166129be528` — `playwright/e2e/myAccount.spec.ts:88`
+- `26803343548f` — `playwright/e2e/auth.spec.ts:103`
+- `43dfbdb912d9` — `playwright/e2e/placements/acceptApplication.spec.ts:144`
+- `9bbc4081a989` — `playwright/e2e/facilityOnboarding.spec.ts:32`
+- `63172183d01a` — `playwright/e2e/homeHealth/fullLifecycle.spec.ts:876`
+- `6b98dfce6bf1` — `playwright/e2e/auth.spec.ts:182`
+
+Runs:
+
+- [[external evidence reference]]([external evidence reference])
+- [[external evidence reference]]([external evidence reference])
+
+## Investigation Findings
+
+Failure surface: test setup/auth/data, before browser user-flow assertions.
+
+Shared dependency: staging [backend service]/test-helper user creation plus AWS Cognito user pool `us-west-2_HV1ibP3I6`. CI config sets `E2E_ENVIRONMENT=staging` and `E2E_SERVICE_NAME=[backend service]`.
+
+Shared helper path:
+
+- `playwright/helpers/cognitoPassword.ts` calls `AdminSetUserPasswordCommand` for freshly created facility users and throws after five `UserNotFoundException` retries spaced 2s apart.
+- `playwright/helpers/cognitoUserTypes.ts` has the sibling pattern for `AdminUpdateUserAttributesCommand` used by worker/HCP setup.
+- Failing tests reach these through shared helpers such as `createFacilityUserWithRetry`, `createLtcFacilityWithUser`, `createHomeHealthcareWorkplaceWithUser`, `createHcfWithAssignedShiftWithRetry`, and `loginWithCognitoPassword`.
+
+Representative CI evidence:
+
+- Run [reference redacted]`, job `e2e-playwright-1`: `Created facility user ... email: playwright-gtygfpwvlhf@playwright-hcf.com`at`2026-07-06T11:43:07Z`, followed immediately by `Cognito user ... not found (attempt 1/5)`through attempt 4, then the test fails from`playwright/helpers/cognitoPassword.ts:65`.
+- Run [reference redacted]`, job `e2e-playwright-1`: same sequence for `playwright-fovjnxnxzsj@playwright-hcf.com`; the helper fails after five attempts from `playwright/helpers/cognitoPassword.ts:65`.
+- The failures occurred on separate self-hosted runners in the `cbh` group (`m8a.4xlarge`, `us-west-2b`), not one stale workspace.
+- Current `origin/main` still has the same relevant setup code; no open `flaky-test-fix` change was found for this exact signature/fingerprints.
+
+Datadog/incident check:
+
+- Local Datadog CLI credentials were unavailable (`dog` and `~/.dogrc` absent).
+- [incident.io]([external evidence reference]) telemetry has no configured telemetry datasource, so direct Datadog logs/metrics/traces could not be queried from this session.
+- [incident.io]([external evidence reference]) did not show Cognito/staging/user-create incidents in `2026-07-06T11:00:00Z` to `2026-07-06T12:00:00Z`.
+- One unrelated incident existed in the window: `INC-423` Stripe Payment Issues for Workers.
+- One Platform Datadog alert existed in the window: production HCF login high latency at `2026-07-06T11:05:36Z`; this does not directly explain staging Cognito user provisioning.
+
+Current confidence: 4/5 that this is one shared setup/backend-provisioning failure mode, not six independent test flakes. Confidence is not 5/5 because direct Datadog traces/logs for staging [backend service]/Cognito provisioning were unavailable.
+
+## Acceptance Criteria
+
+- [ ] The shared setup path waits on or deterministically creates/validates Cognito users before `AdminSetUserPassword`/`AdminUpdateUserAttributes` are called.
+- [ ] Readiness is based on a concrete `AdminGetUser` success signal, with a documented timeout/backoff bound and clear behavior for `UserNotFoundException`, throttling, and final timeout.
+- [ ] Timeout failures include the exhaustion metadata listed above so future flakes can be debugged from CI logs without rerunning the investigation.
+- [ ] Retries are idempotent and do not amplify Cognito/backend throttling.
+- [ ] The implementation reduces call burstiness where the shared setup creates multiple users or applies multiple Cognito mutations in one flow.
+- [ ] The fix applies to all contained fingerprints, not individual test assertions.
+- [ ] If [backend service] or auth infrastructure is the true fix locus, document the frontend harness evidence and implement in the correct repo or add the needed observability before closing.
+- [ ] Add or update focused tests for the shared helper behavior where practical.
+- [ ] Run the documented relevant verification for the changed repo.
+
+## Suggested Starting Points
+
+- `playwright/helpers/cognitoPassword.ts`
+- `playwright/helpers/cognitoUserTypes.ts`
+- `playwright/api/user.ts`
+- `playwright/api/facility.ts`
+- `playwright/api/homeHealth.ts`
+- `playwright/helpers/login.ts`
+
+Also inspect backend/test-helper behavior for `/api/facilityUser`, `/api/user/create`, and any JIT Cognito import path that should make new users appear in `us-west-2_HV1ibP3I6`.
+
+## Related
+
+Investigation: `[ticket redacted]`

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-11.md

@@ -0,0 +1,98 @@
+# Historical plan snapshot
+
+## Groundcrew
+
+Repository: `[admin frontend]`
+Implementation workflow: use the `cb-work` skill or, if unavailable, the `core:go` skill.
+
+Include this implementation ticket ID in the change body.
+
+```bash
+
+```
+
+## Flake details
+
+```json
+{
+  "repo": "[admin frontend]",
+  "test": "Chat (redesign) — mobile chat from shift details on mobile renders as a stacked bottom sheet and can be ended",
+  "file": "playwright/e2e/chat.spec.ts:241",
+  "framework": "playwright",
+  "isNewFlaky": false,
+  "failures": [
+    {
+      "error": "Error: expect(page).toHaveURL(expected) failed\n\nExpected pattern: /chatWorkerId=/\nReceived string:  \"[external evidence reference]"\nTimeout: 4000ms\n\nCall log:\n  - Expect \"toHaveURL\" with timeout 4000ms\n    8 × unexpected value \"[external evidence reference]"\n\n\nCall Log:\n- Timeout 30000ms exceeded while waiting on the predicate",
+      "stack": "Error: expect(page).toHaveURL(expected) failed\n\nExpected pattern: /chatWorkerId=/\nReceived string:  \"[external evidence reference]"\nTimeout: 4000ms\n\nCall log:\n  - Expect \"toHaveURL\" with timeout 4000ms\n    8 × unexpected value \"[external evidence reference]"\n\n\nCall Log:\n- Timeout 30000ms exceeded while waiting on the predicate\n    at clickUntilUrl (/opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/chat.spec.ts:125:6)\n    at /opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/chat.spec.ts:264:13\n    at WorkerMain._runTest (/opt/actions-runner/_work/[admin frontend]/[admin frontend]/node_modules/dd-trace/packages/datadog-instrumentations/src/playwright.js:1692:5)",
+      "branch": "main",
+      "pipeline": "[external evidence reference]",
+      "commit": "40f5b4ebe9cc9d01c4ef6129a67e238087690723",
+      "durationMs": 60384,
+      "shard": "4/4",
+      "timestamp": "2026-07-02T15:01:43Z"
+    }
+  ]
+}
+```
+
+## Plan output
+
+**Test ID:** `03dd965d45c5`
+
+**Confidence:** 4/5. The artifact directly proves chat opened while `chatWorkerId` was absent. The missing link is exact identification of the competing history writer because current reporter output does not log URL writes.
+
+**Failure surface:** Product/client state drift. The click was not a no-op and the backend chat-channel request succeeded; the failure is the client URL state not reflecting the open chat panel.
+
+**Current main status:** Current `origin/main` still has the failing code path. The failing commit `40f5b4e` already included prior test-only hardening from change [reference redacted] and change [reference redacted]. No later relevant changes touched `playwright/e2e/chat.spec.ts`, `useChatPanel`, or `useShiftDeepLinking`.
+
+**Symptom:** The Playwright test clicked the mobile Shift Details `Chat` button, then `clickUntilUrl(... /chatWorkerId=/ ...)` timed out for 30s. The final URL remained `/schedule?date=2026-07-03&view=day&shiftId=6a467d5e35d466dbaffea56b`.
+
+**Root cause:** The shift-details chat modal and the URL are two sources of truth. In this occurrence the chat modal state and worker info were set, but `chatWorkerId` was missing from the URL. The earlier retry helper correctly avoids re-clicking once chat is visibly open, so it cannot repair this state drift.
+
+**Evidence:**
+
+- LLM report for run [reference redacted]`: attempt 1 failed; attempt 2 passed.
+- Failure timeline: at ~28.6s, `Click getByRole('button', { name: 'Chat', exact: true })` completed; at ~29.07s, two `POST [external evidence reference] calls returned `201`with request body`{"facilityId":"6a467d5ca3fe1f1fd5fb40e5","agentId":"6a467d5936acbdb4f58f3d02"}`.
+- Screenshot/page snapshot at failure show `Close chat`, `Chat messages`, and the disabled `Chat message` textbox mounted in the stacked bottom sheet.
+- The URL assertion still saw no `chatWorkerId` for the entire retry budget.
+- change [reference redacted] originally included a guarded URL reconciliation effect in `useChatPanel`, then removed it before integration. Its own notes say to re-add it if this exact flake recurs.
+
+**Proposed fix:** Product fix in `src/appV2/redesign/Chat/hooks/useChatPanel.ts` plus focused hook tests.
+
+1. Reintroduce the guarded reconciliation from change [reference redacted]'s removed commits:
+   - import `useLocation` in `useChatPanel`;
+   - track `chatOpenedShiftId` in a ref;
+   - set that ref when chat opens from a click or deep link;
+   - clear it when chat closes or when shift-change cleanup runs;
+   - while chat is open and `chatWorkerInfo.workerId` exists, if `location.search` lacks the matching `chatWorkerId` and `chatOpenedShiftId.current === shiftId`, call `updateChatUrlParameter(chatWorkerInfo.workerId)`.
+2. Keep the shift guard. Without it, a later shift change could resurrect `?shiftId=B&chatWorkerId=A`.
+3. Add/restore `useChatPanel.test.tsx` coverage:
+   - restores `chatWorkerId` when another URL writer drops it while chat is open on the same shift;
+   - does not restore `chatWorkerId` after switching to another shift;
+   - preserves existing close/toggle/deep-link behavior.
+4. Do not add more Playwright retries/timeouts for this symptom; the app state is already visibly open, so extra clicking would mask URL/state drift.
+
+**Observability to reach 5/5:** Add temporary or permanent frontend debug telemetry for query-param modal URL writes in this area:
+
+- In `useChatPanel.updateChatUrlParameter`, log old URL, new URL, workerId, shiftId, and reason (`open`, `close`, `repair`) in non-PII-safe structured form.
+- In `useShiftDeepLinking.updateUrl` / `buildShiftDeepLinkUrl`, log old URL, new URL, shiftId/inviteId, and whether `chatWorkerId` was preserved or removed.
+- Ideally emit these as Datadog RUM actions or console debug gated for E2E so the Playwright LLM report captures the writer sequence next time.
+
+**Sibling candidates:** Query-param-driven drawer/sheet hooks that maintain separate React modal state and URL params: `useShiftDeepLinking`, `useChatPanel`, My Professionals profile/chat URL state, MonthlyView selected slot/chat URL state.
+
+**Validation plan:**
+
+- `npm run test:v2 -- src/appV2/redesign/Chat/hooks/useChatPanel.test.tsx src/appV2/redesign/DailyView/hooks/useShiftDeepLinking.test.tsx`
+- `npm run lint:fast -- src/appV2/redesign/Chat/hooks/useChatPanel.ts src/appV2/redesign/Chat/hooks/useChatPanel.test.tsx`
+- If a deployed environment is available, rerun `playwright/e2e/chat.spec.ts` for the mobile project against staging/development.
+
+**Open questions:** None blocking. A larger URL-as-source-of-truth modal model would be cleaner, but the guarded reconciliation is the smallest fix supported by this artifact.
+
+**Residual risk:** If a different writer repeatedly strips `chatWorkerId` every render, reconciliation could loop or hide a deeper ownership bug. The shift guard and tests reduce stale-worker risk, and URL-write telemetry would make any remaining loop diagnosable.
+
+## Prior related context
+
+- `[ticket redacted]`: prior investigation.
+- `[ticket redacted]`: duplicate prior investigation.
+- `[ticket redacted]`: prior implementation for the same family of mobile chat URL flakes.
+- change [reference redacted]: test-only hardening available after removing the exact product-side reconciliation that this recurrence now supports.

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-12.md

@@ -0,0 +1,99 @@
+# Historical plan snapshot
+
+## Groundcrew
+
+Repository: [mobile frontend]
+Implementation workflow: use the `cb-work` skill when available. If that skill is unavailable, use the `core:go` skill.
+
+## Task
+
+Fix the flaky Playwright flow where the rate-negotiation `SlideToConfirmButton` sometimes does not invoke the proposal action, leaving the test on `/shift-negotiation/:shiftId` after the slide gesture instead of navigating back to `/shift/:shiftId`.
+
+Include this implementation ticket ID in the change body.
+
+## Flake Details
+
+```json
+{
+  "repo": "[mobile frontend]",
+  "test": "Rate Negotiations new UI should propose new rate for a shift and end negotiation",
+  "file": "playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts:369",
+  "framework": "playwright",
+  "isNewFlaky": false,
+  "failures": [
+    {
+      "error": "Error: expect(page).toHaveURL(expected) failed\n\nExpected: \"[external evidence reference]"\nReceived: \"[external evidence reference]"\nTimeout: 30000ms",
+      "stack": "rateNegotiationv2.spec.ts:466",
+      "branch": "main",
+      "pipeline": "[external evidence reference]",
+      "commit": "7638c4bd74e598414254053d8c97e0611dbad943",
+      "durationMs": 52870,
+      "shard": "2/4",
+      "timestamp": "2026-07-06T16:26:13Z"
+    }
+  ]
+}
+```
+
+## Plan Output
+
+Confidence: 4/5. The failure artifact directly shows the slide CTA still open after the gesture, and the component code has a concrete stale-state completion check. Confidence is not 5/5 because the LLM report hit network retention caps, so absence of a retained `POST /negotiation` is strong but not absolute proof that no mutation request was emitted.
+
+Failure surface: User action no-op, with product component behavior as the likely root and test harness diagnostics as a secondary improvement.
+
+Current main status: The affected code path still exists on current `origin/main`/HEAD `a58a6893d9c025196f1b10bff49b548f2cd03910`. No open change with label `flaky-test-fix` matched this test or file. Commit `77129b26883` landed after the failing commit and only adds `workerAuthToken` to shift-offer setup; it does not address the slide/no-op path.
+
+Symptom: In failed attempt 0, the test executes `slideToConfirmButton(page, "Slide to propose $33.00/hr")`, then `expect(page).toHaveURL(shiftDetailsPath)` times out at `playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts:467`. The actual URL stays `/home-v2/shift-discovery/list/shift-negotiation/6a4bd731b22f99dbbc009a7d`.
+
+Root cause: `SlideToConfirmButton` decides whether the slide completed in `handlePointerUp` using React state `offsetX`. During a fast drag/release, especially under CI load, the last `pointermove` can call `setOffsetX(...)` but `pointerup` can still observe the previous render's `offsetX` value. That makes the component reset to 0 and skip `onConfirm()`, even though the pointer moved far enough. The Playwright helper triggers this edge by moving and releasing quickly after the rate-negotiation footer migration to `SlideToConfirmButton` in commit `7638c4bd74e`.
+
+Evidence:
+
+- LLM report `/tmp/playwright-llm-report-28806486162/llm-report.json` has one flaky test in the shard: 15 passed, this test passed only on retry.
+- Failed timeline: `Bounding box getByText('Slide to propose $33.00/hr').locator('../..')` at 20536ms, `Mouse move` at 20541ms, `Mouse down` at 20545ms, `Mouse move` at 20562ms, `Mouse up` at 21272ms, then `Expect "toHaveURL"` fails at 21275ms.
+- Failure screenshot shows the `Shift Rate Negotiation` bottom sheet still open with `Slide to propose $33.00/hr`; it is not in loading/success state and has not navigated away.
+- Retained negotiation network entries around the slide are reads only: `GET /api/negotiation/shifts/:shiftId?offerId=...` at 19826ms and 20878ms. There is no retained `POST /negotiation` proposal write near the slide. The report did hit network caps (`instancesDroppedByGroupCap: 17`, `instancesEvictedAfterAdmission: 10`), so this supports but does not solely prove the no-op.
+- `src/appV2/redesign/system/ui-components/components/SlideToConfirmButton/index.tsx` lines 177-209 update `offsetX` in `handlePointerMove` and read `offsetX` in `handlePointerUp` to decide `offsetX / currentMax >= 0.8`.
+- `playwright/utils/button.ts` lines 43-59 uses a generic fast mouse drag for every `SlideToConfirmButton`; `playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts` uses it at lines 464 and 634. Timekeeping E2Es also use the same helper.
+- There is no dedicated `SlideToConfirmButton` component test file covering fast drag/release behavior.
+
+Proposed fix:
+
+1. In `src/appV2/redesign/system/ui-components/components/SlideToConfirmButton/index.tsx`, stop using render-state `offsetX` as the source of truth inside `handlePointerUp`. Compute the release offset from the current `PointerEvent` (`event.clientX - dragStateRef.current.startX`) and/or keep the latest clamped offset in a ref that is updated synchronously in `handlePointerMove`. Use that computed/ref value for the threshold check, then update state for rendering.
+2. Keep the reset/complete state transitions the same: partial drags reset to 0; completed drags set to max, mark complete, and call `onConfirm()` exactly once.
+3. Add focused appV2 component coverage for `SlideToConfirmButton`: a fast drag that crosses the threshold and releases immediately calls `onConfirm`, a partial drag does not, and disabled/loading states still do not call `onConfirm`. Prefer user-facing queries where possible; if the current component lacks accessible semantics, keep the test scoped to the rendered CTA text and pointer events.
+4. Improve E2E diagnostics around the proposal action in `playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts`: after sliding, wait for the deterministic proposal mutation or a post-success route/UI signal so a future no-op fails at the missing `POST /negotiation`/confirm signal instead of a 30s URL timeout. Avoid arbitrary sleeps or blind retries.
+
+Observability to reach 5/5:
+
+- Add deterministic Playwright evidence around the slide action: wait for the `POST /negotiation` request/response after the proposal slide and include its absence in the failure path.
+- If touching the component, consider adding temporary debug output gated by the existing E2E/debug localStorage pattern or test-only attachments for slide metrics (`startX`, release delta, max offset, threshold result) if the component remains hard to diagnose in traces.
+- No backend telemetry is required for this plan unless the deterministic wait proves the mutation is emitted and failing server-side.
+
+Sibling candidates:
+
+- `playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts:634` uses the same helper in the counter-proposal path.
+- `playwright/e2e/shift/timekeeping.spec.ts` uses `slideToConfirmButton` for clock-out flows at lines 663, 755, 858, and 1010.
+- All product uses of shared `SlideToConfirmButton` inherit the stale pointer-state behavior, including shift cancel, timekeeping, booking confirmation, Clipboard Score, and rate negotiation.
+
+Validation plan:
+
+- `npm run test:v2 src/appV2/redesign/system/ui-components/components/SlideToConfirmButton/SlideToConfirmButton.test.tsx`
+- `npm run test:v2 src/appV2/Negotiations/RateNegotiationBottomSheet.test.tsx`
+- With a valid `playwright.env`, run `npx playwright test playwright/e2e/rateNegotiations/rateNegotiationv2.spec.ts --project "Mobile Chrome" --config ./playwright.config.ts`
+- Run the repo's standard verification command if required by the final diff scope.
+
+Open questions: None blocking. The highest-confidence local fix is in the shared slide component; the E2E change should improve diagnostics, not mask the product behavior.
+
+Residual risk: If fixing the slide component reveals a real backend/post-success navigation issue after `POST /negotiation`, the deterministic E2E wait should expose that as a different failure surface with a request/response artifact.
+
+## Acceptance Criteria
+
+- [ ] Fast slide/release over the completion threshold reliably calls `onConfirm` in `SlideToConfirmButton`.
+- [ ] Partial/disabled/loading slide cases remain unchanged.
+- [ ] The rate-negotiation proposal E2E waits on a deterministic proposal or post-success signal instead of relying only on a later URL timeout.
+- [ ] Validation commands above pass or any environment-only blocker is documented in the change.
+
+## Related
+
+Investigation ticket: `[ticket redacted]`

package/skills/flaky-critic/references/backtests/2026-07-16-b8-prior-attempts/inputs/case-13.md

@@ -0,0 +1,25 @@
+# Historical plan snapshot
+
+## Flaky Test Report
+
+The following E2E test in `[admin frontend]` is among the **top 10 flakiest tests** (last 30 days) on the [Datadog Flaky Tests Management]([external evidence reference]) dashboard. Owned by **Synapse**.
+
+### Affected Tests
+
+| \#  | Test                                                                                                             | Failures (30d) | File                               | Repo                                              |
+| --- | ---------------------------------------------------------------------------------------------------------------- | -------------- | ---------------------------------- | ------------------------------------------------- |
+| 1   | `Daily View — Admin User should navigate to daily view, display shifts, interact with filters and shift details` | 6              | `playwright/e2e/dailyView.spec.ts` | [[admin frontend]]([external evidence reference]) |
+
+### Datadog Links
+
+- [Flaky Tests Dashboard]([external evidence reference])
+
+### Context
+
+This test exercises the Daily View page for an Admin User — navigating to it, verifying shifts are displayed, and interacting with filters and shift details. Previous investigations ([ticket redacted], [ticket redacted]) canonical earlier occurrences, but the test continues to flake.
+
+### Recommended Next Steps
+
+1. Check Datadog CI test traces for the specific failure error messages
+2. Compare with previous fix in [ticket redacted] to see if the same root cause has regressed
+3. Investigate filter interaction timing or data loading race conditions