CodeDiag

codediag

你的哪些 API 路由可以被任何人调用？
_{为 Next.js、SvelteKit、React Router、Express、 Fastify、Hono、Elysia、NestJS 和 tRPC 检查身份验证与校验覆盖情况，还会检查安全性、依赖项、测试和结构。一条命令，无需账户，可离线运行。}

安装

npx @sabahattink/codediag scan .

就这样。配置是可选的，无需账户或服务端，并且使用 --no-audit 可让扫描完全离线运行。

也可以全局安装——这还会将 codediag 命令添加到你的 PATH 中， 下面的所有示例都假设已完成此操作：

npm install -g @sabahattink/codediag

**包名说明：**在 npm 上发布的包名为 @sabahattink/codediag，目前正在转移旧版 codediag 名称的所有权。安装后，CLI 二进制文件仍为 codediag。如果／当不带作用域的名称再次可用时，我们会发布迁移公告。

检查内容

codediag 会自动检测你的技术栈并运行 5 个分析器。每项发现都有稳定的规则 ID（规则参考）、严重级别、可用时的位置信息，以及建议的修复方法。

API 健康状况 NestJS · Express · Fastify · Hono · Elysia · Next.js · SvelteKit · React Router · tRPC

使用 AST 分析（ts-morph，而非正则表达式）检查应用实际公开的路由。

• NestJS： 身份验证守卫，包括全局守卫（useGlobalGuards、 APP_GUARD）、基于 UseGuards 的自定义装饰器，以及 @Public() 风格的 免验证方式；用于请求正文的 DTO 类（而非 any、Record 或 接口），以及 ValidationPipe 是否会强制执行这些 DTO；Swagger 文档和 返回类型。
• Express： 从 express()、Router() 和带类型的参数解析路由器；路由上的 身份验证和验证中间件、较早调用的 router.use()，以及跨文件的 app.use(path, mw, router) 挂载；集中式错误处理和健康端点。
• Fastify： 来自 fastify.get() 和 fastify.route() 的路由，追踪经 register() 注册的插件、fastify-plugin 封装，以及 @fastify/autoload 目录（目录前缀、autoPrefix 和 autohooks，按 fastify-cli 项目的用法处理）； 路由或其上下文中的 onRequest/preHandler 身份验证钩子、变更数据路由上的 正文架构、setErrorHandler 和健康端点。
• Hono： new Hono() 应用上的路由、basePath()，以及跨文件通过 app.route() 挂载的子应用，并按注册顺序重放；路由上的身份验证中间件 （jwt()、bearerAuth()、basicAuth() 或自定义中间件），或较早调用且匹配的 app.use()；zValidator 和其他正文验证器；onError；以及健康端点。
• Elysia： new Elysia() 实例上的路由、prefix、group()，以及跨文件通过 use() 挂载的插件，包括函数式插件，并按注册顺序结合 Elysia 的钩子作用域 重放：只有插件的钩子为 scoped 或 global（{ as: 'scoped' }、 .as('scoped')）时，才会作用于使用它的实例。身份验证可通过 onBeforeHandle()、会以 401 拒绝请求的 derive() 或 resolve()、 guard()、better-auth 的 { auth: true } 等身份验证宏、onRequest()， 或处理器中的检查实现；当路由未使用一个已有的身份验证钩子时，问题说明会指出 该钩子是仅限于其插件，还是在路由之后才执行。路由选项或 guard() 中的正文架构 （TypeBox、Zod 或其他 Standard Schema）；onError；以及健康端点。
• Next.js： App Router 和 Pages Router API 处理器，不会因此惩罚仅包含前端的 项目。只有当中间件（Next.js 16 中的 proxy.ts）会将对该路径的匿名请求拦截时， 才能保护该路由：逐个评估其 matcher、pathname 检查、next-auth、Clerk 的 protect()、Auth.js authorized 回调及其返回的辅助函数（例如 Supabase 的 updateSession()）。
• SvelteKit： +server 端点和表单操作，使用来自 src/routes 的路由 ID； 在 handle 钩子中（通过 sequence() 和路径或路由 ID 守卫）或处理器及其调用的 辅助函数中实现身份验证；如果唯一的身份验证检查位于布局 load 中，则注明这一点， 因为它不会针对操作和端点运行；正文验证；以及在 svelte.config.js 中关闭的 CSRF 来源检查。
• React Router 和 Remix： 来自 app/routes.ts 或 Remix v2 扁平路由文件的 actions 和 loaders；在 action、其辅助函数或路由 middleware 中实现身份验证； 若唯一的身份验证检查位于父路由或当前路由自身的 loader 中，则单独列出相应规则， 因为两者都不会在 action 运行前执行；以及对表单和 JSON 正文进行架构验证。
• tRPC： 从 initTRPC 经由构建器链解析的过程、导出的构建器（例如 protectedProcedure），以及跨文件的嵌套或合并路由器（包括 ~/ 路径别名）； 未使用身份验证中间件的 mutation（根据中间件实际检查的内容判断，而非其名称）、 接受任何内容的 .input() 解析器，以及会暴露堆栈跟踪的错误格式化器或 isDev: true。每个过程前都有身份验证也计为有效：拒绝匿名调用者的 createContext、Express 或 Hono 挂载之前的身份验证中间件、Fastify 插件上的身份验证 钩子，或会拒绝对 tRPC 路由发起的匿名请求的 Next.js middleware.ts （Next.js 16 中的 proxy.ts，也包括 Auth.js）。这些检查会在承载 tRPC 的服务器 中运行（T3/Next.js、Express、Fastify、Hono、Elysia、SvelteKit），独立的 tRPC 服务则作为单独的技术栈处理。有意公开的 mutation（例如注册）只要附有理由充分的 codediag-ignore-next-line 指令，就会被接受。

