[HouMinXi]

Summary

• Adds a Grok Bot connection flow with login, token refresh and its own executor.
• Adds the dashboard for bot lists, transcript watch, cards and sending.
• Includes Grok translations, namespace metadata, provider documentation and five Grok environment variables.

Integration fixes

The repair series restores upstream API, provider, authorization, usage and UI contracts removed by the original branch. It fixes malformed request handling, cancellation and stale-watch cleanup, per-request bridge ownership, and late UI updates after switching accounts or bots. Auxiliary routes and cleanup use the existing active-lease admission check; this is a check before dispatch, not a reservation for the whole stream.

Main repair checkpoint: 086ee08887e8373c30603dbf3c5b24765d5b90c5.

Follow-up: 78c39ae93b0abcb45fdee1bac8c8443b91a8d35d. This fixes the Sidebar matchMedia fixture, updates the reserved-prefix regression for grok-bot, and regenerates documentation artwork with the correct provider counts and missing digit glyph. Only tests, documentation generators and generated SVGs change. CI for this follow-up has not yet been validated.

Validation at the main repair checkpoint

• Passed 456 focused Node tests and 36 React tests, with normal process exits.
• Passed full lint and the normal commit hooks. The private UI-kit snapshot check was skipped because its reference clone was unavailable.
• Passed a separate typecheck of all 14 changed API route roots and their dependencies, with unchanged compiler options. The full API gate could not complete locally because of memory limits.
• The full dashboard gate completed with the inherited cliTools TS2353 error. Five pre-existing missing test mappings and the unchanged error-helper failure in the sync-models route remain. Quality thresholds and baselines were not relaxed.

The remote full API gate completed and failed with two diagnostics outside its frozen baseline: availabilityRouterFilters.ts TS2345 and cliTools.ts TS2353. Both also reproduce in a focused typecheck on the exact release base, 139070680f77728e2309eb4df18463282a1c990a. All CI runs for the main repair checkpoint have finished. The application build passed, but the overall CI result was failure. These results apply to 086ee08887e8373c30603dbf3c5b24765d5b90c5, not the follow-up commit.

A full application build and live OAuth/Grok compatibility have not been verified locally.

[HouMinXi]

All latest checks have finished for 78c39ae93b0abcb45fdee1bac8c8443b91a8d35d, tested against release base 139070680f77728e2309eb4df18463282a1c990a. CI remains red. The earlier Sidebar fixture, reserved-prefix and SVG generation failures no longer appear. Build and Quality Ratchet passed; Semgrep also passed.

The UI job passed the canonical MCP stage (590/590). Its later UI stage recorded 4,113 passes and one skip, but two unhandled timer errors failed the job. Both errors reproduce on the exact release base when observing for 2.3 seconds after real jsdom teardown. The normal focused suites pass on their own; this was a teardown diagnostic, not a rerun of the full baseline CI. The reload timer originates in useModelImportHandlers.test.tsx, test preserves a discovered per-model targetFormat, not the last-active file named by Vitest.

The other reproduced baseline blockers cover the two API diagnostics, SSO, environment/migration docs, generated skills, provenance, missing test mappings and sync-models error handling. #18658 contains the shared repairs. The provenance commit ca7fc3f5 exists on GitHub but is unavailable in the normal release checkout; that repair uses the landed b19031110b commit. OSV remains 29 against a limit of 27 with inputs identical to the base. No same-time base rescan was made, and the effect of #18658's node-forge upgrade on the current count is not established.

OmniGlyph timer cleanup already has #18525. Reload-timer isolation is being prepared locally in the tests. That work has not changed product navigation or opened another issue.

[HouMinXi]

At 320e22ac, all eight unit-test shards (including the boot harness fix), Build, Coverage and Quality Ratchet passed. The Quality Gates, API Route Typecheck and Semgrep workflows also passed. CI is still red on the UI job: 4,130 passed, two failed and one skipped.

Both failures are in the batch-input wizard tests: the 60,000-row CSV case exceeded its 15-second limit, then the small JSONL case failed because its select element was absent. The batch test and inspected direct production paths are byte-identical to release 075d6e5; the earlier Grok 1d4157f3 and Jules b105a0be runs passed these tests. The original four-case suite also passes locally. This does not establish the cause of the first CI timeout or prove a baseline failure.

A controlled delay reproduces the timeout followed by the next-test failure, showing that unfinished async work can contaminate the following case. A proposed bounded cleanup still fails with a longer delay, so that partial patch has not been published. The initial slowdown remains unexplained.

Could a maintainer rerun the failed UI job on this head to help distinguish a repeatable failure from a scheduling-sensitive one? My account lacks upstream write access to rerun it. This is a diagnostic request; no fix for these two failures is claimed.