devmonitor — VS Code extension

The capture client (spec §6.1 / ROADMAP Phase 1). It detects the active file's repo + branch, captures file saves, and streams them to the devmonitor backend under the developer's team. Identity comes from a device token issued at onboarding; the token is stored in the OS keychain (VS Code SecretStorage).

What it sends

• session.started on activation (best effort), once joined.

• file.saved on every save of a workspace file: eventType, repo, branch, filePath (relative to the repo root), and a file-level payload — language, lines, chars, and a sha256 content hash. Never the file contents, and never keystrokes (privacy-security.md). Build dirs, VCS internals, and secret files (.env, *.pem, id_rsa, …) are skipped.

• git.committed when a new commit is detected (the git reflog is scanned every ~8s): a timeline event and a POST /api/changes with the assembled bundle, via git show:

  • the commit message (the developer's intent — fed into the analysis),
  • the full diff,
  • post-commit contents of the changed files (ranked by size),
  • depth-1 imported files — the local files the changed files import, so the model sees the definitions a change depends on (relative imports only; JS/TS + best-effort Python),
  • README + manifests (package.json/pyproject.toml/go.mod/…) for grounding,
  • per-file +/− line counts.

  This triggers the AI explanation + AI-detection. Secret/binary files and noise (lockfiles, *.min.*, *.map) are skipped; the backend applies a token budget and redacts again before the model call. Large commits aren't truncated — the backend fans out to map-reduce so every file is still analyzed.

  On-demand content: while the content-channel WebSocket (/ws) is connected, the commit is sent thin (diff + per-file stats only, onDemand: true) and the backend pulls the file contents / imports / manifests on demand over the channel (serving only repo-relative, non-secret paths). Pushing the full bundle above is the fallback used when the channel is down.

• git.branch_changed on checkout/switch.

Why the reflog (not just "did HEAD's sha change"): it records why HEAD moved, so commits are told apart from branch switches, resets, pulls, and fast-forwards — no false "commits," no mis-attributing pulled-in work. A per-repo marker is persisted across sessions, so commits made while VS Code was closed are caught up on next launch (and a brand-new repo is baselined without replaying history).

Each event carries a client eventId (dedup), a per-session sessionId, and a monotonic seq (ordering), matching docs/event-schema.md.

Develop / run

cd extension
npm install
npm run compile          # or: npm run watch

Then in VS Code, open the extension/ folder and press F5 to launch an Extension Development Host with the extension loaded.

1. Set devmonitor.backendUrl in Settings if the backend isn't on http://localhost:3000.
2. Run devmonitor: Join a team (invite link) from the Command Palette and paste an invite link/token (generate one via the backend's POST /api/teams/:teamId/invites).
3. Edit and save a file inside a git repo — the manager's GET /api/teams/:teamId/changes / activity feed should show it.

The status-bar item shows capture state (join / capturing / paused); click it for Join / Pause / Resume / Sign out.

Commands

• devmonitor.join — Join a team (invite link)
• devmonitor.pause / devmonitor.resume — toggle capture
• devmonitor.signOut — clear the device token + identity

Not yet (planned)

• git.pushed and heartbeat/presence events (activity.heartbeat, time-to-write) — the rest of the docs/event-schema.md catalog.
• Caller resolution (who calls the changed code) — imports are done; callers (reverse lookup) are the next context tier.
• Full .gitignore honoring (today: exclusion list + secret/noise-file skip).
• Batching + durable retry buffer for transient send failures.