安全性

检查硬编码凭据、.gitignore 中对 .env 的保护、Helmet、速率限制、开放的 CORS、弱密码哈希，以及直接比较密码的做法。会在 AST 中查找运行时危险操作（eval、new Function、Shell 命令、原始 SQL、禁用 TLS 验证），并追踪请求数据经过变量、解构、重新赋值，以及进入自有辅助函数和服务的最多两次调用。因此，const cmd = req.query.cmd; exec(cmd) 属于严重问题；如果 run 在另一个文件中调用 exec，那么 run(req.query.cmd) 也一样。还会追踪请求数据进入类所存储的字段（包括经过构造函数的情况）、进入 map/forEach 回调和 for...of 循环，以及传递给接口或注入令牌背后的 NestJS 提供程序。tRPC 过程的 input 也属于请求数据，即使经过 .input(schema) 验证也是如此。请求数据若进入文件路径、传出请求的主机、重定向或 HTML 响应，会分别报告为路径遍历、SSRF、开放重定向或反射型 XSS；若请求数据被编译为模板或用作对象路径，则会报告为模板注入或原型污染。接受 none 或忽略过期时间的 JWT 选项，以及缺少 httpOnly/secure 的会话 Cookie，也会被标记。还会在 Git 跟踪的 JSON、YAML、Dockerfile、.npmrc 和 .env 文件中查找密钥，报告中绝不会包含密钥值。启用 --secret-history（或在 .codediag.yml 中设置 secretHistory）后，还会搜索近期提交新增的凭据，即使这些凭据后来已被删除，仍会保留在每个克隆中（secret-in-git-history）；此功能默认关闭，因为结果取决于克隆深度。对于 Supabase 项目，会按顺序重放 supabase/migrations；API 可访问但未启用行级安全策略的表属于严重问题（supabase-table-without-rls），using 或 with check 为 true 的写入策略也一样（supabase-permissive-policy）。请参阅安全分析。

依赖项

