feat(sidebar): user-set task labels with priority sort

[DanielVisca]

Problem

There's no lightweight way to triage the sidebar task list — you can pin (moves the row to a dedicated section) or archive (removes it), but nothing in between to mark a task as high priority, actively worked, deprioritized, or done while keeping it in place.

Changes

• Label a task from its context menu: right-click → new radio-style "Label" submenu (High priority / Active / Deprioritized / Done / None), with the current label checked. Labeled rows show a small colored dot (inbox priority-dot styling); unlabeled rows are unchanged.
• New "Priority" option in the Sort by menu: orders High priority → Active → unlabeled → Deprioritized → Done, tie-broken by last activity.
• Persistence follows the pin pattern: a nullable label column on workspaces and task_metadata (migration 0023_task_labels), WorkspaceMetadataService.setTaskLabel with the dual-table rowless fallback, riding the existing getAllTaskTimestamps record into TaskData with optimistic updates. Per-device only, like pins.
• Label metadata (enum, display names, accents, sort ranks) lives in @posthog/shared (task-label.ts) so workspace-server, core, ui, and the web host share one source of truth. apps/web mirrors the field in its localStorage metadata store; setting labels is desktop-only for now (the web host has no task context menu).
• Labels are keyed by task id, so a labeled task keeps its label wherever it renders; channel feed cards don't render the dot yet (the TaskLabelDot component is reusable there later).

How did you test this?

• TDD (red → green) at each layer with new/extended Vitest suites: shared label constants, WorkspaceMetadataService.setTaskLabel + timestamp projections, parseTimestamps/deriveTaskData, the context-menu Label submenu + intent resolution, TaskItem dot rendering, and priority sorting in partitionAndSortTasks.
• Integration test round-tripping labels through real SQLite via the full migration chain (task-label-persistence.test.ts), proving migration 0023 applies.
• pnpm typecheck, pnpm lint, biome lint packages/core (zero noRestrictedImports), and node scripts/check-host-boundaries.mjs all clean. Remaining test failures in the full suite are pre-existing sandbox git-environment failures (identical on a clean checkout).
• Could not drive the live Electron app in this environment (no display server / signed-in profile) — worth a quick manual pass: right-click a task → Label → High priority, confirm the orange dot, relaunch to confirm persistence, then Sort by → Priority.

Automatic notifications

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

---

Created with PostHog Code

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

React Doctor found 1 issue in 1 file · 1 warning.

1 warning

src/features/sidebar/components/items/TaskLabelDot.tsx

• ⚠️ src/features/sidebar/components/items/TaskLabelDot.tsx:15 Role used instead of HTML tag prefer-tag-over-role

_{Reviewed by React Doctor for commit c88684b.}

[github-actions]

This PR has had no activity for 7 days and has been marked stale. We are moving to the monorepo and tightening PR staleness in preparation, so it will be closed in 7 days if no further activity occurs.

[charlesvien]

Hey @DanielVisca, we've migrated this repo into the PostHog/posthog monorepo, so this PR needs to be recreated there.

Easiest path: check out the monorepo and run the /porting-code-prs skill with your agent pointed at this PR. It has the migration guide and path remappings baked in so the agent doesn't have to figure them out. You don't strictly need it though, just asking your agent to port the PR works fine too.

Shout if you get stuck.