docs: Add Azure DevOps integration plan

[QliknzMB]

• Add comprehensive implementation plan for ADO support
• Define multi-provider architecture (GitHub/GitLab/ADO)
• Include provider abstraction layer design
• Document API mappings and code examples
• Add frontend provider selection UI specs

Base Branch

• This PR targets the develop branch (required for all feature/fix PRs)
• This PR targets main (hotfix only - maintainers)

Description

Related Issue

Closes #

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 📚 Documentation
• ♻️ Refactor
• 🧪 Test

Area

• Frontend
• Backend
• Fullstack

Commit Message Format

Follow conventional commits: <type>: <subject>

Types: feat, fix, docs, style, refactor, test, chore

Example: feat: add user authentication system

Checklist

• I've synced with develop branch
• I've tested my changes locally
• I've followed the code principles (SOLID, DRY, KISS)
• My PR is small and focused (< 400 lines ideally)

CI/Testing Requirements

• All CI checks pass
• All existing tests pass
• New features include test coverage
• Bug fixes include regression tests

Screenshots

Before	After

Feature Toggle

• Behind localStorage flag: use_feature_name
• Behind settings toggle
• Behind environment variable/config
• N/A - Feature is complete and ready for all users

Breaking Changes

Breaking: Yes / No

Details:

Summary by CodeRabbit

• New Features

  • Azure DevOps integration: PR and work item support, frontend setup modal, work-items view, sidebar navigation, IPC/events and typed API for ADO operations.

• Documentation

  • New comprehensive ADO integration plan, migration checklist, API mapping references, and updated environment config examples.

• Chores

  • Added optional ADO SDK dependencies and new environment variables to enable/configure the integration.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
21 out of 25 committers have signed the CLA.

✅ abe238
✅ AndyMik90
✅ mirzaaghazadeh
✅ fireapache
✅ MikeeBuilds
✅ gnoviawan
✅ sniggl
✅ hluisi
✅ Ashwinhegde19
✅ Mitsu13Ion
✅ AlexMadera
✅ eddie333016
✅ Pdzly
✅ Orinks
✅ StillKnotKnown
✅ tallinn102
✅ arcker
✅ bvdr
✅ Crimson341
✅ QliknzMB
✅ aaronson2012
❌ andydataguy
❌ Pranaveswar19
❌ jackchuka
❌ aslaker
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds Azure DevOps (ADO) integration across backend and frontend: new backend AzureDevOpsProvider and factory wiring, ADO env/deps, frontend IPC handlers, types, utils, preload API, renderer components (setup modal, work items), IPC channel constants, and related exports.

Changes

