nestjs-code-audit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

NestJS Code Audit

NestJS代码审计

Inspect the current user's NestJS project and return one consolidated report of verified code problems and evidence-backed risks. Audit only; do not modify the target project.

检查当前用户的NestJS项目，返回一份整合了已验证代码问题及有证据支撑风险的报告。仅执行审计操作；不得修改目标项目。

Pre-execution conflict guard

执行前冲突防护

Run this guard after identifying every applicable skill and before editing files, installing packages, generating code, running migrations, changing infrastructure, or executing any other state-changing command. Read-only repository inspection and non-mutating static checks are allowed while resolving the guard.

在识别所有适用能力后、编辑文件、安装包、生成代码、运行迁移、更改基础设施或执行任何其他会改变状态的命令前，运行此防护机制。在解决冲突期间，允许进行只读仓库检查和非修改性静态检查。

Prerequisites

前置条件

Confirm the target root, requested scope, repository instructions, git state, package manager, installed dependencies, NestJS/Node/TypeScript versions, and available quality scripts.

Load

nestjs-architecture-principles

nestjs-oop-design-patterns

, and

nestjs-features-performance

before classifying semantic findings.

Treat the target repository's explicit contracts and verified runtime constraints as evidence. Do not import this repository's preferred folder structure into an unrelated project.

确认目标根目录、请求范围、仓库说明、Git状态、包管理器、已安装依赖、NestJS/Node/TypeScript版本及可用的质量脚本。

在对语义结果进行分类前，加载

nestjs-architecture-principles

、

nestjs-oop-design-patterns

和

nestjs-features-performance

。

将目标仓库的明确约定和已验证的运行时约束视为证据。不得将此仓库偏好的文件夹结构引入无关项目。

Primary ownership

主要归属权

This skill owns audit orchestration, safe evidence collection, cross-skill deduplication, severity normalization, and the final report. It does not override the domain owners:

```
nestjs-architecture-principles
```
owns module, capability, dependency, data/write, transaction, and service-boundary findings.
```
nestjs-oop-design-patterns
```
owns object responsibility, invariant placement, coupling, abstraction, and pattern/refactoring findings.
```
nestjs-features-performance
```
owns NestJS lifecycle, API/error, security, testing, runtime, performance, reliability, and delivery findings.

Syntax, TypeScript, and lint failures are reported as toolchain facts. A single issue that crosses lanes keeps one primary owner and lists the other skills as supporting context.

nestjs-professional-software-engineering

may provide general code-quality context, but this skill's read-only boundary controls the audit. Fixes require a separately authorized implementation workflow.

nestjs-feature-audit

owns branch-specific roadmap traceability and the feature-status report. This skill may supply verified quality findings, but it does not replace the roadmap gate or reorganize the report around whole-repository severity.

nestjs-git-commit-pr-message

may publish an explicitly requested audit report, but it cannot use publication as authorization to fix findings or mutate the audited project.

此能力负责审计编排、安全证据收集、跨能力去重、严重性标准化及最终报告生成。它不会覆盖领域所有者：

```
nestjs-architecture-principles
```
负责模块、能力、依赖、数据/写入、事务及服务边界相关结果。
```
nestjs-oop-design-patterns
```
负责对象职责、不变量放置、耦合、抽象及模式/重构相关结果。
```
nestjs-features-performance
```
负责NestJS生命周期、API/错误、安全、测试、运行时、性能、可靠性及交付相关结果。

语法、TypeScript及lint失败将作为工具链事实报告。若单个问题涉及多个领域，保留一个主要所有者，并将其他能力列为支持上下文。

nestjs-professional-software-engineering

可提供通用代码质量上下文，但此能力的只读边界控制着审计流程。修复操作需要单独授权的实施工作流。

nestjs-feature-audit

负责分支特定的路线图可追溯性及功能状态报告。此能力可提供已验证的质量结果，但不会替代路线图关卡或围绕全仓库严重性重新组织报告。

nestjs-git-commit-pr-message

可发布明确请求的审计报告，但不能将发布视为修复问题或修改被审计项目的授权。

Conflict test

冲突测试

A conflict exists when active skills would:

classify the same evidence as incompatible problems or recommend incompatible outcomes;
require checks whose commands, environment assumptions, or side effects cannot all remain read-only;
claim primary ownership of the same finding without a clear handoff; or
proceed without dependencies, configuration, authorization, or evidence required to make a reliable claim.