运行相应的 npm、pnpm、Yarn Classic 或 Yarn Berry 审计（使用 --no-audit 可跳过；audit: production 仅检查实际发布的依赖项），在每条漏洞发现中列出受影响的软件包及其安全公告，检查锁文件与 packageManager 是否一致，标记已弃用的软件包，并验证引擎规范和必要脚本。最多向上查找三层父目录中的 monorepo 锁文件。成功的审计结果会以锁文件和 package.json 为键，在 node_modules/.cache/codediag 中保留一小时，以便后续扫描复用（依赖项摘要会说明复用情况）；删除该目录即可强制重新审计。pnpm 会从任意软件包审计整个工作区锁文件，因此共用同一锁文件的软件包只需运行一次审计，每个软件包仅报告其自身依赖项可达的安全公告。

测试

检查测试文件和测试框架（Jest、Vitest、Mocha、Ava、node:test）、测试与源代码的比例、集成测试目录以及覆盖率。如果存在 coverage-summary.json，则会依据行数/语句 80%、函数/分支 70% 的标准进行衡量；否则，CodeDiag 会检查 Jest、Vitest、node:test、c8 或 nyc 配置中是否设有实际覆盖率阈值。

结构

检查 README 内容、Lint 和格式配置（也包括从工作区根目录继承的配置）、解析后的 TypeScript 严格模式、NestJS 功能模块，以及 .env.example 等环境模板。

评分

每个分析器的评分为 0–100。加权平均分决定等级：

API Health: 25%  ·  Security: 30%  ·  Dependencies: 20%  ·  Testing: 15%  ·  Structure: 10%

A+	A	B+	B	C	D	F
95+	90+	85+	80+	70+	60+	<60

默认情况下，分析器评分使用评分版本 2：每个分析器从 100 分开始，每项发现按严重性权重扣分（严重 25 分、警告 8 分、提示 2 分）。同一规则后续发现的扣分为前一项的一半，因此单条规则最多扣除其权重的两倍。如果某项发现的根本原因也已报告（例如完全没有测试时出现“没有测试目录”），则会降级为 info，通过 causedBy 关联，且不扣分。若某项发现导致分析器没有可评估内容，例如缺少 package.json，则该分析器得分为 0。

每个失分项都会列在 JSON 输出的 scoreBreakdown 中、HTML 和 Markdown 报告中，以及使用 --verbose 时各分析器下方。设置 scoring: { version: 1 }，即可在再一个版本中保留此前的检查通过评分。

CLI

codediag scan .                    # Full report
codediag scan . --format json      # JSON (for CI/CD)
codediag scan . --format sarif     # SARIF 2.1.0 (for code scanning)
codediag scan . --format md        # Markdown (for PRs)
codediag scan . --format svg       # SVG score badge
codediag scan . --format html > codediag-report.html  # Interactive dashboard
codediag scan . --format fixes > codediag-fixes.md     # Review checklist
codediag scan . --format prompt > codediag-prompt.txt  # Review-only AI handoff
codediag scan . --ci               # JSON output + exit code
codediag scan . --threshold 80     # Exit 1 below 80 in any output mode
codediag scan . --fail-on critical # Exit 1 on any active critical finding
codediag scan . --quiet            # Score only
codediag scan . --verbose          # All issues and the score breakdown
codediag scan . --no-audit         # Offline: skip the package manager audit
codediag scan . --update-baseline .codediag-baseline.json  # Record accepted findings
codediag scan . --ci --baseline .codediag-baseline.json    # Fail only on new findings
codediag scan . --compare previous.json   # Score change, new and fixed findings
codediag scan . --changed-since origin/main  # Only files this branch changes
codediag scan . --workspaces              # Every monorepo package, combined
codediag scan . --history .codediag/history  # Record scans, show the trend
codediag scan . --secret-history         # Also secrets removed but still in Git history
codediag rules                     # List every rule
codediag explain open-cors         # Explain a rule and how to suppress it
codediag init                      # Create .codediag.yml
codediag mcp                       # Serve MCP on stdio for AI agents

