Cancel the mistaken CLS-regression outstanding-issues request

[BigSimmo]

Summary

• Cancels the outstanding-issues inbox request queued in Queue outstanding-issues request: mobile CLS regression on / #2059 (docs/outstanding-issues-inbox/d92786de-de31-4118-84cc-0a9098e7f2e0.json), which claimed a real mobile CLS regression on /.

Context

While investigating why PR #2050's CI kept failing Lighthouse budget, I initially concluded (in #2059) that a real, code-level mobile CLS regression had reappeared on / (measuring 0.236 against a 0.013 baseline across multiple CI runs on the correctly pinned browser).

Follow-up investigation reverses that conclusion. Running the same Lighthouse harness locally against origin/main (CHROME_PATH=/opt/pw-browsers/chromium npm run verify:lighthouse -- --keep, after correcting an earlier wrong CHROME_PATH that made every measurement silently fail with exit code 0 — a trap worth noting for future runs) produced this table:

| run | LCP ms | baseline | TBT ms | baseline | CLS | baseline |
| desktop-documents-search | 811 | 783 | 0 | 0 | 0.119 | 0.119 |
| desktop-dsm | 836 | 846 | 2 | 0 | 0.014 | 0.014 |
| desktop-forms | 757 | 876 | 6 | 14 | 0.063 | 0.063 |
| desktop-root | 699 | 868 | 12 | 2 | 0.006 | 0.006 |
| desktop-therapy-compass | 811 | 793 | 19 | 0 | 0.000 | 0.000 |
| mobile-documents-search | 2339 | 2380 | 530 | 375 | 0.000 | 0.000 |
| mobile-dsm | 2788 | 2373 | 441 | 361 | 0.035 | 0.035 |
| mobile-forms | 2744 | 2357 | 472 | 316 | 0.075 | 0.075 |
| mobile-root | 2338 | 2365 | 422 | 339 | 0.013 | 0.013 |
| mobile-therapy-compass | 2813 | 2388 | 471 | 297 | 0.000 | 0.000 |

Every route/strategy — including mobile-root CLS — matches its committed baseline exactly. main has no code-level CLS regression. The repeated 0.236 CI failures were environmental/CI-infra noise (most plausibly resource contention from the unusually high concurrent CI load PR #2050 generated while its branch was auto-resyncing many times in a short window), not a product defect.

This PR queues a cancel request against the original add request per scripts/ledger-inbox.mjs (node scripts/ledger-inbox.mjs cancel <uuid> --reason "..."), so the false finding does not get reconciled into the canonical docs/outstanding-issues.md ledger.

Verification

• node scripts/ledger-inbox.mjs cancel ... — the script's own validation accepted the request and reported it merge-safe.
• Verification not run beyond that: this is a single generated, schema-validated JSON file under docs/outstanding-issues-inbox/. No source/build/test surface is touched.

Risk and rollout

Not applicable — append-only tracking document correcting a prior tracking document; no code/behavior change.

Notes

• Full investigation detail is in the queued cancel request file itself.

---

Generated by Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[supabase]

This pull request has been ignored for the connected project sjrfecxgysukkwxsowpy because there are no changes detected in supabase directory. You can change this behaviour in Project Integrations Settings ↗︎.

---

Preview Branches by Supabase.
Learn more about Supabase Branching ↗︎.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 23 minutes

Limit details: You’ve used all 1 included review currently available under your plan. You completed 97 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour.

Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 11679299-b84b-4327-bcdd-ba723598e662

📥 Commits

Reviewing files that changed from the base of the PR and between f6e0364 and b72b9e8.

📒 Files selected for processing (2)

• docs/branch-review-records/cc8a51d4e4ee056183065529ec544e6682e14063b450adc6a6ac211b9fe7553e.record.md
• docs/outstanding-issues-inbox/51e687a9-406a-4f2e-bb70-f6ba9aebef53.json

---

_{Comment @coderabbitai help to get the list of available commands.}