feat: Add Visual Studio extension for AI edit detection

[sanjog-gururaj]

Summary

Adds a Visual Studio (VSIX) extension that detects Copilot-generated code edits and calls git ai checkpoint to record AI vs human authorship, matching the existing IntelliJ and VS Code extensions.

Extension (C#/.NET, agent-support/visualstudio/):

• Stack trace analysis on ITextBuffer.Changed to detect Copilot Chat edits (CopilotBufferUpdater.ApplyEditsAndSaveAsync)
• before_edit / after_edit checkpoint pairs for AI edits with 300ms debounce
• known_human checkpoint on document save with 500ms debounce
• Binary resolution with version check (≥1.0.23), git repo root detection
• Unit tests for pure logic (BinaryResolver, GitRepoResolver, CheckpointInput serialization, DocumentSaveListener)

Rust-side (src/mdm/agents/visual_studio.rs):

• VisualStudioInstaller implementing HookInstaller trait
• Windows-only VS installation discovery via vswhere.exe
• Extension presence detection by scanning VSIX manifests
• Process name detection (devenv)

CI (.github/workflows/test-visualstudio-extension.yml):

• Build + test on windows-latest, path-filtered to agent-support/visualstudio/**

Detection coverage

Scenario	Detected	Method
Copilot Chat edits (Apply)	Yes (High confidence)	Microsoft.VisualStudio.Conversations.UI.Internal.Copilot* namespace
Human typing	Correctly excluded	No Copilot frames in stack
Inline completions (Tab)	Not yet	No Copilot-specific frame available (generic VS SuggestionService infrastructure)

Known limitations

• Inline completion acceptance uses generic VS SuggestionService.AcceptSuggestionCommandHandler — not attributable to Copilot specifically. Will auto-detect if GitHub adds Copilot-specific frames in future updates.
• CheckpointService.Current singleton has a theoretical startup race (MEF loads TextBufferListener before GitAiPackage.InitializeAsync completes). Low practical impact.
• Automatic VSIX installation via VSIXInstaller.exe is stubbed — currently provides manual Marketplace install instructions.

Test plan

• Human typing → no AI detection, known_human on save
• Copilot Chat edit → agent-v1 before/after checkpoints, correct attribution in git ai log
• Full stack trace analysis to verify no false positives (CopilotPreemptingCommandFilter is command chain infrastructure, present in ALL edits)
• Unit tests pass (dotnet test)
• CI workflow builds on Windows

---

[CLAassistant]

All committers have signed the CLA.

[devin-ai-integration]

Devin Review found 2 new potential issues.

[devin-ai-integration]

🔴 vswhere called with multiple -property flags, but only the last one takes effect

The find_visual_studio_windows() function passes three -property flags (installationPath, installationVersion, instanceId) to vswhere.exe. However, vswhere's -property option is a single-value parameter — each subsequent -property overwrites the previous one. Only the last flag (instanceId) takes effect, so the JSON output contains only instanceId per entry.

The filter_map at lines 260-280 tries to extract all three properties (installationPath, installationVersion, instanceId), but entry.get("installationPath") returns None (because that property wasn't requested), causing every entry to be filtered out via the ? operator. This means find_visual_studio_windows() always returns an empty Vec, making the entire Visual Studio installer non-functional — it will never detect VS installations.

Correct usage of vswhere -property (from the CI workflow in this same PR)

The workflow file at .github/workflows/test-visualstudio-extension.yml:74 correctly uses a single -property flag:

$vsRoot = & $vswhere -latest -requires Microsoft.Component.MSBuild -property installationPath

The fix is to remove all -property flags so that vswhere returns all properties in its JSON output.

Suggested change

	.args([
	"-all",
	"-format",
	"json",
	"-property",
	"installationPath",
	"-property",
	"installationVersion",
	"-property",
	"instanceId",
	])
	"-all",
	"-format",
	"json",

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

🟡 DocumentSaveListener sends absolute paths in known_human checkpoint dirty_files keys, inconsistent with agent-v1 relative paths

In DocumentSaveListener.ExecuteCheckpoint, the dirtyFiles dictionary keys and editedPaths list use absolute file paths (e.g. C:\Users\dev\project\src\main.cs). In contrast, TextBufferListener.SendBeforeEditIfNeeded and ScheduleAfterEditCheckpoint use GitRepoResolver.ToRelativePath() to convert to repo-relative paths (e.g. src\main.cs) for the same fields in agent-v1 checkpoints.

While the Rust known_human.rs preset uses resolve_absolute() which handles absolute paths correctly (so this doesn't cause a runtime crash), the path format inconsistency means known_human checkpoint dirty_file keys won't match the POSIX-normalized relative paths used elsewhere in git-ai's working log system (AGENTS.md states: "Paths are POSIX-normalized"). This could cause dirty-file content matching to fail when reconciling known_human checkpoints against agent-v1 checkpoints for the same files.

Suggested change

	foreach (var absolutePath in paths)
	{
	try
	{
	if (!File.Exists(absolutePath)) continue;
	var content = File.ReadAllText(absolutePath);
	dirtyFiles[absolutePath] = content;
	editedPaths.Add(absolutePath);
	foreach (var absolutePath in paths)
	{
	try
	{
	if (!File.Exists(absolutePath)) continue;
	var content = File.ReadAllText(absolutePath);
	var relativePath = GitRepoResolver.ToRelativePath(absolutePath, workspaceRoot);
	dirtyFiles[relativePath] = content;
	editedPaths.Add(relativePath);
	}

---

Was this helpful? React with 👍 or 👎 to provide feedback.