residoo 0.1.0 → 0.3.0

package/src/sources/qodo-gen.js

@@ -0,0 +1,189 @@
+"use strict";
+
+const fs = require("fs");
+const { createInterface } = require("readline/promises");
+const path = require("path");
+const os = require("os");
+
+/**
+ * Qodo Gen (formerly CodiumAI / Codium) — the VS Code and JetBrains AI chat
+ * extension published by Qodo.
+ *
+ * VERIFICATION STATUS (read this before trusting anything below):
+ * multi-source-corroborated-but-UNVERIFIED against a real install, and
+ * meaningfully WEAKER corroboration than this project's other sources — read
+ * this whole note before trusting it. Neither VS Code, JetBrains, nor any
+ * Qodo extension is installed on the machine this adapter was built on
+ * (checked: no /Applications/*Code*.app, no `code` on PATH, no ~/.qodo
+ * directory, no ~/Library/Application Support/JetBrains/<product>/options
+ * containing anything Qodo-named). Qodo Gen is closed-source (the public
+ * `Codium-ai/codiumai-vscode-release` / `codiumai-jetbrains-release` repos
+ * are release-notes/changelog mirrors only, no extension source), so unlike
+ * cody.js and amazon-q.js in this project, this adapter's path claim could
+ * NOT be checked against the vendor's own source code — only its docs:
+ *
+ *   1. Qodo's own current documentation,
+ *      docs.qodo.ai/qodo-documentation/qodo-gen/chat/chat-history (fetched
+ *      2026-09-02): "Qodo saves chat history locally in the user's home
+ *      directory at `.qodo/history`. The file naming uses a hash of the
+ *      workspace path to ensure uniqueness," plus: history not touched in
+ *      90+ days is auto-deleted; VS Code does NOT migrate history across
+ *      extension upgrades (a fresh install loses it) while JetBrains DOES.
+ *   2. Qodo's own changelog, docs.qodo.ai/changelog, entry for "Qodo 1.0.8"
+ *      (24 Apr 25): "The History file is now named `.qodo/history` and has
+ *      been moved to the user folder for better file organization. The file
+ *      is named using a hash of the workspace path to ensure uniqueness" —
+ *      independently dated/versioned wording that agrees with (1), and
+ *      implies this is a genuine change from an earlier, different layout
+ *      (see the IDAHO-VAULT finding below for what that earlier layout
+ *      likely looked like).
+ *
+ *   Both of the above are the SAME vendor (Qodo's own docs site stating the
+ *   same fact twice, once in reference docs and once in a changelog) — NOT
+ *   two independent parties, despite counting as two fetches. Searching
+ *   specifically for independent, third-party confirmation of the exact
+ *   `~/.qodo/history` BASE DIRECTORY turned up nothing conclusive: the one
+ *   real, concrete GitHub artifact found (`LAF-US/IDAHO-VAULT`,
+ *   `GIT-REMOVAL-COMMANDS.txt`, a real user's own repo, commits from mid/late
+ *   2026, well after the v1.0.8 changelog date) shows a file
+ *   `.qodo/history/<64-hex-hash>.json` committed INSIDE that repo's own
+ *   project directory, not under that user's home directory — but on
+ *   inspection this is very likely Qodo's separate automated code-review
+ *   product (`qodo-ai/command`, the "Qodo Gen CLI" / PR-Agent lineage, whose
+ *   own README describes exactly this "review your repo from the terminal,
+ *   for CI/CD" use case) writing a per-repo review-report artifact, given the
+ *   surrounding context ("Qodo review (...) flagged a medium-severity bug")
+ *   reads as a CI/PR-review finding, not a chat transcript. That is a
+ *   DIFFERENT Qodo product from the IDE chat extension this adapter targets,
+ *   so it neither confirms nor contradicts the `~/.qodo/history` claim above
+ *   for Qodo Gen specifically — it only corroborates that Qodo's tooling in
+ *   general uses this exact `.qodo/history/<hash>.json` naming shape
+ *   somewhere, which is real, but not the specific base-directory claim this
+ *   adapter depends on.
+ *
+ * Built anyway, per CONTRIBUTING.md's allowance for a source with credible
+ * corroboration but no real install — but flagged here, honestly, as this
+ * project's single WEAKEST-verified source: one primary party (the vendor,
+ * stated twice) rather than genuinely independent agreement, and a live
+ * install is unusually likely to be needed to firm this up (there is no
+ * source code to fall back on the way cody.js/amazon-q.js could). If you
+ * have Qodo Gen installed, confirming `~/.qodo/history/*.json` actually
+ * exists and holds real chat content — or reporting exactly where it
+ * actually lives if not — is the single most useful thing you can do for
+ * this source (see CONTRIBUTING.md).
+ *
+ * No per-OS path branching in either Qodo source read above — the docs
+ * describe a plain home-directory dotfolder (`~/.qodo` /
+ * `%USERPROFILE%\.qodo` on Windows), consistent with it being deliberately
+ * IDE-agnostic: the same docs note JetBrains preserves this history across
+ * upgrades where VS Code's own extension-local storage would not, which only
+ * makes sense if both IDEs read/write ONE shared, non-IDE-specific location
+ * — the same reasoning amazon-q.js documents for `~/.aws/amazonq/history`
+ * and continue.js already documents for `~/.continue` in this project.
+ */
+function historyDir() {
+  return path.join(os.homedir(), ".qodo", "history");
+}
+
+const HISTORY_DIR = historyDir();
+
+// Bounds for readLines() — same rationale and values as claude-code.js.
+// Not backed by a real Qodo Gen history file this tool was tested against
+// (no install to test with) — see the verification-status note above.
+const MAX_BYTES = 2 * 1024 * 1024 * 1024; // 2GB
+const READ_TIMEOUT_MS = 60_000;
+
+function id() { return "qodo-gen"; }
+function label() { return "Qodo Gen"; }
+
+function available() {
+  try { return fs.statSync(HISTORY_DIR).isDirectory(); } catch { return false; }
+}
+
+/**
+ * Same defensive symlink-following pattern as claude-code.js's
+ * isKindFollowingSymlink — see that file's docstring for the full reasoning.
+ * Duplicated rather than imported, matching this project's "small,
+ * self-contained file" convention.
+ */
+function isKindFollowingSymlink(fullPath, dirent, checkFn) {
+  if (checkFn(dirent)) return true;
+  if (!dirent.isSymbolicLink()) return false;
+  try { return checkFn(fs.statSync(fullPath)); } catch { return false; }
+}
+const isFileFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isFile());
+
+/**
+ * Yield { file, mtimeMs, sizeBytes, broken } for every `*.json` file
+ * directly inside `~/.qodo/history/` (flat, not recursive — every source
+ * describing this layout, vendor docs and the IDAHO-VAULT artifact alike,
+ * shows hash-named files as immediate children, no further nesting).
+ *
+ * Not filtered to a specific filename shape (e.g. requiring a hex-looking
+ * name): the exact hash algorithm/length isn't confirmed (docs say "a hash
+ * of the workspace path" without naming one), so — same caution cursor.js
+ * documents for not hard-coding a key-name allowlist likely to drift — any
+ * `*.json` found directly in this Qodo-owned directory is scanned rather
+ * than pattern-matched by filename.
+ */
+function* files() {
+  let entries;
+  try { entries = fs.readdirSync(HISTORY_DIR, { withFileTypes: true }); }
+  catch { return; } // no history directory at all — Qodo Gen never ran, or never opened chat
+
+  for (const e of entries) {
+    if (!e.name.endsWith(".json")) continue;
+    const file = path.join(HISTORY_DIR, e.name);
+    if (!isFileFollowingSymlink(file, e)) {
+      if (e.isSymbolicLink()) yield { file, broken: true };
+      continue;
+    }
+    let stat;
+    try { stat = fs.statSync(file); } catch { yield { file, broken: true }; continue; }
+    yield { file, mtimeMs: stat.mtimeMs, sizeBytes: stat.size, broken: false };
+  }
+}
+
+/**
+ * Read one `.qodo/history/*.json` file as an array of raw text lines.
+ *
+ * Streamed line-by-line via readline/promises, same as claude-code.js and
+ * amazon-q.js — whether a given file turns out to be one flat JSON document
+ * or something line-delimited, per-line scanning handles both: a flat
+ * document just becomes one long "line," bounded by MAX_BYTES. Status
+ * vocabulary matches every other source in this project.
+ */
+async function readLines(file) {
+  let stat;
+  try { stat = fs.statSync(file); }
+  catch { return { lines: [], status: "failed", bytesRead: 0 }; }
+  if (stat.size > MAX_BYTES) return { lines: [], status: "too-large", bytesRead: 0 };
+
+  const lines = [];
+  let bytesRead = 0;
+  const stream = fs.createReadStream(file, { encoding: "utf-8" });
+  const rl = createInterface({ input: stream, crlfDelay: Infinity });
+
+  // Same rationale as claude-code.js: no natural timeout exists anywhere in
+  // Node's stream/readline stack, and a retargeted symlink can make the
+  // underlying open() block forever with no event ever firing.
+  const timer = setTimeout(() => stream.destroy(new Error("read timed out")), READ_TIMEOUT_MS);
+
+  try {
+    for await (const line of rl) {
+      lines.push(line);
+      bytesRead += Buffer.byteLength(line, "utf-8") + 1; // +1 for the stripped newline
+    }
+    return { lines, status: "complete", bytesRead };
+  } catch {
+    // Whatever WAS read before the failure is real content and may contain
+    // a real secret — kept, not discarded, same as every other source here.
+    return { lines, status: lines.length > 0 ? "partial" : "failed", bytesRead };
+  } finally {
+    clearTimeout(timer);
+    rl.close();
+    stream.destroy();
+  }
+}
+
+module.exports = { id, label, available, files, readLines };

