architecture

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Architecture Skill

架构技能

Version: 3.0 Source: Architecture Principles + Project Structure Profiles

How to structure a project — both logically (module design, dependency flow) and physically (folder layout, naming, type-specific conventions).

Version: 3.0 Source: Architecture Principles + Project Structure Profiles

如何构建项目——包括逻辑层面（模块设计、依赖流向）和物理层面（文件夹布局、命名规则、特定类型项目的约定）。

Scope and Boundaries

范围与边界

This skill covers: Module design, dependency flow, folder structure, naming conventions, and project-type-specific layouts.

This skill does NOT cover: Code quality within files (see

code-quality

), documentation standards (see

documentation

), or build/deploy configuration.

Relationship to other skills:

Works alongside
```
code-quality
```
(file-level conventions) and
```
documentation
```
(docs standards)
Consumed by clean-team
```
:audit
```
command (with focus:
```
structure
```
)
Referenced by clean-team, implement-team, and diagnose-team agents

本技能涵盖： 模块设计、依赖流向、文件夹结构、命名约定及特定类型项目的布局。

本技能不涵盖： 文件内部的代码质量（详见

code-quality

）、文档标准（详见

documentation

）或构建/部署配置。

与其他技能的关系：

与
```
code-quality
```
（文件级约定）和
```
documentation
```
（文档标准）协同工作
被clean-team的
```
:audit
```
命令使用（聚焦于
```
structure
```
）
被clean-team、implement-team和diagnose-team agents引用

North Star

核心目标

Goal: Small changes stay local.

A typical feature should touch 1-2 modules, ship quickly, and not require coordinated edits across the system. If you find yourself editing 5+ files across multiple layers for a simple change, that's a design smell.

目标： 小改动仅影响局部。

一个典型功能应仅涉及1-2个模块，快速交付，无需跨系统协调修改。如果您发现一个简单的改动需要跨多个层级编辑5个以上文件，这就是设计坏味道。

Core Principles

核心原则

1. Explicit Over Magic

1. 显式优于魔法

Prefer readable wiring over convention-heavy frameworks. When someone reads your code, the control flow should be obvious. No

@AutoInject()

decorators that hide what depends on what — use explicit constructor parameters.

优先选择可读性强的代码连接方式，而非依赖大量约定的框架。当有人阅读您的代码时，控制流应一目了然。不要使用

@AutoInject()

装饰器来隐藏依赖关系——请使用显式的构造函数参数。

2. Boundaries Are Sacred

2. 边界不可侵犯

Modules communicate only through contracts (APIs, props, events). No reaching into another module's internals. Import from the module's public API, never from internal files.

模块仅通过契约（API、props、事件）进行通信。不得直接访问其他模块的内部实现。仅从模块的公开API导入，绝不要从内部文件导入。

3. Own Your Data

3. 数据所有权明确

Each module owns its schema/state. Other modules read via APIs or props, never direct access. If OrderModule needs user data, it calls

UserModule.getUserById()

— it doesn't query the users table directly.

每个模块拥有自己的 schema/状态。其他模块通过API或props读取数据，绝不直接访问。如果OrderModule需要用户数据，它应调用

UserModule.getUserById()

——而非直接查询用户表。

4. Optimize for Refactoring

4. 为重构优化

If code is hard to move or rename, it's a design smell. Loose coupling enables safe refactoring.

如果代码难以移动或重命名，这就是设计坏味道。松耦合才能实现安全重构。

The 3 Layers

三层架构

01-presentation/  →  02-logic/  →  03-data/

Layer	Responsibility	Examples
Presentation	What users see and interact with	Components, pages, styles
Logic	How it's built, business rules	Services, use cases, validation
Data	How it persists, external sources	Repositories, models, adapters

01-presentation/  →  02-logic/  →  03-data/

层级	职责	示例
Presentation	用户可见及交互的部分	组件、页面、样式
Logic	实现方式、业务规则	服务、用例、验证
Data	持久化方式、外部数据源	仓库、模型、适配器

Valid Dependency Flow

合法依赖流向

Presentation → Logic → Data ✅
Data → Logic ❌ (blocked)
Logic → Presentation ❌ (blocked)
Presentation → Data ❌ (blocked — no layer skipping)

Presentation → Logic → Data ✅
Data → Logic ❌（禁止）
Logic → Presentation ❌（禁止）
Presentation → Data ❌（禁止——禁止跨层级跳转）

