feat(bluebird): open channel CONTEXT.md from new-task chip

[raquelmsmith]

Problem

In a channel's new-task composer (project-bluebird), the Using: #<channel> CONTEXT.md chip could only be dismissed (×) — there was no way to see what the CONTEXT.md actually contains before submitting. After submit you can open the context tab to read it; this brings the same affordance to the composer.

Why: users wanted to review the channel context that will be attached to a task before sending it, not only afterward.

Changes

• TaskInput: new optional onContextChipClick prop turns the chip's icon+label into a button (tooltip "View this context"). The × dismiss is unchanged, and the other TaskInput callers are unaffected.
• ChannelContextPanel (new): read-only markdown panel with a header + close button, mirroring ChannelContextTab.
• WebsiteNewTask: wires the chip to a right-side ResizableSidebar panel; content is mounted only while open, and the chip stays non-interactive when the channel has no CONTEXT.md.
• analytics-events: added a view_context ChannelActionType, tracked on chip click.

How did you test this?

• pnpm --filter @posthog/ui typecheck and @posthog/shared typecheck — clean
• Biome lint on all touched files — clean
• New Vitest suites (5 tests, all passing): ChannelContextPanel (title/body/no-prefix/close) and WebsiteNewTask (chip → panel opens + view_context tracked; chip disabled when no context)

Not done: manual run of the Electron app.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

---

Created with PostHog Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit dca1847.}

[github-actions]

Purely additive UI feature — new optional prop on TaskInput (fully backward-compatible), new side-panel component with tests, and a new analytics event type. No production-risk patterns: no data-model changes, no API contract breaks, no forbidden imports, and all business logic stays out of stores and components. Zero reviews is acceptable here given the additive, well-tested, self-contained nature of the change.

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/ui/src/features/canvas/components/WebsiteNewTask.tsx:40-47
`view_context` tracks on every toggle, so closing the panel fires the event a second time. Each open→close→open cycle inflates the metric by 2×. The fix is to move the `track` call inside the state updater where the previous value is available, firing only when transitioning from closed to open.

```suggestion
  const handleContextChipClick = useCallback(() => {
    setContextPanelOpen((open) => {
      if (!open) {
        track(ANALYTICS_EVENTS.CHANNEL_ACTION, {
          action_type: "view_context",
          surface: "new_task",
          channel_id: channelId,
        });
      }
      return !open;
    });
  }, [channelId]);
```

### Issue 2 of 2
packages/ui/src/features/canvas/components/ChannelContextPanel.test.tsx:34-50
The two title-rendering cases test the same rendering property under different `channelName` inputs and are a natural fit for `it.each`, which is the preferred parameterised style in this codebase.

```suggestion
  it.each([
    {
      channelName: "project-bluebird",
      expectedTitle: "#project-bluebird CONTEXT.md",
    },
    { channelName: undefined, expectedTitle: "CONTEXT.md" },
  ])(
    "renders title '$expectedTitle' for channelName=$channelName",
    ({ channelName, expectedTitle }) => {
      render(
        <Theme>
          <ChannelContextPanel
            channelName={channelName}
            body="# Heading\n\nSome **context** body."
            onClose={vi.fn()}
          />
        </Theme>,
      );
      expect(screen.getByText(expectedTitle)).toBeInTheDocument();
    },
  );
```

_{Reviews (1): Last reviewed commit: "feat(bluebird): open channel CONTEXT.md ..." | Re-trigger Greptile}

[greptile-apps]

view_context tracks on every toggle, so closing the panel fires the event a second time. Each open→close→open cycle inflates the metric by 2×. The fix is to move the track call inside the state updater where the previous value is available, firing only when transitioning from closed to open.

