feat(coc): Agents canvas follow-ups — hide toggle without sub-agents + fix overlay scroll#328
Merged
Merged
Conversation
The Agents canvas is only meaningful once a chat has actually spawned sub-agents. ChatDetail now derives `hasSubAgents` from the agent-run tree and: - hides the Thread/Agents toggle when there are none, and - renders from `effectiveView` (= `view` only when sub-agents exist, otherwise `thread`) so a stale `?view=agents` deep-link can't strand the user on an empty canvas with no toggle to escape — it instead "waits", revealing the canvas the moment the first sub-agent appears. The thread-only flow cards (Ralph start, Implement-plan) also key off `effectiveView`, so they still show on the thread fallback. Adds a static-analysis test for the gating wiring (mirroring the other ChatDetail source tests in that folder) and updates the coc-knowledge dashboard-spa reference. The data contract this relies on (no `Task` calls ⇒ no children) is already covered in agent-canvas-data.test.ts. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The agents-canvas wheel-to-zoom handler in the shared `useZoomPan` hook ran for any wheel event bubbling to the canvas container, including ones from inside the open AgentInspector panel — so scrolling the panel zoomed the canvas instead of scrolling the panel's content. The wheel handler now skips events whose target is inside a `[data-no-drag]` region — the same opt-out the pan-drag handler already honors. The inspector (and the toolbar/legend, and the DAG charts' zoom controls) already carry `data-no-drag`, so their content scrolls natively while the canvas surface still zooms as before. Adds real-DOM wheel tests to useZoomPan.test.ts (the existing tests poke a mock ref and never attach the native wheel listener) covering both the zoom-over-surface and no-zoom-inside-overlay cases, and notes the opt-out in the coc-knowledge dashboard-spa reference. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The pre-save `data-unsaved === 'true'` check read the attribute synchronously right after the title edit, while the post-save check already used `waitFor`. `hasUnsavedChanges` reaches the (mocked) chat lens a render-tick after the edit re-renders the panel, so under CI load the bare read caught a stale 'false' (observed on the macos-latest shard 1 of coc-test). Poll for it with `waitFor`, matching the post-save assertion. Test-only; unrelated to the agents-canvas changes in this PR — the chat stack is fully mocked here, so it surfaced purely as CI flake on this PR's run. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
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.
Two follow-up improvements to the Agents canvas (the spatial sub-agent run tree shipped in #326).
1. Hide the Thread/Agents toggle until the chat has sub-agents
feat(coc): hide Thread/Agents toggle until the chat has sub-agentsThe Agents canvas is only meaningful once a chat has actually spawned sub-agents, so showing the
Thread | Agentstoggle on a plain chat was noise.ChatDetailnow deriveshasSubAgentsfrom the agent-run tree and:effectiveView(= viewonly when sub-agents exist, otherwisethread). This means a stale?view=agentsdeep-link on a chat without sub-agents can't strand the user on an empty canvas with no toggle to escape — it falls back to the thread and "waits", revealing the canvas the moment the first sub-agent appears.The thread-only flow cards (Ralph start, Implement-plan) also key off
effectiveView, so they still show on the thread fallback.2. Don't zoom the canvas when scrolling inside an overlay
fix(coc): don't zoom the canvas when scrolling inside an overlayThe wheel-to-zoom handler in the shared
useZoomPanhook fired for any wheel event bubbling up to the canvas container — and theAgentInspectorpanel renders inside that container. So scrolling the inspector's content zoomed the canvas instead of scrolling the panel.The wheel handler now bails when the event originates inside a
[data-no-drag]region — the same opt-out the pan-drag handler already honored. The inspector already carriesdata-no-dragon itsoverflow-y: autoelement, so its content now scrolls natively while the canvas surface still zooms as before. As a bonus, the toolbar/legend (and the DAG charts' zoom controls, which also usedata-no-drag) no longer trigger an accidental zoom when scrolled over.Testing
ChatDetail-agents-toggle.test.ts— static-analysis test for the toggle/effectiveViewwiring (matching the repo's existingChatDetailsource-test convention; the component is too hook/context/SSE-heavy to render).useZoomPan.test.ts— the existing tests poke a mock ref and never attach the native wheel listener; the new ones cover zoom-over-surface (withpreventDefault) and no-zoom-inside-[data-no-drag]-overlay.useZoomPanconsumers' suites (WorkflowDAGChart×2, all DAG tests) — all green.npm run build:clientclean;eslintreports 0 errors on changed files.Reviewer notes
useZoomPanhook. The change is additive (only affects elements that opt in with[data-no-drag]); behavior for the WorkflowDAG consumers is unchanged except that scrolling directly over their already-data-no-dragzoom controls no longer zooms — a strict improvement.coc-knowledgedashboard-spa.mdreference updated for both behaviors.🤖 Generated with Claude Code