Module Boundaries

模块边界

A module is a cohesive unit with a clear public API, hidden implementation, and defined dependencies.

模块是一个内聚的单元，拥有清晰的公开API、隐藏的实现细节及明确的依赖关系。

Module Rules

模块规则

Single Entry Point: Each module exposes its API through an index file. External imports MUST go through it.

No Circular Dependencies: Modules cannot depend on each other in a cycle. Break cycles by extracting shared code, using events, or introducing an interface.

Own Your Data: Each module owns its data exclusively. Cross-module data is accessed via APIs, never direct DB queries.

单一入口点： 每个模块通过index文件暴露其API。外部导入必须通过该入口点。

无循环依赖： 模块之间不能形成循环依赖。可通过提取共享代码、使用事件或引入接口来打破循环。

数据所有权明确： 每个模块独占其数据。跨模块数据访问必须通过API，绝不能直接查询数据库。

Coupling Guidelines

耦合指南

Coupling Type	OK?
Type import	Always
Function call via public API	Usually
Direct instantiation	Carefully
Shared mutable state	Avoid

Full details:
references/module-boundaries.md
— Module structure, boundary rules, communication patterns, coupling levels, refactoring guidance

耦合类型	是否允许
类型导入	始终允许
通过公开API调用函数	通常允许
直接实例化	谨慎使用
共享可变状态	避免使用

详细内容：
references/module-boundaries.md
—— 模块结构、边界规则、通信模式、耦合级别、重构指南

Folder Structure

文件夹结构

A well-organized project isn't just tidy — it's a project where you never have to ask "where does this go?" or "where would I find that?" The structure itself answers those questions. When folders mirror how you think about the project, navigation becomes intuitive rather than a search exercise. You find things where you expect them to be, on the first try.

This matters even more when AI is involved. AI has no memory between sessions — it can't learn your project's layout over time the way a human teammate would. Every session starts fresh. A clear, predictable structure means the AI spends less time searching and more time doing useful work. Descriptive folder names, consistent conventions, and logical grouping are context that the AI reads for free on every interaction.

The goal: any file should be findable in 2-3 navigation steps based on intuition alone. If you have to search, the structure failed.

一个组织良好的项目不仅整洁——更重要的是，您永远不必问“这个文件放在哪里？”或“我在哪里能找到那个文件？”。项目结构本身就能回答这些问题。当文件夹的组织方式与您对项目的思考方式一致时，导航会变得直观而非搜索。您第一次就能在预期的位置找到文件。

这一点在AI参与开发时更为重要。AI在会话之间没有记忆——它无法像人类队友那样随时间了解项目的布局。每次会话都是全新的开始。清晰、可预测的结构意味着AI花费在搜索上的时间更少，更多时间用于完成有用的工作。描述性的文件夹名称、一致的约定和逻辑分组是AI在每次交互中都能免费获取的上下文信息。

目标： 任何文件都应能通过直觉在2-3次导航步骤内找到。如果您需要搜索，说明结构设计失败了。

Organize by Feature Within Tiers

按功能在层级内组织

For web projects using 3-tier architecture, organize by feature WITHIN each tier — don't scatter a single feature across global

models/

services/

controllers/

directories.

Within 02-logic/:
Prefer:                          Avoid:
02-logic/                        02-logic/
  users/                           models/
    user.model.ts                    user.model.ts
    user.service.ts                  order.model.ts
  orders/                          services/
    ...                              user.service.ts
                                     order.service.ts

Feature-based grouping keeps related code together within each tier. Tiers enforce dependency flow (presentation → logic → data), while feature folders enforce cohesion within each tier. These are complementary, not contradictory.

For non-web projects (CLI tools, libraries, scripts) that don't use 3-tier architecture, apply feature-based grouping at the project root level.

对于使用三层架构的Web项目，在每个层级内按功能组织——不要将单个功能分散到全局的

models/

、

services/

、

controllers/

目录中。

Within 02-logic/:
Prefer:                          Avoid:
02-logic/                        02-logic/
  users/                           models/
    user.model.ts                    user.model.ts
    user.service.ts                  order.model.ts
  orders/                          services/
    ...                              user.service.ts
                                     order.service.ts