package/src/sources/qwen-code.js

@@ -0,0 +1,244 @@
+"use strict";
+
+const fs = require("fs");
+const { createInterface } = require("readline/promises");
+const path = require("path");
+const os = require("os");
+
+/**
+ * Qwen Code (QwenLM/qwen-code) session/chat transcripts.
+ *
+ * VERIFICATION STATUS (read this before trusting anything below): this
+ * source is corroborated by the actual current source code of the official
+ * QwenLM/qwen-code repository on GitHub (fetched and read directly) plus
+ * that project's own published docs and GitHub issues from real users
+ * describing real installs. It has NOT been checked against a real Qwen
+ * Code install or real transcript content — Qwen Code is not installed on
+ * the machine this adapter was built on (checked: no `qwen` on PATH, no
+ * `~/.qwen` directory, no `@qwen-code/qwen-code` in global npm packages).
+ * If you have Qwen Code installed, the most useful thing you can do is run
+ * `residoo scan` and confirm `sourcesScanned`/`filesScanned` look right for
+ * what you know is actually on disk under `~/.qwen`, then report back
+ * either way.
+ *
+ * Qwen Code began as a fork of google-gemini/gemini-cli (same author's
+ * `ChatRecordingService` naming, same general architecture) retargeted at
+ * Alibaba's Qwen models, but its storage layout has since diverged from
+ * gemini-cli's rather than staying a copy with the dotfolder renamed — this
+ * source was built by reading QwenLM/qwen-code's OWN code, not by assuming
+ * it still matches gemini-cli.js's layout.
+ *
+ * Storage location, confirmed directly from source
+ * (packages/core/src/config/storage.ts and
+ * packages/core/src/services/chatRecordingService.ts on QwenLM/qwen-code's
+ * `main` branch):
+ *
+ *   - Base directory: `$QWEN_HOME/.qwen` if that env var is set (confirmed
+ *     directly in `getGlobalQwenDir()`'s source: `process.env['QWEN_HOME']`,
+ *     resolved and used as-is), otherwise `~/.qwen` (`QWEN_DIR = '.qwen'`
+ *     joined onto `os.homedir()`, with a documented fallback to
+ *     `os.tmpdir()/.qwen` if `os.homedir()` itself comes back empty — no
+ *     other per-OS branching, same as gemini-cli).
+ *   - Current (as of this research) chat storage:
+ *     `~/.qwen/projects/<sanitizedCwd>/chats/<sessionId>.jsonl` —
+ *     `PROJECT_DIR_NAME = 'projects'`, `getProjectDir()` joins it with
+ *     `sanitizeCwd(projectRoot)`, and `ChatRecordingService` writes
+ *     `path.join(storage.getProjectDir(), 'chats', sessionId + '.jsonl')`,
+ *     one JSON record appended per line (metadata line first, then one
+ *     record per turn) — confirmed directly in chatRecordingService.ts.
+ *     Inactive sessions get moved into a `chats/archive/` subdirectory
+ *     (per Qwen Code's own daemon/session-lifecycle docs) rather than
+ *     deleted, so archived transcripts are still real, still-scannable
+ *     content sitting one level deeper.
+ *   - A SEPARATE, older-style temp dir also still exists in the current
+ *     source: `~/.qwen/tmp/<hash>/` (`TMP_DIR_NAME = 'tmp'`,
+ *     `getProjectTempDir()` using a SHA-256 `getProjectHash()`, the same
+ *     shape gemini-cli.js's tmp dir uses) — but on the current codebase
+ *     this is used for `checkpoints/`, not `chats/`. Because this project
+ *     is a fork whose own history plausibly went through the same
+ *     "everything under tmp/" phase gemini-cli.js's docstring describes
+ *     before settling on `projects/`, this source defensively ALSO walks
+ *     `tmp/<id>/chats/` if present — cheap when absent (a single failed
+ *     readdir), and catches transcripts left behind by an older Qwen Code
+ *     version without having to know exactly which version drew the line.
+ *
+ * Deliberately OUT OF SCOPE: an experimental PROJECT-LOCAL history mode
+ * referenced in qwen-code's own issue tracker — `getHistoryDir()` falling
+ * back to `<projectRoot>/.qwen/chat-history/` instead of a home-directory
+ * location when enabled. Every other source in residoo (including this
+ * one's primary path) scans one well-known location under the user's home
+ * directory; walking every project directory anywhere on disk looking for
+ * a stray `.qwen/chat-history` folder is a fundamentally different, far
+ * broader operation this source does not attempt. Also out of scope, for
+ * the same reasoning as gemini-cli.js: `<projectTempDir>/checkpoints/`.
+ *
+ * Sources consulted: QwenLM/qwen-code source on GitHub (storage.ts,
+ * chatRecordingService.ts, fetched from the `main` branch); Qwen Code's own
+ * published docs at qwenlm.github.io/qwen-code-docs (session-lifecycle and
+ * daemon-mode pages, confirming the `chats/` + `chats/archive/` structure
+ * and JSONL format at a description level); GitHub issues #2373, #1100 and
+ * #3606 on QwenLM/qwen-code (real users describing session resume/export
+ * behavior against their own installs).
+ */
+function qwenHomeDir() {
+  const base = process.env.QWEN_HOME || os.homedir() || os.tmpdir();
+  return path.join(base, ".qwen");
+}
+
+const ROOT = qwenHomeDir();
+const PROJECTS_DIR = path.join(ROOT, "projects");
+const TMP_DIR = path.join(ROOT, "tmp"); // legacy/defensive, see module docstring
+const CHAT_FILE_EXT = /\.(jsonl|json)$/i;
+
+// See gemini-cli.js's identical constant for the reasoning — bounded rather
+// than hard-coded at exactly the one nesting level (chats/archive/)
+// confirmed from source, so a further nesting change gets scanned rather
+// than silently missed, and bounded at all so a symlink cycle can't turn
+// this into an infinite walk.
+const MAX_CHATS_DEPTH = 4;
+
+// Same caveat as gemini-cli.js's identical constant: a generous, untested
+// backstop, not evidence from a real large Qwen Code transcript — no
+// install was available to produce one.
+const MAX_BYTES = 2 * 1024 * 1024 * 1024; // 2GB
+const READ_TIMEOUT_MS = 60_000;
+
+function id() { return "qwen-code"; }
+function label() { return "Qwen Code"; }
+
+function available() {
+  try { return fs.statSync(ROOT).isDirectory(); } catch { return false; }
+}
+
+/**
+ * Same defensive symlink-following pattern as claude-code.js — see that
+ * file's docstring for the full reasoning. Duplicated rather than imported:
+ * each source here is meant to be a small, self-contained file a reviewer
+ * can audit on its own (see CONTRIBUTING.md).
+ */
+function isKindFollowingSymlink(fullPath, dirent, checkFn) {
+  if (checkFn(dirent)) return true;
+  if (!dirent.isSymbolicLink()) return false;
+  try { return checkFn(fs.statSync(fullPath)); } catch { return false; }
+}
+const isDirFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isDirectory());
+const isFileFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isFile());
+
+/**
+ * Walk a `chats/` directory (or one of its subdirectories, e.g. `archive/`)
+ * for candidate session files, up to MAX_CHATS_DEPTH levels deep. A missing
+ * directory yields nothing and is NOT reported broken — a project that has
+ * never recorded a chat, or a Qwen Code version that never wrote `tmp/`
+ * chats at all, is normal absence, same convention cursor.js's
+ * statIfPresent() uses. A directory that exists but can't be read, or a
+ * symlink that can't be resolved, IS reported broken.
+ */
+function* walkChatFiles(dir, depth) {
+  let entries;
+  try { entries = fs.readdirSync(dir, { withFileTypes: true }); }
+  catch { return; }
+
+  for (const e of entries) {
+    const full = path.join(dir, e.name);
+
+    if (isDirFollowingSymlink(full, e)) {
+      if (depth < MAX_CHATS_DEPTH) yield* walkChatFiles(full, depth + 1);
+      continue;
+    }
+    if (isFileFollowingSymlink(full, e)) {
+      if (!CHAT_FILE_EXT.test(e.name)) continue;
+      let stat;
+      try { stat = fs.statSync(full); } catch { yield { file: full, broken: true }; continue; }
+      yield { file: full, mtimeMs: stat.mtimeMs, sizeBytes: stat.size, broken: false };
+      continue;
+    }
+    // Neither resolves as a directory nor a file: a dangling symlink is the
+    // one case worth reporting.
+    if (e.isSymbolicLink()) yield { file: full, broken: true };
+  }
+}
+
+/**
+ * Enumerate every immediate child of `parentDir` as a candidate project
+ * directory and walk its `chats/` subdirectory. Shared between the current
+ * `projects/<sanitizedCwd>/` layout and the legacy/defensive `tmp/<hash>/`
+ * one — both are "one directory per project, chats live in a `chats/`
+ * subdirectory of it," differing only in how the per-project name was
+ * derived, which this source does not try to recompute (see module
+ * docstring on `sanitizeCwd`/`getProjectHash`).
+ */
+function* walkProjectDirs(parentDir) {
+  let projectDirs;
+  try { projectDirs = fs.readdirSync(parentDir, { withFileTypes: true }); }
+  catch { return; }
+
+  for (const projEnt of projectDirs) {
+    const projDir = path.join(parentDir, projEnt.name);
+    if (!isDirFollowingSymlink(projDir, projEnt)) {
+      if (projEnt.isSymbolicLink()) yield { file: projDir, broken: true };
+      continue;
+    }
+    yield* walkChatFiles(path.join(projDir, "chats"), 0);
+  }
+}
+
+/**
+ * Yield { file, mtimeMs, sizeBytes, broken } for every Qwen Code chat
+ * transcript found under `~/.qwen/projects/<id>/chats/` (current layout)
+ * and, defensively, `~/.qwen/tmp/<id>/chats/` (legacy layout — see module
+ * docstring). A project directory present in both would be enumerated
+ * independently under each root; in practice a given project's chats live
+ * under one or the other depending on which Qwen Code version wrote them,
+ * so this is not expected to double-count real files, only to widen which
+ * Qwen Code versions' transcripts get found.
+ */
+function* files() {
+  yield* walkProjectDirs(PROJECTS_DIR);
+  yield* walkProjectDirs(TMP_DIR);
+}
+
+/**
+ * Read one transcript as an array of raw text lines. Identical approach to
+ * claude-code.js's readLines() — see that file's docstring for the full
+ * reasoning (streamed via readline/promises, a generous size cap, a hard
+ * read timeout since Node's stream/readline stack has none built in); not
+ * re-derived here since nothing about it is Qwen-Code-specific.
+ *
+ * Works the same whether `file` is JSONL (the current, and documented,
+ * format) or a legacy whole-session `.json` document — per the adapter
+ * contract, lines don't need to be valid JSON individually, they just need
+ * pattern-matching against.
+ */
+async function readLines(file) {
+  let stat;
+  try { stat = fs.statSync(file); }
+  catch { return { lines: [], status: "failed", bytesRead: 0 }; }
+  if (stat.size > MAX_BYTES) return { lines: [], status: "too-large", bytesRead: 0 };
+
+  const lines = [];
+  let bytesRead = 0;
+  const stream = fs.createReadStream(file, { encoding: "utf-8" });
+  const rl = createInterface({ input: stream, crlfDelay: Infinity });
+
+  const timer = setTimeout(() => stream.destroy(new Error("read timed out")), READ_TIMEOUT_MS);
+
+  try {
+    for await (const line of rl) {
+      lines.push(line);
+      bytesRead += Buffer.byteLength(line, "utf-8") + 1; // +1 for the stripped newline
+    }
+    return { lines, status: "complete", bytesRead };
+  } catch {
+    // Whatever WAS read before the failure is real content and may contain
+    // a real secret — discarding it because the file didn't finish cleanly
+    // would be a silent false negative, which is worse than an honest
+    // "partial" label.
+    return { lines, status: lines.length > 0 ? "partial" : "failed", bytesRead };
+  } finally {
+    clearTimeout(timer);
+    rl.close();
+    stream.destroy();
+  }
+}
+
+module.exports = { id, label, available, files, readLines };