Cohort / File(s)	Summary
Integration plan (new doc) guides/ADO-INTEGRATION-PLAN.md	New integration plan describing multi-provider architecture, backend provider abstraction, ADO backend components, frontend provider UI/config, env vars, API mappings, and migration checklist.
Backend env & deps apps/backend/.env.example, apps/backend/requirements.txt	Adds ADO-related .env examples and Python deps: azure-devops>=7.1.0b4,<8.0.0, msrest>=0.7.1,<1.0.0.
Backend provider exports & factory apps/backend/runners/github/providers/__init__.py, apps/backend/runners/github/providers/factory.py	Exposes AzureDevOpsProvider, list_available_providers, is_provider_available; get_provider now instantiates AzureDevOpsProvider for ProviderType.AZURE_DEVOPS.
Azure DevOps provider implementation apps/backend/runners/github/providers/azure_devops_provider.py	New AzureDevOpsProvider implementing provider interface: lazy auth, PR operations (fetch/list/diff/review/merge/close), work item CRUD/comments/labels, repo info, low-level API helpers, and parsing/mapping utilities. (Dense, review for API mapping and error handling.)
Frontend IPC registration apps/frontend/src/main/ipc-handlers/ado/index.ts, .../index.ts	New ADO IPC entry point; registerADOHandlers() registered in main IPC setup and re-exported.
Frontend ADO handlers, types & utils apps/frontend/src/main/ipc-handlers/ado/* types.ts, utils.ts, pr-handlers.ts, workitem-handlers.ts	New types, config parsing, API builders (getADOConfig, buildADOApiUrl), request helpers (adoFetch, adoPatch), sanitizers, state normalization, and many IPC handlers for PRs and work items. (Review for HTTP auth, error messages, and WIQL sanitization.)
IPC constants apps/frontend/src/shared/constants/ipc.ts	Added many ADO-related IPC channel constants and event channels (PR, work item, investigation, autofix).
Preload API & modules apps/frontend/src/preload/api/index.ts, .../modules/ado-api.ts, .../modules/index.ts	New typed ADO IPC API surface (createADOAPI, ADOAPI), IPC-wrapped methods for work items and PRs, event listeners, and module export.
Renderer components & exports apps/frontend/src/renderer/components/ADOSetupModal.tsx, .../ADOWorkItems.tsx, .../index.ts	New ADOSetupModal and ADOWorkItems React components added and re-exported; App and Sidebar wired to show ADO views and nav items. (Review UX flows and env-driven gating.)
Env handling & project types apps/frontend/src/main/ipc-handlers/env-handlers.ts, apps/frontend/src/shared/types/project.ts	Project env parsing/generation extended to include ADO keys; ProjectEnvConfig gains adoEnabled, adoOrganization, adoProject, adoRepoName, adoPat, adoInstanceUrl.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  participant Renderer as Renderer (UI)
  participant Preload as Preload API
  participant Main as Main (IPC handlers)
  participant Backend as Backend (server)
  participant Factory as Provider Factory
  participant ADOProv as AzureDevOpsProvider
  participant ADO as Azure DevOps API

  Renderer->>Preload: getADOPullRequest(projectId, prId)
  Preload->>Main: IPC request (ado:pr:get)
  Main->>Backend: forward provider request (type=AZURE_DEVOPS)
  Backend->>Factory: resolve provider(provider_type=AZURE_DEVOPS, kwargs)
  Factory-->>Backend: AzureDevOpsProvider instance
  Backend->>ADOProv: fetch_pr(prId)
  ADOProv->>ADO: GET /pullrequests/{id}
  ADOProv->>ADO: GET /pullrequests/{id}/iterations
  ADO-->>ADOProv: PR payload + iterations/diff
  ADOProv-->>Backend: normalized PRData
  Backend-->>Main: PRData
  Main-->>Preload: IPC response (PRData)
  Preload-->>Renderer: PRData
  rect rgba(128,200,255,0.10)
    note right of ADOProv: ADOProv maps ADO API -> internal PR/Issue types
  end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• feat: add i18n internationalization system #248 — related frontend navigation/i18n changes that overlap with added navigation keys and Sidebar edits.
• fix(a11y): Add missing ARIA attributes for screen reader accessibility #634 — modifies Sidebar UI/accessibility where this PR adds ADO nav items and expands SidebarView.

Suggested labels

feature, area/fullstack, size/XL, 🔄 Checking

Suggested reviewers

• AndyMik90
• AlexMadera

Poem

🐰
I hopped through code and env tonight,
Brought ADO handlers into light.
From PRs to items, queues that hum,
Providers set—the integrations come.
🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 74.16% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'docs: Add Azure DevOps integration plan' accurately describes the primary change: introduction of comprehensive ADO integration documentation and implementation plan.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Summary of Changes

Hello @QliknzMB, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a comprehensive plan to integrate Azure DevOps (ADO) support into the Auto-Claude application. The plan details a multi-provider architecture, including a new backend abstraction layer for Git services and a dedicated ADO client implementation. It also covers frontend changes for provider selection and ADO API interaction, along with necessary environment configurations and dependencies, laying the groundwork for expanding Auto-Claude's compatibility beyond GitHub and GitLab.

Highlights

• Multi-Provider Architecture: Introduces a design for supporting GitHub, GitLab, and Azure DevOps, allowing users to select their preferred Git platform.
• Backend Abstraction Layer: Defines a new GitProvider abstract base class and a factory for creating provider-specific instances, ensuring a unified interface for Git operations.
• Azure DevOps Client Implementation: Details the Python backend client for ADO, covering repository, pull request, and work item operations, including API mappings.
• Frontend Integration: Outlines the new directory structure, a ProviderSelector UI component, and a TypeScript ADO API service for the frontend.
• Environment & Dependencies: Specifies new environment variables (ADO_PAT, ADO_ORGANIZATION, etc.) and required Python (azure-devops, msrest) and Node.js (azure-devops-node-api) dependencies.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[github-actions]

🎉 Thanks for your first PR!

A maintainer will review it soon. Please make sure:

• Your branch is synced with develop
• CI checks pass
• You've followed our contribution guide

Welcome to the Auto Claude community!

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive and well-structured design document for integrating Azure DevOps support into Auto-Claude. The plan is detailed, covering backend and frontend architecture, a provider abstraction layer, API mappings, and configuration changes. The proposed design is solid. My review includes a few suggestions to address minor inconsistencies within the plan, improve type safety in the data models, and enhance the robustness of the API client implementation. Overall, this is an excellent planning document that will be a valuable guide for development.

[gemini-code-assist]

In the WorkItem dataclass, tags: List[str] = None is not type-safe, as None is not a List[str]. The recommended way to handle mutable defaults in dataclasses is with field(default_factory=list). This ensures a new list is created for each instance. You will also need to update the import from dataclasses to include field (e.g., from dataclasses import dataclass, field).

Suggested change

	tags: List[str] = None
	tags: List[str] = field(default_factory=list)

[gemini-code-assist]

The proposed directory structure for the ado integration lists separate files like repos.py, pull_requests.py, and work_items.py. However, the implementation plan then shows all of this logic consolidated within apps/backend/integrations/ado/client.py. This is inconsistent and could be confusing during implementation. For better modularity and to match the proposed structure, consider splitting the logic from client.py into the respective files. For example, pull_request related methods would go into pull_requests.py.

[gemini-code-assist]

There's an inconsistency in Python list type hints. The GitProvider abstract base class uses List[Branch] (from typing), but the ADOProvider implementation here uses the modern list[Branch] syntax. While list is fine for Python 3.9+, for consistency with the base class and to ensure compatibility with potentially older Python versions supported by the project, it would be better to use List[Branch] here. This also applies to list_pull_requests and list_issues.

Suggested change

	async def list_branches(self) -> list[Branch]:
	async def list_branches(self) -> List[Branch]:

[gemini-code-assist]

The list_issues method hardcodes a limit of 200 work items (result.work_items[:200]). This could be problematic for projects with more than 200 issues in a given state, as it will silently truncate the list. It's better to either implement pagination to fetch all items or at least make this limit configurable and document it clearly in the method's docstring.

[gemini-code-assist]

The plan includes adding the azure-devops-node-api dependency to apps/frontend/package.json. However, the implementation example for the frontend service (adoApi.ts) uses the native fetch API directly and does not appear to use this library. The azure-devops-node-api library is intended for the Node.js environment (main process), while adoApi.ts is for the renderer process. Please clarify if this library is intended for use in the main process. If it's not used, it should be removed from the dependencies to avoid an unnecessary package.

[coderabbitai]

Actionable comments posted: 13

🤖 Fix all issues with AI agents

In @guides/ADO-INTEGRATION-PLAN.md:
- Around line 690-696: The fetch<T> function lacks error handling for network,
timeout, and JSON parse failures; wrap the fetch and subsequent response.json()
in a try/catch inside the private async fetch<T>(endpoint: string, options:
RequestInit = {}) method, check response.ok as before, and on any exception log
a clear message including the endpoint and error (e.g., via console.error or the
project's logger) and rethrow the error so callers can handle it; ensure the
catch also covers JSON parsing errors by awaiting response.json() inside the try
block.
- Line 686: The code is exposing the Personal Access Token via this.config.pat
in the frontend Authorization header; remove any usage of this.config.pat from
client-side code and instead route ADO requests through a backend endpoint that
injects the Authorization header, or implement OAuth/MSAL to obtain short-lived
tokens server-side; update any frontend call sites that currently build headers
like `Authorization: \`Basic ${btoa(`:${this.config.pat}`)}\`` to call your new
backend proxy (or OAuth flow) and have the backend add the Authorization header
using a securely stored PAT or access token.
- Line 30: Replace lowercase vendor branding "github" with the official
capitalized form "GitHub" wherever it appears as a value for the GIT_PROVIDER
option and elsewhere in the document; specifically update the table row that
lists `GIT_PROVIDER` values (currently showing `github`, `gitlab`, `ado`) to use
`GitHub` and search for other occurrences (e.g., the other instance flagged) and
change them to "GitHub" to match official branding.
- Around line 541-543: The _map_work_item implementation assumes `assigned`
supports .get which can raise if `assigned` is None or not a dict-like; guard
this by verifying `assigned` is dict-like before accessing keys (e.g. check
isinstance(assigned, dict) or hasattr(assigned, "get")) and only call .get when
safe, otherwise extract fields via attribute access (e.g. getattr) or default to
empty strings; update the `assigned_to=Identity(...) if assigned else None`
construction to perform that type-check and safe extraction for displayName and
uniqueName.
- Around line 820-853: Add a new "Security best practices" subsection to the
appendix advising: never commit PATs to version control and avoid exposing them
in command history or browser consoles (update the curl PAT example to note this
risk and to read the PAT from a secure store or environment variable without
echoing it), prefer environment variables or secret/credential managers (and
include a note to rotate PATs regularly), avoid embedding hardcoded project
names in WIQL by parameterizing/escaping inputs and sanitize any user-supplied
fields used in WIQL queries to prevent injection, and recommend using OAuth/MSAL
or Managed Identities instead of PATs for long-term, production-grade
authentication.
- Line 765: Replace the loose semver ranges with tighter patch-level pins:
change the "azure-devops>=7.1.0" entry to a patch-bound specifier (e.g.,
"~7.1.0" or "7.1.x" or an exact "7.1.0") to allow only 7.1.* fixes, and change
"azure-devops-node-api@^14.0.0" to a patch-bound specifier like "~14.0.0" (or
"14.0.x" / exact "14.0.0") so only patch releases are accepted; update the two
occurrences referenced by their exact strings ("azure-devops>=7.1.0" and
"azure-devops-node-api@^14.0.0") accordingly.
- Around line 1-862: Summary: The review flags four critical issues to fix
before implementation: insecure PAT handling in frontend, incorrect async/await
use in backend ADO client, unsafe mutation of Azure SDK objects, and a WIQL
injection risk. Fix instructions: 1) Remove PAT usage from frontend
ADOApiService.initialize and ProviderSelector flow — instead implement a backend
proxy/IPC endpoint that holds ADO_PAT securely and performs ADO REST calls;
update frontend to call that proxy (references: ADOApiService.initialize,
ProviderSelector and adoApi). 2) Correct async usage in ADOProvider methods:
ensure ADOProvider.get_repository, list_branches, create_pull_request,
list_pull_requests, get_pull_request, merge_pull_request, create_issue,
list_issues, get_issue, close_issue properly await or run blocking azure-devops
client calls off the event loop (use sync wrappers or asyncio.to_thread) rather
than leaving synchronous SDK calls inside async functions (references: class
ADOProvider and its methods). 3) Avoid mutating SDK model objects returned from
the Azure SDK—construct proper update models or call provided update helpers
instead of setting attributes on objects (fix merge_pull_request where pr.status
and pr.completion_options are assigned; use the appropriate
GitPullRequestUpdate/CompletionOptions model). 4) Eliminate WIQL injection by
parameterizing queries instead of f-string interpolation in list_issues (and
frontend queryWorkItems) — build WIQL with safe parameters or use prepared
filters and validate/whitelist input (references: ADOProvider.list_issues Wiql
usage and frontend ADOApiService.queryWorkItems). Ensure these four fixes are
implemented before proceeding with other changes.
- Line 66: Three fenced code blocks lack language specifiers which breaks syntax
highlighting and markdownlint; update the three blocks referenced at lines 66,
557, and 764 to include an appropriate language tag (e.g., use "tree" or "text"
for directory listings at line 66, "text" or "tree" for the frontend directory
block at line 557, and "text" or "requirements" for the requirements file block
at line 764) by editing the opening fence to include the chosen identifier so
renderers and linters correctly apply syntax highlighting.
- Line 275: The WorkItem dataclass currently defines tags: List[str] = None
which uses a mutable list via a shared default; change the field to use
dataclasses.field with a default factory: update the tags annotation to tags:
List[str] = field(default_factory=list) and add an import for field from
dataclasses (ensure typing.List is already imported); locate the WorkItem class
and replace the default None with field(default_factory=list) so each instance
gets its own list.
- Line 744: The template literal in the fetch call is incorrectly using
`$${type}` and should interpolate the variable `type` as `${type}`; locate the
fetch invocation (the return this.fetch(...) call) that builds the
`/wit/workitems/...` endpoint and replace the malformed `$${type}` with
`${type}` so the endpoint becomes `/wit/workitems/${type}?api-version=7.1`,
ensuring the API path is correctly constructed.
- Around line 491-499: The WIQL query in the Wiql(...) construction is
vulnerable to injection because it interpolates self.project directly; update
the query to use the WIQL server-side @project macro instead of '{self.project}'
(leave state_filter interpolation intact), and ensure you still pass
project=self.project to query_by_wiql() so the macro is resolved server-side;
specifically edit the Wiql(query=...) string used before calling query_by_wiql()
to replace the literal project value with @project.
- Line 361: The repo uses Python 3.10+ type hint syntax (e.g., list[Branch],
list[PullRequest], list[WorkItem], and union syntax in
apps/backend/agents/tools_pkg/models.py), but there is no explicit Python
version pinned; either pin Python >=3.10 in pyproject.toml or setup.py by adding
python = "^3.10" (or equivalent) or convert all 3.10-only annotations to Python
3.9-compatible typing (replace list[...] with typing.List[...] and X | Y unions
with typing.Union[...] or Optional[...]), updating signatures such as
list_branches and the models in models.py to use List, Optional, or Union and
adding the necessary imports from typing.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 5e78390 and ef257fb.

📒 Files selected for processing (1)

• guides/ADO-INTEGRATION-PLAN.md

🧰 Additional context used

🪛 LanguageTool

guides/ADO-INTEGRATION-PLAN.md

[uncategorized] ~30-~30: The official name of this software platform is spelled with a capital “H”.
Context: ...| GIT_PROVIDER | Provider selection | github, gitlab, ado | | ADO_PAT | Perso...

(GITHUB)

---

[uncategorized] ~803-~803: The official name of this software platform is spelled with a capital “H”.
Context: ... get_provider() factory | Backend | | github.com URLs | Provider-specific URLs | Th...

(GITHUB)

🪛 markdownlint-cli2 (0.18.1)

guides/ADO-INTEGRATION-PLAN.md

66-66: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

557-557: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

764-764: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (2)

guides/ADO-INTEGRATION-PLAN.md (2)

599-599: The type keyword syntax is standard TypeScript and does not require TypeScript 5.4+.

The project uses TypeScript 5.9.3, and the basic type alias syntax (type ProviderType = ...) has been valid TypeScript since early versions (1.6+), not 5.4+. No TypeScript version compatibility action is needed.

However, the accessibility concern is valid: the provider selection buttons lack proper ARIA attributes. For better a11y compliance, add role="radio", aria-checked, or aria-selected attributes, and consider implementing keyboard navigation (arrow keys) for radio-button-like selection patterns.

Likely an incorrect or invalid review comment.

---

313-314: Avoid storing authentication credentials as instance properties.

Storing self.credentials and maintaining a persistent Connection object with PAT authentication as instance properties creates a security risk. If the provider instance is serialized, logged, or debugged, sensitive credentials could be exposed. This pattern differs from the existing GitHub provider implementation, which passes tokens via environment variables instead.

Consider:

1. Creating credentials fresh for each API call, or
2. Using a secure credential manager (e.g., keyring library), or
3. Documenting that instances must never be logged/serialized.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Overall Assessment: Comprehensive plan with significant implementation concerns.

This is a well-structured design document for ADO integration. However, multiple critical and major issues must be addressed before implementation:

Critical (must fix before coding):

1. Frontend credential storage security—PAT in JavaScript memory is unacceptable
2. Async/await correctness in backend ADO client
3. Azure SDK object mutation compatibility
4. WIQL injection vulnerability

Major (address during implementation):

1. Python 3.10+ type hint compatibility
2. Frontend error handling for API failures
3. Endpoint syntax validation ($${type})
4. Security documentation for credentials and query parameterization

Recommended refactors:

1. Backend API via secure proxy pattern (avoid PAT in frontend)
2. TypeScript/i18n accessibility (aria-selected, keyboard navigation)
3. Tighter dependency version pinning (~ instead of ^)
4. Comprehensive error handling and retry logic

The architecture is sound, but implementation will require careful attention to security, API compatibility, and error resilience.

🧰 Tools

🪛 LanguageTool

[uncategorized] ~30-~30: The official name of this software platform is spelled with a capital “H”.
Context: ...| GIT_PROVIDER | Provider selection | github, gitlab, ado | | ADO_PAT | Perso...

(GITHUB)

---

[uncategorized] ~803-~803: The official name of this software platform is spelled with a capital “H”.
Context: ... get_provider() factory | Backend | | github.com URLs | Provider-specific URLs | Th...

(GITHUB)

🪛 markdownlint-cli2 (0.18.1)

66-66: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

557-557: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

---

764-764: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md around lines 1 - 862, Summary: The review
flags four critical issues to fix before implementation: insecure PAT handling
in frontend, incorrect async/await use in backend ADO client, unsafe mutation of
Azure SDK objects, and a WIQL injection risk. Fix instructions: 1) Remove PAT
usage from frontend ADOApiService.initialize and ProviderSelector flow — instead
implement a backend proxy/IPC endpoint that holds ADO_PAT securely and performs
ADO REST calls; update frontend to call that proxy (references:
ADOApiService.initialize, ProviderSelector and adoApi). 2) Correct async usage
in ADOProvider methods: ensure ADOProvider.get_repository, list_branches,
create_pull_request, list_pull_requests, get_pull_request, merge_pull_request,
create_issue, list_issues, get_issue, close_issue properly await or run blocking
azure-devops client calls off the event loop (use sync wrappers or
asyncio.to_thread) rather than leaving synchronous SDK calls inside async
functions (references: class ADOProvider and its methods). 3) Avoid mutating SDK
model objects returned from the Azure SDK—construct proper update models or call
provided update helpers instead of setting attributes on objects (fix
merge_pull_request where pr.status and pr.completion_options are assigned; use
the appropriate GitPullRequestUpdate/CompletionOptions model). 4) Eliminate WIQL
injection by parameterizing queries instead of f-string interpolation in
list_issues (and frontend queryWorkItems) — build WIQL with safe parameters or
use prepared filters and validate/whitelist input (references:
ADOProvider.list_issues Wiql usage and frontend ADOApiService.queryWorkItems).
Ensure these four fixes are implemented before proceeding with other changes.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Capitalize "GitHub" in table entries and throughout.

Lines 30 and 803 contain lowercase github which should follow the official GitHub branding with a capital "H".

📝 Proposed fixes

- | Provider | Status | Features |
- |----------|--------|----------|
- | **GitHub** | Existing | PRs, Issues, Webhooks |
+ | Provider | Status | Features |
+ |----------|--------|----------|
+ | **GitHub** | Existing | PRs, Issues, Webhooks |

Also update line 803:

- | `github.com` URLs | Provider-specific URLs | Throughout |
+ | `GitHub.com` URLs | Provider-specific URLs | Throughout |

Also applies to: 803-803

🧰 Tools

🪛 LanguageTool

[uncategorized] ~30-~30: The official name of this software platform is spelled with a capital “H”.
Context: ...| GIT_PROVIDER | Provider selection | github, gitlab, ado | | ADO_PAT | Perso...

(GITHUB)

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 30, Replace lowercase vendor branding
"github" with the official capitalized form "GitHub" wherever it appears as a
value for the GIT_PROVIDER option and elsewhere in the document; specifically
update the table row that lists `GIT_PROVIDER` values (currently showing
`github`, `gitlab`, `ado`) to use `GitHub` and search for other occurrences
(e.g., the other instance flagged) and change them to "GitHub" to match official
branding.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Add language specifiers to fenced code blocks.

Lines 66, 557, and 764 have fenced code blocks without language identifiers (e.g., python, bash, ```json). This:

1. Breaks syntax highlighting in markdown renderers
2. Violates markdownlint rules
3. Reduces readability

Add language identifiers to all code blocks:

-```
+```python

Apply to:

• Line 66: Directory structure (no language needed, but use tree or text)
• Line 557: Frontend directory structure (use text or tree)
• Line 764: Requirements file (use text or requirements)

Also applies to: 557-557, 764-764

🧰 Tools

🪛 markdownlint-cli2 (0.18.1)

66-66: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 66, Three fenced code blocks lack
language specifiers which breaks syntax highlighting and markdownlint; update
the three blocks referenced at lines 66, 557, and 764 to include an appropriate
language tag (e.g., use "tree" or "text" for directory listings at line 66,
"text" or "tree" for the frontend directory block at line 557, and "text" or
"requirements" for the requirements file block at line 764) by editing the
opening fence to include the chosen identifier so renderers and linters
correctly apply syntax highlighting.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Fix mutable default argument in WorkItem dataclass.

Using None as a default for a mutable List[str] field is not idiomatic. Use field(default_factory=list) to avoid sharing state between instances.

🔧 Proposed fix

 from dataclasses import dataclass
+from dataclasses import field
 from typing import Optional, List
 from datetime import datetime

 @dataclass
 class WorkItem:
     """Issue / Work Item (normalized)."""
     id: int
     title: str
     description: Optional[str]
     state: str
     item_type: str
     assigned_to: Optional[Identity]
     created_at: datetime
     web_url: str
     provider: str
-    tags: List[str] = None
+    tags: List[str] = field(default_factory=list)

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 275, The WorkItem dataclass currently
defines tags: List[str] = None which uses a mutable list via a shared default;
change the field to use dataclasses.field with a default factory: update the
tags annotation to tags: List[str] = field(default_factory=list) and add an
import for field from dataclasses (ensure typing.List is already imported);
locate the WorkItem class and replace the default None with
field(default_factory=list) so each instance gets its own list.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat guides/ADO-INTEGRATION-PLAN.md | tail -200

Repository: AndyMik90/Auto-Claude

Length of output: 5867

---

🌐 Web query:

Azure DevOps Python SDK async operations support

💡 Result:

Short answer: The official Azure DevOps Python package (azure-devops / microsoft/azure-devops-python-api) is synchronous only — there is no official async/await client. [1]

Options if you need async behavior:

• Call the Azure DevOps REST API directly from an async HTTP client (aiohttp or httpx). Microsoft’s REST API docs include async examples and are the canonical surface to call. [2]
• Use a community async wrapper (e.g., aioazuredevops) or similar third‑party packages on PyPI. [3]
• Keep using the official SDK but run blocking calls in an executor (ThreadPoolExecutor) to avoid blocking an event loop.
  For general Azure Python libraries, Microsoft provides .aio async clients for services that support it — but that pattern is not applied to the azure-devops Python client. [4]

References:

• Official Azure DevOps Python API repo (sync client). [1]
• Azure DevOps REST API docs / samples (recommended for async HTTP calls). [2]
• Example community async package on PyPI (aioazuredevops). [3]
• Azure Python SDK async guidance (.aio pattern). [4]

---

🏁 Script executed:

sed -n '400,425p' guides/ADO-INTEGRATION-PLAN.md

Repository: AndyMik90/Auto-Claude

Length of output: 1107

---

🏁 Script executed:

sed -n '460,520p' guides/ADO-INTEGRATION-PLAN.md

Repository: AndyMik90/Auto-Claude

Length of output: 2155

---

🌐 Web query:

azure-devops Python SDK async await support

💡 Result:

Short answer: The official microsoft/azure-devops-python-api (pip package azure-devops) is a synchronous wrapper around the Azure DevOps REST API and does not provide async/await (.aio) clients. See the repo and docs. [1][2]

If you need async:

• Call the Azure DevOps REST endpoints directly using an async HTTP client (aiohttp or httpx) and await requests. (This is the common workaround; the SDK is just a thin sync wrapper.) [2]
• Or run the sync SDK calls in a threadpool (asyncio.to_thread or loop.run_in_executor) if you must reuse the existing library.
• Note: other Azure Python SDKs follow the async .aio pattern, but that applies to Azure service SDKs (azure-*.aio) — not the Azure DevOps Python API. [3]

References:

1. microsoft/azure-devops-python-api (repo README). [4]
2. GitHub issues / samples showing the SDK is a REST wrapper and samples are not actively maintained. [5][6]
3. Azure SDK Python guidelines / async .aio pattern (explains .aio clients for other Azure SDKs). [3]

Would you like a small aiohttp example that calls an Azure DevOps REST API (with PAT auth)?

---

🌐 Web query:

azure-devops-python-api GitClient synchronous blocking calls

💡 Result:

Short answer: The azure-devops-python-api GitClient is synchronous/blocking. The library is a thin synchronous wrapper around the Azure DevOps REST API (methods issue HTTP requests and return results), it does not ship separate async/aio clients — so calls block the calling thread. [1][2]

If you need non‑blocking behavior in an async app, run calls in a thread or executor (eg. asyncio.to_thread or loop.run_in_executor) or offload to worker threads/processes. (If you want, I can show a small example.)

Sources:

• azure-devops-python-api (repo README / docs) — thin wrapper / sync calls. [1]
• Azure Python SDK guidelines (sync vs async separate clients; async libs use .aio) — guidance explaining async clients are separate. [2]

References:
[1] https://github.com/microsoft/azure-devops-python-api
[2] https://azure.github.io/azure-sdk/python_design.html

---

🌐 Web query:

azure-devops-python-api is synchronous blocking library

💡 Result:

Short answer: Yes — azure-devops-python-api is a synchronous, blocking thin wrapper around the Azure DevOps REST APIs (no official async/.aio client). [1][2]

Notes:

• The repo README describes it as a "thin wrapper around the Azure DevOps REST APIs" and shows synchronous client usage. [1]
• Azure's modern Python SDK pattern documents the separate async (.aio) packages for libraries that provide async support; the azure-devops-python-api is not part of that async/.aio ecosystem. [2]

If you need non‑blocking calls you can:

• Run the synchronous client in a ThreadPoolExecutor / background thread, or
• Implement your own async HTTP transport that calls the REST endpoints (e.g., using httpx or aiohttp). [2]

Sources:
[1] microsoft/azure-devops-python-api README.
[2] Azure Python SDK docs — async libraries / transports.

---

Refactor async methods to properly handle blocking Azure DevOps SDK calls.

The async methods call blocking synchronous operations from the azure-devops-python-api library without await or asyncio.to_thread(). The official Azure DevOps SDK is synchronous-only with no async support. These method signatures create a contract that they won't block the event loop, but they do.

Either:

1. Remove the async decorator and handle synchronously, or
2. Wrap blocking calls with asyncio.to_thread() (e.g., await asyncio.to_thread(self.git.get_pull_requests, ...)), or
3. Call the Azure DevOps REST API directly using an async HTTP client (aiohttp/httpx).

Affects: list_pull_requests(), get_pull_request(), merge_pull_request(), create_issue(), list_issues(), get_issue(), close_issue(), and similar methods that invoke blocking SDK operations.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Avoid storing PAT in frontend JavaScript memory.

Line 686: The Personal Access Token (PAT) is stored in the config object and used for every fetch request. Frontend JavaScript is inherently insecure for credential storage—users can inspect memory and local storage.

Best practices:

1. Proxy API calls through the backend: Let the backend handle ADO authentication and expose sanitized endpoints.
2. Use OAuth/MSAL: Azure DevOps supports OAuth; use Azure AD authentication instead of PAT.
3. Temporary tokens: Fetch short-lived tokens from the backend, not long-lived PATs.

This is a significant security gap and should be addressed before deployment.

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 686, The code is exposing the
Personal Access Token via this.config.pat in the frontend Authorization header;
remove any usage of this.config.pat from client-side code and instead route ADO
requests through a backend endpoint that injects the Authorization header, or
implement OAuth/MSAL to obtain short-lived tokens server-side; update any
frontend call sites that currently build headers like `Authorization: \`Basic
${btoa(`:${this.config.pat}`)}\`` to call your new backend proxy (or OAuth flow)
and have the backend add the Authorization header using a securely stored PAT or
access token.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add error handling for API fetch calls.

Lines 690-696: The fetch() method lacks error handling for network failures, timeouts, or JSON parsing errors. Users won't be notified if API calls fail.

Add try/catch blocks and proper error propagation:

private async fetch<T>(endpoint: string, options: RequestInit = {}): Promise<T> {
  // ... existing code ...
  try {
    const response = await fetch(url, { ...options, headers });
    if (!response.ok) {
      throw new Error(`ADO API error: ${response.status}`);
    }
    return response.json();
  } catch (error) {
    console.error(`API call failed for ${endpoint}:`, error);
    throw error; // Let caller handle
  }
}

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md around lines 690 - 696, The fetch<T> function
lacks error handling for network, timeout, and JSON parse failures; wrap the
fetch and subsequent response.json() in a try/catch inside the private async
fetch<T>(endpoint: string, options: RequestInit = {}) method, check response.ok
as before, and on any exception log a clear message including the endpoint and
error (e.g., via console.error or the project's logger) and rethrow the error so
callers can handle it; ensure the catch also covers JSON parsing errors by
awaiting response.json() inside the try block.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cd /root && find . -name "ADO-INTEGRATION-PLAN.md" -type f 2>/dev/null | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 120

---

🏁 Script executed:

# Read the file to see the context around line 744
if [ -f "./guides/ADO-INTEGRATION-PLAN.md" ]; then
  wc -l ./guides/ADO-INTEGRATION-PLAN.md
fi

Repository: AndyMik90/Auto-Claude

Length of output: 101

---

🏁 Script executed:

# Get context around line 744
if [ -f "./guides/ADO-INTEGRATION-PLAN.md" ]; then
  sed -n '735,755p' ./guides/ADO-INTEGRATION-PLAN.md
fi

Repository: AndyMik90/Auto-Claude

Length of output: 664

---

🌐 Web query:

Azure DevOps REST API create work item endpoint syntax endpoint format

💡 Result:

Endpoint format

• POST https://dev.azure.com/{organization}/{project}/_apis/wit/workitems/${type}?api-version={version}. [1] (learn.microsoft.com)

Headers

• Authorization: Basic <base64(user:PAT)>
• Content-Type: application/json-patch+json. [1] (learn.microsoft.com)

Request body (JSON Patch array)

• Example:
  [
  { "op": "add", "path": "/fields/System.Title", "from": null, "value": "Sample task" },
  { "op": "add", "path": "/fields/System.AssignedTo", "value": "[email protected]" }
  ]
• Use the work item type in the path (e.g., $Task, $Bug, $User Story). [2] (learn.microsoft.com)

Optional query params

• validateOnly, bypassRules, suppressNotifications, $expand. [1] (learn.microsoft.com)

Notes

• Use the latest documented api-version (e.g., 7.1 or preview versions as needed). See Microsoft docs for examples and latest versions. [1] (learn.microsoft.com)

Sources
[1] Microsoft Learn — Work Items - Create (Azure DevOps REST API). (learn.microsoft.com)
[2] Microsoft docs sample request (JSON Patch example). (learn.microsoft.com)

Citations:

• 1: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.1&utm_source=openai
• 2: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.1&utm_source=openai
• 3: https://learn.microsoft.com/en-gb/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-5.0&utm_source=openai
• 4: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.1&utm_source=openai
• 5: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.1&utm_source=openai
• 6: https://learn.microsoft.com/en-us/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-7.1&utm_source=openai
• 7: https://learn.microsoft.com/en-gb/rest/api/azure/devops/wit/work-items/create?view=azure-devops-rest-5.0&utm_source=openai

---

Fix malformed template literal interpolation in API endpoint.

Line 744: The endpoint uses $${type} which is incorrect. In JavaScript template literals, ${variable} is the correct syntax for interpolation. The extra $ will produce a malformed endpoint path.

Update to:

return this.fetch(`/wit/workitems/${type}?api-version=7.1`, {

The double $$ syntax is not valid for template literal variable interpolation and will cause the API request to fail.

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 744, The template literal in the
fetch call is incorrectly using `$${type}` and should interpolate the variable
`type` as `${type}`; locate the fetch invocation (the return this.fetch(...)
call) that builds the `/wit/workitems/...` endpoint and replace the malformed
`$${type}` with `${type}` so the endpoint becomes
`/wit/workitems/${type}?api-version=7.1`, ensuring the API path is correctly
constructed.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Tighten dependency version pinning.

Lines 765 and 776 use loose version constraints:

• azure-devops>=7.1.0 allows any version >= 7.1.0, including breaking changes (8.0.0, 9.0.0, etc.)
• azure-devops-node-api@^14.0.0 allows breaking changes up to 15.0.0

For production stability, use tighter constraints:

- azure-devops>=7.1.0
+ azure-devops~=7.1.0

- "azure-devops-node-api": "^14.0.0"
+ "azure-devops-node-api": "~14.0.0"

This ensures patch updates (7.1.x) but prevents major breaking changes (8.0.0).

Also applies to: 776-776

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md at line 765, Replace the loose semver ranges
with tighter patch-level pins: change the "azure-devops>=7.1.0" entry to a
patch-bound specifier (e.g., "~7.1.0" or "7.1.x" or an exact "7.1.0") to allow
only 7.1.* fixes, and change "azure-devops-node-api@^14.0.0" to a patch-bound
specifier like "~14.0.0" (or "14.0.x" / exact "14.0.0") so only patch releases
are accepted; update the two occurrences referenced by their exact strings
("azure-devops>=7.1.0" and "azure-devops-node-api@^14.0.0") accordingly.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Document security best practices for WIQL queries and PAT usage.

The appendix includes WIQL examples and authentication instructions, but lacks security guidance:

1. Line 824-830: Shows how to encode PAT in curl, but doesn't warn about storing PAT in command history, environment variables, or browser console
2. Line 845-853: WIQL example uses hardcoded project name; should mention parameterization/escaping

Add a security section to the appendix:

• Never commit PATs to version control
• Use environment variables or secure credential managers
• Sanitize user input in WIQL queries
• Consider OAuth/MSAL over PAT for long-term solutions

🤖 Prompt for AI Agents

In @guides/ADO-INTEGRATION-PLAN.md around lines 820 - 853, Add a new "Security
best practices" subsection to the appendix advising: never commit PATs to
version control and avoid exposing them in command history or browser consoles
(update the curl PAT example to note this risk and to read the PAT from a secure
store or environment variable without echoing it), prefer environment variables
or secret/credential managers (and include a note to rotate PATs regularly),
avoid embedding hardcoded project names in WIQL by parameterizing/escaping
inputs and sanitize any user-supplied fields used in WIQL queries to prevent
injection, and recommend using OAuth/MSAL or Managed Identities instead of PATs
for long-term, production-grade authentication.

[coderabbitai]

Actionable comments posted: 9

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

apps/backend/runners/github/providers/__init__.py (1)

20-32: Fix import sorting to resolve pipeline failure.

The pipeline is failing due to unsorted imports (Ruff I001). Imports should be sorted alphabetically within groups.

Proposed fix

-from .factory import get_provider, register_provider, list_available_providers, is_provider_available
+from .azure_devops_provider import AzureDevOpsProvider
+from .factory import (
+    get_provider,
+    is_provider_available,
+    list_available_providers,
+    register_provider,
+)
 from .github_provider import GitHubProvider
-from .azure_devops_provider import AzureDevOpsProvider
 from .protocol import (
     GitProvider,
     IssueData,

🤖 Fix all issues with AI agents

In @apps/backend/requirements.txt:
- Around line 19-21: The azure-devops requirement is using a loose beta
constraint; change the line referencing the azure-devops package in
apps/backend/requirements.txt from "azure-devops>=7.1.0b4" to pin the beta
explicitly as "azure-devops==7.1.0b4" (or replace with a stable version when one
is available) and add a short comment nearby noting that this is a pinned beta
and should be reviewed/updated when a stable 7.1.x release is published; leave
msrest as-is unless you choose to pin it similarly.

In @apps/backend/runners/github/providers/azure_devops_provider.py:
- Around line 556-557: The empty except blocks in apply_labels and remove_labels
silently swallow errors; change them to catch Exception as e and log the
exception (e.g., logger.exception or logger.error with the exception) including
context such as the function name (apply_labels/remove_labels), repo/pr
identifiers and the labels being applied/removed, so failures are visible; do
not leave the block blank—either re-raise after logging or return a clear
failure result per the surrounding API contract.
- Around line 748-751: The POST call currently uses urllib.request.urlopen(req,
data=body) without a timeout; update the call to include the same timeout used
for other requests (e.g., pass timeout=timeout or a DEFAULT_TIMEOUT constant) so
it becomes urllib.request.urlopen(req, data=body, timeout=timeout), and ensure
the timeout variable or constant is defined/imported in the scope where body and
req are used (same function handling the request).
- Around line 239-251: The current broad except in the
create_pull_request_reviewer call swallows all failures; replace the silent pass
with logging of the exception and context so real errors aren't masked: catch
Exception as e and call the provider's logger (e.g., self.logger.exception or
self.logger.warning) including pr_number, repository_id/self._repo_name,
project/self._project, reviewer_id="me" and vote to provide context; optionally
still suppress expected permission-related errors by checking error type/status
and only escalate/log unexpected failures.
- Around line 615-622: The WIQL query interpolates self._project directly;
update the code that constructs the Wiql instance (the Wiql(...) block) to
escape or sanitize self._project the same way used earlier in this file (reuse
the existing escape/sanitize helper or apply the same quoting/escaping logic)
before embedding it into the f-string, i.e. compute a safe_project variable from
self._project and use that in the query to prevent WIQL injection while
preserving existing behavior.
- Around line 344-371: The WIQL construction in azure_devops_provider (the block
that builds conditions and the resulting query string) directly interpolates
user inputs (filters.author, filters.assignee, filters.labels) and is vulnerable
to injection; fix it by sanitizing those values before embedding them — replace
any single quote characters in filters.author, filters.assignee and each label
in filters.labels with two single quotes (escaping for WIQL/SQL-style literals)
or otherwise normalize/validate inputs, then use the sanitized variables when
appending to conditions in the method that builds the query (the SELECT ... FROM
WorkItems WHERE {' AND '.join(conditions)} block).
- Around line 191-214: Remove the unused local variables target_version and
source_version (they are computed but never used) and change the exception
handling so you don't return an error string as if it were diff content: instead
log the exception (using self.logger or self._logger; include the
exception/traceback for debugging) and return an empty string, or alternatively
re-raise the exception if the caller should handle it—do not return f"Error
fetching diff: {e}".
- Around line 277-285: The PR creation code hard-codes deleteSourceBranch=True
in the GitPullRequest completion options, which should be configurable; update
the logic around the GitPullRequest instantiation (variable update_pr) to read a
configuration or parameter (e.g., a new function arg, environment variable, or
provider setting) that controls deleteSourceBranch and pass that boolean instead
of the literal True, defaulting to the current behavior if unset, and ensure any
callers that create or call the merge routine (where update_pr is constructed)
are updated to accept or propagate this new option.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ef257fb and debe3a5.

📒 Files selected for processing (5)

• apps/backend/.env.example
• apps/backend/requirements.txt
• apps/backend/runners/github/providers/__init__.py
• apps/backend/runners/github/providers/azure_devops_provider.py
• apps/backend/runners/github/providers/factory.py

🧰 Additional context used

📓 Path-based instructions (2)

apps/backend/.env*

📄 CodeRabbit inference engine (CLAUDE.md)

apps/backend/.env*: Enable Electron MCP for E2E testing by setting ELECTRON_MCP_ENABLED=true in .env and starting the Electron app with npm run dev
Configure memory system credentials in apps/backend/.env and validate with graphiti_config.py

Files:

• apps/backend/.env.example

apps/backend/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

apps/backend/**/*.py: Always use the Claude Agent SDK (claude-agent-sdk package) for all AI interactions, never use the Anthropic API directly
Use the create_client() function from apps/backend/core/client.py to instantiate Claude SDK clients, not direct ClaudeSDKClient initialization