生成仓库徽章：

codediag scan . --format svg > codediag.svg

趋势和变更文件

--compare 接受任意较早的 JSON 报告，并显示变更内容：总分和各分析器的分数变化、新增的发现（标记为 NEW 和 isNew: true），以及此后已修复的发现。该选项适用于所有输出格式；HTML 报告会添加变更面板和“新增”筛选器，SARIF 则会使用 baselineState 标记结果。

codediag scan . --format json > reports/main.json      # on main
codediag scan . --compare reports/main.json --verbose  # on your branch

--changed-since <revision> 会将扫描范围限制为与某个 Git 版本不同的文件：包括合并基点之后的提交、已暂存和未暂存的编辑，以及新建的未跟踪文件。只报告并评分这些文件中的发现，因此得分反映的是变更而非整个项目；报告还会说明有多少其他位置的发现被排除。

codediag scan . --changed-since origin/main --threshold 90

--history <directory> 会保留趋势记录：每次扫描都会保存到该目录（codediag-<timestamp>.json），报告会展示最近 50 次记录扫描的得分趋势，在终端和 Markdown 中以迷你趋势图呈现，在 HTML 报告中则以图表和表格视图呈现。提交该目录，或在 CI 中缓存它，即可保留历史记录。

codediag scan . --history .codediag/history

Monorepo

--workspaces 会扫描 npm、pnpm 或 Yarn 工作区、Lerna 仓库或 Nx 工作区中的每个软件包（Turborepo 使用你的包管理器的工作区）。每个软件包都会单独检测技术栈并评分；若软件包有自己的 .codediag.yml，则使用该配置，否则使用根目录配置，并将根目录的 ignore 路径重新映射到软件包目录。合并后的报告会列出每个软件包，并对实际运行过的各个分析器取平均分；总分则使用常规分析器权重。软件包审计会并行运行，每次处理 4 个，然后再分析软件包。发现的位置相对于根目录；项目级发现会指向软件包的 package.json，因此基线、--compare、--changed-since、SARIF 和 GitHub Action（workspaces: true）都能在整个仓库范围内正常工作。

codediag scan . --workspaces
codediag scan . --workspaces --format html > monorepo-report.html
codediag scan . --workspaces --package-threshold 70   # Gate every package too

合并平均分可能会掩盖某个较弱的软件包。packageThreshold（或 --package-threshold，或 Action 的 package-threshold 输入）也会分别检查每个软件包的分数：低于阈值的软件包会导致扫描失败，其名称会显示在 stderr 和作业摘要中，并在每份报告中标记。软件包自己的 .codediag.yml 可以设置不同的 packageThreshold。

扫描工作区根目录而不使用 --workspaces 时，会将其作为一个项目扫描，并建议使用该标志。

优先审核的修复建议

CodeDiag 可以将分析器的发现转化为按优先级排列的修复清单。 每个项目都保持未勾选状态，并明确要求审核；CodeDiag 绝不会 编辑项目文件或自动应用建议。

codediag scan . --format fixes > codediag-fixes.md

若要与编码 Agent 配合使用，--format prompt 会生成结构化交接内容， 将诊断信息视为不可信数据，并指示 Agent 在提出补丁前检查 所引用的文件。提示词仅包含诊断元数据，不包含源文件内容或机密信息， 并禁止在用户明确批准前进行编辑。

codediag scan . --format prompt > codediag-prompt.txt

有关输出约定和推荐工作流，请参阅优先审核的修复建议指南。

VS Code 扩展

VS Code 扩展运行相同的分析器引擎，将已定位的发现发布到“问题”面板， 并可直接在编辑器中打开 HTML 报告、修复计划或 AI 审核提示词。每个问题 上的快速修复可在该行或整个文件中抑制相应规则（由你填写原因），也可以打开其文档。GitHub Actions 成功运行后会发布 可安装的 .vsix 产物，直到该扩展在 Visual Studio Marketplace 上架。

