You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up findings from the zcode (GLM-5.3) review of #1385 that were below the merge bar (no critical/high). Each was verified against the code; fix in small PRs.
medium — native/macos/MCPProxy/MCPProxy/Views/DashboardView.swift:79-94: F7 (macOS token-savings 'estimate' label) is only PARTIALLY fixed: the Token Savings card now shows the 'estimate' capsule correctly, but the Dashboard's top-center hub badge renders the identical simulated stats.savedTokensPercentage figure with no 'estimate' indication at all -- the same number is labelled in one place and unlabelled, more prominently, in another.
medium — frontend/src/views/Activity.vue:2363-2387,2702-2704,2714-2748,1573-1618: Clicking the F2 conflict banner's 'Clear filters' button leaves the Activity table stuck showing 'No activity records found' instead of refetching: clearFilters() sets filterServer/filterTool to '', which fires the refetch watch synchronously while scopeConflict is still stale-true (only applyRouteFilters, run after the async router navigation completes, resets it) -- loadActivities() early-returns under the stale flag, and once scopeConflict later flips to false the refetch watch (which does not depend on scopeConflict) never re-fires.
medium — frontend/src/views/Activity.vue:1791-1808,2779-2786: The new F8 scoped-sessions fetch (loadScopedSessionsForView, fired via an immediate watch during setup) and the pre-existing unscoped loadSessions() (fired in onMounted, slightly later) both write the same sessionsRaw ref with no sequencing/ordering guard, unlike the reloadSeq pattern this codebase already uses elsewhere for the identical class of race (Usage.vue). Under normal in-order responses the later-issued unscoped fetch wins and overwrites the scoped result.
low — internal/httpapi/scope_filters.go:74-77: A scope-filter parameter sent with an empty value (?token= with no value) bypasses the FR-080a gate entirely and returns 200 with unfiltered rows instead of the mandated 400.
low — cmd/mcpproxy/activity_cmd.go:388: activity summary --from exits 1 correctly (no window widening) but with a different message than the exact string FR-075 pins verbatim, even though this same PR reproduces the contract's --tool conflict string character-for-character elsewhere.
low — native/macos/MCPProxy/MCPProxy/State/ScopeFilter.swift:150-155: Every macOS in-app link (session-row drill-down, token row, session hand-off) builds a fresh ScopeFilter from scratch instead of copying sticky from/to fields off the current filter the way the Web linkTo does, so active sticky filters are silently discarded on navigation.
low — native/macos/MCPProxy/MCPProxy/Views/ActivityView.swift:786-799,841-845: loadSessions bails out silently when apiClient is nil, so with the core stopped the Sessions view shows the generic "No sessions recorded" instead of the core-not-running message the Calls view in the same PR already distinguishes.
low — native/macos/MCPProxy/MCPProxy/Views/ActivityFolding.swift:30: A folded tool_quarantine_change batch prints the record's status as the verb with no fallback for an empty action, unlike the Web sibling which falls back to 'changed'.
Follow-up findings from the zcode (GLM-5.3) review of #1385 that were below the merge bar (no critical/high). Each was verified against the code; fix in small PRs.
native/macos/MCPProxy/MCPProxy/Views/DashboardView.swift:79-94: F7 (macOS token-savings 'estimate' label) is only PARTIALLY fixed: the Token Savings card now shows the 'estimate' capsule correctly, but the Dashboard's top-center hub badge renders the identical simulatedstats.savedTokensPercentagefigure with no 'estimate' indication at all -- the same number is labelled in one place and unlabelled, more prominently, in another.frontend/src/views/Activity.vue:2363-2387,2702-2704,2714-2748,1573-1618: Clicking the F2 conflict banner's 'Clear filters' button leaves the Activity table stuck showing 'No activity records found' instead of refetching: clearFilters() sets filterServer/filterTool to '', which fires the refetch watch synchronously while scopeConflict is still stale-true (only applyRouteFilters, run after the async router navigation completes, resets it) -- loadActivities() early-returns under the stale flag, and once scopeConflict later flips to false the refetch watch (which does not depend on scopeConflict) never re-fires.frontend/src/views/Activity.vue:1791-1808,2779-2786: The new F8 scoped-sessions fetch (loadScopedSessionsForView, fired via an immediate watch during setup) and the pre-existing unscoped loadSessions() (fired in onMounted, slightly later) both write the same sessionsRaw ref with no sequencing/ordering guard, unlike the reloadSeq pattern this codebase already uses elsewhere for the identical class of race (Usage.vue). Under normal in-order responses the later-issued unscoped fetch wins and overwrites the scoped result.internal/httpapi/scope_filters.go:74-77: A scope-filter parameter sent with an empty value (?token= with no value) bypasses the FR-080a gate entirely and returns 200 with unfiltered rows instead of the mandated 400.cmd/mcpproxy/activity_cmd.go:388: activity summary --from exits 1 correctly (no window widening) but with a different message than the exact string FR-075 pins verbatim, even though this same PR reproduces the contract's --tool conflict string character-for-character elsewhere.native/macos/MCPProxy/MCPProxy/State/ScopeFilter.swift:150-155: Every macOS in-app link (session-row drill-down, token row, session hand-off) builds a fresh ScopeFilter from scratch instead of copying sticky from/to fields off the current filter the way the Web linkTo does, so active sticky filters are silently discarded on navigation.native/macos/MCPProxy/MCPProxy/Views/ActivityView.swift:786-799,841-845: loadSessions bails out silently when apiClient is nil, so with the core stopped the Sessions view shows the generic "No sessions recorded" instead of the core-not-running message the Calls view in the same PR already distinguishes.native/macos/MCPProxy/MCPProxy/Views/ActivityFolding.swift:30: A folded tool_quarantine_change batch prints the record's status as the verb with no fallback for an empty action, unlike the Web sibling which falls back to 'changed'.