Files:

• apps/backend/runners/github/providers/__init__.py
• apps/backend/runners/github/providers/factory.py
• apps/backend/runners/github/providers/azure_devops_provider.py

---

⚙️ CodeRabbit configuration file

apps/backend/**/*.py: Focus on Python best practices, type hints, and async patterns.
Check for proper error handling and security considerations.
Verify compatibility with Python 3.12+.

Files:

• apps/backend/runners/github/providers/__init__.py
• apps/backend/runners/github/providers/factory.py
• apps/backend/runners/github/providers/azure_devops_provider.py

🧬 Code graph analysis (3)

apps/backend/runners/github/providers/__init__.py (1)

apps/backend/runners/github/providers/factory.py (4)

• get_provider (42-118)
• register_provider (22-39)
• list_available_providers (121-135)
• is_provider_available (138-159)

apps/backend/runners/github/providers/factory.py (3)

apps/backend/runners/github/providers/azure_devops_provider.py (2)

• repo (108-110)
• provider_type (104-105)

apps/backend/runners/github/providers/github_provider.py (2)

• repo (67-68)
• provider_type (63-64)

apps/backend/runners/github/providers/protocol.py (3)

• repo (186-188)
• ProviderType (17-24)
• provider_type (181-183)

apps/backend/runners/github/providers/azure_devops_provider.py (1)

apps/backend/runners/github/providers/protocol.py (4)

• IssueData (66-87)
• PRFilters (141-152)
• ProviderType (17-24)
• ReviewData (111-122)

🪛 GitHub Actions: Lint

apps/backend/runners/github/providers/__init__.py

[error] 20-20: Ruff check failed: Import block is un-sorted or un-formatted.

🪛 GitHub Check: CodeQL

apps/backend/runners/github/providers/azure_devops_provider.py

[notice] 192-192: Unused local variable
Variable target_version is not used.

---

[notice] 193-193: Unused local variable
Variable source_version is not used.

---

[notice] 556-556: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

---

[notice] 594-594: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

🪛 GitHub Check: python

apps/backend/runners/github/providers/__init__.py

[failure] 20-32: Ruff (I001)
apps/backend/runners/github/providers/init.py:20:1: I001 Import block is un-sorted or un-formatted

apps/backend/runners/github/providers/azure_devops_provider.py

[failure] 732-734: Ruff (I001)
apps/backend/runners/github/providers/azure_devops_provider.py:732:9: I001 Import block is un-sorted or un-formatted

---

[failure] 702-705: Ruff (I001)
apps/backend/runners/github/providers/azure_devops_provider.py:702:9: I001 Import block is un-sorted or un-formatted

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (python)
• GitHub Check: CodeQL (javascript-typescript)

🔇 Additional comments (7)

apps/backend/.env.example (1)

111-136: LGTM!

The Azure DevOps configuration block is well-documented, follows the established pattern of other provider sections, and clearly specifies required PAT scopes. The support for both Azure DevOps Services (cloud) and Azure DevOps Server (on-prem) via ADO_INSTANCE_URL is a nice touch.

apps/backend/runners/github/providers/azure_devops_provider.py (3)

27-70: LGTM!

The dataclass initialization with lazy environment variable loading and required field validation is well-implemented. The fallback of _repo_name to _project when not specified is a sensible default.

---

71-101: LGTM!

The lazy connection initialization with clear ImportError messaging is well-designed. The client properties properly ensure connection before access.

---

757-853: LGTM!

The helper methods for parsing ADO data structures into protocol-compliant dataclasses are well-implemented. The fallback behaviors (e.g., updated_at using creation_date, datetime.now() for missing timestamps) are reasonable and documented.

apps/backend/runners/github/providers/__init__.py (1)

46-51: LGTM!

The __all__ exports are properly updated to include the new AzureDevOpsProvider and factory utility functions.

apps/backend/runners/github/providers/factory.py (2)

102-116: LGTM with a minor note.

The Azure DevOps provider instantiation correctly extracts ADO-specific kwargs and maps them to the provider's private fields. The fallback logic for _repo_name (line 113) handles the case where repo_name isn't provided by extracting from the repo parameter.

One observation: using private field names (_organization, _project) as constructor kwargs is unconventional for dataclasses, but it works correctly given the provider's implementation.

---

128-128: LGTM!

The list_available_providers and is_provider_available functions are correctly updated to include AZURE_DEVOPS as a built-in provider.

Also applies to: 154-156

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

🧩 Analysis chain

🌐 Web query:

azure-devops python package PyPI latest stable version releases

💡 Result:

Latest PyPI release: azure-devops 7.1.0b4 (pre-release), published Nov 20, 2023. No newer non-prerelease (stable) version appears on PyPI. [1][2]

Sources:
[1] PyPI project page — azure-devops (release history).
[2] PyPI mirror listing for azure-devops.

---

Consider pinning azure-devops to ==7.1.0b4 or monitor for stable release.

The constraint azure-devops>=7.1.0b4 uses the latest available version on PyPI, which is currently in beta with no stable release published. While the loose constraint allows auto-upgrades to a future stable 7.1.0 when available, consider either pinning to ==7.1.0b4 explicitly for production stability or periodically checking for stable releases.

🤖 Prompt for AI Agents

In @apps/backend/requirements.txt around lines 19 - 21, The azure-devops
requirement is using a loose beta constraint; change the line referencing the
azure-devops package in apps/backend/requirements.txt from
"azure-devops>=7.1.0b4" to pin the beta explicitly as "azure-devops==7.1.0b4"
(or replace with a stable version when one is available) and add a short comment
nearby noting that this is a pinned beta and should be reviewed/updated when a
stable 7.1.x release is published; leave msrest as-is unless you choose to pin
it similarly.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider logging vote failures instead of silently ignoring them.

The exception is silently caught and ignored when setting the reviewer vote. While the comment explains the rationale, this could mask legitimate errors (e.g., network issues, permission problems).

Proposed improvement

             try:
                 self.git_client.create_pull_request_reviewer(
                     reviewer={
                         "vote": vote,
                     },
                     repository_id=self._repo_name,
                     pull_request_id=pr_number,
                     reviewer_id="me",  # Current user
                     project=self._project,
                 )
-            except Exception:
-                pass  # Vote may fail if user is not a reviewer
+            except Exception as e:
+                # Vote may fail if user is not a reviewer
+                import logging
+                logging.debug(f"Could not set reviewer vote on PR #{pr_number}: {e}")

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
239 - 251, The current broad except in the create_pull_request_reviewer call
swallows all failures; replace the silent pass with logging of the exception and
context so real errors aren't masked: catch Exception as e and call the
provider's logger (e.g., self.logger.exception or self.logger.warning) including
pr_number, repository_id/self._repo_name, project/self._project,
reviewer_id="me" and vote to provide context; optionally still suppress expected
permission-related errors by checking error type/status and only escalate/log
unexpected failures.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider making deleteSourceBranch configurable.

The merge operation hard-codes deleteSourceBranch: True. This behavior may not be desired in all workflows—some teams prefer to keep source branches for history or debugging purposes.

Proposed fix

 async def merge_pr(
     self,
     pr_number: int,
     merge_method: str = "squash",
     commit_title: str | None = None,
+    delete_source_branch: bool = True,
 ) -> bool:
     """Merge a pull request."""
     try:
         ...
         update_pr = GitPullRequest(
             status="completed",
             last_merge_source_commit=pr.last_merge_source_commit,
             completion_options={
-                "deleteSourceBranch": True,
+                "deleteSourceBranch": delete_source_branch,
                 "mergeStrategy": merge_strategy_map.get(merge_method, "squash"),
                 "mergeCommitMessage": commit_title,
             },
         )

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
277 - 285, The PR creation code hard-codes deleteSourceBranch=True in the
GitPullRequest completion options, which should be configurable; update the
logic around the GitPullRequest instantiation (variable update_pr) to read a
configuration or parameter (e.g., a new function arg, environment variable, or
provider setting) that controls deleteSourceBranch and pass that boolean instead
of the literal True, defaulting to the current behavior if unset, and ensure any
callers that create or call the merge routine (where update_pr is constructed)
are updated to accept or propagate this new option.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Empty except blocks silently swallow errors.

Both apply_labels and remove_labels catch all exceptions and pass silently. This makes debugging difficult and leaves callers unaware of failures.

Proposed fix - add logging

         except Exception:
-            pass
+            import logging
+            logging.warning(f"Failed to apply labels to work item #{issue_or_pr_number}")

         except Exception:
-            pass
+            import logging
+            logging.warning(f"Failed to remove labels from work item #{issue_or_pr_number}")