Resolve conflicts in this order: explicit user intent, target-repository contracts and verified runtime constraints, then the narrowest primary owner above. If a material conflict remains, omit the disputed claim from confirmed findings and record it under Needs verification with the missing evidence. If a requested action would cross this skill's read-only boundary, stop before mutation and require a separately authorized implementation workflow. Never manufacture consensus, run an unsafe command, or modify the project to make the audit pass.

当活跃能力出现以下情况时，即存在冲突：

将同一证据归类为不相容问题或建议不相容的结果；
要求进行的检查其命令、环境假设或副作用无法全部保持只读；
声称对同一结果拥有主要归属权但无明确交接；
在缺乏做出可靠声明所需的依赖、配置、授权或证据的情况下继续执行。

按以下顺序解决冲突：明确的用户意图、目标仓库的约定和已验证的运行时约束，然后是上述最具体的主要所有者。若仍存在实质性冲突，则将有争议的声明从已确认结果中排除，并记录在需要验证部分，同时注明缺失的证据。若请求的操作会跨越此能力的只读边界，则在修改前停止，并要求单独授权的实施工作流。切勿人为制造共识、运行不安全命令或修改项目以通过审计。

Invocation

调用方式

Preferred portable invocation:

text

$nestjs-code-audit
$nestjs-code-audit full src/payments
$nestjs-code-audit static
$nestjs-code-audit security src/auth

Codex CLI/IDE custom-prompt alias, when installed:

text

/prompts:nestjs-audit
/prompts:nestjs-audit full src/payments

Codex does not provide arbitrary bare user-defined commands such as

/Nestjs audit

; keep the supported alias explicit.

首选可移植调用方式：

text

$nestjs-code-audit
$nestjs-code-audit full src/payments
$nestjs-code-audit static
$nestjs-code-audit security src/auth

安装Codex CLI/IDE自定义提示别名后：

text

/prompts:nestjs-audit
/prompts:nestjs-audit full src/payments

Codex不提供诸如

/Nestjs audit

之类的任意裸用户定义命令；请明确使用受支持的别名。

Actions

操作

Action	Coverage
`full` (default)	Safe static gates plus architecture, object design, runtime, security, testing, and delivery review
`static`	Syntax, TypeScript, lint, configuration, and directly related toolchain failures
`architecture`	Modules, dependencies, data/write ownership, transactions, events, ports, and service boundaries
`design`	Responsibilities, invariants, coupling, abstractions, patterns, and refactoring risks
`runtime`	Nest lifecycle, API/errors, reliability, performance evidence, health, shutdown, and delivery
`security`	Input, identity/access, tenant isolation, secrets, output, abuse controls, and security tests
`tests`	Test-layer choice, missing boundary coverage, flaky lifecycle risks, and safely runnable checks

An optional repository-relative scope follows the action. If the first argument is not a recognized action, treat all arguments as the scope/focus and use

full

. Focused actions still load the three domain skills to resolve ownership, but they report only the requested lane and explicit cross-lane blockers.

操作	覆盖范围
`full` （默认）	安全静态检查门控，加上架构、对象设计、运行时、安全、测试及交付审查
`static`	语法、TypeScript、lint、配置及直接相关的工具链失败情况
`architecture`	模块、依赖、数据/写入归属权、事务、事件、端口及服务边界
`design`	职责、不变量、耦合、抽象、模式及重构风险
`runtime`	Nest生命周期、API/错误、可靠性、性能证据、健康检查、 shutdown及交付
`security`	输入、身份/访问、租户隔离、密钥、输出、滥用控制及安全测试
`tests`	测试层选择、缺失的边界覆盖、不稳定的生命周期风险及可安全运行的检查

操作后可跟可选的仓库相对范围。若第一个参数不是已识别的操作，则将所有参数视为范围/焦点，并使用

full

模式。聚焦操作仍会加载三个领域能力以解决归属权问题，但仅报告请求的领域及明确的跨领域阻塞问题。

Audit workflow

审计工作流

1. Establish eligibility and scope

1. 确定资格与范围

