* fix(deps): resolve low and medium Dependabot alerts
Bump vulnerable transitive and direct dependencies across npm, Go, and
Rust to clear all fixable low/medium severity Dependabot advisories.
npm (pnpm.overrides, scoped by major; hono pinned in @kandev/theme to
force the shadcn dev-CLI peer):
- ajv@6 6.15.0, @babel/core 7.29.x, body-parser 2.3.0,
brace-expansion 1.1.16/2.1.2, dompurify 3.4.12, hono 4.12.x,
@hono/node-server 2.0.x, js-yaml 4.3.0, lodash(-es) 4.18.x,
markdown-it 14.3.x, mermaid 11.16.x, path-to-regexp@8 8.4.x,
picomatch@2 2.3.2, postcss 8.5.x, protobufjs 7.6.5, qs 6.15.x,
uuid@11 11.1.1, ws 8.21.x
Go: golang.org/x/net 0.55.0, github.com/jackc/pgx/v5 5.9.2
Rust (apps/desktop): serde_with 3.21.0, tauri family 2.11.x
(rand 0.7.3 dropped by the tauri cascade)
Highs are handled by a separate effort; docker/grpc left untouched.
Remaining unresolved mediums: glib (blocked by tauri's gtk ^0.18
constraint) and docker cp advisories (fix requires the docker major
bump owned by the highs effort / no patched version yet).
* fix(desktop): align @tauri-apps/cli with the 2.11 Rust crate bump
The Rust `tauri` crate moved to 2.11.5, but `@tauri-apps/cli` (which runs
`tauri build` for desktop packaging) was still pinned to 2.8.4. Tauri
expects the CLI and crate on the same minor line, so bump the CLI to
2.11.4 to keep packaging tooling in sync with the Cargo crates.
---------
Co-authored-by: Kandev Agent <agent@kandev.dev>
* feat(web): show task linkage on GitHub PR list
Add a compact indicator next to each PR showing whether a task already
exists. When tasks are linked, show a clickable button with the task
title and a count badge for multiple tasks. When no task exists, show
'No task created yet'.
- Add usePRKeyToTasks hook that maps PR keys to task associations
- Add PRRowTaskIndicator component for the per-PR task UI
- Wire the data through github-page-client into PRList
- Add tests for the indicator and hook utility
* feat(web): improve PR task indicator with task titles and multi-task dropdown
- Show actual task title instead of PR title in single-task case
- Replace count badge with dropdown menu for multiple linked tasks
- Switch icon from GitPullRequest to Checklist
- Load all workflow snapshots on GitHub page to hydrate task titles
- Fix test to use unique task_id per fixture
* feat(web): neutralize PR task indicator color and add tooltip
The checklist icon previously mirrored PR aggregate status, which duplicated
information already shown on the PR row and misleadingly suggested it
reflected task state. Drop the color and add a tooltip surfacing the actual
task title and workflow step.
Adds e2e coverage for the GitHub PR list task indicator: empty badge,
single-task button, and tooltip content.
* fix(web): navigate to task page when clicking PR task indicator
replaceTaskUrl only mutates history.state, which sets active task in the
store but does not trigger a Next.js route change. From /github, this left
the URL pointing to /t/<id> while the page still rendered the GitHub list.
Use router.push so the click actually navigates to the task.
* test(web): cover PR task indicator click navigation
Extends the GitHub PR list task indicator spec with a click assertion
verifying the URL changes to /t/<taskId> and the PR list unmounts.
Regression guard for the replaceTaskUrl → router.push fix.
* fix(github): link task to PR at creation time, not via branch poller
Tasks started from the GitHub PR list "+ Task" button were left without a
github_task_prs row when the worktree branch did not match the PR's head
branch on GitHub. This happened for PR-review-style tasks, which check out
synthetic branches (e.g. feature/review-...-h92) that don't exist as PR
heads. The poller's FindPRByBranch could never resolve them, so only the
first task whose branch happened to match got linked — every other task
created from the same PR was missing from the indicator.
The PR is already known at "+ Task" time, so persist the linkage
immediately rather than waiting on branch-based discovery:
- AssociateExistingPRByURL: new service method that creates the
github_task_prs row from a PR URL without creating a PR watch. The
watch is still created later at agent start via ensureSessionPRWatch.
- POST /api/v1/github/task-prs/associate: HTTP endpoint exposing it.
- QuickTaskLauncher.handleSuccess: after task creation, fires a
best-effort associate call with the task's repository_id and PR URL.
Failures fall back to the legacy poller path silently.
Backend test covers two distinct tasks linking to the same PR.
E2e adds a PR with two tasks and asserts the multi-task indicator
("Tasks 2") renders alongside the single-task and empty cases.
* refactor(github): make task-PR create endpoint RESTful
Rename POST /api/v1/github/task-prs/associate to POST /api/v1/github/task-prs.
The action-named "/associate" was RPC-styled; the resource collection is the
right URL for creation alongside the existing GET. Frontend client renamed
associateTaskPR → createTaskPR to match.
* fix(github): address PR review findings
- Map invalid PR URL to HTTP 400 (was 500). New ErrInvalidPRURL sentinel
lets the controller distinguish parse failures from genuine server
errors. Other failure paths still return 500.
- Prefer dialog-time repositoryId in pickRepositoryIdForPR. Multi-repo
tasks with shared branch names were ambiguous under pure branch
matching; the matched repo id captured by the launcher dialog wins
when present.
- Cover usePRKeyToTasks (not only the prKey util) with hook tests:
empty input, multi-task grouping, distinct keys, and the non-array
defensive branch.
- Lock createTaskPR request semantics: method/body now win over a
caller's options.init so the POST JSON shape can't be overridden.
* fix(web): use TaskPR row id for dropdown key
Multi-repo tasks can produce more than one TaskPR row for the same PR
(one row per repository_id), so keying the multi-task dropdown by
task_id risked a duplicate-key warning and unstable reconciliation.
Switch to the row id, which is unique per row.
João Salavisa