Also applies to: 594-595

🧰 Tools

🪛 GitHub Check: CodeQL

[notice] 556-556: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
556 - 557, The empty except blocks in apply_labels and remove_labels silently
swallow errors; change them to catch Exception as e and log the exception (e.g.,
logger.exception or logger.error with the exception) including context such as
the function name (apply_labels/remove_labels), repo/pr identifiers and the
labels being applied/removed, so failures are visible; do not leave the block
blank—either re-raise after logging or return a clear failure result per the
surrounding API contract.

[coderabbitai]

⚠️ Potential issue | 🟠 Major

Add timeout to urllib.request.urlopen to prevent indefinite hangs.

The urlopen call has no timeout, which can cause the application to hang indefinitely if the Azure DevOps API is unresponsive.

Proposed fix

-        with urllib.request.urlopen(req) as response:
+        with urllib.request.urlopen(req, timeout=30) as response:
             return json.loads(response.read().decode())

Also, the static analysis flagged unsorted imports. Consider moving imports to the top of the file or sorting them:

-        import urllib.request
-        import urllib.parse
         import json
+        import urllib.parse
+        import urllib.request

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	import urllib.request
	import urllib.parse
	import json
	import base64
	url = f"{self._instance_url}/{self._organization}/{self._project}/_apis{endpoint}"
	if params:
	url += "?" + urllib.parse.urlencode(params)
	# Add API version if not present
	if "api-version" not in url:
	separator = "&" if "?" in url else "?"
	url += f"{separator}api-version=7.1"
	auth = base64.b64encode(f":{self._pat}".encode()).decode()
	req = urllib.request.Request(url)
	req.add_header("Authorization", f"Basic {auth}")
	req.add_header("Content-Type", "application/json")
	with urllib.request.urlopen(req) as response:
	return json.loads(response.read().decode())
	import urllib.request
	import urllib.parse
	import json
	import base64
	url = f"{self._instance_url}/{self._organization}/{self._project}/_apis{endpoint}"
	if params:
	url += "?" + urllib.parse.urlencode(params)
	# Add API version if not present
	if "api-version" not in url:
	separator = "&" if "?" in url else "?"
	url += f"{separator}api-version=7.1"
	auth = base64.b64encode(f":{self._pat}".encode()).decode()
	req = urllib.request.Request(url)
	req.add_header("Authorization", f"Basic {auth}")
	req.add_header("Content-Type", "application/json")
	with urllib.request.urlopen(req, timeout=30) as response:
	return json.loads(response.read().decode())

🧰 Tools

🪛 GitHub Check: python

[failure] 702-705: Ruff (I001)
apps/backend/runners/github/providers/azure_devops_provider.py:702:9: I001 Import block is un-sorted or un-formatted

[coderabbitai]

Actionable comments posted: 10

🤖 Fix all issues with AI agents

In @apps/backend/requirements.txt:
- Around line 19-21: The requirements file currently allows azure-devops to
float across beta releases using "azure-devops>=7.1.0b4,<8.0.0"; change the
constraint to pin the exact beta version by replacing that range with an exact
equality for the 7.1.0b4 release (i.e., use azure-devops==7.1.0b4) so builds are
reproducible; update any related CI/lockfile if present to match the pinned
azure-devops version.

In @apps/backend/runners/github/providers/azure_devops_provider.py:
- Around line 306-307: Replace the silent except block that currently does
"except Exception: pass" in the vote-related code with an exception handler that
captures the exception (e.g., except Exception as e) and logs the failure with
context (PR/commit id, reviewer id, and any action like "vote" or "set_vote")
using the module/class logger (e.g., self.logger or logger) — keep the existing
behavior of not raising after logging but ensure the log uses logger.exception
or logger.error with the exception details so network/permission errors are
visible for debugging.
- Around line 686-687: The empty except in remove_labels is swallowing errors;
change it to catch Exception as e and log the failure with the exception and
contextual details (e.g., issue/PR id, repo, labels) using the existing logger
(self.logger or logger) so label operation failures are visible for debugging;
do not suppress exceptions silently—either log and continue or re-raise if
callers expect errors.
- Around line 228-269: In fetch_pr_diff: remove the unused fetch of pr (the call
to self.git_client.get_pull_request) since pr is never used; keep the commits
check (commits variable) and bail with an empty string if no commits; safely
handle a missing or None changes.change_entries when building diff_lines; and do
not return an error string on exception—raise the exception (or let it
propagate) instead so callers can handle errors rather than receiving an invalid
diff string.
- Around line 385-386: The close_pr handler currently swallows all exceptions
(except Exception: return False); update the except block in close_pr to log the
failure before returning False by catching the exception as e and calling the
provider's logger (use the class logger used elsewhere in this file, e.g.,
self.logger or logger) with the PR context and the exception (use
logger.exception or logger.error(..., exc_info=True)), similar to how merge_pr
was fixed—include PR identifier/URL and the exception message/trace to aid
debugging.
- Line 21: Replace typing.List and typing.Optional with modern built-ins: change
the import line to use "from typing import Any" (remove List and Optional), then
update all type hints in this file (e.g., in functions/methods and class
signatures such as any occurrences inside AzureDevOpsProvider, get_* methods, or
helpers) replacing "List[X]" with "list[X]" and "Optional[X]" with "X | None".
Ensure any forward references or imports still resolve and run type checks after
the changes.
- Around line 555-556: The close_issue handler swallows all exceptions without
any logging; update the except block in the close_issue method of
AzureDevOpsProvider (or the close_issue function) to log the failure details
before returning False: catch Exception as e and call the module/class logger
(e.g., self.logger.exception(...) or self.logger.error(..., exc_info=True)) with
a short message that includes the issue id/context and the exception to aid
debugging, then return False as before.
- Around line 585-602: The current nested try/except swallows all errors; modify
both except blocks to capture the exception as a variable (e.g., "except
Exception as e") and log the full exception and context before continuing—use
the instance logger (self.logger.exception or self.logger.error with traceback)
or logging.exception if no instance logger, and include identifiers like
issue_or_pr_number, self._repo_name and self._project and whether it was the
work-item or PR-path; keep the fallback behavior (attempt PR comment) and still
return 0 on final failure after logging the error.
- Around line 359-360: The bare except block that returns False hides merge
errors; update the exception handler in the AzureDevOpsProvider merge routine
(the except Exception: return False) to log the failure before returning False —
call an appropriate logger (e.g., self.logger.exception or module-level
logger.exception) with a descriptive message like "Failed to merge PR" and
include the exception so the stacktrace is recorded, then return False as
before.
- Around line 778-787: The check_permissions function is a documented stub that
always returns "write" and is unused; update the function docstring or body to
include a clear TODO explaining it's a placeholder for future ADO permission
resolution, describe expected behavior (e.g., resolve project-level ADO
permissions or raise/not-used), and mark it as intentionally unused for now
(e.g., TODO: implement or integrate with permission checks) so reviewers know it
isn't an active authorization bypass; reference the async def
check_permissions(username: str) function and leave the current simplified
return in place until implementation.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between debe3a5 and 04dfa73.

📒 Files selected for processing (2)

• apps/backend/requirements.txt
• apps/backend/runners/github/providers/azure_devops_provider.py

🧰 Additional context used

📓 Path-based instructions (1)

apps/backend/**/*.py

📄 CodeRabbit inference engine (CLAUDE.md)

apps/backend/**/*.py: Always use the Claude Agent SDK (claude-agent-sdk package) for all AI interactions, never use the Anthropic API directly
Use the create_client() function from apps/backend/core/client.py to instantiate Claude SDK clients, not direct ClaudeSDKClient initialization

Files:

• apps/backend/runners/github/providers/azure_devops_provider.py

---

⚙️ CodeRabbit configuration file

apps/backend/**/*.py: Focus on Python best practices, type hints, and async patterns.
Check for proper error handling and security considerations.
Verify compatibility with Python 3.12+.

Files:

• apps/backend/runners/github/providers/azure_devops_provider.py

🧬 Code graph analysis (1)

apps/backend/runners/github/providers/azure_devops_provider.py (1)

apps/backend/runners/github/providers/protocol.py (5)

• IssueData (66-87)
• IssueFilters (126-137)
• PRFilters (141-152)
• ProviderType (17-24)
• ReviewData (111-122)

🪛 GitHub Check: CodeQL

apps/backend/runners/github/providers/azure_devops_provider.py

[notice] 232-232: Unused local variable
Variable pr is not used.

---

[notice] 594-594: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

---

[notice] 646-646: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

🪛 GitHub Check: python

apps/backend/runners/github/providers/azure_devops_provider.py

[failure] 315-315: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:315:23: UP045 Use X | None for type annotations

---

[failure] 185-185: Ruff (UP006)
apps/backend/runners/github/providers/azure_devops_provider.py:185:71: UP006 Use list instead of List for type annotation

---

[failure] 185-185: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:185:40: UP045 Use X | None for type annotations

---

[failure] 87-87: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:87:20: UP045 Use X | None for type annotations

---

[failure] 86-86: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:86:11: UP045 Use X | None for type annotations

---

[failure] 85-85: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:85:17: UP045 Use X | None for type annotations

---

[failure] 84-84: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:84:15: UP045 Use X | None for type annotations

---

[failure] 83-83: Ruff (UP045)
apps/backend/runners/github/providers/azure_devops_provider.py:83:20: UP045 Use X | None for type annotations

---

[failure] 21-21: Ruff (UP035)
apps/backend/runners/github/providers/azure_devops_provider.py:21:1: UP035 typing.List is deprecated, use list instead

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)

• GitHub Check: CodeQL
• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (4)

apps/backend/runners/github/providers/azure_devops_provider.py (4)

793-857: LGTM on API operations.

Timeouts are properly set (30 seconds), and blocking calls are correctly wrapped with asyncio.to_thread. The function-local imports are acceptable for these low-level utility methods.

---

862-958: LGTM on helper methods.

The parsing logic handles ADO's data structures appropriately, with sensible fallbacks for missing data. The datetime parsing covers multiple input formats correctly.

---

646-647: Empty except blocks silently swallow errors in apply_labels.

Add logging to aid debugging when label operations fail.

Likely an incorrect or invalid review comment.

---

338-342: Consider making delete_source_branch configurable.

The delete_source_branch=True is hardcoded. Some workflows prefer to retain source branches for history or debugging.

Likely an incorrect or invalid review comment.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Pin azure-devops to exact beta version for production stability.

The azure-devops>=7.1.0b4,<8.0.0 constraint still allows auto-upgrades to future beta versions. Since 7.1.0b4 is a pre-release with no stable version available, consider pinning to ==7.1.0b4 for reproducible builds.

Suggested fix

-azure-devops>=7.1.0b4,<8.0.0
+azure-devops==7.1.0b4  # Pinned beta - update when stable 7.1.x is released

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	# Azure DevOps Integration (optional - for ADO provider)
	azure-devops>=7.1.0b4,<8.0.0
	msrest>=0.7.1,<1.0.0
	# Azure DevOps Integration (optional - for ADO provider)
	azure-devops==7.1.0b4 # Pinned beta - update when stable 7.1.x is released
	msrest>=0.7.1,<1.0.0

🤖 Prompt for AI Agents

In @apps/backend/requirements.txt around lines 19 - 21, The requirements file
currently allows azure-devops to float across beta releases using
"azure-devops>=7.1.0b4,<8.0.0"; change the constraint to pin the exact beta
version by replacing that range with an exact equality for the 7.1.0b4 release
(i.e., use azure-devops==7.1.0b4) so builds are reproducible; update any related
CI/lockfile if present to match the pinned azure-devops version.

[coderabbitai]

🛠️ Refactor suggestion | 🟠 Major

Use modern type annotation syntax.

Per Python 3.10+ and Ruff UP035/UP006 rules, use built-in list instead of typing.List and X | None instead of Optional[X].

Suggested fix for imports

-from typing import Any, List, Optional
+from typing import Any

Then update all type hints throughout the file:

• Optional[X] → X | None
• List[X] → list[X]

Committable suggestion skipped: line range outside the PR's diff.

🧰 Tools

🪛 GitHub Check: python

[failure] 21-21: Ruff (UP035)
apps/backend/runners/github/providers/azure_devops_provider.py:21:1: UP035 typing.List is deprecated, use list instead

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py at line 21,
Replace typing.List and typing.Optional with modern built-ins: change the import
line to use "from typing import Any" (remove List and Optional), then update all
type hints in this file (e.g., in functions/methods and class signatures such as
any occurrences inside AzureDevOpsProvider, get_* methods, or helpers) replacing
"List[X]" with "list[X]" and "Optional[X]" with "X | None". Ensure any forward
references or imports still resolve and run type checks after the changes.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Remove unused variable and fix error handling.

1. Line 232: pr is fetched but never used (flagged by CodeQL).
2. Line 269: Returning an error string as diff content is problematic—callers may treat it as valid diff output.

Suggested fix

     async def fetch_pr_diff(self, number: int) -> str:
         """Fetch the diff for a pull request."""
         try:
