Skip to content

feat: add Conventional Comments support to code review#501

Merged
backnotprop merged 7 commits intomainfrom
feat/conventional-comments
Apr 7, 2026
Merged

feat: add Conventional Comments support to code review#501
backnotprop merged 7 commits intomainfrom
feat/conventional-comments

Conversation

@backnotprop
Copy link
Copy Markdown
Owner

Summary

  • Adds optional Conventional Comments label picker to the code review annotation toolbar — labels like suggestion, issue, nitpick, question, etc. with an inline blocking/non-blocking toggle per label
  • Exports annotations in conventional format (**label** (decoration): text) as plain markdown, compatible with GitHub PRs and any text-based review system
  • Adds a dedicated Comments settings tab with master toggle (off by default), label editor (add/edit/delete/reorder), per-label blocking decorator toggle, educational "how it works" section with spec link, and live example output
  • Integrates with existing type system — conventionalLabel and decorations fields on CodeAnnotation and DiffAnnotationMetadata, with draft persistence across file switches

Changes

Types (packages/ui/types.ts): ConventionalLabel union type (11 built-in labels + string & {} for custom), ConventionalDecoration type, new optional fields on CodeAnnotation and DiffAnnotationMetadata

Picker (packages/review-editor/components/ConventionalLabelPicker.tsx): Monospace tag-style label buttons with semantic theme tones (danger/warn/info/success/neutral), mini toggle switch for blocking/non-blocking when enabled for the active label, ConventionalLabelBadge for inline annotation headers

Settings (packages/ui/components/Settings.tsx): Comments tab with integrated label editor — single list with inline blocking toggles, add/delete/reset controls, max 12 labels, opacity fade when feature is disabled

Integration: Toolbar, DiffViewer, InlineAnnotation, ReviewSidebar, export feedback, draft persistence, config store

Test plan

  • Enable Conventional Comments in Settings → Comments tab
  • Select lines in diff, verify label picker appears above textarea
  • Select a label (e.g. suggestion), verify blocking toggle appears for labels that support it
  • Submit annotation, verify badge appears in inline comment and sidebar
  • Send feedback, verify exported text uses **label** (decoration): text format
  • Add/edit/delete custom labels in settings, verify picker updates
  • Toggle feature off, verify picker hidden and settings body fades
  • Switch files, verify draft preserves label/decoration state
  • Edit existing annotation, verify label/decorations restore correctly

Add structured label system based on the Conventional Comments spec
(conventionalcomments.org) to the code review annotation toolbar.

- Label picker with 9 default labels (suggestion, nit, question, issue,
  praise, thought, note, todo, chore) shown above the comment textarea
- Per-label blocking/non-blocking toggle for labels where severity is
  ambiguous (issue, suggestion, todo, chore)
- Labels exported as `**label** (decoration): text` in markdown feedback,
  naturally readable on GitHub and machine-parseable
- Label badges shown on inline annotations and sidebar cards
- Settings tab (Comments) with: master on/off toggle, editable label
  list with add/remove/rename, per-label blocking decorator toggle,
  educational intro with spec link and example output
- Feature is off by default, persisted via config store
- Custom labels supported via settings (up to 12)

For provenance purposes, this commit was AI assisted.
Fix label clearing bug where editing an annotation to remove its
conventional label silently preserved the old value. Fix parseCCLabels
accepting 'non-blocking' as a truthy blocking value. Fix duplicate
custom label identities when adding multiple labels. Prepend
conventional prefix to platform PR/MR inline comments.

For provenance purposes, this commit was AI assisted.
All six server config handlers (bun plan/review/annotate + pi
plan/review/annotate) now accept and save the conventionalComments
boolean, so the setting survives server restarts.

For provenance purposes, this commit was AI assisted.
getServerConfig() was not returning the conventionalComments value
from config.json, so the setting silently reset to false on cookie
clear or new browser sessions. Also adds the field to the
PlannotatorConfig interface so saveConfig() is properly typed.

For provenance purposes, this commit was AI assisted.
…mments

- Remove slug derivation from label editing — store display text
  verbatim so badges and exports show what the user typed
- Emit conventional prefix in export even when annotation has no
  prose text (suggestion-only annotations were losing their label)
- Include conventionalLabel in draft save condition so label
  selection persists across file switches

For provenance purposes, this commit was AI assisted.
- Wrap label + decorations + colon in markdown bold per the
  Conventional Comments spec examples (was bolding only the label)
- Allow users to clear all labels — empty array no longer falls
  back to defaults in either the picker or the settings parser
- Enable blocking decorator on the question label by default; the
  spec permits blocking questions and they sometimes are critical

For provenance purposes, this commit was AI assisted.
- Sync conventionalLabels to ~/.plannotator/config.json so custom
  label configurations survive cookie clears and remote/SSH
  sessions, matching the persistence story for conventionalComments.
  Stored as a parsed array on disk; serialized as JSON string in
  the local config store to match the cookie format.
- Remove no-op intermediate variable in handleSubmitAnnotation;
  pass conventionalLabel/decorations directly with proper coalescing
  per call path (edit preserves null, add coalesces to undefined).
- Use index-prefixed key in the picker label list to avoid React
  warnings if duplicate labels ever exist.

For provenance purposes, this commit was AI assisted.
@backnotprop backnotprop merged commit dd04e6b into main Apr 7, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant