Open source · MIT
· GitHub:
· npm:
@rebornace/dsh-tracescope(v0.3.2)
AI models are great at reasoning about code — but only when they're handed grounded inputs. In practice, most app-quality work never reaches a model: after a PR merges, the diff sits in Git, the design spec sits in Figma, the crash stack sits in a monitoring console, and someone has to gather and structure all of it by hand before an AI can say anything useful.
I built TraceScope to lower that barrier: a plugin for DeepSeek Harness (DSH) — DeepSeek's desktop agent environment with a sidebar-plugin system — that turns your Git diff, your design specs, and your crash feeds into structured, deterministic inputs, so the AI analysis you get back is grounded in your actual codebase. It runs in the DSH sidebar, and the same capabilities are exposed over MCP, so you can drive the whole workflow from Cursor, Claude Code, Codex — or any other MCP-capable agent.
Where this fits in your stack
Before the details, the honest positioning — TraceScope is not trying to replace the tools you already use; it sits next to them:
Visual regression (Percy, Chromatic) compares screenshots of your running app. TraceScope's design diff compares the design file itself against your code, statically — no build, no emulator, no browser session. It answers "does the implementation match the spec?" earlier than screenshot tools can.
Crash monitoring (Sentry, Crashlytics, Bugsnag) tells you that something crashed. TraceScope's crash analysis helps with the next step: matching the stack to your repo and drafting the fix direction. Today it wires into Firebase Crashlytics and Umeng U-APM; Sentry and others are on the roadmap (more below).
Impact analysis is the piece most teams still do by gut feel: "what does this change touch?" It computes the answer from the diff and the dependency graph instead.
The consistent design bet: everything that can be parsed is parsed deterministically, so the AI analysis you get is grounded in facts, not guesses. No model is needed to diff a design tree or resolve a stack frame; the model does what it's actually good at — reading your source and reasoning about what the change, the drift, or the crash means for your app.
The three pillars
| Capability | Input | Output |
|---|---|---|
| Impact analysis | Stable ↔ candidate commits (local Git, or a hosted code-platform API) | Direct changes + static ripple, as a reviewable regression checklist |
| Design diff | Figma / Lanhu design links + code repository | Static UI-difference list + side-by-side highlight, AI-assisted write-back, issue submission |
| Crash analysis | Firebase Crashlytics / Umeng U-APM, or a pasted stack trace + code directory | Stack parsing, repo file hits, report, AI conclusion written back to the session |
All three share one sidebar, one tracker configuration, and one MCP tool surface.
1. Impact analysis: "what's the blast radius of this change?"
Give it two commits — the stable baseline and the candidate you're about to release — and it computes:
Direct changes: the files that actually changed.
Static reverse-dependency ripple: who imports or references them, propagated to a configurable depth (default 2). This is a real impact-analysis pass over your dependency graph, not a file list with guesswork.
The ripple pass understands actual source languages: Kotlin/Java, Swift/Objective-C, Dart/Flutter, TypeScript/JavaScript, Vue, the CSS family, and HTML. Other languages still get a direct-changes list — just no ripple. The local-Git mode builds its index from commit objects, so it doesn't even need a readable working tree; there's a hosted-code-platform API fallback for setups where local Git isn't an option (that mode skips static ripple).
The output is a checkbox regression checklist with human-readable feature names (from a tracescope.modules.yml mapping, falling back to static titles, then heuristics), per-item notes, screenshots (up to 3 per item), Markdown/CSV export, and one-click issue submission to your tracker. It's the "what to re-verify before release" list, generated instead of remembered.
2. Design diff: "does the implementation match the spec?"
Design fidelity work today is screenshot-based: you run the app, capture it, and diff images. TraceScope takes a different route — it treats the design file as the source of truth and compares it to the code statically:
Page discovery covers Android (XML / Compose / View), iOS (Xib / SwiftUI / UIKit), Flutter, React Native, Harmony ArkUI, uni-app, Taro, Web (HTML / React / Vue / Svelte / Angular), mini-programs (WXML / AXML / TTML / Swan), and .NET MAUI XAML.
Layered comparison: L0 fingerprints the design page against code pages (or you pin the file manually / let AI re-match); L1 does attribute-level static tree comparison (
DesignDoc↔DesignDoc) — geometry, colors and tokens, typography (with unit conversion across dp / sp / rpx /cqw), multi-layer shadows and blur, transforms, visibility, resources; L2 falls back to heuristics (copy, control counts) when there's no precise geometry tree; L3 hands the source-reading list and prompts to the AI and writes its conclusions back to the sidebar.Depth is pluggable, not forked: a design-enrichment registry currently ships a full static layout engine for Android XML (viewport measurement, dependency-closure fingerprints, Adapter-bound list-item restoration, dynamic text projection). Other stacks get uniform attribute-level comparison; a sidebar toggle forces uniform granularity when you want speed over depth.
Design sources: Figma and Lanhu, both normalized into a single
DesignDoc— the comparison pipeline doesn't care which tool produced the file.
Because it never needs a running app, the check is cheap enough to run on every screen you touch — not just the ones someone remembered to eyeball.
3. Crash analysis: "what is this crash, and where do I start?" (new in 0.3.x)
The newest pillar picks up where crash monitoring leaves off. It pulls crash / ANR lists from a provider — or accepts a pasted stack trace when no credentials are set — and analyzes them against your code directory:
Sources: Firebase Crashlytics and Umeng U-APM. No credentials set? Paste a stack trace and the whole analysis flow still works.
Filtering stays aligned with the console: the filter area is collapsed by default, and version / OS / device options are sourced from the same metadata the console uses — so you can only select what the console would actually return.
Local analysis:
analyzeparses the stack, matches frames to files in the code directory by name, and produces a summary with hit files and fix hints — no model call, fully deterministic.AI write-back: "Analyze & write to session" creates an AI job and drops a prompt with a job ID into the current session; when the agent calls
tracescope_publish_crash_analysis, the sidebar polls and auto-displays the conclusion. Manual write-back and paste fallbacks exist.Issue submission: a dedicated crash body (optionally including the AI conclusion) goes to your tracker — GitHub Issues, GitLab Issues, a generic webhook, or Yunxiao (Alibaba Cloud DevOps).
Crash providers are registered through the same CrashProvider adapter contract as everything else — adding Sentry or another APM is a new adapter, not a fork of the main path (see the roadmap below).
MCP: the same engine, any agent
Everything above is exposed through @rebornace/tracescope-mcp. The execution layer is shared with the DSH host via @rebornace/dsh-tracescope/agent-api — host routes are thin wrappers, so behavior is identical whether you drive it from the sidebar or from a tool call.
There are 19 tools across the three pillars, grouped by workflow: impact (diff, impact analysis, manual-verification job creation and write-back), design review (snapshot, findings, page re-matching), and crash (probe, filter options, list, detail, local analyze, AI job creation, publish, job polling). Credentials can be passed as tool parameters or read from local config (~/.tracescope). The MCP surface is client-agnostic: the full list → analyze → write-back loop runs in Cursor, Claude Code, Codex — or any other MCP-capable agent — with or without the sidebar.
Architecture
@rebornace/tracescope-core ← deterministic analysis engine (impact + design + crash parse)
@rebornace/dsh-tracescope ← DSH plugin: Host API + sidebar UI + agent-api
@rebornace/tracescope-mcp ← MCP server (same tool surface as the Host)
packages/.../design-enrichment/ ← per-stack deep-enhancement plugins
Two design principles worth calling out:
Deterministic floor, AI ceiling. Everything that can be computed is computed — the AI never hallucinates a diff or a stack match, because it never needs to.
No vendor lock-in. Crash providers, trackers, and design sources are all registry-based adapters (
CrashProvider,TrackerAdapter, design-source normalization). Adding a new one doesn't fork the main path.
The plugin also self-updates without depending on a plugin marketplace: it checks npm latest through the Host and installs via the official plugin manager, with a visible update button and status card in the desktop UI.
Install & use
Node.js
>= 20; the official DeepSeek Harness desktop app is recommended.Install and open the TraceScope sidebar:
dsh plugin --profile desktop add @rebornace/dsh-tracescope
UI language (English / Chinese) follows the desktop app's setting.
Install from npm
latest; community marketplace cards may lag behind.
A typical crash workflow: pick the source → save credentials → fetch the list → open a detail → analyze (local, deterministic) → analyze & write to session → the agent writes back the conclusion → submit the issue.
Platform coverage today — and where it's going
Honest scope: the adapter coverage is still limited, and it will grow toward the platforms teams actually use. The current wiring, and what's coming:
| Extension surface | Currently wired | On the roadmap |
|---|---|---|
| Crash providers | Firebase Crashlytics, Umeng U-APM, pasted stacks | Sentry, Bugly, other APMs |
| Trackers | GitHub Issues, GitLab Issues, generic webhook, Yunxiao | Jira, Feishu / Lark, other ticketing systems |
| Design sources | Figma, Lanhu | MasterGo, other design collaboration tools |
| Code-stack adapters | Android XML (deep enhancement), iOS, Flutter, RN, Web, mini-programs, and more | more per-stack layout engines and list restoration |
If you need a specific platform — your APM, your ticketing system, your design tool — open a GitHub Issue with the platform name, the auth method, whether a public API exists, and your typical use case. Clearly-scoped requests get prioritized. That feedback drives the roadmap order. The full roadmap lives in the repo docs.
Closing
TraceScope is open source under MIT, built to lower the barrier to applying AI analysis to app quality: impact analysis answers "what changed and what to re-check", design diff answers "where does the implementation drift from the spec", and crash analysis answers "what is this crash and where do I start fixing it" — from one sidebar, one tracker config, one MCP surface.
Try it, open an Issue for the platform you need, or send a PR.
Links
GitHub: rebornace/dsh-tracescope
Full guide: docs/GUIDE.md
Changelog: CHANGELOG.md
Feedback: Issues
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.