Suggested change

	const handleContextChipClick = useCallback(() => {
	setContextPanelOpen((open) => !open);
	track(ANALYTICS_EVENTS.CHANNEL_ACTION, {
	action_type: "view_context",
	surface: "new_task",
	channel_id: channelId,
	});
	}, [channelId]);
	const handleContextChipClick = useCallback(() => {
	setContextPanelOpen((open) => {
	if (!open) {
	track(ANALYTICS_EVENTS.CHANNEL_ACTION, {
	action_type: "view_context",
	surface: "new_task",
	channel_id: channelId,
	});
	}
	return !open;
	});
	}, [channelId]);

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/ui/src/features/canvas/components/WebsiteNewTask.tsx
Line: 40-47

Comment:
`view_context` tracks on every toggle, so closing the panel fires the event a second time. Each open→close→open cycle inflates the metric by 2×. The fix is to move the `track` call inside the state updater where the previous value is available, firing only when transitioning from closed to open.

```suggestion
  const handleContextChipClick = useCallback(() => {
    setContextPanelOpen((open) => {
      if (!open) {
        track(ANALYTICS_EVENTS.CHANNEL_ACTION, {
          action_type: "view_context",
          surface: "new_task",
          channel_id: channelId,
        });
      }
      return !open;
    });
  }, [channelId]);
```

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

The two title-rendering cases test the same rendering property under different channelName inputs and are a natural fit for it.each, which is the preferred parameterised style in this codebase.

Suggested change

	it("renders the channel-qualified CONTEXT.md title and body", () => {
	renderPanel();
	expect(
	screen.getByText("#project-bluebird CONTEXT.md"),
	).toBeInTheDocument();
	expect(screen.getByText("Heading")).toBeInTheDocument();
	expect(screen.getByText("context")).toBeInTheDocument();
	});
	it("omits the channel prefix when no name is given", () => {
	render(
	<Theme>
	<ChannelContextPanel body="body" onClose={vi.fn()} />
	</Theme>,
	);
	expect(screen.getByText("CONTEXT.md")).toBeInTheDocument();
	});
	it.each([
	{
	channelName: "project-bluebird",
	expectedTitle: "#project-bluebird CONTEXT.md",
	},
	{ channelName: undefined, expectedTitle: "CONTEXT.md" },
	])(
	"renders title '$expectedTitle' for channelName=$channelName",
	({ channelName, expectedTitle }) => {
	render(
	<Theme>
	<ChannelContextPanel
	channelName={channelName}
	body="# Heading\n\nSome **context** body."
	onClose={vi.fn()}
	/>
	</Theme>,
	);
	expect(screen.getByText(expectedTitle)).toBeInTheDocument();
	},
	);

Context Used: Do not attempt to comment on incorrect alphabetica... (source)

Prompt To Fix With AI

This is a comment left during a code review.
Path: packages/ui/src/features/canvas/components/ChannelContextPanel.test.tsx
Line: 34-50

Comment:
The two title-rendering cases test the same rendering property under different `channelName` inputs and are a natural fit for `it.each`, which is the preferred parameterised style in this codebase.

```suggestion
  it.each([
    {
      channelName: "project-bluebird",
      expectedTitle: "#project-bluebird CONTEXT.md",
    },
    { channelName: undefined, expectedTitle: "CONTEXT.md" },
  ])(
    "renders title '$expectedTitle' for channelName=$channelName",
    ({ channelName, expectedTitle }) => {
      render(
        <Theme>
          <ChannelContextPanel
            channelName={channelName}
            body="# Heading\n\nSome **context** body."
            onClose={vi.fn()}
          />
        </Theme>,
      );
      expect(screen.getByText(expectedTitle)).toBeInTheDocument();
    },
  );
```

**Context Used:** Do not attempt to comment on incorrect alphabetica... ([source](https://app.greptile.com/review/custom-context?memory=instruction-0))

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

New commits pushed (delta classified non_trivial_delta) — stamphog approval dismissed; re-review running automatically.

[github-actions]

Purely additive UI feature with good test coverage. Both bot concerns (analytics double-tracking and it.each style) were already addressed before this review — the current code guards tracking behind the open-transition check and uses the parameterized test form. No showstoppers found.