基于功能的分组将每个层级内的相关代码放在一起。层级强制依赖流向（presentation → logic → data），而功能文件夹则强制每个层级内的内聚性。两者互补，而非矛盾。

对于非Web项目（CLI工具、库、脚本），如果不使用三层架构，则在项目根目录级别应用基于功能的分组。

Universal Structural Principles

通用结构原则

These apply to every project regardless of type.

Naming Consistency — Pick one casing convention per category and apply it everywhere. All components PascalCase, all utilities camelCase, all configs kebab-case. Consistency makes things findable — when you know the convention, you can predict the file name before you look.

Logical Grouping — Related files live together. If you change one, you'll likely change the others. Co-locate by default. Only separate when there's a clear benefit. The test for grouping: "If I'm working on X, what else will I need open?"

Reasonable Depth — No more than 4 levels from root to file. Every level of nesting must earn its place. If a folder contains only one subfolder containing one file — flatten it. Deep nesting isn't organization, it's a scavenger hunt.

Clear Entry Point — Someone opening the project for the first time should know where to start within 10 seconds. Root README explains what the project is. The main entry file is named conventionally (

index

main

app

). Top-level folders tell the story of what the project is.

Clean Root — The project root should contain only what must be there — entry points, top-level config, and the folders that define the project's structure. Config files that must live at root (

.gitignore

package.json

tsconfig.json

) get a pass — stray scripts, utilities, and one-off files do not. When in doubt, move it deeper. The root is the first impression.

Self-Documenting Names — Folder names describe what's inside, not how it's used.

formatters/

validators/

parsers/

are clear.

utils/

helpers/

misc/

are dumping grounds. If a folder has more than 10 files with no shared theme, split by what the files actually do.

这些原则适用于所有类型的项目。

命名一致性 —— 为每个类别选择一种命名规范并全局应用。所有组件使用PascalCase，所有工具函数使用camelCase，所有配置文件使用kebab-case。一致性让文件更易查找——当您了解规范时，就能在查找前预测文件名。

逻辑分组 —— 相关文件放在一起。如果您修改其中一个，很可能也需要修改其他文件。默认将相关文件放在一起。仅当有明确益处时才分开。分组的测试标准：“当我处理X时，还需要打开哪些文件？”

合理的深度 —— 从根目录到文件的层级不超过4层。每一层嵌套都必须有存在的理由。如果一个文件夹仅包含一个子文件夹和一个文件——则扁平化结构。过深的嵌套不是组织，而是寻宝游戏。

清晰的入口点 —— 第一次打开项目的人应能在10秒内知道从哪里开始。根目录的README说明项目用途。主入口文件使用约定名称（

index

、

main

、

app

）。顶级文件夹讲述项目的核心内容。

整洁的根目录 —— 项目根目录应仅包含必须存在的内容——入口点、顶级配置及定义项目结构的文件夹。必须放在根目录的配置文件（

.gitignore

、

package.json

、

tsconfig.json

）可以保留——但零散的脚本、工具函数和一次性文件不行。如有疑问，将其移至更深层级。根目录是第一印象。

自文档化的名称 —— 文件夹名称描述其中的内容，而非使用方式。

formatters/

、

validators/

、

parsers/

是清晰的名称。

utils/

、

helpers/

、

misc/

是垃圾场。如果一个文件夹包含10个以上无共同主题的文件，应按文件的实际功能拆分。

Project Type Profiles

项目类型配置文件

Type-specific folder structures, naming conventions, and red flags. Each profile is a self-contained reference.

特定类型项目的文件夹结构、命名约定及警示标志。每个配置文件都是独立的参考文档。

Detection Decision Tree

检测决策树

Does the project contain...

  ├─ package.json + .tsx/.jsx/.css/.html files?
  │  └─ YES → Load references/web.md
  │
  ├─ Assets/ + .cs scripts + .unity scene files?
  │  ├─ VRChat SDK present? (Packages/com.vrchat.*, VRCSDK3, UdonSharp)
  │  │  └─ YES → Load references/vrchat.md (overrides Unity)
  │  └─ No VRC SDK
  │     └─ Load references/unity.md
  │
  ├─ .blend files + texture images?
  │  └─ YES → Load references/blender.md
  │
  ├─ .tf files / cdk.json / template.yaml?
  │  └─ YES → Load references/data-iac.md
  │
  └─ None of the above?
     └─ Use Universal Structural Principles above

