staging → main: auto-promote 5cd5a28 - #2620
Merged
Merged
Conversation
chore: sync main → staging (auto, ff to 61223de)
User screenshot showed pale lavender user bubbles with hard-to-read white text and a nearly-invisible agent bubble blending into the dark panel. Root causes: 1. Tailwind v4 defaults `dark:` to `prefers-color-scheme: dark`. Our ThemeProvider writes `data-theme="dark"` on <html> so user toggle wins over OS — but `dark:` classes elsewhere in the codebase weren't tracking it. Added `@custom-variant dark` to re-bind the variant. 2. `bg-accent` themes lighter in dark mode (--color-accent: #6883e8), dropping white-text contrast to ~3:1 (fails WCAG AA). Switched user bubble to solid blue-600/500 so it stays ~5:1 in both modes. 3. `bg-surface-card` (#1a1d23) was only ~7% lighter than the panel bg (#0e1014), making agent bubbles disappear. Bumped to zinc-700 in dark; light mode keeps the warm surface-card tint. 4. System (error) bubble's /10 overlay was nearly invisible; raised to /25 in dark with stronger border + ink for readability. Sub-tab + textarea polish included: low-contrast `text-ink-soft` → `text-ink-mid`, focus-visible rings on tabs, dark variants on textarea. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
fix(canvas): dark-mode chat bubble contrast
PR #2571 fixed synth-E2E by branching MODEL_SLUG per runtime, but only the langgraph branch was verified at runtime — hermes / claude-code / override / fallback had zero automated coverage. A future regression (e.g. dropping the langgraph case) would silently revert and only surface as "Could not resolve authentication method" mid-E2E. This PR: - Extracts the dispatch into tests/e2e/lib/model_slug.sh as a sourceable pick_model_slug() function. No behavior change. - Adds tests/e2e/test_model_slug.sh — 9 assertions across all 5 dispatch branches plus the override path. Verified to FAIL when any branch is flipped (manually regressed langgraph slash-form to confirm the test catches it; restored before commit). - Wires the unit test into ci.yml's existing shellcheck job (only runs when tests/e2e/ or scripts/ change). Pure-bash, no live infra. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…overage test(e2e): pin pick_model_slug behavior with bash unit tests
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…TP panic-recovery test + refactor 2 more sites to recoverPanic) CR2 review on PR #2625 (REQUEST_CHANGES, 5-axis) flagged two gaps in the panic-recovery coverage that this commit fixes: (1) The helper was only wired into session_auth.go's cache sweeper. The other 2 same-package #2125 call sites (ratelimit.go bucket cleanup, mcp_ratelimit.go bucket cleanup) still used the inline `defer func() { if r := recover(); ... }()` pattern. Refactored both to use the testable `recoverPanic(prefix)` helper. With this change, the helper has 3 in-production call sites in the middleware package (session_auth sweeper, ratelimit cleanup, mcp_ratelimit cleanup) — the contract test in panic_recovery_test.go now covers real production paths, not just one call site. (2) The CTO spec for the original regression asked for "a regression that exercises the real HTTP panic-recovery path (minimal Gin/router stack with the production recovery middleware, a handler that panics, and assertions for 500/ status shape and no process crash)". The previous test exercised a synthetic copy of the goroutine pattern. Added TestHTTPPanicRecovery_HandlerPanicReturns500 that: - wires gin.Recovery() middleware (the standard project-wide recovery that would be the right shape for a follow-up) - registers a /panic handler that panics - asserts the response is 500 (not connection-reset / crash) - asserts the engine survives (a /after-panic follow-up request still returns 200 with the expected body) - wraps the test in an outer recover() that fails the test if a panic escapes gin.Recovery() at the process level Honest gap documented in the test doc: core#2125 only added per-goroutine recover() wrappers — it did NOT introduce a project-wide HTTP-panic recovery middleware. So this test documents the gap and the right shape for a follow-up. The assertions serve as the regression gate: if a future change accidentally re-introduces a process-crash on a handler panic, the 500/200/process-alive assertions will fail. Build clean, vet clean, all tests pass: ok workspace-server/internal/middleware 0.099s ok workspace-server/cmd/server 0.019s go vet clean. The 3 cross-package #2125 sites (terminal.go × 3, a2a_proxy.go × 1, bundle/importer.go × 1) remain inline — the cycle risk between internal/middleware and internal/handlers/internal/bundle (and the cross-package import churn) makes a same-package helper the right scope. Documented in the test doc + this commit body. Refs: molecule-core#2615, core#2125, agent-reviewer-cr2 REQUEST_CHANGES on PR #2620 Co-Authored-By: Claude <noreply@anthropic.com>
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
…ve synthetic handler-panic test) Second-round CR2 review (REQUEST_CHANGES, commit 7fa5e5d) correctly flagged that TestHTTPPanicRecovery_HandlerPanicReturns500 used a synthetic gin.New() + gin.Recovery() engine, not the production router.Setup flow (which uses gin.Default() at line 40 of workspace-server/internal/router/router.go). The test could pass even if the production router was later changed to gin.New() without recovery — exactly the regression shape the test should NOT be able to pass. Per CR2 option 2 in the second review, removed the synthetic handler-panic test from the PR. The doc block now records the production-router gap honestly: testing the real router.Setup requires ~10 dependencies (Hub, Broadcaster, Provisioner, handlers.WorkspaceHandler, etc.) — a non-trivial refactor on its own, and the right scope for a follow-up PR. The PR's merge-blocking coverage is now narrowed to: (a) the real http client.Timeout regression (TestRefreshEnv FromCP_ClientTimeoutFiresOnSlowUpstream) — slow-upstream test against the production refreshEnvFromCP, proves the 10s client.Timeout actually fires (b) the recoverPanic helper contract (TestRecoverPanic_*) — exercised by the 3 in-production call sites in internal/middleware: session_auth sweeper, ratelimit cleanup, mcp_ratelimit cleanup (refactored from the original 1-site coverage in this PR) Build/vet/test all clean: ok workspace-server/internal/middleware 0.115s go vet clean. Refs: molecule-core#2615, core#2125, agent-reviewer-cr2 REQUEST_CHANGES round 2 on PR #2620 (commits ff9874e, 7fa5e5d) Co-Authored-By: Claude <noreply@anthropic.com>
HongmingWang-Rabbit
pushed a commit
that referenced
this pull request
Jun 12, 2026
Serialized merge by gitea-merge-queue after current-main, genuine approvals, and required CI checks were green.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated promotion of
staging(5cd5a28b) tomain. All required staging gates green at this SHA: CI, E2E Staging Canvas, E2E API Smoke, CodeQL.This PR is auto-generated by
.github/workflows/auto-promote-staging.ymlwhenever every required gate completes green on the same staging SHA. It exists because main's branch protection requires status checks "set by the expected GitHub apps" — directgit pushfrom a workflow can't satisfy that, only PR merges through the queue can.Merge queue lands this; no human action needed unless gates fail. Reverse-direction sync (the merge commit on main → staging) is handled by
auto-sync-main-to-staging.yml.