npm run extension:package

有关安装、命令、工作区信任边界和保存时扫描行为，请参阅 VS Code 扩展指南。

JSON 输出约定发布于 schema/scan-result.schema.json。 有关兼容性保证和字段定义，请参阅 JSON 输出文档。

对于代码扫描平台，--format sarif 会输出 SARIF 2.1.0，包含稳定的 规则 ID、源代码位置、严重级别和发现指纹：

codediag scan . --format sarif > codediag-report.sarif

有关字段映射和 GitHub Code Scanning 工作流，请参阅 SARIF 输出文档。 每条规则都在规则参考中进行了说明。

指南

针对那些看似能保护路由、实则并不能的身份验证检查，提供简短且有来源支持的解答：

• 在 +layout.server.ts 中进行身份验证检查，能保护 SvelteKit 表单操作吗？
• 父级加载器的身份验证检查能保护 React Router 中的子路由吗？
• 你的 Next.js 中间件正在保护 API 路由吗？

AI Agent

让你的编码 Agent 使用 CodeDiag 的分析结果回答“哪些路由任何人都能调用？”。在 Claude Code 中安装插件，即可添加一项技能 和 MCP 服务：

/plugin install codediag --marketplace sabahattink/codediag

其他 MCP 客户端可以使用 npx -y @sabahattink/codediag mcp 启动服务。 它提供 find_unprotected_routes、scan_project 和 explain_rule，并且 始终离线运行。AI Agent 指南介绍了 Claude Code、Cursor、VS Code 和 Claude Desktop 的设置方法；对于未使用 MCP 的 Agent，可参阅 Agent 技能。

CI/CD

# GitHub Actions (no npm install required)
- uses: sabahattink/codediag@v0
  id: codediag
  with:
    threshold: 80

该 Action 会添加评分注释和作业摘要、写入 JSON 和 SARIF 报告，并在评分低于指定阈值时使作业失败。启用 comment: true（并授予 pull-requests: write 权限）后，它还会持续更新一条拉取请求评论，其中包含评分、评分相较上次推送的变化，以及拉取请求所更改文件中的问题。后续步骤可使用其 score、grade、report 和 sarif 输出。所有输入、输出和完整工作流请参阅 GitHub Action 指南。

拉取请求评论示例

✅ CodeDiag：88/100（B+）

▲ 较上次运行提高 4 分 · 阈值 80

分析器	评分	问题数
API 健康度	92/100	1
安全性	67/100	2
依赖项	100/100	0
测试	98/100	1
结构	100/100	0

已更改文件中的问题（2）

	规则	位置	问题
🔴	reflected-xss	src/routes/search.ts:14	请求数据未经转义便写入 HTML 响应
🟡	open-redirect	src/routes/auth.ts:31	重定向目标来自请求数据

未列出：项目其他位置还有 1 个问题。

要在现有代码库中采用 CodeDiag？请提交一个基线，让门禁只在出现新问题时失败：

- uses: sabahattink/codediag@v0
  with:
    threshold: 80
    baseline: .codediag-baseline.json   # created with --update-baseline

# npm-based GitHub Actions step
- run: npx @sabahattink/codediag scan . --ci --threshold 80

# GitLab CI
codediag:
  script: npx @sabahattink/codediag scan . --ci --threshold 80

# Pre-push hook (husky)
npx @sabahattink/codediag scan . --quiet --threshold 70

配置

可选。创建 .codediag.yml 或运行 codediag init。命令行 --threshold 的优先级高于配置中的阈值。每次扫描该项目时都会强制执行已配置的阈值。如果没有配置文件，普通扫描仅提供信息；--ci 使用默认阈值 70。

threshold: 70
failOn: critical         # optional; any active critical finding fails the scan
packageThreshold: 60     # optional; each --workspaces package must reach it
ignore: [node_modules, dist, .git, coverage]
maxFileSizeKb: 512
scoring:
  version: 2
rules:
  missing-swagger: off   # or info, warning, critical
audit: true              # false skips the network audit; production skips devDependencies
secretHistory: false     # true searches the last 1000 commits for removed secrets, or give a number
analyzers:
  api: true
  security: true
  dependencies: true
  testing: true
  structure: true

遇到未知选项或无效值时，扫描会失败，而不是静默忽略。ignore 下的目录和 glob 条目会应用于检查源文件的分析器。

可以在源代码中屏蔽单个问题，但必须提供原因；也可以通过基线接受现有问题，让 CI 仅在出现新问题时失败：

// codediag-ignore-next-line unsafe-dynamic-code -- plugin code is signed and sandboxed

请参阅屏蔽项、规则设置和基线。

源文件发现过程始终会跳过任意深度下的 node_modules、dist、coverage、.next 和 .turbo 目录，跳过 *.min.js 和 *.map 文件、点开头的目录，以及项目 .gitignore 文件匹配的所有内容（包括嵌套文件和 Git 根目录之前父目录中的文件）。大于 maxFileSizeKb 或看起来像压缩构建产物的代码文件会被跳过，并列在 JSON skipped 摘要中。

支持的技术栈

技术栈	API 健康度	安全性	依赖项	测试	结构
NestJS	✅	✅	✅	✅	✅
Next.js	✅	✅	✅	✅	✅
SvelteKit	✅	✅	✅	✅	✅
React Router / Remix	✅	✅	✅	✅	✅
Express	✅	✅	✅	✅	✅
Fastify	✅	✅	✅	✅	✅
Hono	✅	✅	✅	✅	✅
Elysia	✅	✅	✅	✅	✅
tRPC	✅	✅	✅	✅	✅
Node.js	—	✅	✅	✅	✅

CodeDiag 的定位

CodeDiag 是面向 Node.js 后端的快速、可解释健康检查工具，并非代码检查工具或完整 SAST 平台的替代品。建议与它们搭配使用：

• ESLint 或 Biome 可在你编写代码时发现代码级错误；CodeDiag 则检查它们无法发现的项目级防护措施，例如 NestJS 路由是否受全局守卫保护，或 Express 路由器是否挂载在身份验证之后。
• Semgrep、CodeQL 或 SonarQube 会运行深入且覆盖整个语言的规则集；CodeDiag 专注于一小组考虑框架特性的规则，尽量减少误报，并通过评分说明每一分的扣除原因。
• npm audit、Snyk 或 Dependabot 会跟踪存在漏洞的依赖项；CodeDiag 会运行你的包管理器的审计，并将结果纳入同一份报告。

所有操作都可通过一条命令在本地完成；需要在 GitHub Code Scanning 中查看结果时，还可输出 SARIF。

干净扫描不代表什么

CodeDiag 会检查每条路由是否包含它能识别的身份验证检查和输入验证。结果干净并不代表应用安全：

• 对象级授权。 路由可以要求用户登录，但仍允许用户 A 通过发送不同的 ID 来读取或更改用户 B 的记录。CodeDiag 不会检查处理程序是否将数据限定在调用者范围内；每种资源进行一次跨用户测试，就能发现它遗漏的问题。
• 直接访问数据库。 如果浏览器直接与数据库通信，例如使用 Supabase 的 anon key 或 Firebase，那么行级安全策略或安全规则才是安全边界，无论 API 路由防护得多好。CodeDiag 会读取 Supabase 迁移文件，检查未启用 RLS 的表，以及对所有行开放写入的策略；但它不会判断策略条件是否正确，不会读取线上数据库，也不会读取 Firebase 规则。
• Next.js Server Actions 目前尚未纳入分析。请在每个 Server Action 中检查身份验证。
• 按名称信任的检查。 像 requireUser() 这样的辅助函数会被视为身份验证检查；CodeDiag 会深入跟踪项目辅助函数几层调用，但无法证明它们会拒绝所有不符合条件的执行路径。
• Webhook 重放。 已验证的签名可以验证发送者身份；CodeDiag 不会检查时间戳容差或幂等性。
• 未纳入分析的服务。 Koa、Hapi、Nuxt 和 Nitro、Astro 以及其他服务都不会进行 API Health 分析；报告会针对它们显示“未分析路由”，而不是显示没有路由问题。
• 其他运行时。 仅分析 Node.js 后端，不分析 Python、Go、Ruby 或 Java 服务。

路线图

• **0.2：**支持 NestJS、Express 和 Next.js 的分析器；经过验证的配置；JSON schema、SARIF、HTML、SVG 徽章、修复计划、GitHub Action 和 VS Code 扩展。
• **0.3「可靠引擎」：**支持遵循 gitignore 的发现机制，跳过嵌套依赖项和打包文件（CodeDiag 自身扫描耗时从 15 s 降至 1.3 s）；规则注册表、可解释的评分、抑制项、基线、离线扫描，以及针对 Express、NestJS 和安全接收点的精准修复。请参阅 更新日志。
• **0.4 和 0.5：**路径遍历、SSRF、开放重定向和反射型 XSS 规则；GitHub Action 在拉取请求中发表评论。
• **0.6「深度扫描」：**Fastify 分析；JWT、Cookie、模板注入、原型污染和 shell spawn 规则；扫描配置文件和已提交的 .env 文件中的密钥；--compare 和 --changed-since；重新设计的 HTML 报告；VS Code 快速修复。
• **0.7「跨文件」：**通过辅助函数和服务进行跨文件污点追踪； 用于单体仓库的 --workspaces（CLI、Action 和 VS Code）；Hono 分析； --history 评分趋势；拉取请求评论中的基准分支差异； 审计建议详情和 audit: production。
• **0.8「深度」：**tRPC 过程；通过字段、构造函数、 回调和注入的提供程序进行污点追踪；@fastify/autoload 项目；从目录树中删除但保留在 Git 历史记录中的密钥；每个软件包的阈值和 --fail-on 门控；VS Code 中的修复快速操作。
• 0.9「边界」：createContext 中的 tRPC 身份验证、Express 挂载和 Next.js 中间件；审计结果缓存一小时，并在工作区软件包之间并发运行；Dependabot 更新会重新构建 Action 包。
• **0.10「覆盖范围」：**SvelteKit 和 React Router/Remix 分析；Hono 和 Fastify 挂载前面以及 Auth.js 中间件中的 tRPC 身份验证；按路由评估 Next.js 中间件；每个工作区锁文件运行一次 pnpm 审计，并按软件包拆分；减少真实应用中密码和密钥的误报。
• **0.11「Agent」：**MCP 服务（codediag mcp）、Agent Skill 和 Claude Code 插件，让编码 Agent 可以用 CodeDiag 查找未受保护的路由。
• **0.12「行」：**从 supabase/migrations 读取缺少行级安全性的 Supabase 表，以及对所有行开放的写入策略。
• **0.13「范围」：**支持跟踪插件和钩子作用域的 Elysia 分析，以及针对 CodeDiag 未分析的服务提供「未分析路由」说明。
• **后续计划：**请参阅 docs/roadmap.md，了解计划支持的框架、编辑器改进和更深入的污点追踪。

贡献

请参阅 CONTRIBUTING.md，了解开发工作流、测试要求和拉取请求指南。

CodeDiag 对你的代码判断有误？请使用能说明问题的最小代码片段报告误报或漏报。问题和想法请前往 讨论区。

git clone https://github.com/sabahattink/codediag.git
cd codediag
npm ci
npm run check
node dist/index.js scan /path/to/project

请使用 conventional commits：feat:、fix:、docs:、refactor:

安全漏洞应按照 SECURITY.md 私下报告，而不要通过公开议题提交。

许可证

MIT - Sabahattin Kalkan

_{如果 codediag 在用户发现问题之前就帮你找到了问题，请给它一个 ⭐}