Resolve the current working directory and optional user scope without escaping the repository root.
Read
```
AGENTS.md
```
and other repository instructions,
```
package.json
```
, lockfiles,
```
nest-cli.json
```
, TypeScript and lint configuration, bootstrap files, module files, tests, and deployment manifests that affect the scope.
Verify that
```
@nestjs/core
```
is declared or that the repository is clearly a NestJS workspace. If not, stop and report that this audit is not applicable.
Record the current branch and dirty state. Do not alter or discard existing changes.
State a one-sentence baseline of the observed architecture. Do not infer Clean Architecture, DDD, CQRS, or microservices from folder names.

解析当前工作目录及可选的用户范围，确保不超出仓库根目录。
读取
```
AGENTS.md
```
及其他仓库说明、
```
package.json
```
、锁文件、
```
nest-cli.json
```
、TypeScript和lint配置、引导文件、模块文件、测试及影响范围的部署清单。
验证是否声明了
```
@nestjs/core
```
，或仓库是否明确为NestJS工作区。若未满足，停止并报告此审计不适用。
记录当前分支及未提交状态。不得更改或丢弃现有更改。
用一句话陈述观察到的架构基线。不得从文件夹名称推断Clean Architecture、DDD、CQRS或微服务架构。

2. Collect deterministic evidence

2. 收集确定性证据

Use the bundled collector from this skill's directory:

bash

node scripts/collect-quality-evidence.mjs --root "$PWD" --run

Add

--scope <relative-path>

when the user requested a narrower audit. The collector:

reads manifests and source files without changing them;
identifies the package manager and available quality scripts;
runs only allow-listed, non-fixing ESLint and
```
tsc --noEmit
```
commands when
```
--run
```
is present;
never installs dependencies, runs builds, updates snapshots, writes coverage, or invokes arbitrary package scripts;
returns JSON containing command results and heuristic review candidates.

If dependencies are missing or a command is unsafe, unavailable, timed out, or outside scope, record it as not run. Do not reinterpret a missing check as a pass. Never run

lint --fix

, format/write commands, migrations, deployment commands, live integration tests, or tests that may reach shared infrastructure during this audit.

使用此技能目录中的捆绑收集器：

bash

node scripts/collect-quality-evidence.mjs --root "$PWD" --run

当用户请求更窄范围的审计时，添加

--scope <relative-path>

。收集器：

读取清单和源文件但不修改它们；
识别包管理器及可用的质量脚本；
当存在
```
--run
```
参数时，仅运行允许的、非修复性的ESLint和
```
tsc --noEmit
```
命令；
从不安装依赖、运行构建、更新快照、写入覆盖率或调用任意包脚本；
返回包含命令结果和启发式审查候选的JSON。

若依赖缺失，或命令不安全、不可用、超时或超出范围，则记录为未运行。不得将缺失的检查视为通过。在此审计期间，切勿运行

lint --fix

、格式化/写入命令、迁移、部署命令、实时集成测试或可能触及共享基础设施的测试。

3. Review four evidence lanes

3. 审查四个证据领域

Toolchain correctness

工具链正确性

Report parser, TypeScript, and lint diagnostics exactly enough to locate the problem.
Deduplicate cascaded compiler errors when they share one root cause.
Separate command failure from a code finding, such as missing dependencies or broken configuration.

报告解析器、TypeScript及lint诊断信息，内容需足以定位问题。
当级联编译器错误共享同一根本原因时，进行去重。
将命令失败与代码问题分开，例如缺失依赖或配置损坏。

Architecture

架构

Trace bootstrap entry points, module imports/exports, provider visibility, request/message paths, persistence ownership, transactions, events, and external adapters. Confirm cycles or boundary leaks from real imports and call paths. Do not report architectural preference as a defect.

追踪引导入口点、模块导入/导出、提供者可见性、请求/消息路径、持久化归属权、事务、事件及外部适配器。从实际导入和调用路径确认循环依赖或边界泄漏。不得将架构偏好报告为缺陷。

Object design and maintainability

对象设计与可维护性

Inspect responsibilities, dependency clusters, invariant placement, repeated conditional variation, framework/vendor leakage, hidden service location, speculative abstractions, and risky refactor seams. File length or a regex signal alone is not a finding.

检查职责、依赖集群、不变量放置、重复条件变化、框架/供应商泄漏、隐藏服务定位、推测性抽象及高风险重构接缝。仅文件长度或正则信号不足以作为问题记录。

Runtime, security, and verification

运行时、安全与验证

