Thanks for the clear request. Current behaviour for context:

• The Code Comments tab shows a blue dot (var(--primary)) when the pull request has code-comment activity newer than your last visit to that tab.
• Visiting the Code Comments tab clears the indicator.
• The colour does not currently consider unresolved vs resolved status.

Below are clarifying choices so we can open an implementation issue with a concrete plan. Please reply with your picks (e.g. 1A, 2A, 3A, 4A, 5A).

1. When should the circle appear?

A. Unviewed activity only (recommended)
Keep today’s visibility rule: show a circle only when there are unviewed code-comment updates. Use colour to distinguish “has unresolved comments” vs “all resolved”. No circle after you have viewed the tab.

• Pros: Matches your clarification; preserves “something new” meaning; smallest behaviour change.
• Cons: Unresolved comments that you already viewed do not keep a persistent reminder on the tab.

B. Persist for unresolved
Always show an “open” coloured circle while any code comment is unresolved (even after viewing). Use blue only for unviewed updates when every comment is resolved.

• Pros: Stronger reminder that review work remains.
• Cons: Changes the indicator from “new activity” to mixed “status + new”; can feel noisy on long-lived PRs.

C. Union of both signals
Show whenever there is unviewed activity or any unresolved comment (colour encodes which case).

• Pros: Never miss open comments or new activity.
• Cons: Most complex mentally and in UI; hardest to explain in a tooltip.

2. Which colour means “open / unresolved”?

A. Warning / orange (var(--warning)) (recommended)
Same attention family as pending review cues elsewhere.

• Pros: Familiar “needs attention” signal; not as alarming as an error.
• Cons: Slightly less urgency than red.

B. Danger / red (var(--danger))

• Pros: Maximum urgency.
• Cons: Easy to read as a hard failure/error rather than open discussion.

C. Keep blue for unresolved; use another colour for “all resolved but unviewed”

• Pros: Emphasises open comments with the existing primary colour.
• Cons: Inverts your stated preference (blue for all-resolved).

3. What counts as “has open code comments” for colouring?

A. Any unresolved code comment on the PR (recommended)
If at least one comment is unresolved, unviewed activity uses the open colour.

• Pros: Simple; matches “one or more open-code comments”; cheap to compute/maintain.
• Cons: Colour does not say whether the new activity itself is on an open thread.

B. Only when the unviewed updates involve unresolved comments
e.g. new/replied/reopened activity on unresolved threads; updates that only touch resolved threads stay blue.

• Pros: Colour more precisely reflects the new activity.
• Cons: More complex rules and edge cases (status transitions, bulk resolve, etc.).

4. Should the tab’s default filter change when the open-coloured circle is shown?

A. No — keep showing all comments (recommended)
Colour is a hint only; users can filter to unresolved themselves. (Existing UI already avoids defaulting the tab to unresolved-only because updates can also come from resolved threads.)

• Pros: Least surprising; no conflict with updates on resolved comments.
• Cons: One extra click if you only care about open threads.

B. Yes — auto-filter to unresolved when the open-coloured indicator is present

• Pros: Faster path to outstanding review comments.
• Cons: Can hide new activity on resolved threads; surprising if you expected the full list.

5. Should the indicator expose a tooltip?

A. Yes (recommended)
e.g. “New code comment updates (unresolved comments remain)” vs “New code comment updates”.

• Pros: Makes the two colours discoverable without docs.
• Cons: Minor extra UI copy to maintain.

B. No tooltip

• Pros: Minimal UI.
• Cons: Colour meaning may be unclear at first.

Suggested default package if you want a quick path: 1A + 2A + 3A + 4A + 5A
That keeps the circle as a new-activity indicator, paints it warning/orange when any comment is still unresolved, keeps blue when all are resolved, clears it after viewing, and documents the meaning in a tooltip.

Once you confirm the choices, I’ll create a follow-up implementation issue with a concrete plan.

1. B. However, if the unresolved code comment has already been viewed, then an unfilled circle that reflects the open color on the edge of the circle.
2. A
3. Hopefully I've answered it in question one. Let me know if any clarification is required.
4. A
5. Only if there is an existing tooltip.

