docs(issues): capture the unreproduced forms UI failure and the sync-loop CI gap

[BigSimmo]

Summary

Two loose ends from the PR #2149 session, recorded as /issues inbox requests so they survive the session instead of being re-derived later. Docs-only: two new files under docs/outstanding-issues-inbox/, no source, config, or canonical-ledger changes.

• tests/ui-forms-section-nav.spec.ts failed once on fix(dsm): stop the diagnosis page stating its criteria twice #2149 and was never reproduced. Production UI shard 3 reported 166 passed / 1 failed on "expands information previews into one continuous answer": after clicking the trigger, the preview text should leave the trigger and appear in the panel, and it stayed in the trigger. Not a timing race — the locator polled 24 times across the full 10s timeout and resolved to 1 element every time, so it was a stable wrong state. Not attributable to fix(dsm): stop the diagnosis page stating its criteria twice #2149, which changed exactly dsm-diagnosis-page.tsx and one ledger record, zero forms files, against behaviour owned by src/components/forms/form-detail-page.tsx. Not in tests/flake-ledger.json. The job's re-run and the following cycle were both cancelled, so fix(dsm): stop the diagnosis page stating its criteria twice #2149 merged with the question open.

• The record also captures why CI can hide this. UI jobs are path-scoped, so a docs-only push to main skips Production UI entirely — verified in main run 32183858120, where Production UI, Production UI critical, Build and Lighthouse budget all report conclusion: skipped. The CI-triage bot nevertheless cited that run as "Compared with main CI run #12334 (success)", which is an aggregate comparison that never exercised the test and should not be read as a green baseline.

• #145 is recorded RESOLVED, but its guard does not cover the path actually used. That row closed on the basis that the operator sync helper skips update-branch while required CI is in flight. A plain git merge origin/main + push, and GitHub's Update branch button, bypass it. fix(dsm): stop the diagnosis page stating its criteria twice #2149 took nine merge-main heads in 3.5 hours; the aggregate went red eight times as CANCELLED with no failing job and never once for a genuine failure of the diff. The cancellations widened as the interval tightened, ending with a cycle that lost all ten jobs including changes itself, whose *_CHANGED outputs were empty because scope detection never completed. Its real cost was the loss of the one genuine signal above.

• Each record notes what must not be done: no quarantine on a single observation and no weakening of the assertion for the first; and for the second, no disabling cancel-in-progress for pull requests, which is deliberate, pinned by tests/ci-cache-safety.test.ts, and whose base-branch exemption exists for a separate reason. #095 is explicitly credited as having behaved correctly throughout — it distinguished cancellation from failure and correctly stayed red, since a cancelled job verifies nothing.

Both are new: docs/outstanding-issues.md has no row mentioning this spec, and the sync finding is a gap against a closed row rather than a duplicate of the open churn item #CCZ4HB, which concerns the review-bot budget.

Verification

• npm run verify:pr-local

Verification not run: npm run verify:pr-local — this adds two JSON files under docs/outstanding-issues-inbox/ and touches no executable path, so the applicable ledger gates were run directly instead:

• npm run check:ledger-write-discipline → Ledger write discipline passed for b400b138f8c1..HEAD. (first run correctly refused while the requests were untracked, since it compares committed refs; re-run after committing)

• npm run check:outstanding-issues → Outstanding-issues guard passed: 378 rows (44 open, 334 archived), unique display and durable ids, collision-free allocation enabled, deprecated next-id marker ignored, no merge driver, no ids deleted from base b400b138f8c1.

• Inbox integrity → Ledger inbox check passed: 23 pending request(s), 370 applied.

• npm run format → no changes to the new files.

• npm run verify:ui when UI, routing, styling, browser behavior, reduced-motion, or forced-colors behavior changed

UI verification not run: docs-only change, no UI surface touched.

Risk and rollout

• Risk: None. Two additive inbox request files; the canonical docs/outstanding-issues.md is untouched and is only edited later by npm run issues:reconcile.
• Rollback: git revert the single commit, or drop the two files.
• Provider or production effects: None.

Notes

Follow-up work after #2149 merged, so this is a fresh branch restarted from main rather than new commits on merged history. Run npm run issues:reconcile from a serialized ledger branch after this lands to apply both requests to the canonical ledger.

---

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 current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in: 17 minutes

Limit details: You’ve used the included review currently available. Your 102 included PR review attempts over the past 7 days set your current allowance 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 within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 840b4574-52e7-4105-9c6d-3af832fa6b6b

📥 Commits

Reviewing files that changed from the base of the PR and between 51ecb89 and 43560c7.

📒 Files selected for processing (2)

• docs/outstanding-issues-inbox/35ca1ac6-1c59-4ef5-b19e-b047796dba90.json
• docs/outstanding-issues-inbox/3fdf9173-da22-4d0c-aed6-51966f091f43.json

---

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