Priority rule: When multiple profiles match, use the most specific. VRChat overrides Unity. A project with both application code and IaC should use the application profile for the app and reference data-iac for the infrastructure portion.

Does the project contain...

  ├─ package.json + .tsx/.jsx/.css/.html files?
  │  └─ YES → Load references/web.md
  │
  ├─ Assets/ + .cs scripts + .unity scene files?
  │  ├─ VRChat SDK present? (Packages/com.vrchat.*, VRCSDK3, UdonSharp)
  │  │  └─ YES → Load references/vrchat.md (overrides Unity)
  │  └─ No VRC SDK
  │     └─ Load references/unity.md
  │
  ├─ .blend files + texture images?
  │  └─ YES → Load references/blender.md
  │
  ├─ .tf files / cdk.json / template.yaml?
  │  └─ YES → Load references/data-iac.md
  │
  └─ None of the above?
     └─ Use Universal Structural Principles above

优先级规则： 当多个配置文件匹配时，使用最具体的那个。VRChat配置覆盖Unity配置。同时包含应用代码和IaC的项目，应用部分使用应用配置文件，基础设施部分参考data-iac配置。

Available Profiles

可用配置文件

Profile	Reference File	Best For
Web (React/Node)	`references/web.md`	SPAs, fullstack apps, Node APIs, React projects
Unity	`references/unity.md`	Unity games, tools, non-VRChat Unity projects
VRChat	`references/vrchat.md`	VRChat worlds and avatars (extends Unity)
Blender	`references/blender.md`	3D modeling, texturing, rendering projects
Data/IaC (AWS)	`references/data-iac.md`	Terraform, CDK, CloudFormation infrastructure

配置文件	参考文件	适用场景
Web (React/Node)	`references/web.md`	单页应用、全栈应用、Node API、React项目
Unity	`references/unity.md`	Unity游戏、工具、非VRChat的Unity项目
VRChat	`references/vrchat.md`	VRChat世界和角色（扩展Unity配置）
Blender	`references/blender.md`	3D建模、纹理、渲染项目
Data/IaC (AWS)	`references/data-iac.md`	Terraform、CDK、CloudFormation基础设施

How to Use

使用方法

Detect the project type using the decision tree above
Load the matching profile from
```
references/
```
Compare the actual structure against the expected layout

Evaluate using the checklist in

assets/structure-evaluation-checklist.md

Flag deviations as findings — prioritize red flags highest

检测 —— 使用上述决策树确定项目类型
加载 —— 从
```
references/
```
加载匹配的配置文件
对比 —— 将实际结构与预期布局对比

评估 —— 使用

assets/structure-evaluation-checklist.md

中的检查清单

标记 —— 将偏差标记为问题——优先处理红色警示

Adding a New Profile

添加新配置文件

Create
```
references/<type>.md
```
following the standard template:
- Why This Structure Matters — problem, benefit, cost of ignoring
- Detection — file patterns that identify this project type
- Expected Structure — annotated directory tree with principle comments
- Naming Conventions — table of type/convention/example
- Red Flags — 3-column table: Flag | Root Cause | Fix
- When to Reconsider — symptom → problem → action table
Add a row to the Available Profiles table above
Add a branch to the Detection Decision Tree

Add a type-specific section to

assets/structure-evaluation-checklist.md

按照标准模板创建
```
references/<type>.md
```
:
- 该结构的重要性 —— 问题、益处、忽略的成本
- 检测方式 —— 识别该项目类型的文件模式
- 预期结构 —— 带原则注释的目录树
- 命名约定 —— 类型/约定/示例表格
- 红色警示 —— 3列表格：警示 | 根本原因 | 修复方案
- 何时重新考虑 —— 症状→问题→行动表格
在上述可用配置文件表格中添加一行
在检测决策树中添加分支

在

assets/structure-evaluation-checklist.md

中添加特定类型的部分

Pattern Selection

模式选择

Pattern	Use When
Pure functions	Stateless transformations
Module with functions	Grouping related functions
Class	State or DI needed
Factory	Complex object creation
Repository	Data access abstraction

Default to simplicity: Function → Module → Class → Pattern

Full catalog:
references/design-patterns.md
— Factory, Builder, Adapter, Facade, Decorator, Strategy, Observer, Command, Repository, Result Type