Inspect lifecycle placement, validation, authentication/authorization, tenant/resource ownership, public error and response contracts, secrets/logging, query and resource bounds, timeouts/retries/idempotency, health/shutdown, test boundaries, and deployment evidence when present. Do not claim performance problems without measurements.

检查生命周期放置、验证、认证/授权、租户/资源归属权、公共错误和响应约定、密钥/日志记录、查询和资源限制、超时/重试/幂等性、健康检查/ shutdown、测试边界及部署证据（若存在）。若无测量数据，不得声称存在性能问题。

4. Verify and deduplicate findings

4. 验证与去重结果

A confirmed finding needs:

a stable ID:
```
TOOL
```
,
```
ARCH
```
,
```
OOP
```
,
```
RUN
```
,
```
SEC
```
, or
```
TEST
```
plus a number;
severity: critical, high, medium, or low;
primary owning skill;
file and line evidence plus the relevant import, call path, diagnostic, or configuration;
concrete impact, not only a rule name;
the smallest safe remedy;
a validation step that could prove the remedy.

Use critical only for a present security, data-loss, tenant-isolation, or severe availability risk. High requires likely incorrect behavior or a boundary flaw blocking a known change. Medium requires a credible maintainability, correctness, or operability cost. Low is a localized improvement with limited risk.

Move unverified regex signals, suspected dead code, possible performance issues, and checks blocked by missing dependencies to Needs verification. Do not inflate the report with style preferences or multiple findings for one root cause.

已确认的问题需包含：

稳定ID：
```
TOOL
```
、
```
ARCH
```
、
```
OOP
```
、
```
RUN
```
、
```
SEC
```
或
```
TEST
```
加数字；
严重性：critical（严重）、high（高）、medium（中）或low（低）；
主要负责能力；
文件和行证据，加上相关的导入、调用路径、诊断或配置；
具体影响，而非仅规则名称；
最安全的最小修复方案；
可证明修复有效的验证步骤。

仅当存在当前安全、数据丢失、租户隔离或严重可用性风险时，使用critical级别。high级别适用于可能的错误行为或阻碍已知变更的边界缺陷。medium级别适用于可信的可维护性、正确性或可操作性成本。low级别是局部改进，风险有限。

将未验证的正则信号、疑似死代码、可能的性能问题及因依赖缺失而受阻的检查移至需要验证部分。不得将风格偏好或同一根本原因的多个问题纳入报告以夸大内容。

Required report

必需报告

Return Markdown in this order:

Audit verdict: pass, pass with risks, or fail; audited scope; one-sentence baseline.
Quality gates: syntax/TypeScript, lint, tests if safely available, and audit coverage, each marked pass, fail, or not run with the exact command or reason.
Finding summary: counts by severity and owner.
Confirmed findings: ordered by severity and impact, using the evidence/remedy/validation contract above.
Needs verification: candidate, missing evidence, and smallest next check.
Healthy patterns: only notable controls actually verified in the repository.
Recommended order: a short, dependency-aware remediation sequence; do not implement it unless the user separately asks.

If there are no confirmed problems, say so and list the checks that were not run. A clean lint result is not proof of sound architecture, security, runtime behavior, or test coverage.

按以下顺序返回Markdown格式内容：

审计结论：通过、带风险通过或失败；审计范围；一句话基线。
质量门控：语法/TypeScript、lint、测试（若可安全获取）及审计覆盖率，分别标记为通过、失败或未运行，并注明确切命令或原因。
问题摘要：按严重性和所有者统计数量。
已确认问题：按严重性和影响排序，遵循上述证据/修复/验证约定。
需要验证：候选问题、缺失证据及最小的下一步检查。
健康模式：仅列出仓库中实际验证的显著控制措施。
推荐修复顺序：简短的、依赖感知的修复序列；除非用户单独要求，否则不得实施。

若无已确认问题，需明确说明，并列出未运行的检查。lint结果干净并不代表架构合理、安全、运行时行为正确或测试覆盖率达标。

Reference routing

参考路由

Need	Load
Decide which checks may run without modifying the project	check-policy.md
Assign and deduplicate findings across the three domain skills	finding-ownership.md
Format the final audit consistently	report-template.md

需求	加载内容
确定哪些检查可在不修改项目的情况下运行	check-policy.md
在三个领域能力间分配并去重问题	finding-ownership.md
统一格式化最终审计报告	report-template.md