package/src/sources/roo-code.js

@@ -0,0 +1,239 @@
+"use strict";
+
+const fs = require("fs");
+const { createInterface } = require("readline/promises");
+const path = require("path");
+const os = require("os");
+
+/**
+ * Roo Code (VS Code extension, a community fork of Cline) session history.
+ *
+ * VERIFICATION STATUS: read directly out of Roo Code's own current source on
+ * GitHub (RooCodeInc/Roo-Code) during this source's research, not guessed
+ * from Cline's near-identical layout even though the two are in fact close:
+ *   - src/package.json — `"name": "roo-cline"`, `"publisher":
+ *     "RooVeterinaryInc"`. VS Code lowercases publisher.name when it names
+ *     the on-disk globalStorage folder, so the real folder is
+ *     `rooveterinaryinc.roo-cline`, not the mixed-case form the manifest
+ *     declares — corroborated independently by a real user's own reported
+ *     path in a GitHub issue about disk usage
+ *     (`~/.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/tasks`,
+ *     RooCodeInc/Roo-Code#4174), i.e. an actual observed path from an actual
+ *     install, not just the manifest's declared casing.
+ *   - src/shared/globalFileNames.ts — the per-task filenames below.
+ *   - src/core/task-persistence/TaskHistoryStore.ts — its own doc comment
+ *     states the exact layout verbatim: "Each task's HistoryItem is stored
+ *     as an individual JSON file in its existing task directory
+ *     (`globalStorage/tasks/<taskId>/history_item.json`). A single index
+ *     file (`globalStorage/tasks/_index.json`) is maintained as a cache for
+ *     fast list reads at startup."
+ * What this could NOT be checked against: a real Roo Code install on the
+ * machine this source was built on — VS Code itself isn't installed there.
+ * See CONTRIBUTING.md for what "verified" is supposed to mean and treat
+ * findings from this source accordingly until someone with Roo Code actually
+ * installed confirms it against real data.
+ *
+ * Roo Code writes one JSON file per concern into a per-task directory under
+ * its extension's VS Code globalStorage folder, plus one root-level index:
+ *
+ *   <VS Code User dir>/globalStorage/rooveterinaryinc.roo-cline/tasks/
+ *     _index.json                     - cache of every task's HistoryItem
+ *     <taskId>/
+ *       api_conversation_history.json - full message history sent to the model
+ *       ui_messages.json              - the rendered chat transcript
+ *       history_item.json             - this task's own HistoryItem record
+ *       task_metadata.json            - files touched, model/token usage
+ *
+ * Filenames inside a task directory are deliberately NOT allow-listed beyond
+ * "every *.json file directly inside tasks/<taskId>/": this fork has already
+ * added fields over time (history_item.json is a comparatively recent
+ * addition per its own source comment above) and hard-coding today's list is
+ * exactly the kind of thing likely to go stale the same way cursor.js's
+ * docstring describes for Cursor's own key names. `_index.json` is one level
+ * up, directly inside tasks/, so it is checked separately rather than by the
+ * per-task glob. A task's `checkpoints/` subdirectory (shadow-git snapshots
+ * used for file revert) is deliberately NOT walked — those are git object
+ * stores, not text transcripts.
+ *
+ * Base directory: VS Code has a portable/remote/Insiders/fork multiverse of
+ * possible per-profile "User" directories. This source checks the two by far
+ * most common ones on each OS — standard VS Code ("Code") and VS Code
+ * Insiders ("Code - Insiders") — and deliberately does NOT attempt every
+ * fork (VSCodium, etc.) or the separate ~/.vscode-server tree used by
+ * remote-SSH sessions (even though the corroborating GitHub issue above
+ * happens to be exactly that case) — a named, narrower scope rather than a
+ * guess at an exhaustive list.
+ *
+ * Also named rather than silently assumed: Roo Code supports a configurable
+ * custom storage base path (per open GitHub issues discussing it) that would
+ * move all of the above somewhere this source does not check. That is a
+ * real, acknowledged gap, not a silent one.
+ */
+const EXT_ID = "rooveterinaryinc.roo-cline";
+
+function vscodeUserDirs() {
+  const home = os.homedir();
+  const variants = ["Code", "Code - Insiders"];
+  if (process.platform === "darwin") {
+    return variants.map((v) => path.join(home, "Library", "Application Support", v, "User"));
+  }
+  if (process.platform === "win32") {
+    const appData = process.env.APPDATA || path.join(home, "AppData", "Roaming");
+    return variants.map((v) => path.join(appData, v, "User"));
+  }
+  // Linux and other XDG-following unix platforms.
+  const configHome = process.env.XDG_CONFIG_HOME || path.join(home, ".config");
+  return variants.map((v) => path.join(configHome, v, "User"));
+}
+
+function tasksDirs() {
+  return vscodeUserDirs().map((userDir) => path.join(userDir, "globalStorage", EXT_ID, "tasks"));
+}
+
+// Bounds for readLines() — same rationale and same values as claude-code.js.
+// Not backed by a real Roo Code transcript this tool was tested against (no
+// install to test with) — see the verification-status note above.
+const MAX_BYTES = 2 * 1024 * 1024 * 1024; // 2GB
+const READ_TIMEOUT_MS = 60_000;
+
+function id() { return "roo-code"; }
+function label() { return "Roo Code"; }
+
+function available() {
+  return tasksDirs().some((dir) => {
+    try { return fs.statSync(dir).isDirectory(); } catch { return false; }
+  });
+}
+
+/**
+ * Same defensive symlink-following pattern as claude-code.js's
+ * isDirFollowingSymlink/isFileFollowingSymlink — see that file's docstring
+ * for the full reasoning. Duplicated rather than imported: each source in
+ * this project is meant to be a small, self-contained file a reviewer can
+ * audit on its own (see CONTRIBUTING.md and cursor.js's own note on this).
+ */
+function isKindFollowingSymlink(fullPath, dirent, checkFn) {
+  if (checkFn(dirent)) return true;
+  if (!dirent.isSymbolicLink()) return false;
+  try { return checkFn(fs.statSync(fullPath)); } catch { return false; }
+}
+const isDirFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isDirectory());
+const isFileFollowingSymlink = (p, d) => isKindFollowingSymlink(p, d, (x) => x.isFile());
+
+/**
+ * Resolve one constructed file path (not a directory-listing Dirent) into
+ * zero or one files() entries — used for tasks/_index.json, which is a fixed
+ * filename rather than something discovered by listing a directory. Same
+ * convention as cursor.js's statIfPresent: a path that simply doesn't exist
+ * yields nothing (normal — e.g. an install old enough to predate this file),
+ * `broken: true` is reserved for a path that looked like it should resolve
+ * and didn't (a dangling symlink).
+ */
+function* statIfPresent(filePath) {
+  let lst;
+  try { lst = fs.lstatSync(filePath); }
+  catch { return; }
+
+  if (lst.isSymbolicLink()) {
+    try {
+      const st = fs.statSync(filePath);
+      if (!st.isFile()) { yield { file: filePath, broken: true }; return; }
+      yield { file: filePath, mtimeMs: st.mtimeMs, sizeBytes: st.size, broken: false };
+    } catch {
+      yield { file: filePath, broken: true };
+    }
+    return;
+  }
+
+  if (!lst.isFile()) return;
+  yield { file: filePath, mtimeMs: lst.mtimeMs, sizeBytes: lst.size, broken: false };
+}
+
+/**
+ * Yield { file, mtimeMs, sizeBytes, broken } for tasks/_index.json and every
+ * *.json file directly inside every task directory, across every candidate
+ * VS Code User dir.
+ *
+ * broken:true marks a tasks/ entry or a *.json entry that looked like it
+ * should resolve (chiefly a dangling symlink) but didn't — never silently
+ * skipped, same convention as claude-code.js and cursor.js.
+ */
+function* files() {
+  for (const tasksDir of tasksDirs()) {
+    yield* statIfPresent(path.join(tasksDir, "_index.json"));
+
+    let taskEntries;
+    try { taskEntries = fs.readdirSync(tasksDir, { withFileTypes: true }); }
+    catch { continue; } // this VS Code variant/profile simply has no Roo Code tasks dir — normal, not broken
+
+    for (const taskEntry of taskEntries) {
+      if (taskEntry.name === "_index.json") continue; // already handled above
+      const taskDir = path.join(tasksDir, taskEntry.name);
+      if (!isDirFollowingSymlink(taskDir, taskEntry)) {
+        if (taskEntry.isSymbolicLink()) yield { file: taskDir, broken: true };
+        continue; // a stray non-directory entry under tasks/ is out of scope, not broken
+      }
+
+      let fileEntries;
+      try { fileEntries = fs.readdirSync(taskDir, { withFileTypes: true }); }
+      catch { yield { file: taskDir, broken: true }; continue; }
+
+      for (const e of fileEntries) {
+        if (!e.name.endsWith(".json")) continue;
+        const file = path.join(taskDir, e.name);
+        if (!isFileFollowingSymlink(file, e)) {
+          if (e.isSymbolicLink()) yield { file, broken: true };
+          continue;
+        }
+        let stat;
+        try { stat = fs.statSync(file); } catch { yield { file, broken: true }; continue; }
+        yield { file, mtimeMs: stat.mtimeMs, sizeBytes: stat.size, broken: false };
+      }
+    }
+  }
+}
+
+/**
+ * Read one JSON file as an array of raw text lines.
+ *
+ * Roo Code writes these via a JSON-with-indentation writer (safeWriteJson,
+ * confirmed used by TaskHistoryStore.ts) — real multi-line, indented text,
+ * not a single giant line — so the same streamed readline/promises approach
+ * claude-code.js uses for JSONL applies here essentially unchanged, and gets
+ * the same benefits: no whole-file-as-one-string V8 string-length ceiling,
+ * and a partial read (the file started streaming but the read failed
+ * partway) still returns whatever lines WERE read rather than discarding
+ * real content.
+ *
+ * Status vocabulary matches every other source in this project: "complete",
+ * "partial", "too-large", "failed".
+ */
+async function readLines(file) {
+  let stat;
+  try { stat = fs.statSync(file); }
+  catch { return { lines: [], status: "failed", bytesRead: 0 }; }
+  if (stat.size > MAX_BYTES) return { lines: [], status: "too-large", bytesRead: 0 };
+
+  const lines = [];
+  let bytesRead = 0;
+  const stream = fs.createReadStream(file, { encoding: "utf-8" });
+  const rl = createInterface({ input: stream, crlfDelay: Infinity });
+
+  const timer = setTimeout(() => stream.destroy(new Error("read timed out")), READ_TIMEOUT_MS);
+
+  try {
+    for await (const line of rl) {
+      lines.push(line);
+      bytesRead += Buffer.byteLength(line, "utf-8") + 1; // +1 for the stripped newline
+    }
+    return { lines, status: "complete", bytesRead };
+  } catch {
+    return { lines, status: lines.length > 0 ? "partial" : "failed", bytesRead };
+  } finally {
+    clearTimeout(timer);
+    rl.close();
+    stream.destroy();
+  }
+}
+
+module.exports = { id, label, available, files, readLines };