模式	使用场景
纯函数	无状态转换
函数模块	分组相关函数
类	需要状态或依赖注入(DI)
工厂模式	复杂对象创建
仓库模式	数据访问抽象

默认选择简单方案： 函数 → 模块 → 类 → 模式

完整目录：
references/design-patterns.md
—— 工厂、构建器、适配器、外观、装饰器、策略、观察者、命令、仓库、结果类型

Testing Strategy

测试策略

Type	Purpose	Scope	Volume
Unit	Fast, deterministic, domain-heavy	Single function/component	Heavy
Integration	DB, APIs, external services	Module boundaries	Moderate
E2E	Critical user paths only	Full stack	Minimal

Heavy unit tests, moderate integration, minimal E2E. E2E sprawl leads to brittle, slow test suites. Contract tests recommended for API boundaries.

类型	目的	范围	数量
单元测试	快速、确定性、聚焦领域	单个函数/组件	大量
集成测试	数据库、API、外部服务	模块边界	中等
端到端测试	仅覆盖关键用户路径	全栈	少量

大量单元测试、中等集成测试、少量端到端测试。端到端测试泛滥会导致测试套件脆弱且缓慢。推荐为API边界添加契约测试。

Anti-Patterns

反模式

Code Architecture

代码架构

Anti-Pattern	Symptom	Fix
God Object	>500 lines, >10 public exports	Extract cohesive submodules
Anemic Domain Model	Getters/setters only, services do all work	Move behavior to entities
Shotgun Surgery	Adding a field requires 5+ file changes	Better encapsulation

反模式	症状	修复方案
上帝对象	超过500行，10个以上公开导出	提取内聚的子模块
贫血领域模型	仅包含getter/setter，所有逻辑在服务中实现	将行为移至实体类
霰弹式修改	添加一个字段需要修改5个以上文件	更好的封装

Project Structure

项目结构

Anti-Pattern	Symptom	Fix
Cluttered Root	15+ files at project root, stray scripts alongside config	Move everything that isn't an entry point or required config into folders
God Folder	One folder with 40+ files	Group by domain, feature, or function
Ghost Folders	Empty folders with no files and no clear purpose	Delete unless part of an intentional pattern
Naming Soup	Mixed casing: `UserProfile.tsx` , `order-utils.ts` , `payment_service.py`	Pick one convention per file type, enforce it
Orphaned Files	Files that nothing imports or references	Verify unused, then delete
Deep Nesting	5+ folder levels to reach a single file	Flatten — levels should reflect real boundaries
Mirror Trees	`src/` and `tests/` with identical structures	Co-locate unit tests with source; separate tree only for integration/E2E
Config Explosion	10+ config files at root	Consolidate where possible, move to `config/`

反模式	症状	修复方案
杂乱的根目录	项目根目录有15个以上文件，零散脚本与配置文件混放	将所有非入口点和非必需配置的文件移至文件夹中
上帝文件夹	一个文件夹包含40个以上文件	按领域、功能或函数分组
幽灵文件夹	空文件夹，无文件且无明确用途	除非是有意设计的模式，否则删除
命名混乱	混合大小写： `UserProfile.tsx` , `order-utils.ts` , `payment_service.py`	为每种文件类型选择一种规范并强制执行
孤立文件	无任何导入或引用的文件	确认未使用后删除
过深嵌套	到达单个文件需要5层以上文件夹	扁平化结构——层级应反映真实的边界
镜像目录	`src/` 和 `tests/` 结构完全相同	单元测试与源代码放在一起；仅将集成/端到端测试放在单独目录中
配置爆炸	根目录有10个以上配置文件	尽可能合并，移至 `config/` 目录

When to Extract

何时拆分服务

Start with a modular monolith (single deployable, clean internal boundaries).

Extract to separate services only when:

Reason	Example
Scale	One part needs independent scaling
Team	Separate teams need independent deploy cycles
Technology	A component needs a different runtime/language

Don't extract for "cleanliness" — that adds operational complexity without benefit.

从模块化单体应用开始（单个可部署单元，内部边界清晰）。

仅在以下情况时提取为独立服务：

原因	示例
扩展需求	某部分需要独立扩展
团队分工	不同团队需要独立的部署周期
技术差异	某个组件需要不同的运行时/语言

不要为了“整洁”而拆分 —— 这会增加运维复杂度而无实际益处。

Observability Basics

可观测性基础