Don't assume. ask any clarifying questions if required in a multiple choice format. Give me the pros and cons of each option and give me your recommendation for each

Thanks — recorded your answers, and a few points need confirmation before I can open an implementation issue.

Locked in so far

• 1: Persist for unresolved, with an unfilled/open-edge circle when unresolved comments are already viewed
• 2A: Warning / orange (var(--warning)) for the open/unresolved colour
• 4A: Do not auto-filter the tab to unresolved
• 5: Tooltip only if one already exists — the Code Comments tab indicator currently has no tooltip, so this defaults to no tooltip unless you choose otherwise in Q9

Please reply with picks (e.g. 6A, 7A, 8A, 9A, 10A).

6. Confirm the full indicator matrix

A. Yes — use this matrix (recommended)

• Pros: Matches your Q1 answer plus the original “blue when all resolved but unviewed” intent; clear priority (fill = unviewed, colour = open vs all-resolved).
• Cons: Two visual styles (fill vs outline) to learn.

B. Something different — please describe the desired states.

7. What counts as “already viewed” for the unfilled circle?

Today, visit tracking is PR tab-level: visiting Code Comments after the latest code-comment activity clears the current blue dot. There is no per-thread visit flag for this indicator.

A. Keep tab-level visit semantics (recommended)
Unfilled orange when unresolved comments remain and you have visited the Code Comments tab since the latest activity; filled orange when there is newer activity you have not visited yet.

• Pros: Reuses existing visit data; smallest behaviour/implementation change; easy to explain.
• Cons: Opening the tab counts as viewed even if you did not open a specific thread.

B. Per-thread / per-comment visit tracking
Unfilled only when every unresolved thread has been individually viewed; otherwise filled.

• Pros: More precise reminder.
• Cons: New visit model; more complex UX and implementation; larger change.

8. What counts as “has open code comments” for colour / hollow state? (Q3)

A. Any unresolved code comment on the PR (recommended)
If at least one comment is unresolved, use the open colour (filled or unfilled per Q6/Q7).

• Pros: Matches “one or more open code comments”; simple and cheap.
• Cons: Colour does not say whether the new activity itself is on an open thread.

B. Only when unviewed updates involve unresolved threads
Open colour only if the new activity touches unresolved threads; otherwise stay blue even if older unresolved comments exist elsewhere.

• Pros: Colour tracks the new activity more closely.
• Cons: Conflicts with persistent “unresolved remain” reminder from Q1; more edge cases.

9. Tooltips (none exist today)

A. No tooltip (recommended, per your answer to 5)

• Pros: Honours “only if existing”; minimal UI.
• Cons: Filled vs unfilled meaning may need a moment to learn.

B. Add tooltips for the new states
e.g. “Unresolved code comments” vs “New code comment updates (unresolved remain)” vs “New code comment updates”.

• Pros: Makes fill/outline/colour discoverable.
• Cons: New UI copy; goes beyond “only if existing”.

10. Unfilled circle style

A. Same-size outline circle in warning colour, transparent fill (recommended)
Stroke/edge only; same footprint as today’s filled dot.

• Pros: Closest to “unfilled … open color on the edge”; consistent size in the tab.
• Cons: Outline can be slightly harder to notice than a solid fill at small sizes.

B. Same idea, but slightly thicker stroke / higher contrast treatment

• Pros: Easier to see when hollow.
• Cons: Slightly different visual weight than the filled dot.

Suggested package: 6A, 7A, 8A, 9A, 10A

Once you confirm, I’ll create a follow-up implementation issue with a concrete plan.

6. A
7. A
8. A
9. A
10. A

@zaakiy Thanks — all choices are locked. Created the follow-up implementation issue and closing this Question.

Locked design

• Tab-level visit semantics (unchanged)
• “Open” = any unresolved code comment on the PR
• No auto-filter to unresolved
• No tooltip
• Same-size outline ring for the viewed+unresolved state

Tracked for implementation as issue #2958.