-            # Get the PR to find the commits
-            pr = await asyncio.to_thread(
-                self.git_client.get_pull_request,
-                repository_id=self._repo_name,
-                pull_request_id=number,
-                project=self._project,
-            )
-
             # Get commits in the PR
             commits = await asyncio.to_thread(
                 self.git_client.get_pull_request_commits,

-        except Exception as e:
-            return f"Error fetching diff: {e}"
+        except Exception:
+            # Return empty diff on failure; caller should handle missing diff gracefully
+            return ""

🧰 Tools

🪛 GitHub Check: CodeQL

[notice] 232-232: Unused local variable
Variable pr is not used.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
228 - 269, In fetch_pr_diff: remove the unused fetch of pr (the call to
self.git_client.get_pull_request) since pr is never used; keep the commits check
(commits variable) and bail with an empty string if no commits; safely handle a
missing or None changes.change_entries when building diff_lines; and do not
return an error string on exception—raise the exception (or let it propagate)
instead so callers can handle errors rather than receiving an invalid diff
string.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Log vote failures instead of silently ignoring.

The exception is silently swallowed. While the comment explains the rationale, this masks legitimate errors (network issues, permission problems).

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
306 - 307, Replace the silent except block that currently does "except
Exception: pass" in the vote-related code with an exception handler that
captures the exception (e.g., except Exception as e) and logs the failure with
context (PR/commit id, reviewer id, and any action like "vote" or "set_vote")
using the module/class logger (e.g., self.logger or logger) — keep the existing
behavior of not raising after logging but ensure the log uses logger.exception
or logger.error with the exception details so network/permission errors are
visible for debugging.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Add logging for merge failures.

Returning False without logging makes debugging difficult. Callers won't know why the merge failed.

Suggested fix

-        except Exception:
-            return False
+        except Exception as e:
+            import logging
+            logging.warning(f"Failed to merge PR #{pr_number}: {e}")
+            return False

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
359 - 360, The bare except block that returns False hides merge errors; update
the exception handler in the AzureDevOpsProvider merge routine (the except
Exception: return False) to log the failure before returning False — call an
appropriate logger (e.g., self.logger.exception or module-level
logger.exception) with a descriptive message like "Failed to merge PR" and
include the exception so the stacktrace is recorded, then return False as
before.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Add logging for close_pr failures.

Same concern as merge_pr—silent failures hinder debugging.

Suggested fix

-        except Exception:
-            return False
+        except Exception as e:
+            import logging
+            logging.warning(f"Failed to close PR #{pr_number}: {e}")
+            return False

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	except Exception:
	return False
	except Exception as e:
	import logging
	logging.warning(f"Failed to close PR #{pr_number}: {e}")
	return False

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
385 - 386, The close_pr handler currently swallows all exceptions (except
Exception: return False); update the except block in close_pr to log the failure
before returning False by catching the exception as e and calling the provider's
logger (use the class logger used elsewhere in this file, e.g., self.logger or
logger) with the PR context and the exception (use logger.exception or
logger.error(..., exc_info=True)), similar to how merge_pr was fixed—include PR
identifier/URL and the exception message/trace to aid debugging.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Add logging for close_issue failures.

Consistent with other operations, failures should be logged for debugging.

Suggested fix

-        except Exception:
-            return False
+        except Exception as e:
+            import logging
+            logging.warning(f"Failed to close work item #{number}: {e}")
+            return False

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
555 - 556, The close_issue handler swallows all exceptions without any logging;
update the except block in the close_issue method of AzureDevOpsProvider (or the
close_issue function) to log the failure details before returning False: catch
Exception as e and call the module/class logger (e.g.,
self.logger.exception(...) or self.logger.error(..., exc_info=True)) with a
short message that includes the issue id/context and the exception to aid
debugging, then return False as before.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Improve error handling in add_comment fallback logic.

The nested try-except structure silently swallows all errors. While the fallback from work item to PR comment is intentional, complete silence makes troubleshooting impossible.

Suggested fix

         except Exception:
             # Try as PR comment
             try:
                 from azure.devops.v7_1.git.models import Comment, CommentThread

                 comment = Comment(content=body)
                 thread = CommentThread(comments=[comment], status="active")

                 result = await asyncio.to_thread(
                     self.git_client.create_thread,
                     comment_thread=thread,
                     repository_id=self._repo_name,
                     pull_request_id=issue_or_pr_number,
                     project=self._project,
                 )
                 return result.id if result else 0
-            except Exception:
+            except Exception as e:
+                import logging
+                logging.debug(f"Failed to add comment to #{issue_or_pr_number}: {e}")
                 return 0

🧰 Tools

🪛 GitHub Check: CodeQL

[notice] 594-594: Empty except
'except' clause does nothing but pass and there is no explanatory comment.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
585 - 602, The current nested try/except swallows all errors; modify both except
blocks to capture the exception as a variable (e.g., "except Exception as e")
and log the full exception and context before continuing—use the instance logger
(self.logger.exception or self.logger.error with traceback) or logging.exception
if no instance logger, and include identifiers like issue_or_pr_number,
self._repo_name and self._project and whether it was the work-item or PR-path;
keep the fallback behavior (attempt PR comment) and still return 0 on final
failure after logging the error.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Empty except blocks silently swallow errors in remove_labels.

Add logging to aid debugging when label operations fail.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
686 - 687, The empty except in remove_labels is swallowing errors; change it to
catch Exception as e and log the failure with the exception and contextual
details (e.g., issue/PR id, repo, labels) using the existing logger (self.logger
or logger) so label operation failures are visible for debugging; do not
suppress exceptions silently—either log and continue or re-raise if callers
expect errors.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

🧩 Analysis chain

🏁 Script executed:

rg -n -C3 'check_permissions' --type=py -g '!*test*'

Repository: AndyMik90/Auto-Claude

Length of output: 2044

---

🏁 Script executed:

rg -n 'await\s+.*\.check_permissions\(|\.check_permissions\(' --type=py -g '!*test*'

Repository: AndyMik90/Auto-Claude

Length of output: 47

---

🏁 Script executed:

rg -n 'check_permissions' --type=py -g '!*test*' -B2 -A5

Repository: AndyMik90/Auto-Claude

Length of output: 2374

---

🏁 Script executed:

rg -n 'check_permissions' . --type-list | head -20 && rg -n '\.check_permissions\(|check_permissions\s*\(' . -B1 -A1 | grep -v 'def check_permissions' | grep -v '.pyc'

Repository: AndyMik90/Auto-Claude

Length of output: 945

---

🏁 Script executed:

# Search for actual method calls (excluding definitions)
rg 'check_permissions\(' . --type=py | grep -v 'def check_permissions' | grep -v 'async def check_permissions'

Repository: AndyMik90/Auto-Claude

Length of output: 47

---

🏁 Script executed:

# Check if check_permissions is referenced in any configuration, comments, or future plans
rg 'check_permissions' . --type-list=all -i | head -30

Repository: AndyMik90/Auto-Claude

Length of output: 454

---

🏁 Script executed:

# Search for all references to check_permissions without type restrictions
rg 'check_permissions' . -i | grep -v '.pyc' | grep -v '__pycache__'

Repository: AndyMik90/Auto-Claude

Length of output: 423

---

🏁 Script executed:

# Check for TODO/FIXME comments in the provider files
rg -n 'TODO|FIXME|XXX' apps/backend/runners/github/providers/ --type=py | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 47

---

🏁 Script executed:

# Search for endpoints or functions that might call check_permissions
rg -n 'permission' apps/backend/runners/github/providers/ --type=py | grep -i 'check\|call\|invoke'

Repository: AndyMik90/Auto-Claude

Length of output: 926

---

🏁 Script executed:

# Look at the context around the protocol definition
cat -n apps/backend/runners/github/providers/protocol.py | sed -n '430,455p'

Repository: AndyMik90/Auto-Claude

Length of output: 870

---

🏁 Script executed:

# Check the entire protocol interface to understand its purpose
cat -n apps/backend/runners/github/providers/protocol.py | head -50

Repository: AndyMik90/Auto-Claude

Length of output: 1551

---

🏁 Script executed:

# Verify if any other providers also have check_permissions stubs
find apps/backend/runners/github/providers -name '*_provider.py' -type f | xargs -I {} basename {}

Repository: AndyMik90/Auto-Claude

Length of output: 108

---

🏁 Script executed:

# Let's also verify the azure_devops_provider file structure around this method
cat -n apps/backend/runners/github/providers/azure_devops_provider.py | sed -n '775,800p'

Repository: AndyMik90/Auto-Claude

Length of output: 1200

---

🏁 Script executed:

# Check if there are any other stub methods in the azure provider that follow this pattern
grep -n 'return "' apps/backend/runners/github/providers/azure_devops_provider.py | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 212

---

check_permissions is a documented stub that is currently unused in the codebase.

The method's limitations are already clearly documented (lines 782-786), explaining that ADO permissions are more complex and this returns a simplified default. Since this method is not called anywhere in the codebase, there is no active authorization bypass risk. If this is intended for future use, consider adding a TODO comment clarifying the implementation status and expected behavior.

🤖 Prompt for AI Agents

In @apps/backend/runners/github/providers/azure_devops_provider.py around lines
778 - 787, The check_permissions function is a documented stub that always
returns "write" and is unused; update the function docstring or body to include
a clear TODO explaining it's a placeholder for future ADO permission resolution,
describe expected behavior (e.g., resolve project-level ADO permissions or
raise/not-used), and mark it as intentionally unused for now (e.g., TODO:
implement or integrate with permission checks) so reviewers know it isn't an
active authorization bypass; reference the async def check_permissions(username:
str) function and leave the current simplified return in place until
implementation.

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts:
- Around line 159-167: The diff summary returned by the handler currently only
lists change type and path (built from changesResult.changeEntries into
diffLines) instead of actual file content diffs; either add a clear inline
comment near the construction of diffLines (and in the function handling PR
diffs) stating this is an intentional lightweight summary for performance and
not a full content diff, or implement full diffs by fetching file
contents/patches for each change and include them in the returned string;
reference the changesResult.changeEntries array and the diffLines construction
to locate where to add the comment or expand the logic.

In @apps/frontend/src/main/ipc-handlers/ado/utils.ts:
- Around line 31-37: The return object includes a redundant fallback for
repoName; remove the "|| ''" and return repoName directly since repoName was
earlier set from vars['ADO_REPO_NAME'] || projectName and projectName is
validated truthy. Update the return in the function that builds the ADO config
to use repoName (not repoName || '') and keep the other fields (organization,
project: projectName, pat, instanceUrl) unchanged.
- Around line 117-125: The current sanitizeWiqlString function triggers the
no-control-regex lint rule due to literal control-character escapes in the regex
used to strip control chars; update sanitizeWiqlString to avoid the
control-regex by either (A) replacing the problematic regex with a
function-based sanitization that iterates characters (e.g.,
Array.from(value).filter(ch => { const c = ch.charCodeAt(0); return !(c >= 0 &&
c <= 0x1f) && !(c >= 0x7f && c <= 0x9f); }).join('')) before slicing, or (B) if
you must keep the regex, add an inline eslint disable comment just above the
regex line to suppress no-control-regex for that single occurrence; apply the
change inside sanitizeWiqlString so the control characters are removed without
causing the linter/pipeline failure.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 04dfa73 and edcdccc.

📒 Files selected for processing (7)

• apps/frontend/src/main/ipc-handlers/ado/index.ts
• apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts
• apps/frontend/src/main/ipc-handlers/ado/types.ts
• apps/frontend/src/main/ipc-handlers/ado/utils.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/main/ipc-handlers/index.ts
• apps/frontend/src/shared/constants/ipc.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/main/ipc-handlers/index.ts
• apps/frontend/src/main/ipc-handlers/ado/types.ts
• apps/frontend/src/main/ipc-handlers/ado/index.ts
• apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts
• apps/frontend/src/shared/constants/ipc.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/main/ipc-handlers/ado/utils.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/main/ipc-handlers/index.ts
• apps/frontend/src/main/ipc-handlers/ado/types.ts
• apps/frontend/src/main/ipc-handlers/ado/index.ts
• apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts
• apps/frontend/src/shared/constants/ipc.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/main/ipc-handlers/ado/utils.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/main/ipc-handlers/index.ts
• apps/frontend/src/main/ipc-handlers/ado/types.ts
• apps/frontend/src/main/ipc-handlers/ado/index.ts
• apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts
• apps/frontend/src/shared/constants/ipc.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/main/ipc-handlers/ado/utils.ts

🧬 Code graph analysis (4)

apps/frontend/src/main/ipc-handlers/index.ts (1)

apps/frontend/src/main/ipc-handlers/ado/index.ts (1)

• registerADOHandlers (16-19)

apps/frontend/src/main/ipc-handlers/ado/types.ts (1)

apps/frontend/src/main/ipc-handlers/ado/index.ts (3)

• ADOConfig (23-23)
• ADOWorkItem (23-23)
• ADOPullRequest (23-23)

apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts (2)

apps/frontend/src/main/ipc-handlers/ado/types.ts (2)

• ADOAPIPullRequest (57-84)
• ADOPullRequest (126-153)

apps/frontend/src/main/ipc-handlers/ado/utils.ts (4)

• normalizePRState (138-148)
• extractBranchName (154-156)
• getADOConfig (14-41)
• adoFetch (56-82)

apps/frontend/src/main/ipc-handlers/ado/utils.ts (2)

apps/frontend/src/shared/types/project.ts (1)

• Project (5-13)

apps/frontend/src/main/ipc-handlers/ado/types.ts (1)

• ADOConfig (5-11)

🪛 Biome (2.1.2)

apps/frontend/src/main/ipc-handlers/ado/utils.ts

[error] 122-122: Unexpected control character in a regular expression.

Control characters are unusual and potentially incorrect inputs, so they are disallowed.

(lint/suspicious/noControlCharactersInRegex)

---

[error] 122-122: Unexpected control character in a regular expression.

Control characters are unusual and potentially incorrect inputs, so they are disallowed.

(lint/suspicious/noControlCharactersInRegex)

🪛 GitHub Actions: CI

apps/frontend/src/main/ipc-handlers/ado/utils.ts

[error] 122-122: no-control-regex: Unexpected control character(s) in regular expression: \x00, \x1f

🪛 GitHub Check: test-frontend

apps/frontend/src/main/ipc-handlers/ado/utils.ts

[failure] 122-122:
Unexpected control character(s) in regular expression: \x00, \x1f

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (javascript-typescript)
• GitHub Check: CodeQL (python)

🔇 Additional comments (8)

apps/frontend/src/shared/constants/ipc.ts (1)

514-555: LGTM!

The ADO IPC channel constants are well-organized and follow the existing naming conventions. The grouping (work items, PRs, events, auto-fix) mirrors the patterns established for GitHub and GitLab integrations.

apps/frontend/src/main/ipc-handlers/index.ts (1)

95-96: LGTM!

The ADO handlers are correctly registered in the IPC setup flow. The parameterless registration aligns with the current ADO handler implementation that doesn't require agentManager or getMainWindow dependencies.

apps/frontend/src/main/ipc-handlers/ado/index.ts (1)

1-23: LGTM!

Clean module organization with clear documentation. The entry point correctly aggregates work item and PR handler registrations, and appropriately re-exports utilities and types for external use.

apps/frontend/src/main/ipc-handlers/ado/types.ts (1)

98-153: LGTM!

The normalized types (ADOWorkItem, ADOPullRequest) provide good GitHub/GitLab compatibility with appropriate aliases (number for id). The vote values documentation (line 145) is helpful for understanding the ADO review system.

apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts (2)

21-57: LGTM!

The transformWorkItem function correctly maps ADO API fields to the normalized application format. The handling of optional fields (assignees, tags) and the closedAt approximation using ChangedDate are reasonable for ADO's data model.

---

107-149: LGTM!

The WIQL query construction properly uses sanitizeWiqlString for the project name to prevent injection. The state filtering logic correctly maps to ADO's work item states, and the batch fetch with a 200-item limit is a sensible safeguard.

apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts (1)

20-49: LGTM!

Good transformation logic with appropriate handling of ADO-specific fields. The comment on line 44 helpfully documents the ADO limitation regarding updatedAt.

apps/frontend/src/main/ipc-handlers/ado/utils.ts (1)

56-82: LGTM!

The adoFetch implementation correctly handles Basic authentication with PAT and provides comprehensive error messages including status and response body.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider documenting the diff summary limitation.

The current implementation returns only a summary of changed files (change type and path) rather than actual file content diffs. This differs from typical GitHub/GitLab PR diff behavior. If this is intentional for performance or summary purposes, consider adding a comment explaining this design decision. Otherwise, users expecting full diffs may be surprised.

🤖 Prompt for AI Agents

In @apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts around lines 159 -
167, The diff summary returned by the handler currently only lists change type
and path (built from changesResult.changeEntries into diffLines) instead of
actual file content diffs; either add a clear inline comment near the
construction of diffLines (and in the function handling PR diffs) stating this
is an intentional lightweight summary for performance and not a full content
diff, or implement full diffs by fetching file contents/patches for each change
and include them in the returned string; reference the
changesResult.changeEntries array and the diffLines construction to locate where
to add the comment or expand the logic.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Minor: Redundant fallback for repoName.

Line 34 uses repoName || '', but repoName is already assigned a fallback value on line 26 (vars['ADO_REPO_NAME'] || projectName). Since projectName is validated as truthy on line 29, repoName will never be falsy at this point.

♻️ Simplify redundant fallback

     return {
       organization,
       project: projectName,
-      repoName: repoName || '',
+      repoName,
       pat,
       instanceUrl,
     };

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	return {
	organization,
	project: projectName,
	repoName: repoName || '',
	pat,
	instanceUrl,
	};
	return {
	organization,
	project: projectName,
	repoName,
	pat,
	instanceUrl,
	};

🤖 Prompt for AI Agents

In @apps/frontend/src/main/ipc-handlers/ado/utils.ts around lines 31 - 37, The
return object includes a redundant fallback for repoName; remove the "|| ''" and
return repoName directly since repoName was earlier set from
vars['ADO_REPO_NAME'] || projectName and projectName is validated truthy. Update
the return in the function that builds the ADO config to use repoName (not
repoName || '') and keep the other fields (organization, project: projectName,
pat, instanceUrl) unchanged.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Fix the control character regex to resolve pipeline failure.

The regex on line 122 triggers the no-control-regex lint rule, causing CI to fail. While the intent is correct (sanitizing control characters), the linter flags literal control character escapes.

Use a character code-based approach or disable the rule for this specific line:

🐛 Proposed fix using eslint-disable comment

 export function sanitizeWiqlString(value: string): string {
   if (!value) return '';
   // Escape single quotes (WIQL string delimiter)
   let sanitized = value.replace(/'/g, "''");
   // Remove control characters
+  // eslint-disable-next-line no-control-regex
   sanitized = sanitized.replace(/[\x00-\x1f\x7f-\x9f]/g, '');
   // Limit length
   return sanitized.slice(0, 500);
 }

Alternatively, use a function-based approach to avoid the regex entirely:

♻️ Alternative: Function-based sanitization

 export function sanitizeWiqlString(value: string): string {
   if (!value) return '';
   // Escape single quotes (WIQL string delimiter)
   let sanitized = value.replace(/'/g, "''");
   // Remove control characters (0x00-0x1f and 0x7f-0x9f)
-  sanitized = sanitized.replace(/[\x00-\x1f\x7f-\x9f]/g, '');
+  sanitized = Array.from(sanitized)
+    .filter(char => {
+      const code = char.charCodeAt(0);
+      return !((code >= 0x00 && code <= 0x1f) || (code >= 0x7f && code <= 0x9f));
+    })
+    .join('');
   // Limit length
   return sanitized.slice(0, 500);
 }

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	export function sanitizeWiqlString(value: string): string {
	if (!value) return '';
	// Escape single quotes (WIQL string delimiter)
	let sanitized = value.replace(/'/g, "''");
	// Remove control characters
	sanitized = sanitized.replace(/[\x00-\x1f\x7f-\x9f]/g, '');
	// Limit length
	return sanitized.slice(0, 500);
	}
	export function sanitizeWiqlString(value: string): string {
	if (!value) return '';
	// Escape single quotes (WIQL string delimiter)
	let sanitized = value.replace(/'/g, "''");
	// Remove control characters (0x00-0x1f and 0x7f-0x9f)
	sanitized = Array.from(sanitized)
	.filter(char => {
	const code = char.charCodeAt(0);
	return !((code >= 0x00 && code <= 0x1f) || (code >= 0x7f && code <= 0x9f));
	})
	.join('');
	// Limit length
	return sanitized.slice(0, 500);
	}

🧰 Tools

🪛 Biome (2.1.2)

[error] 122-122: Unexpected control character in a regular expression.

Control characters are unusual and potentially incorrect inputs, so they are disallowed.

(lint/suspicious/noControlCharactersInRegex)

---

[error] 122-122: Unexpected control character in a regular expression.

Control characters are unusual and potentially incorrect inputs, so they are disallowed.

(lint/suspicious/noControlCharactersInRegex)

🪛 GitHub Actions: CI

[error] 122-122: no-control-regex: Unexpected control character(s) in regular expression: \x00, \x1f

🪛 GitHub Check: test-frontend

[failure] 122-122:
Unexpected control character(s) in regular expression: \x00, \x1f

🤖 Prompt for AI Agents

In @apps/frontend/src/main/ipc-handlers/ado/utils.ts around lines 117 - 125, The
current sanitizeWiqlString function triggers the no-control-regex lint rule due
to literal control-character escapes in the regex used to strip control chars;
update sanitizeWiqlString to avoid the control-regex by either (A) replacing the
problematic regex with a function-based sanitization that iterates characters
(e.g., Array.from(value).filter(ch => { const c = ch.charCodeAt(0); return !(c
>= 0 && c <= 0x1f) && !(c >= 0x7f && c <= 0x9f); }).join('')) before slicing, or
(B) if you must keep the regex, add an inline eslint disable comment just above
the regex line to suppress no-control-regex for that single occurrence; apply
the change inside sanitizeWiqlString so the control characters are removed
without causing the linter/pipeline failure.

[coderabbitai]

Actionable comments posted: 10

🤖 Fix all issues with AI agents

In @apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts:
- Around line 173-178: The current code truncates to 200 items via const ids =
queryResult.workItems.slice(0, 200)... which hides results for large backlogs;
make the batch size configurable (introduce a BATCH_SIZE constant or add a
config.batchSize/env var and replace the hardcoded 200), or implement pagination
by repeatedly calling adoFetch(`/wit/workitems?ids=...`) in chunks of BATCH_SIZE
until all ids from queryResult.workItems are fetched; additionally return or
attach a totalCount (e.g., from queryResult or aggregate) alongside
workItemsResult so callers can detect truncation.

In @apps/frontend/src/preload/api/modules/ado-api.ts:
- Around line 194-198: The callbacks use overly broad unknown types; define
precise result interfaces (e.g., ADOInvestigationCompleteResult and
ADOPRReviewCompleteResult) matching the IPC payload shape and replace the
unknown type in onADOInvestigationComplete and onADOPRReviewComplete signatures
with those interfaces; update the createIpcListener generic usage so the
listener callback is strongly typed and adjust any related exports/imports to
use the new types.
- Around line 8-34: The ADOWorkItem interface is duplicated; extract the
ADOWorkItem type into a single shared module and export it, then replace the
local interface in both the preload module containing ADOWorkItem and the IPC
handler that currently duplicates it with an import of that shared ADOWorkItem;
ensure the shared export includes all fields (id, number, title, state,
workItemType, tags, assignees, author, priority, iteration, areaPath, createdAt,
updatedAt, closedAt, url, htmlUrl) and update the import statements in the files
that referenced the old local definitions.

In @apps/frontend/src/renderer/components/ADOSetupModal.tsx:
- Around line 142-326: The renderCredentialsStep JSX uses hardcoded user-facing
strings; update the ADOSetupModal component to use i18n by importing and calling
useTranslation (with the appropriate namespace) and replace all visible text in
renderCredentialsStep—titles, descriptions, labels, placeholders, button text,
help link text, PAT guidance, optional hints and error messages (e.g., "Connect
to Azure DevOps", "Configure your Azure DevOps connection...", "You'll need a
Personal Access Token (PAT)", "Organization *", "Project *", "Personal Access
Token *", "Save Without Testing", "Test & Save", "Skip for now", and the error
string)—with t('...') keys; ensure keys follow the project's namespace/prefix
convention and update any template strings or concatenations to use t with
interpolation where needed (refer to renderCredentialsStep,
handleSaveWithoutTest, testConnection and the error state usages to locate all
occurrences).
- Line 29: The ADOSetupModalProps declares and the ADOSetupModal component
destructures a project prop that is never used; either remove project from the
ADOSetupModalProps interface and from the component destructuring, or use it to
pre-fill the adoProject state or display project context. Update the interface
ADOSetupModalProps and the component signature to drop project if unused, or set
initial state for adoProject (or render project info) using the project value so
the prop is actually consumed (ensure references to project are removed if you
choose deletion to avoid linter errors).

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx:
- Around line 276-282: The button rendering inside ADOWorkItems (the element
with key={wi.id} that calls setSelectedWorkItem onClick and uses isSelected for
styling) lacks an explicit type and will default to type="submit"; update that
button to include type="button" to prevent unintended form submissions when this
component is nested in a form.
- Around line 41-363: The ADOWorkItems component currently uses many hardcoded
user-facing strings; import and call the i18n hook (useTranslation) at the top
of ADOWorkItems (same pattern as ADOSetupModal) and replace all literals with
translation lookups (e.g., t('ado:workItems.title'), t('ado:connect.title'),
t('ado:buttons.configure'), t('ado:buttons.settings'), t('ado:buttons.refresh'),
t('ado:search.placeholder'), t('ado:empty.noMatches'), t('ado:empty.noItems'),
t('ado:detail.selectWorkItem'), and any labels like
Author/Assigned/Created/Iteration/Tags/Description); ensure namespace prefix
(e.g., 'ado:') is used consistently, update any JSX text, button labels, badge
counts, placeholders and error messages to use t(), and add corresponding keys
to the ado translation namespace so ADOSetupModal and ADOWorkItems share the
same localization keys.
- Around line 458-461: The code renders unsanitized HTML from Azure DevOps via
dangerouslySetInnerHTML using workItem.body in the ADOWorkItems React component,
which creates an XSS risk; fix it by installing DOMPurify and @types/dompurify,
import DOMPurify in ADOWorkItems.tsx, sanitize workItem.body (e.g., const
safeHtml = DOMPurify.sanitize(workItem.body)) before passing it into
dangerouslySetInnerHTML, or replace the dangerouslySetInnerHTML usage with a
safe render that uses the sanitized string; ensure the sanitize step runs
wherever workItem.body is mapped or prepared so no raw HTML reaches
dangerouslySetInnerHTML.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between edcdccc and 935c6f5.

📒 Files selected for processing (8)

• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/preload/api/index.ts
• apps/frontend/src/preload/api/modules/ado-api.ts
• apps/frontend/src/preload/api/modules/index.ts
• apps/frontend/src/renderer/components/ADOSetupModal.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/renderer/components/index.ts
• apps/frontend/src/shared/constants/ipc.ts

🧰 Additional context used

📓 Path-based instructions (3)

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/preload/api/index.ts
• apps/frontend/src/preload/api/modules/index.ts
• apps/frontend/src/renderer/components/index.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/renderer/components/ADOSetupModal.tsx
• apps/frontend/src/preload/api/modules/ado-api.ts
• apps/frontend/src/shared/constants/ipc.ts

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/preload/api/index.ts
• apps/frontend/src/preload/api/modules/index.ts
• apps/frontend/src/renderer/components/index.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/renderer/components/ADOSetupModal.tsx
• apps/frontend/src/preload/api/modules/ado-api.ts
• apps/frontend/src/shared/constants/ipc.ts

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/preload/api/index.ts
• apps/frontend/src/preload/api/modules/index.ts
• apps/frontend/src/renderer/components/index.ts
• apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts
• apps/frontend/src/renderer/components/ADOSetupModal.tsx
• apps/frontend/src/preload/api/modules/ado-api.ts
• apps/frontend/src/shared/constants/ipc.ts

🧠 Learnings (1)

📚 Learning: 2026-01-04T23:59:45.209Z

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.

Applied to files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/renderer/components/ADOSetupModal.tsx

🧬 Code graph analysis (3)

apps/frontend/src/renderer/components/ADOWorkItems.tsx (2)

.design-system/src/lib/icons.ts (2)

• Zap (38-38)
• ChevronRight (23-23)

apps/frontend/src/preload/api/modules/ado-api.ts (1)

• ADOWorkItem (8-34)

apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts (2)

apps/frontend/src/main/ipc-handlers/ado/types.ts (2)

• ADOAPIWorkItem (13-43)
• ADOWorkItem (98-124)

apps/frontend/src/main/ipc-handlers/ado/utils.ts (4)

• normalizeWorkItemState (130-133)
• getADOConfig (14-41)
• adoFetch (56-82)
• sanitizeWiqlString (117-125)

apps/frontend/src/preload/api/modules/ado-api.ts (1)

apps/frontend/src/shared/constants/ipc.ts (1)

• IPC_CHANNELS (6-557)

🪛 ast-grep (0.40.4)

apps/frontend/src/renderer/components/ADOWorkItems.tsx

[warning] 459-459: Usage of dangerouslySetInnerHTML detected. This bypasses React's built-in XSS protection. Always sanitize HTML content using libraries like DOMPurify before injecting it into the DOM to prevent XSS attacks.
Context: dangerouslySetInnerHTML
Note: [CWE-79] Improper Neutralization of Input During Web Page Generation [REFERENCES]
- https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
- https://cwe.mitre.org/data/definitions/79.html

(react-unsafe-html-injection)

🪛 Biome (2.1.2)

apps/frontend/src/renderer/components/ADOWorkItems.tsx

[error] 276-282: Provide an explicit type prop for the button element.

The default type of a button is submit, which causes the submission of a form when placed inside a form element. This is likely not the behaviour that you want inside a React application.
Allowed button types are: submit, button or reset

(lint/a11y/useButtonType)

---

[error] 460-460: Avoid passing content using the dangerouslySetInnerHTML prop.

Setting content using code can expose users to cross-site scripting (XSS) attacks

(lint/security/noDangerouslySetInnerHtml)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (python)
• GitHub Check: CodeQL (javascript-typescript)

🔇 Additional comments (8)

apps/frontend/src/renderer/components/index.ts (1)

11-12: LGTM!

The new ADO component exports follow the established barrel export pattern and are properly placed alongside related integrations (after GitHubIssues).

apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts (3)

150-162: WIQL query construction looks secure.

Good use of sanitizeWiqlString for the project name before interpolation into the WIQL query. The state conditions use hardcoded values, avoiding injection risks.

---

21-57: LGTM!

The transformWorkItem function correctly maps ADO API fields to the application's normalized format, with proper handling of:

• Optional fields (assignedTo, _links)
• Tag parsing from semicolon-separated string
• State normalization via normalizeWorkItemState
• Fallback URL generation when _links.html is missing

---

382-390: LGTM!

The registerWorkItemHandlers function cleanly aggregates all handler registrations, following a consistent pattern for IPC handler setup.

apps/frontend/src/preload/api/modules/index.ts (1)

14-14: LGTM!

The ADO API module export follows the established barrel pattern and is appropriately positioned alongside other provider APIs (GitHub, Linear).

apps/frontend/src/preload/api/index.ts (1)

12-12: LGTM!

The ADO API integration follows the established pattern used for GitHub:

• Namespaced under ado property in ElectronAPI
• Factory properly creates the API via createADOAPI()
• Both the factory and type are exported for external use

Also applies to: 34-34, 52-53, 70-70, 89-89

apps/frontend/src/preload/api/modules/ado-api.ts (1)

248-268: LGTM!

The createADOAPI factory cleanly assembles all ADO operations and event listeners into a typed API object, matching the pattern established by createGitHubAPI.

apps/frontend/src/shared/constants/ipc.ts (1)

512-513: LGTM!

The formatting change adds consistency with the trailing comma pattern used throughout the file.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider making the batch size limit configurable or documenting the 200-item cap.

The 200-item limit is reasonable for performance, but users with large backlogs may not realize results are truncated. Consider adding a total count or pagination support.

📝 Optional: Return total count for transparency

         if (!queryResult.workItems || queryResult.workItems.length === 0) {
           return { success: true, data: [] };
         }

+        const totalCount = queryResult.workItems.length;
         // Fetch full work item details (batch, max 200)
         const ids = queryResult.workItems.slice(0, 200).map(wi => wi.id);
         // ... fetch details ...

-        return { success: true, data: result };
+        return { 
+          success: true, 
+          data: result,
+          // Optional: include metadata about truncation
+          // meta: { total: totalCount, returned: result.length, truncated: totalCount > 200 }
+        };

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts around lines
173 - 178, The current code truncates to 200 items via const ids =
queryResult.workItems.slice(0, 200)... which hides results for large backlogs;
make the batch size configurable (introduce a BATCH_SIZE constant or add a
config.batchSize/env var and replace the hardcoded 200), or implement pagination
by repeatedly calling adoFetch(`/wit/workitems?ids=...`) in chunks of BATCH_SIZE
until all ids from queryResult.workItems are fetched; additionally return or
attach a totalCount (e.g., from queryResult or aggregate) alongside
workItemsResult so callers can detect truncation.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Type duplication: ADOWorkItem is defined in both preload and IPC handler layers.

The ADOWorkItem interface here (lines 8-34) mirrors the one in apps/frontend/src/main/ipc-handlers/ado/types.ts (lines 97-123). Consider importing from a shared location to avoid drift.

You could move shared types to apps/frontend/src/shared/types/ado.ts and import from there in both locations. This ensures type consistency across the IPC boundary.

🤖 Prompt for AI Agents

In @apps/frontend/src/preload/api/modules/ado-api.ts around lines 8 - 34, The
ADOWorkItem interface is duplicated; extract the ADOWorkItem type into a single
shared module and export it, then replace the local interface in both the
preload module containing ADOWorkItem and the IPC handler that currently
duplicates it with an import of that shared ADOWorkItem; ensure the shared
export includes all fields (id, number, title, state, workItemType, tags,
assignees, author, priority, iteration, areaPath, createdAt, updatedAt,
closedAt, url, htmlUrl) and update the import statements in the files that
referenced the old local definitions.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Consider using more specific types for callback results instead of unknown.

onADOInvestigationComplete and onADOPRReviewComplete callbacks receive unknown typed results. If the result structure is known, define and use specific types for better type safety and developer experience.

📝 Example with specific types

+export interface ADOInvestigationResult {
+  // Define the actual structure
+  summary: string;
+  recommendations: string[];
+}
+
 export function onADOInvestigationComplete(
-  callback: (result: unknown) => void
+  callback: (result: ADOInvestigationResult) => void
 ): IpcListenerCleanup {
   return createIpcListener(IPC_CHANNELS.ADO_INVESTIGATION_COMPLETE, callback);
 }

Also applies to: 212-216

🤖 Prompt for AI Agents

In @apps/frontend/src/preload/api/modules/ado-api.ts around lines 194 - 198, The
callbacks use overly broad unknown types; define precise result interfaces
(e.g., ADOInvestigationCompleteResult and ADOPRReviewCompleteResult) matching
the IPC payload shape and replace the unknown type in onADOInvestigationComplete
and onADOPRReviewComplete signatures with those interfaces; update the
createIpcListener generic usage so the listener callback is strongly typed and
adjust any related exports/imports to use the new types.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Unused project prop.

The project prop is declared in ADOSetupModalProps and destructured in the component but is never used. Either remove it from the interface and destructure, or use it (e.g., to pre-fill adoProject or show context).

♻️ If the prop is not needed, remove it

 interface ADOSetupModalProps {
   open: boolean;
   onOpenChange: (open: boolean) => void;
-  project: Project;
   onComplete: (settings: {
     adoOrganization: string;
     adoProject: string;
     adoRepoName: string;
     adoPat: string;
     adoInstanceUrl: string;
   }) => void;
   onSkip?: () => void;
 }

 export function ADOSetupModal({
   open,
   onOpenChange,
-  project,
   onComplete,
   onSkip,
 }: ADOSetupModalProps) {

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	project: Project;
	interface ADOSetupModalProps {
	open: boolean;
	onOpenChange: (open: boolean) => void;
	onComplete: (settings: {
	adoOrganization: string;
	adoProject: string;
	adoRepoName: string;
	adoPat: string;
	adoInstanceUrl: string;
	}) => void;
	onSkip?: () => void;
	}
	export function ADOSetupModal({
	open,
	onOpenChange,
	onComplete,
	onSkip,
	}: ADOSetupModalProps) {
	// ... rest of component implementation
	}

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOSetupModal.tsx at line 29, The
ADOSetupModalProps declares and the ADOSetupModal component destructures a
project prop that is never used; either remove project from the
ADOSetupModalProps interface and from the component destructuring, or use it to
pre-fill the adoProject state or display project context. Update the interface
ADOSetupModalProps and the component signature to drop project if unused, or set
initial state for adoProject (or render project info) using the project value so
the prop is actually consumed (ensure references to project are removed if you
choose deletion to avoid linter errors).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

All user-facing strings must use i18n translation keys.

This new component contains numerous hardcoded strings that violate the project's i18n requirements. As per coding guidelines, always use useTranslation() hook with namespace prefixes for user-facing text.

Examples of hardcoded strings that need translation:

• "Connect to Azure DevOps"
• "Configure your Azure DevOps connection..."
• "You'll need a Personal Access Token (PAT)"
• "Organization *", "Project *", "Personal Access Token *"
• "Save Without Testing", "Test & Save", "Skip for now"
• Error messages like "Please fill in all required fields"

🔧 Example refactor using useTranslation

+import { useTranslation } from 'react-i18next';
+
 export function ADOSetupModal({
   open,
   onOpenChange,
   project,
   onComplete,
   onSkip,
 }: ADOSetupModalProps) {
+  const { t } = useTranslation('ado');
   const [step, setStep] = useState<SetupStep>('credentials');
   // ...

   const renderCredentialsStep = () => (
     <>
       <DialogHeader>
         <DialogTitle className="flex items-center gap-2">
           <Cloud className="h-5 w-5 text-blue-500" />
-          Connect to Azure DevOps
+          {t('setup.title')}
         </DialogTitle>
         <DialogDescription>
-          Configure your Azure DevOps connection to sync work items and pull requests.
+          {t('setup.description')}
         </DialogDescription>
       </DialogHeader>
       // ... apply similar changes to all user-facing strings
     </>
   );

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOSetupModal.tsx around lines 142 -
326, The renderCredentialsStep JSX uses hardcoded user-facing strings; update
the ADOSetupModal component to use i18n by importing and calling useTranslation
(with the appropriate namespace) and replace all visible text in
renderCredentialsStep—titles, descriptions, labels, placeholders, button text,
help link text, PAT guidance, optional hints and error messages (e.g., "Connect
to Azure DevOps", "Configure your Azure DevOps connection...", "You'll need a
Personal Access Token (PAT)", "Organization *", "Project *", "Personal Access
Token *", "Save Without Testing", "Test & Save", "Skip for now", and the error
string)—with t('...') keys; ensure keys follow the project's namespace/prefix
convention and update any template strings or concatenations to use t with
interpolation where needed (refer to renderCredentialsStep,
handleSaveWithoutTest, testConnection and the error state usages to locate all
occurrences).

[coderabbitai]

⚠️ Potential issue | 🟠 Major

All user-facing strings must use i18n translation keys.

Similar to ADOSetupModal, this new component contains many hardcoded strings violating i18n requirements. Examples include:

• "Azure DevOps Work Items"
• "Connect to Azure DevOps"
• "Configure Connection", "Settings", "Refresh"
• "Search work items...", "No matching work items", "No work items found"
• "Select a work item to view details"
• Labels like "Author:", "Assigned:", "Created:", "Iteration:", "Tags:", "Description"

As per coding guidelines, use useTranslation() hook with namespace prefixes.

🧰 Tools

🪛 Biome (2.1.2)

[error] 276-282: Provide an explicit type prop for the button element.

The default type of a button is submit, which causes the submission of a form when placed inside a form element. This is likely not the behaviour that you want inside a React application.
Allowed button types are: submit, button or reset

(lint/a11y/useButtonType)

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx around lines 41 -
363, The ADOWorkItems component currently uses many hardcoded user-facing
strings; import and call the i18n hook (useTranslation) at the top of
ADOWorkItems (same pattern as ADOSetupModal) and replace all literals with
translation lookups (e.g., t('ado:workItems.title'), t('ado:connect.title'),
t('ado:buttons.configure'), t('ado:buttons.settings'), t('ado:buttons.refresh'),
t('ado:search.placeholder'), t('ado:empty.noMatches'), t('ado:empty.noItems'),
t('ado:detail.selectWorkItem'), and any labels like
Author/Assigned/Created/Iteration/Tags/Description); ensure namespace prefix
(e.g., 'ado:') is used consistently, update any JSX text, button labels, badge
counts, placeholders and error messages to use t(), and add corresponding keys
to the ado translation namespace so ADOSetupModal and ADOWorkItems share the
same localization keys.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Add explicit type="button" to prevent unintended form submissions.

The <button> element defaults to type="submit", which can cause unexpected behavior if placed inside a form context.

🐛 Proposed fix

                     <button
                       key={wi.id}
+                      type="button"
                       onClick={() => setSelectedWorkItem(wi)}
                       className={`w-full text-left p-3 hover:bg-muted/50 transition-colors ${
                         isSelected ? 'bg-muted' : ''
                       }`}
                     >

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	<button
	key={wi.id}
	onClick={() => setSelectedWorkItem(wi)}
	className={`w-full text-left p-3 hover:bg-muted/50 transition-colors ${
	isSelected ? 'bg-muted' : ''
	}`}
	>
	<button
	key={wi.id}
	type="button"
	onClick={() => setSelectedWorkItem(wi)}
	className={`w-full text-left p-3 hover:bg-muted/50 transition-colors ${
	isSelected ? 'bg-muted' : ''
	}`}
	>

🧰 Tools

🪛 Biome (2.1.2)

[error] 276-282: Provide an explicit type prop for the button element.

The default type of a button is submit, which causes the submission of a form when placed inside a form element. This is likely not the behaviour that you want inside a React application.
Allowed button types are: submit, button or reset

(lint/a11y/useButtonType)

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx around lines 276 -
282, The button rendering inside ADOWorkItems (the element with key={wi.id} that
calls setSelectedWorkItem onClick and uses isSelected for styling) lacks an
explicit type and will default to type="submit"; update that button to include
type="button" to prevent unintended form submissions when this component is
nested in a form.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Critical XSS vulnerability: unsanitized HTML injection.

workItem.body originates from the Azure DevOps API and is rendered directly via dangerouslySetInnerHTML without sanitization. An attacker with access to ADO work items could inject malicious scripts.

🔒 Recommended fix: Sanitize HTML with DOMPurify

+import DOMPurify from 'dompurify';
+
 function WorkItemDetail({ workItem }: { workItem: ADOWorkItem }) {
   // ...
   
+  const sanitizedBody = workItem.body 
+    ? DOMPurify.sanitize(workItem.body) 
+    : '';
+
   return (
     // ...
     {workItem.body && (
       <div className="border-t pt-4">
         <h4 className="text-sm font-medium mb-2">Description</h4>
         <div
           className="prose prose-sm dark:prose-invert max-w-none"
-          dangerouslySetInnerHTML={{ __html: workItem.body }}
+          dangerouslySetInnerHTML={{ __html: sanitizedBody }}
         />
       </div>
     )}
   );
 }

You'll need to install DOMPurify:

npm install dompurify
npm install --save-dev @types/dompurify

Committable suggestion skipped: line range outside the PR's diff.

🧰 Tools

🪛 ast-grep (0.40.4)

[warning] 459-459: Usage of dangerouslySetInnerHTML detected. This bypasses React's built-in XSS protection. Always sanitize HTML content using libraries like DOMPurify before injecting it into the DOM to prevent XSS attacks.
Context: dangerouslySetInnerHTML
Note: [CWE-79] Improper Neutralization of Input During Web Page Generation [REFERENCES]
- https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
- https://cwe.mitre.org/data/definitions/79.html

(react-unsafe-html-injection)

🪛 Biome (2.1.2)

[error] 460-460: Avoid passing content using the dangerouslySetInnerHTML prop.

Setting content using code can expose users to cross-site scripting (XSS) attacks

(lint/security/noDangerouslySetInnerHtml)

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx around lines 458 -
461, The code renders unsanitized HTML from Azure DevOps via
dangerouslySetInnerHTML using workItem.body in the ADOWorkItems React component,
which creates an XSS risk; fix it by installing DOMPurify and @types/dompurify,
import DOMPurify in ADOWorkItems.tsx, sanitize workItem.body (e.g., const
safeHtml = DOMPurify.sanitize(workItem.body)) before passing it into
dangerouslySetInnerHTML, or replace the dangerouslySetInnerHTML usage with a
safe render that uses the sanitized string; ensure the sanitize step runs
wherever workItem.body is mapped or prepared so no raw HTML reaches
dangerouslySetInnerHTML.

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash

# First, check if the file exists and get its basic info
echo "=== File information ==="
ls -la apps/frontend/src/shared/constants/ipc.ts 2>/dev/null || echo "File not found at standard path"

# Get line count to understand file structure
wc -l apps/frontend/src/shared/constants/ipc.ts 2>/dev/null

# Try to find the file in case it's at a different location
echo -e "\n=== Searching for ipc.ts or similar files ==="
fd -e ts -e tsx "ipc" --path "*/constants/*" --type f 2>/dev/null | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 274

---

🏁 Script executed:

#!/bin/bash

# Look for ipc files more broadly
echo "=== Searching for ipc-related files ==="
find . -name "*ipc*" -type f 2>/dev/null | grep -E "\.(ts|tsx|js)$" | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 467

---

🏁 Script executed:

#!/bin/bash

# Search for IPC_CHANNELS definition
echo "=== Searching for IPC_CHANNELS object ==="
rg "const IPC_CHANNELS|export.*IPC_CHANNELS" -A 5 --type ts --type tsx 2>/dev/null | head -30

Repository: AndyMik90/Auto-Claude

Length of output: 106

---

🏁 Script executed:

#!/bin/bash

# Look for GitHub, GitLab, and ADO channel definitions
echo "=== Searching for GitHub/GitLab/ADO channel patterns ==="
rg "GITHUB_|GITLAB_|ADO_" --type ts -c | sort -t: -k2 -nr | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 1332

---

🏁 Script executed:

#!/bin/bash

# Search for ADO implementation files
echo "=== Searching for ADO-related implementation files ==="
fd -e ts -e tsx . --type f -x grep -l "ado\|azure\|ADO_" {} \; 2>/dev/null | head -20

Repository: AndyMik90/Auto-Claude

Length of output: 1316

---

🏁 Script executed:

#!/bin/bash

# Read the ipc.ts file to verify the ADO, GitHub, and GitLab sections
echo "=== Reading IPC channels file ==="
cat -n apps/frontend/src/shared/constants/ipc.ts | head -100

Repository: AndyMik90/Auto-Claude

Length of output: 5253

---

🏁 Script executed:

#!/bin/bash

# Get GitHub section (around lines 205-398 as mentioned in review)
echo "=== GitHub section of IPC channels ==="
sed -n '200,400p' apps/frontend/src/shared/constants/ipc.ts | cat -n

Repository: AndyMik90/Auto-Claude

Length of output: 10617

---

🏁 Script executed:

#!/bin/bash

# Get ADO section (lines 514-556 as mentioned in review)
echo "=== ADO section of IPC channels (lines 510-560) ==="
sed -n '510,560p' apps/frontend/src/shared/constants/ipc.ts | cat -n

Repository: AndyMik90/Auto-Claude

Length of output: 2523

---

🏁 Script executed:

#!/bin/bash

# Check for GitLab section
echo "=== GitLab section of IPC channels ==="
sed -n '230,330p' apps/frontend/src/shared/constants/ipc.ts | cat -n

Repository: AndyMik90/Auto-Claude

Length of output: 5331

---

🏁 Script executed:

#!/bin/bash

# Check for ADO handler implementations
echo "=== Checking for ADO IPC handler implementations ==="
find apps/frontend/src/main/ipc-handlers -name "*ado*" -type f 2>/dev/null

# Look inside ADO handlers to see what's implemented
echo -e "\n=== Listing ADO handler files ==="
ls -la apps/frontend/src/main/ipc-handlers/ado/ 2>/dev/null || echo "ADO handlers directory check"

Repository: AndyMik90/Auto-Claude

Length of output: 586

---

🏁 Script executed:

#!/bin/bash

# Check for TODO/FIXME comments related to ADO
echo "=== Searching for TODO/FIXME comments related to ADO ==="
rg -n "TODO|FIXME" --type ts --type tsx -B 2 -A 2 | rg -i "ado|azure|batch|triage|pr.*memory"

Repository: AndyMik90/Auto-Claude

Length of output: 166

---

🏁 Script executed:

#!/bin/bash

# Check what ADO channels are actually handled
echo "=== Checking which ADO channels are registered in handlers ==="
rg "IPC_CHANNELS\.ADO_" apps/frontend/src/main/ipc-handlers/ -n --type ts

Repository: AndyMik90/Auto-Claude

Length of output: 1399

---

🏁 Script executed:

#!/bin/bash

# Check the ADO handlers content for what's implemented
echo "=== ADO PR handlers content ==="
head -50 apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts 2>/dev/null || echo "File not found"

echo -e "\n=== ADO work item handlers content ==="
head -50 apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts 2>/dev/null || echo "File not found"

Repository: AndyMik90/Auto-Claude

Length of output: 3367

---

🏁 Script executed:

#!/bin/bash

# Check if there's an autofix handlers file for ADO
echo "=== Checking for ADO autofix handlers ==="
find apps/frontend/src/main/ipc-handlers/ado -name "*autofix*" -o -name "*triage*" 2>/dev/null

# If not, check what ADO handler files exist
echo -e "\n=== All ADO handler files ==="
find apps/frontend/src/main/ipc-handlers/ado -type f -name "*.ts" 2>/dev/null | xargs -I {} sh -c 'echo "=== {} ===" && head -20 {}'

Repository: AndyMik90/Auto-Claude

Length of output: 3121

---

🏁 Script executed:

#!/bin/bash

# Search for any comments about phased rollout or future ADO features
echo "=== Searching for comments about ADO scope or phased rollout ==="
rg -n "phased|rollout|phase|future|TODO|future.*ado|ado.*future" --type ts --type tsx -B 3 -A 3 | head -100

Repository: AndyMik90/Auto-Claude

Length of output: 174

---

🏁 Script executed:

#!/bin/bash

# Look at the full ADO PR handlers to see what's actually implemented
echo "=== Full ADO PR handlers ==="
cat apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts

Repository: AndyMik90/Auto-Claude

Length of output: 10200

---

🏁 Script executed:

#!/bin/bash

# Look at the full ADO work item handlers
echo "=== Full ADO work item handlers (first 100 lines) ==="
head -100 apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts

Repository: AndyMik90/Auto-Claude

Length of output: 3260

---

🏁 Script executed:

#!/bin/bash

# Check if there are any other handler registration files
echo "=== Check main ipc-setup.ts for handler registration ==="
cat apps/frontend/src/main/ipc-setup.ts | head -150

Repository: AndyMik90/Auto-Claude

Length of output: 2147

---

🏁 Script executed:

#!/bin/bash

# Check if any of the claimed "missing" ADO channels are referenced anywhere
echo "=== Search for ADO_AUTOFIX handlers ==="
rg "ADO_AUTOFIX|ADO_INVESTIGATE_WORK_ITEM|ADO_IMPORT_WORK_ITEMS" --type ts

echo -e "\n=== Search for ADO_TRIAGE or ADO_BATCH ==="
rg "ADO_TRIAGE|ADO_BATCH|ADO_ANALYZE_PREVIEW" --type ts

Repository: AndyMik90/Auto-Claude

Length of output: 1228

---

🏁 Script executed:

#!/bin/bash

# Check GitHub handlers structure to compare
echo "=== GitHub autofix handlers (first 50 lines) ==="
head -50 apps/frontend/src/main/ipc-handlers/github/autofix-handlers.ts

echo -e "\n=== Check for GitHub triage handlers ==="
head -30 apps/frontend/src/main/ipc-handlers/github/triage-handlers.ts

Repository: AndyMik90/Auto-Claude

Length of output: 2705

---

🏁 Script executed:

#!/bin/bash

# Search for any PR or README mentioning ADO phased rollout
echo "=== Searching in PR descriptions or metadata ==="
git log --all --oneline --grep="ADO\|Azure DevOps" 2>/dev/null | head -20

echo -e "\n=== Looking for ADO-related comments in code ==="
rg -i "ado.*phase|ado.*rollout|ado.*future|future.*ado" --type ts -B 2 -A 2

Repository: AndyMik90/Auto-Claude

Length of output: 5845

---

🏁 Script executed:

#!/bin/bash

# Check if ADO_INVESTIGATE_WORK_ITEM and ADO_IMPORT_WORK_ITEMS are implemented
echo "=== Search for handlers of INVESTIGATE_WORK_ITEM and IMPORT_WORK_ITEMS ==="
rg "registerInvestigateWorkItem|registerImportWorkItems|ADO_INVESTIGATE_WORK_ITEM|ADO_IMPORT_WORK_ITEMS" apps/frontend/src/main/ipc-handlers/ado/ -n

echo -e "\n=== Check if these are registered ==="
cat apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts | tail -50

Repository: AndyMik90/Auto-Claude

Length of output: 1739

---

🏁 Script executed:

#!/bin/bash

# Check how many handler registration functions exist in workitem handlers
echo "=== Handler registrations in workitem-handlers.ts ==="
rg "^export function register" apps/frontend/src/main/ipc-handlers/ado/workitem-handlers.ts

echo -e "\n=== Handler registrations in pr-handlers.ts ==="
rg "^export function register" apps/frontend/src/main/ipc-handlers/ado/pr-handlers.ts

Repository: AndyMik90/Auto-Claude

Length of output: 866

---

🏁 Script executed:

#!/bin/bash

# Count the declared ADO channels
echo "=== Count declared ADO channels ==="
rg "ADO_" apps/frontend/src/shared/constants/ipc.ts | wc -l

echo -e "\n=== Count implemented ADO handlers ==="
rg "IPC_CHANNELS\.ADO_" apps/frontend/src/main/ipc-handlers/ado/ | wc -l

echo -e "\n=== Compare GitHub declared vs implemented ==="
echo "GitHub declared:"
rg "GITHUB_" apps/frontend/src/shared/constants/ipc.ts | wc -l

echo "GitHub implemented:"
rg "IPC_CHANNELS\.GITHUB_" apps/frontend/src/main/ipc-handlers/github/ | wc -l

Repository: AndyMik90/Auto-Claude

Length of output: 238

---

🏁 Script executed:

#!/bin/bash

# Get the exact count and list of declared vs implemented ADO channels
echo "=== Declared ADO channels ==="
rg "ADO_" apps/frontend/src/shared/constants/ipc.ts | cut -d: -f2 | sed 's/.*\(ADO_[A-Z_]*\).*/\1/' | sort | uniq

echo -e "\n=== Implemented ADO channel handlers ==="
rg "IPC_CHANNELS\.ADO_" apps/frontend/src/main/ipc-handlers/ado/ | sed 's/.*\(ADO_[A-Z_]*\).*/\1/' | sort | uniq

Repository: AndyMik90/Auto-Claude

Length of output: 375

---

🏁 Script executed:

#!/bin/bash

# Check if autofix channels have any handlers or just TODOs
echo "=== Searching for any reference to autofix handlers ==="
find apps/frontend/src/main/ipc-handlers/ado -type f -exec grep -l "autofix" {} \;

echo -e "\n=== Checking if there's a separate autofix file ==="
ls -la apps/frontend/src/main/ipc-handlers/ado/

Repository: AndyMik90/Auto-Claude

Length of output: 607

---

🏁 Script executed:

#!/bin/bash

# Check if any renderer/frontend code tries to call unimplemented ADO channels
echo "=== Searching for frontend calls to unimplemented ADO channels ==="
rg "ADO_INVESTIGATE_WORK_ITEM|ADO_IMPORT_WORK_ITEMS|ADO_AUTOFIX|ADO_PR_REVIEW[^_]|ADO_INVESTIGATION|ADO_PR_REVIEW_PROGRESS" apps/frontend/src/renderer/ apps/frontend/src/preload/ -n | head -30

Repository: AndyMik90/Auto-Claude

Length of output: 652

---

🏁 Script executed:

#!/bin/bash

# Check the ado-api.ts preload module to see what it exposes
echo "=== Checking preload API module for ADO ==="
cat apps/frontend/src/preload/api/modules/ado-api.ts

Repository: AndyMik90/Auto-Claude

Length of output: 8630

---

🏁 Script executed:

#!/bin/bash

# Check which ADO channels are declared but NOT implemented
echo "=== Declared but NOT implemented ADO channels ==="
echo "Declared channels:"
rg "ADO_" apps/frontend/src/shared/constants/ipc.ts | sed 's/.*\(ADO_[A-Z_]*\).*/\1/' | sort > /tmp/declared.txt

echo "Implemented channels:"
rg "IPC_CHANNELS\.ADO_" apps/frontend/src/main/ipc-handlers/ado/ | sed 's/.*\(ADO_[A-Z_]*\).*/\1/' | sort > /tmp/implemented.txt

echo "Missing from implementation:"
comm -23 /tmp/declared.txt /tmp/implemented.txt

Repository: AndyMik90/Auto-Claude

Length of output: 638

---

🏁 Script executed:

#!/bin/bash

# Verify ADOWorkItems component to see if it uses any unimplemented channels
echo "=== ADOWorkItems component usage ==="
head -100 apps/frontend/src/renderer/components/ADOWorkItems.tsx

Repository: AndyMik90/Auto-Claude

Length of output: 3211

---

ADO IPC channels: 21 declared but unimplemented handlers will cause runtime failures.

Verified: 34 ADO channels declared in ipc.ts, but only 13 have handler implementations. The following 21 channels have no handlers and will fail if invoked:

Work Items (2 missing):

• ADO_INVESTIGATE_WORK_ITEM, ADO_IMPORT_WORK_ITEMS

Pull Requests (3 missing):

• ADO_PR_REVIEW, ADO_PR_REVIEW_CANCEL, ADO_PR_GET_REVIEW

Events (6 missing):

• ADO_INVESTIGATION_PROGRESS, ADO_INVESTIGATION_COMPLETE, ADO_INVESTIGATION_ERROR
• ADO_PR_REVIEW_PROGRESS, ADO_PR_REVIEW_COMPLETE, ADO_PR_REVIEW_ERROR

Auto-Fix (all 10 missing):

• ADO_AUTOFIX_START, ADO_AUTOFIX_STOP, ADO_AUTOFIX_GET_QUEUE, ADO_AUTOFIX_CHECK_TAGS, ADO_AUTOFIX_CHECK_NEW, ADO_AUTOFIX_GET_CONFIG, ADO_AUTOFIX_SAVE_CONFIG, ADO_AUTOFIX_PROGRESS, ADO_AUTOFIX_COMPLETE, ADO_AUTOFIX_ERROR

The preload API (ado-api.ts) exposes listener functions for these unimplemented channels, which will silently fail at runtime. Additionally, ADO lacks features present in GitHub and GitLab integrations (batch operations, triage, analysis preview), and uses CHECK_TAGS instead of CHECK_LABELS unlike other providers.

Implement handlers for all declared channels or remove the declarations to prevent runtime failures. If this is a phased rollout, document it with TODO comments and explicit scope notes.

[coderabbitai]

Actionable comments posted: 3

🤖 Fix all issues with AI agents

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx:
- Around line 148-150: An arbitrary setTimeout is being used to wait for
settings to be saved before refreshing; replace this fragile timing hack by
chaining off the actual promise that completes the save/check operation and call
handleRefresh() only after that promise resolves (for example, await the
saveSettings or the promise returned by checkConnection()), or refactor
checkConnection() to return the new connection status and use that result
instead of relying on isConnected (which updates asynchronously); alternatively,
call fetchWorkItems() unconditionally after the awaited operation completes to
ensure the UI refreshes reliably without relying on setTimeout.

In @apps/frontend/src/renderer/components/Sidebar.tsx:
- Around line 98-102: The ADO nav item for pull requests uses the ListTodo icon
which can be confusing; update the adoNavItems array so the item with id
'ado-pull-requests' uses the GitPullRequest icon instead of ListTodo (leave the
'ado-work-items' item using Cloud unchanged) to match GitHub PR visuals and
improve consistency.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 935c6f5 and 5b34cc6.

📒 Files selected for processing (7)

• apps/frontend/src/main/ipc-handlers/env-handlers.ts
• apps/frontend/src/renderer/App.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/renderer/components/Sidebar.tsx
• apps/frontend/src/shared/i18n/locales/en/navigation.json
• apps/frontend/src/shared/i18n/locales/fr/navigation.json
• apps/frontend/src/shared/types/project.ts

🧰 Additional context used

📓 Path-based instructions (4)

apps/frontend/src/shared/i18n/locales/**/*.json

📄 CodeRabbit inference engine (CLAUDE.md)

apps/frontend/src/shared/i18n/locales/**/*.json: Store translation strings in namespace-organized JSON files at apps/frontend/src/shared/i18n/locales/{lang}/*.json for each supported language
When implementing new frontend features, add translation keys to all language files (minimum: en/.json and fr/.json)

Files:

• apps/frontend/src/shared/i18n/locales/fr/navigation.json
• apps/frontend/src/shared/i18n/locales/en/navigation.json

apps/frontend/src/**/*.{ts,tsx,jsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Files:

• apps/frontend/src/shared/types/project.ts
• apps/frontend/src/renderer/components/Sidebar.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/main/ipc-handlers/env-handlers.ts
• apps/frontend/src/renderer/App.tsx

apps/frontend/src/**/*.{ts,tsx}

📄 CodeRabbit inference engine (CLAUDE.md)

Use useTranslation() hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Files:

• apps/frontend/src/shared/types/project.ts
• apps/frontend/src/renderer/components/Sidebar.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/main/ipc-handlers/env-handlers.ts
• apps/frontend/src/renderer/App.tsx

apps/frontend/**/*.{ts,tsx}

⚙️ CodeRabbit configuration file

apps/frontend/**/*.{ts,tsx}: Review React patterns and TypeScript type safety.
Check for proper state management and component composition.

Files:

• apps/frontend/src/shared/types/project.ts
• apps/frontend/src/renderer/components/Sidebar.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/main/ipc-handlers/env-handlers.ts
• apps/frontend/src/renderer/App.tsx

🧠 Learnings (5)

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/shared/i18n/locales/**/*.json : When implementing new frontend features, add translation keys to all language files (minimum: en/*.json and fr/*.json)

Applied to files:

• apps/frontend/src/shared/i18n/locales/fr/navigation.json
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/shared/i18n/locales/en/navigation.json

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/shared/i18n/locales/**/*.json : Store translation strings in namespace-organized JSON files at `apps/frontend/src/shared/i18n/locales/{lang}/*.json` for each supported language

Applied to files:

• apps/frontend/src/shared/i18n/locales/fr/navigation.json

📚 Learning: 2026-01-04T23:59:45.209Z

Learnt from: MikeeBuilds
Repo: AndyMik90/Auto-Claude PR: 661
File: apps/frontend/src/renderer/components/onboarding/OllamaModelSelector.tsx:176-189
Timestamp: 2026-01-04T23:59:45.209Z
Learning: In the AndyMik90/Auto-Claude repository, pre-existing i18n issues (hardcoded user-facing strings) can be deferred for future i18n cleanup passes. Do not fix such issues in PRs that do not introduce new i18n violations, especially in frontend TSX components (e.g., apps/frontend/**/*.tsx). If a PR adds new i18n violations, address them in that PR.

Applied to files:

• apps/frontend/src/renderer/components/Sidebar.tsx
• apps/frontend/src/renderer/components/ADOWorkItems.tsx
• apps/frontend/src/renderer/App.tsx

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/**/*.{ts,tsx,jsx} : Always use i18n translation keys for all user-facing text in the frontend instead of hardcoded strings

Applied to files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx

📚 Learning: 2025-12-30T16:38:36.314Z

Learnt from: CR
Repo: AndyMik90/Auto-Claude PR: 0
File: CLAUDE.md:0-0
Timestamp: 2025-12-30T16:38:36.314Z
Learning: Applies to apps/frontend/src/**/*.{ts,tsx} : Use `useTranslation()` hook with namespace prefixes (e.g., 'navigation:items.key') for accessing translation strings in React components

Applied to files:

• apps/frontend/src/renderer/components/ADOWorkItems.tsx

🧬 Code graph analysis (2)

apps/frontend/src/renderer/components/Sidebar.tsx (1)

apps/frontend/src/renderer/components/settings/utils/hookProxyFactory.ts (1)

• envConfig (23-23)

apps/frontend/src/renderer/App.tsx (1)

apps/frontend/src/renderer/components/ADOWorkItems.tsx (1)

• ADOWorkItems (41-379)

🪛 ast-grep (0.40.4)

apps/frontend/src/renderer/components/ADOWorkItems.tsx

[warning] 475-475: Usage of dangerouslySetInnerHTML detected. This bypasses React's built-in XSS protection. Always sanitize HTML content using libraries like DOMPurify before injecting it into the DOM to prevent XSS attacks.
Context: dangerouslySetInnerHTML
Note: [CWE-79] Improper Neutralization of Input During Web Page Generation [REFERENCES]
- https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
- https://cwe.mitre.org/data/definitions/79.html

(react-unsafe-html-injection)

🪛 Biome (2.1.2)

apps/frontend/src/renderer/components/ADOWorkItems.tsx

[error] 292-298: Provide an explicit type prop for the button element.

The default type of a button is submit, which causes the submission of a form when placed inside a form element. This is likely not the behaviour that you want inside a React application.
Allowed button types are: submit, button or reset

(lint/a11y/useButtonType)

---

[error] 476-476: Avoid passing content using the dangerouslySetInnerHTML prop.

Setting content using code can expose users to cross-site scripting (XSS) attacks

(lint/security/noDangerouslySetInnerHtml)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: CodeQL (python)
• GitHub Check: CodeQL (javascript-typescript)

🔇 Additional comments (14)

apps/frontend/src/shared/i18n/locales/fr/navigation.json (1)

18-19: LGTM! French translations added correctly.

The ADO navigation item translations follow the established pattern and are consistent with existing GitHub/GitLab entries.

apps/frontend/src/shared/i18n/locales/en/navigation.json (1)

18-19: LGTM! English translations added correctly.

The ADO navigation item translations are properly aligned with the French locale and follow the established pattern for GitHub/GitLab integrations.

apps/frontend/src/renderer/App.tsx (2)

43-43: LGTM! ADOWorkItems component imported correctly.

The import follows the established pattern for other integration components (GitHubIssues, GitLabIssues, etc.).

---

805-812: LGTM! ADO Work Items view integrated correctly.

The implementation follows the established pattern for GitHub and GitLab integrations, with proper conditional rendering and settings callback.

apps/frontend/src/shared/types/project.ts (1)

321-327: LGTM! ADO configuration fields properly typed.

The Azure DevOps integration fields follow the established pattern for GitHub and GitLab integrations, with appropriate types and optional fields for flexible configuration.

apps/frontend/src/renderer/components/Sidebar.tsx (2)

57-57: LGTM! SidebarView type extended correctly.

The type now includes both ADO views, maintaining type safety across the sidebar navigation system.

---

147-164: LGTM! ADO navigation integration implemented correctly.

The conditional rendering logic and memoization dependencies are properly configured to show/hide ADO navigation items based on the adoEnabled flag, following the same pattern as GitHub and GitLab integrations.

apps/frontend/src/main/ipc-handlers/env-handlers.ts (5)

23-32: LGTM!

The ADO_ENV_KEYS constant follows the established pattern used by GITLAB_ENV_KEYS. The key naming convention is consistent and the use of as const for type safety is appropriate.

---

146-164: LGTM!

The ADO integration block in generateEnvContent correctly mirrors the GitLab pattern. Each field is conditionally written to the env vars map only when defined, which preserves existing values appropriately.

---

292-301: LGTM!

The .env template section for Azure DevOps follows the established pattern used by other integrations. The default value for ADO_INSTANCE_URL (https://dev.azure.com) is the correct public Azure DevOps endpoint.

---

414-414: LGTM!

Default adoEnabled: false is consistent with the approach for other optional integrations.

---

489-507: LGTM!

The ADO config parsing logic correctly mirrors the GitLab pattern:

• PAT presence triggers auto-enable unless explicitly disabled
• All fields are conditionally populated when present in the .env file
• Instance URL fallback is handled at the generation level

apps/frontend/src/renderer/components/ADOWorkItems.tsx (2)

41-154: Component logic and state management are well-structured.

The separation of concerns with checkConnection, fetchWorkItems, and handleSetupComplete callbacks is clean. The useMemo for filtering and the useEffect hooks for data loading follow React best practices.

---

381-483: WorkItemDetail component is well-organized.

The detail view properly displays work item metadata, handles optional fields conditionally, and provides an external link to ADO. The layout with metadata grid and tags section is clean.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Replace hardcoded string with i18n translation key.

The placeholder message violates the i18n coding guideline that requires all user-facing text to use translation keys.

📝 Proposed fix

Add a translation key to both locale files:

apps/frontend/src/shared/i18n/locales/en/common.json (or appropriate namespace):

+  "adoPullRequestsComingSoon": "ADO Pull Requests view coming soon"

apps/frontend/src/shared/i18n/locales/fr/common.json:

+  "adoPullRequestsComingSoon": "Vue des PRs Azure DevOps à venir"

Then update the component:

                 {activeView === 'ado-pull-requests' && (activeProjectId || selectedProjectId) && (
                   <div className="flex-1 flex items-center justify-center text-muted-foreground">
-                    ADO Pull Requests view coming soon
+                    {t('common:adoPullRequestsComingSoon')}
                   </div>
                 )}

As per coding guidelines, always use i18n translation keys for all user-facing text in the frontend.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	{activeView === 'ado-pull-requests' && (activeProjectId || selectedProjectId) && (
	<div className="flex-1 flex items-center justify-center text-muted-foreground">
	ADO Pull Requests view coming soon
	</div>
	)}
	{activeView === 'ado-pull-requests' && (activeProjectId || selectedProjectId) && (
	<div className="flex-1 flex items-center justify-center text-muted-foreground">
	{t('common:adoPullRequestsComingSoon')}
	</div>
	)}

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Avoid arbitrary setTimeout for coordination.

Using setTimeout(..., 100) to wait for settings to be saved before refreshing is fragile and may cause race conditions on slower systems. Consider using the promise resolution directly.

♻️ Proposed fix

       await window.electronAPI.updateProjectEnv(selectedProject.id, {
         adoEnabled: true,
         adoOrganization: settings.adoOrganization,
         adoProject: settings.adoProject,
         adoRepoName: settings.adoRepoName,
         adoPat: settings.adoPat,
         adoInstanceUrl: settings.adoInstanceUrl,
       });

       setShowSetupModal(false);
-      // Re-check connection after settings are saved
-      setTimeout(() => {
-        handleRefresh();
-      }, 100);
+      // Re-check connection after settings are saved
+      await checkConnection();
+      if (isConnected) {
+        await fetchWorkItems();
+      }
     } catch (error) {
       console.error('Failed to save ADO settings:', error);
     }

Note: Since isConnected won't reflect the new state immediately after checkConnection() due to React's async state updates, you may need to call fetchWorkItems() unconditionally or refactor to return the connection status from checkConnection().

Committable suggestion skipped: line range outside the PR's diff.

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/ADOWorkItems.tsx around lines 148 -
150, An arbitrary setTimeout is being used to wait for settings to be saved
before refreshing; replace this fragile timing hack by chaining off the actual
promise that completes the save/check operation and call handleRefresh() only
after that promise resolves (for example, await the saveSettings or the promise
returned by checkConnection()), or refactor checkConnection() to return the new
connection status and use that result instead of relying on isConnected (which
updates asynchronously); alternatively, call fetchWorkItems() unconditionally
after the awaited operation completes to ensure the UI refreshes reliably
without relying on setTimeout.

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

ADO navigation items configured correctly.

The implementation follows the established pattern for GitHub and GitLab integrations with appropriate keyboard shortcuts.

Optional: Consider using GitPullRequest icon for ADO PRs

The ListTodo icon for ADO pull requests might be confusing since pull requests aren't task lists. The GitPullRequest icon (already imported and used for GitHub PRs) could provide better visual consistency:

 const adoNavItems: NavItem[] = [
   { id: 'ado-work-items', labelKey: 'navigation:items.adoWorkItems', icon: Cloud, shortcut: 'O' },
-  { id: 'ado-pull-requests', labelKey: 'navigation:items.adoPRs', icon: ListTodo, shortcut: 'V' }
+  { id: 'ado-pull-requests', labelKey: 'navigation:items.adoPRs', icon: GitPullRequest, shortcut: 'V' }
 ];

This would align ADO PRs visually with GitHub PRs while keeping the Cloud icon distinctive for ADO work items.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Azure DevOps nav items shown when ADO is enabled
	const adoNavItems: NavItem[] = [
	{ id: 'ado-work-items', labelKey: 'navigation:items.adoWorkItems', icon: Cloud, shortcut: 'O' },
	{ id: 'ado-pull-requests', labelKey: 'navigation:items.adoPRs', icon: ListTodo, shortcut: 'V' }
	];
	// Azure DevOps nav items shown when ADO is enabled
	const adoNavItems: NavItem[] = [
	{ id: 'ado-work-items', labelKey: 'navigation:items.adoWorkItems', icon: Cloud, shortcut: 'O' },
	{ id: 'ado-pull-requests', labelKey: 'navigation:items.adoPRs', icon: GitPullRequest, shortcut: 'V' }
	];

🤖 Prompt for AI Agents

In @apps/frontend/src/renderer/components/Sidebar.tsx around lines 98 - 102, The
ADO nav item for pull requests uses the ListTodo icon which can be confusing;
update the adoNavItems array so the item with id 'ado-pull-requests' uses the
GitPullRequest icon instead of ListTodo (leave the 'ado-work-items' item using
Cloud unchanged) to match GitHub PR visuals and improve consistency.