Structured Logging: JSON, not string concatenation. Include context (

{ userId, timestamp }

), not messages (

'User ' + userId + ' logged in'

Correlation IDs: Track requests across async operations.

Error Boundaries: Catch and report, don't swallow silently.

结构化日志： 使用JSON，而非字符串拼接。包含上下文信息（

{ userId, timestamp }

），而非简单消息（

'User ' + userId + ' logged in'

）。

关联ID： 跨异步操作跟踪请求。

错误边界： 捕获并报告错误，不要静默忽略。

Decision Records

决策记录

For significant architectural choices, document: Context (problem), Decision (what we chose), Alternatives (what else we considered), Consequences (trade-offs).

Location:

Documentation/decisions/

Template:

assets/decision-record-template.md

对于重大架构决策，需记录：上下文（问题）、决策（选择的方案）、备选方案（其他考虑的选项）、后果（权衡）。

位置：

Documentation/decisions/

模板：

assets/decision-record-template.md

Scaling Principles

扩展原则

Project Size	Focus On
Small	North Star, Red Flags
Growing	Add Testing Strategy, Observability
Team	Add Decision Records, Module Ownership

项目规模	关注重点
小型	核心目标、红色警示
成长中	测试策略、可观测性
团队级	决策记录、模块所有权

Red Flags

红色警示

Stop and reconsider when you see:

Smell	Problem	Fix
`shared/common/utils` dumping ground	Ownership unclear, grows forever	Move to owning module or create focused package
Cross-module direct imports	Tight coupling	Use APIs, events, or props
Direct database access across modules	Hidden dependencies	Build a read API or service
"Quick helper" in wrong module	Boundary violation	Move to correct owner
Framework magic hiding control flow	Hard to debug, hard to refactor	Make it explicit
Feature touching 5+ unrelated files	Poor separation	Refactor boundaries

当您看到以下情况时，请暂停并重新考虑：

坏味道	问题	修复方案
`shared/common/utils` 垃圾场	所有权不明确，无限膨胀	移至所属模块或创建聚焦的包
跨模块直接导入	紧耦合	使用API、事件或props
跨模块直接访问数据库	隐藏依赖	构建读取API或服务
“快速工具函数”放在错误的模块中	边界违反	移至正确的所属模块
框架魔法隐藏控制流	难以调试、难以重构	改为显式实现
功能修改涉及5个以上不相关文件	分离度差	重构边界

References

参考文档

```
references/module-boundaries.md
```
— Module structure, boundary rules, communication patterns
```
references/design-patterns.md
```
— Factory, Repository, Adapter, Strategy, Observer, etc.
```
references/migration-patterns.md
```
— Strangler Fig, Branch by Abstraction, Parallel Implementations
```
references/web.md
```
— Web (React/Node) project structure profile
```
references/unity.md
```
— Unity project structure profile
```
references/vrchat.md
```
— VRChat project structure profile (extends Unity)
```
references/blender.md
```
— Blender project structure profile
```
references/data-iac.md
```
— Data/IaC (AWS) project structure profile

```
references/module-boundaries.md
```
—— 模块结构、边界规则、通信模式
```
references/design-patterns.md
```
—— 工厂、仓库、适配器、策略、观察者等
```
references/migration-patterns.md
```
—— 绞杀者模式、抽象分支、并行实现
```
references/web.md
```
—— Web (React/Node)项目结构配置文件
```
references/unity.md
```
—— Unity项目结构配置文件
```
references/vrchat.md
```
—— VRChat项目结构配置文件（扩展Unity配置）
```
references/blender.md
```
—— Blender项目结构配置文件
```
references/data-iac.md
```
—— Data/IaC (AWS)项目结构配置文件

Assets

资源文件

```
assets/architecture-checklist.md
```
— Full architecture review checklist
```
assets/structure-evaluation-checklist.md
```
— Project structure evaluation checklist (universal + per-type)
```
assets/decision-record-template.md
```
— ADR template

```
assets/architecture-checklist.md
```
—— 完整架构审查清单
```
assets/structure-evaluation-checklist.md
```
—— 项目结构评估清单（通用+特定类型）
```
assets/decision-record-template.md
```
—— 架构决策记录模板

Scripts

脚本

```
scripts/analyze_dependencies.py
```
— Map circular dependencies and detect layer violations

```
scripts/analyze_dependencies.py
```
—— 映射循环依赖并检测层级违反