@clipboard-health/ai-rules 2.41.1 → 2.41.2

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

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

@@ -0,0 +1,111 @@
+# 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
+
+```
+
+## 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:876",
+  "framework": "playwright",
+  "isNewFlaky": false,
+  "failures": [
+    {
+      "error": "Error: expect(locator).toBeVisible() failed\n\nLocator: getByRole('dialog').getByText('Cancel Regular visit')\nExpected: visible\nTimeout: 30000ms\nError: element(s) not found\n\nCall log:\n  - Expect \"toBeVisible\" with timeout 30000ms\n  - waiting for getByRole('dialog').getByText('Cancel Regular visit')\n",
+      "stack": "Error: expect(locator).toBeVisible() failed\n\nLocator: getByRole('dialog').getByText('Cancel Regular visit')\nExpected: visible\nTimeout: 30000ms\nError: element(s) not found\n\nCall log:\n  - Expect \"toBeVisible\" with timeout 30000ms\n  - waiting for getByRole('dialog').getByText('Cancel Regular visit')\n\n    at /opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/homeHealth/fullLifecycle.spec.ts:1272:81\n    at /opt/actions-runner/_work/[admin frontend]/[admin frontend]/playwright/e2e/homeHealth/fullLifecycle.spec.ts:1252: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": "c0fc2cd743575ada27d544cea455e13cd45caf28",
+      "durationMs": 51423,
+      "shard": "2/4",
+      "timestamp": "2026-07-05T01:07:09Z"
+    }
+  ]
+}
+```
+
+## Investigation Plan Output
+
+**Test ID:** [ticket redacted] / sighting-key `a5a77ac290d27dc9`
+
+**Confidence:** 4/5. The trace and failure screenshot directly show the cancel button click completed, no dialog was present afterward, and the case visits section was collapsed at failure. The exact React state transition that collapsed/unmounted the visits subtree is inferred rather than directly instrumented.
+
+**Failure surface:** User action no-op / test harness race. The action target existed and Playwright completed the click, but the expected dialog did not start/render before the visit subtree was collapsed/unmounted. No cancellation backend request was emitted.
+
+**Current main status:** Still present on current `origin/main` / HEAD `56b4dfa7131b6f6b84989145d8f0c2657811c252`. The failing path in `playwright/e2e/homeHealth/fullLifecycle.spec.ts` still does a single click followed by `page.getByRole("dialog").getByText("Cancel Regular visit")`. `CaseCard` still stores expansion state locally with `useModalState(ModalStatus.ended)` and `Collapse unmountOnExit`, and `CancelVisitDialog` still lives under `VisitActions` inside that collapsible visit subtree.
+
+**Symptom:** In Step e, `findVisitRowByWorker` found the booked worker row and the row's `Cancel Visit` button. The test clicked it, then timed out for 30s waiting for `getByRole('dialog').getByText('Cancel Regular visit')` at `playwright/e2e/homeHealth/fullLifecycle.spec.ts:1272`.
+
+**Root Cause:** The cancel-visit path is less resilient than the other hardened home-health dialog helpers. It assumes the visit subtree remains expanded and that one button click will synchronously expose the cancel dialog. In the failed attempt, the subtree was collapsed by the time the dialog assertion began, so the `CancelVisitDialog` mounted under `VisitActions` was not present. Because the helper returns a `Locator` after finding the row but does not re-check expansion or retry opening the dialog, the test can lose the row/dialog state between row lookup and assertion.
+
+**Evidence:**
+
+- LLM report artifact `playwright-llm-report` for run [reference redacted]` has schema v3 summary: 52 total tests, 49 passed, 1 flaky, 0 final failures. This test failed once and passed on retry.
+- Failed attempt error: `getByRole('dialog').getByText('Cancel Regular visit')` timed out after 30000ms at line 1272.
+- Failed attempt trace: `findVisitRowByWorker` reloaded the page, expanded case visits, observed the booked worker link `Playwright Iiuwfojg`, observed that row's `Cancel Visit` button, then completed the click without a click-level error.
+- Trace call evidence: click `call@1019` canonical to `<button aria-label="Cancel Visit" ...>`, completed at point `{x:433.12,y:516.25}`, and had no Playwright error. The next assertion `call@1023` waited 30000ms and timed out.
+- Failure screenshot and `error-context` page snapshot show the target case card visible but collapsed with `Show Case Visits`, and no dialog in the DOM.
+- Network evidence around the failed click shows no `PATCH /[home-health service]/api/v1/*/visits/*` cancellation request after the click. No backend cancellation request started, so this is not a backend cancellation failure.
+- Existing fix check: no open change with `flaky-test-fix` matched `fullLifecycle.spec.ts` or home-health E2E. Recent main commits touched this spec for other modal/row lookup flakes, but none directly address this cancel-dialog open path.
+
+**Proposed Fix:** Test harness fix in `playwright/e2e/homeHealth/fullLifecycle.spec.ts`.
+
+1. Add a helper for opening the cancel-visit dialog that mirrors the hardened patterns already used for verify/reject dialogs:
+   - Accept `page`, the case/row lookup inputs, the target visit id when available, and the expected dialog title.
+   - In a bounded `expect(async () => ...).toPass(...)`, ensure the case visits section is expanded, ensure the target row/action button is visible and enabled, click the button only when the expected dialog is not already open, and assert the cancel dialog title plus confirmation text are visible.
+   - Treat only these states as retryable: the case visits section is collapsed after lookup, the target row or action button detaches before the click, the target action is temporarily hidden/disabled, or the expected dialog title plus confirmation text are not visible after the open click while no cancellation `PATCH` has started.
+   - Treat these states as non-retryable: a cancel dialog opens for a different visit, the helper has already clicked the dialog confirmation button, a cancellation `PATCH /visits/{id}` request has started, or the selected visit id no longer matches the expected visit.
+   - Re-clicking `Cancel Visit` is idempotent only before confirmation because the row action opens a client-side dialog; no backend cancellation mutation starts until the dialog's confirmation button is clicked. If the matching dialog is already open, the helper should return/assert it instead of clicking again.
+   - There is no single deterministic completion signal to wait on for dialog open. The row click only changes React modal state inside `VisitActions`, and `CancelVisitDialog` is mounted under the collapsible `CaseVisits` subtree with `Collapse unmountOnExit`; the cancellation network request happens later on confirmation. A bounded web-first assertion on the specific dialog title and confirmation text is therefore the narrowest observable signal.
+   - Attach diagnostics on failure: whether `Show Case Visits` or `Hide Case Visits` is visible, visible dialog texts, visible action button labels, target worker/link count, target visit id if known, and visible visit IDs.
+2. Use the helper for Step e's booked-visit cancellation. Consider using it for Step d's unbooked cancellation too, since Step d has the same single-click/single-dialog-assertion anti-pattern.
+3. Keep the cancellation response wait scoped to the expected visit id for Step e, as it already is. For Step d, if practical, scope the `PATCH /visits` wait to the selected CNA visit id or add enough diagnostics to prove which visit was patched.
+4. Confirm whether modification reason is required under this test user. If required in local/staging auth context, fill `Reason for change` before clicking the dialog's `Cancel Visit`; if not required, leave unchanged. The field is conditional via `useIsModificationReasonRequired()`.
+
+**Observability to Reach 5/5:**
+
+- Add test diagnostics in the new helper for dialog-open failures: expanded/collapsed case visits state, target row count, target button count, dialog count/text, visible action labels, and a short case-card text snapshot.
+- Add reporter or helper-level network notes for whether a `GET /visits/{id}` or `PATCH /visits/{id}` was observed after the open click. This would distinguish “dialog never mounted” from “dialog mounted loading/error state and then unmounted.”
+- Product telemetry is not required for the immediate fix, but if this reappears outside tests, add a lightweight analytics/log event for cancel dialog open failures or visit-action click-to-dialog transitions in the Home Health case dashboard.
+
+**Sibling Candidates:**
+
+- Step d in `playwright/e2e/homeHealth/fullLifecycle.spec.ts` (`Cancel an unbooked CNA regular visit`) uses the same direct cancel click and broad `page.getByRole("dialog")` assertion.
+- Other `VisitActions` dialogs under the collapsible `CaseVisits` subtree are already partially hardened for edit/verify/reject/remove flows; review any remaining direct `page.getByRole("dialog")` open assertions in this spec before stopping.
+
+**Validation Plan:**
+
+- `npm run lint:fast -- playwright/e2e/homeHealth/fullLifecycle.spec.ts` if the script accepts file args; otherwise `npm run lint:fast`.
+- Run the targeted deployed-env Playwright test if available in this repo/environment, or the repo's documented Playwright command for `playwright/e2e/homeHealth/fullLifecycle.spec.ts` against staging.
+- At minimum, run the relevant TypeScript/lint check after editing: `npm run typecheck` if a full check is acceptable; otherwise the narrowest documented check the repo supports.
+
+**Open Questions:** None blocking. The implementation can proceed with the conservative test-harness fix.
+
+**Residual Risk:** The full lifecycle spec remains long and has many backend/test-data dependencies. This fix should stabilize the cancel-dialog open race, but separate flakes in auth, backend eventual consistency, case visit row lookup, or occurrence verification can still surface in the same test.
+
+## Acceptance Criteria
+
+- [ ] Step e opens the booked-visit cancel dialog through a bounded deterministic helper rather than a one-shot click/assertion.
+- [ ] The helper documents and enforces retryable vs non-retryable states before retrying an open click.
+- [ ] The helper only re-clicks `Cancel Visit` while no matching dialog is open, no confirmation click has happened, and no cancellation `PATCH` has started.
+- [ ] The helper uses the specific dialog title and confirmation text as the bounded web-first assertion because there is no earlier deterministic open-completion signal.
+- [ ] Step d either uses the same helper or is explicitly ruled out with evidence.
+- [ ] Failure diagnostics identify whether the case visits section is collapsed, the target row/action is missing, a dialog is loading/erroring, a different visit dialog is open, or no dialog exists.
+- [ ] The change body includes this implementation ticket ID.
+
+## Related Tickets
+
+Investigation source: [ticket redacted]
+
+Prior related tickets from the source task: [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted], [ticket redacted].

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

@@ -0,0 +1,27 @@
+# Historical plan snapshot
+
+## Parent
+
+[ticket redacted] (flakiness program spec), Workstream C.
+
+## Groundcrew
+
+Repository: [admin frontend]
+Implementation workflow: use the `core:cb-work`/`cb-work` skill when available. If that skill is unavailable, follow this repo's [AGENTS.md/CLAUDE.md]([external evidence reference]) implementation workflow and run the documented verification.
+
+## What to build
+
+[ticket redacted] (available) made the backend return the Cognito username from admin user creation. Username-based Cognito operations are strongly consistent; the harness's current resolve-by-email path goes through the eventually consistent alias index, which is the root cause of the "Cognito user does not exist" storm family. Switch the Playwright harness to consume the returned username for all post-creation Cognito operations, then **delete the armor that only existed to absorb the lookup race**: the PreSignUp readiness probe, oversized readiness budgets (the ~90s window), and any throttle/retry logic whose sole purpose was surviving alias-index lag. Keep armor that guards genuinely different hazards (e.g. cross-process rate-limit throttling for call volume).
+
+First step: verify the username field is actually present in the staging environment's responses (the contract available; deployment matters). If absent, stop and report rather than building against a phantom.
+
+## Acceptance criteria
+
+- [ ] Harness user setup consumes the username from the creation response; no post-creation resolve-by-email remains on the setup path.
+- [ ] Obsolete probe/budget/retry code is deleted, each deletion named in the change body with the hazard it guarded now being impossible.
+- [ ] Auth-dependent spec pass rate is unchanged or better across repeated CI runs (state the runs checked).
+- [ ] A classification note distinguishes deleted armor (lookup-lag) from retained armor (rate-limit volume) so reviewers can check the boundary.
+
+## Notes
+
+Evidence: staging-seed-reliability deep dive; [ticket redacted] storm; consumer-side mitigations 152fe5ea8d7/32c31abeeef. Mobile mirror is a separate ticket that adopts this ticket's approach.