Draft PR #634 • Visual Review

Channel Health Diagnostics UI Before / After

This evidence pack documents the user-facing impact of the channel-health diagnostics work for issue #628 and the follow-up UI hardening that landed during review. The screenshots show the same seeded scenarios before the PR and after the current draft head, so the deltas are attributable to this branch rather than a different test setup.

Issue Status
Partially solved. The product now explains the failure path, but bad credentials still need operator action.
Screens Compared
4 paired captures: overview, channels list, auth detail, missing-credentials detail.
Chosen Direction
Shared diagnostics + remediation, not a Telegram-only patch.
Review Hardening
Added neutral checking state, safer tab fallback, and no partial-data overcounting.

What This PR Proves

The screenshots validate the visible remediation experience. The code changes go a bit further than the screenshots alone, so the report separates visual proof from the additional hardening that prevents misleading UI states.

Overview no longer hides the problem
  • Before: dashboard-level attention existed, but the missing-credentials path was easy to miss.
  • After: the overview clearly communicates that channel attention exists and aligns with the richer downstream diagnostics.
Channels list now points to action
  • Before: rows could degrade into vague summaries or omit the useful next step.
  • After: the row copy names the failure and exposes the remediation action more directly.
Auth failures are diagnosable
  • Before: the detail page lacked enough structure for a user to understand what failed.
  • After: the detail page shows what happened, recommended action, credentials entry point, and technical detail.
Config failures are diagnosable
  • Before: missing credentials did not surface a complete remediation path.
  • After: the detail page explains the config problem and exposes the credentials action clearly.

Overview

The dashboard summary is the first place a user looks. It now leads toward the richer diagnostics instead of leaving the channel state effectively opaque.

Overview — Before
Before
Overview before channel diagnostics improvements
Before: the overview conveyed that attention existed, but it did not make the missing-credentials path nearly as actionable as the PR now does downstream.
Overview — After
After
Overview after channel diagnostics improvements
After: the overview aligns with the richer diagnostics flow and no longer relies on the old opaque failure presentation.

Channels List

This is where the PR most clearly replaces vague channel status with named failures and next-step copy.

Channels List — Before
Before
Channels list before channel diagnostics improvements
Before: summaries and remediation copy were incomplete. The list did not consistently tell the user what failed or which action to take next.
Channels List — After
After
Channels list after channel diagnostics improvements
After: the row naming and next-step prompts are explicit. The UI now makes the channel-health state actionable rather than just visible.

Auth Failure Detail

This captures the original class of incident from #628: a channel is enabled but blocked by auth/runtime reality. The page now explains that state instead of flattening it.

Auth Detail — Before
Before
Auth failure detail before channel diagnostics improvements
Before: the user could land on the channel detail view without enough structure to understand what happened, what to try next, or where the credentials/debug entry point was.
Auth Detail — After
After
Auth failure detail after channel diagnostics improvements
After: the page names the auth failure, provides recommended action, exposes the credentials entry point, and shows technical detail useful for debugging.

Missing Credentials Detail

Missing or incomplete channel configuration now gets the same structured treatment as auth failures.

Missing Credentials — Before
Before
Missing credentials detail before channel diagnostics improvements
Before: the config failure path was visually thin and did not fully guide the user back to the required credentials work.
Missing Credentials — After
After
Missing credentials detail after channel diagnostics improvements
After: the UI names the config problem, explains the credentials requirement, and surfaces the action path directly on the page.

Additional Hardening Beyond The Screenshots

Review surfaced a few cases where the visible diagnostics could still be misleading. Those are fixed in code even when they do not have a dedicated screenshot in this pack.

No more false “Stopped” state for unknown-but-enabled channels
  • Enabled channels without backend status now stay neutral as Checking.
  • This prevents the UI from manufacturing attention where the runtime has not yet reported anything.
No more partial-data overcounting in overview
  • Overview attention synthesis only runs when the loaded instance slice is complete.
  • This avoids claiming more failing channels than the current dataset can justify.
Fallback remediation is channel-specific
  • zalo_personal now points to re-auth instead of generic credentials repair.
  • Generic missing-credentials fallback stays on the credentials path with localized copy.
Invalid channel detail tabs fail safely
  • Unsupported ?tab= values now fall back to general.
  • Non-Telegram channels can no longer land on the Telegram-only groups tab.

Assertion Snapshot

These structured checks back up the screenshots by recording the UI markers that were present before and after.

Before
{
  "overview": {
    "needsAttention": true,
    "authChannelVisible": true,
    "missingChannelVisible": false
  },
  "channelsList": {
    "authSummary": false,
    "missingSummary": true,
    "nextStepVisible": true,
    "credentialsActionVisible": false
  },
  "authDetail": {
    "whatHappened": true,
    "recommendedAction": true,
    "reviewCredentials": false,
    "technicalDetail": false
  },
  "missingCredentialsDetail": {
    "missingCredentials": true,
    "completeRequiredCredentials": false,
    "openCredentials": false
  }
}
After
{
  "overview": {
    "needsAttention": true,
    "authVisible": false,
    "missingVisible": false
  },
  "channelsList": {
    "authSummary": true,
    "missingSummary": false,
    "reviewCredentials": true,
    "completeCredentials": true
  },
  "authDetail": {
    "whatHappened": true,
    "authFailed": true,
    "recommendedAction": true,
    "openCredentials": true,
    "technicalDetail": true
  },
  "missingDetail": {
    "whatHappened": true,
    "configInvalid": true,
    "completeCredentials": true,
    "openCredentials": true,
    "technicalDetail": true
  }
}
Visual verdict: this PR fixes GoClaw’s product-side diagnosability gap for the seeded auth and config channel failures. It does not auto-repair invalid credentials, so the incident class from #628 is better described as diagnosable and actionable, not automatically healed.