architecture-optimization

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Architecture Optimization

架构优化

Optimize a working codebase on three axes at once — architecture, code quality, and performance — without breaking what works. This is an interactive, resumable journey of eight phases: the agent asks before every decision and records the outcome in your project's

docs/

folder, so you can stop after any phase and pick up later. It is for a system that ships and earns but has grown slow and tangled; the structure phases make the code safe and cheap to change, the performance phases make it measurably fast, and the closing phases keep it that way.

同时从架构、代码质量和性能三个维度优化可用代码库，且不会破坏现有可用功能。这是一个交互式、可续推进的八阶段流程：智能体在每个决策前都会询问用户，并将结果记录在项目的

docs/

文件夹中，您可在任意阶段暂停，之后继续推进。本流程适用于已上线并产生收益，但逐渐变得缓慢、混乱的系统；架构阶段让代码更安全、修改成本更低，性能阶段让代码可量化地提速，收尾阶段则维持优化后的状态。

Core Principle

核心原则

Measure before optimizing, pin before restructuring — the profiler and the safety net decide, not intuition. Premature optimization is the root of much evil not because optimization is bad, but because unmeasured optimization targets the wrong 97% of the code; and a restructure without pinned behavior is a gamble, not an improvement. This skill sequences the phases, asks the decision questions, and records every choice in

docs/

. The constituent skills carry the method — invoke them rather than improvising their frameworks.

**优化前先测量，重构前先固化——由分析器和安全网做决策，而非直觉。**过早优化是万恶之源，并非因为优化本身不好，而是未经测量的优化会针对错误的97%代码；而未固化行为的重构是赌博，而非改进。本技能按顺序编排各阶段，提出决策问题，并将每一项选择记录在docs/文件夹中。各子技能自带方法——请调用这些技能，而非自行套用其框架。

Journey Map

流程地图

Phase	Skill	Question it answers	Artifact
1	working-with-legacy-code	Is behavior pinned and performance measured, so every change is provable?	Creates docs/PERFORMANCE.md + docs/TECH-DEBT.md; extends docs/TESTING.md — GATE
2	clean-architecture	Do dependencies still point inward, or has the boundary drifted as the code grew?	Extends docs/ARCHITECTURE.md
3	software-design-philosophy	Are modules deep, or has the structure itself become the complexity?	Extends docs/TECH-DEBT.md
4	refactoring-patterns	Can we reshape the hot paths in named, behavior-preserving steps?	Extends docs/TECH-DEBT.md + docs/TESTING.md
5	system-design	What does the measured load say the bottleneck is, and what is the cheapest fix?	Extends docs/PERFORMANCE.md + docs/ARCHITECTURE.md
6	ddia-systems	Is the data layer the bottleneck — queries, indexes, isolation, derived data?	Extends docs/ARCHITECTURE.md + docs/PERFORMANCE.md
7	release-it	Does it stay fast and stable when a dependency is slow or down?	Creates-or-extends docs/RELIABILITY.md
8	pragmatic-programmer	What budgets and habits keep it fast and clean after we stop?	Extends docs/PERFORMANCE.md + docs/TECH-DEBT.md + docs/TESTING.md

阶段	技能	要解决的问题	产出物
1	working-with-legacy-code	是否已固化行为并测量性能，确保每一项变更都可验证？	创建docs/PERFORMANCE.md + docs/TECH-DEBT.md；扩展docs/TESTING.md —— 必经关卡
2	clean-architecture	依赖关系是否仍向内指向，还是随着代码增长出现边界偏移？	扩展docs/ARCHITECTURE.md
3	software-design-philosophy	模块是否具备深度，还是架构本身已成为复杂度来源？	扩展docs/TECH-DEBT.md
4	refactoring-patterns	能否通过可命名、保留行为的步骤重构关键路径？	扩展docs/TECH-DEBT.md + docs/TESTING.md
5	system-design	实测负载显示瓶颈在哪里，最便宜的修复方案是什么？	扩展docs/PERFORMANCE.md + docs/ARCHITECTURE.md
6	ddia-systems	数据层是否是瓶颈——查询、索引、隔离性、衍生数据？	扩展docs/ARCHITECTURE.md + docs/PERFORMANCE.md
7	release-it	当依赖项变慢或宕机时，系统能否保持快速稳定？	创建或扩展docs/RELIABILITY.md
8	pragmatic-programmer	我们停止优化后，哪些预算和习惯能维持代码的快速与整洁？	扩展docs/PERFORMANCE.md + docs/TECH-DEBT.md + docs/TESTING.md

Operating Rules

操作规则

Resume first. Before anything else, read
```
docs/ARCHITECTURE-OPTIMIZATION-PLAN.md
```
and every artifact in the Journey Map. If the tracker exists, summarize the journey state in 3-5 lines and ask which phase to enter. Done when the user has confirmed an entry point. A journey with a tracker is resumed, never restarted.
Intake on first run only. No tracker: run the Intake below, then create
```
docs/ARCHITECTURE-OPTIMIZATION-PLAN.md
```
with every phase statused
```
pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason
```
. Done when the tracker exists and the user has confirmed the phase plan.
Phase entry. Announce: what the phase does, the decision it forces, the artifact it produces, rough effort. Offer proceed / skip / defer — phases marked GATE may be deferred, never skipped. Mark the phase
```
in-progress
```
on proceed. Done when the user chose.
Skill invocation and fallback. Load the phase's skill and use it: each phase's Invoke line names the skill by slug — use that skill to run the phase. If it is not available, offer:
```
npx skills add wondelai/skills/<slug> --global
```
. If the user declines, run the phase from its Brief — the minimum viable method. State which mode you are in.
In-phase decisions. Ask every question under "Decide with the user" — with concrete options and your recommendation. Record the choice in the tracker's Key Decisions. A decision made silently is a defect.
Phase exit. Present the draft artifact content for sign-off before writing. On approval: write or extend the docs/ files, update the tracker (status, Key Decisions, Next Actions). Done when the files are written and the phase row shows
```
done
```
.
Artifact discipline. Read before writing; create a file only if missing, otherwise extend — add or update your sections, preserve everyone else's. Files are UPPERCASE in
```
docs/
```
. Every recommendation lands as a checkbox or a table row with owner and priority. See references/artifact-templates.md when creating a docs/ file for the first time — create it from the full skeleton (all section headings), then fill the sections your phase names.
Never optimize unmeasured, never restructure unpinned. Every change made to reduce a measured baseline cites that baseline and lands in the PERFORMANCE.md Optimization Ledger with before/after — one that doesn't move its number gets reverted, not kept. (Resilience and gating work — timeouts, breakers, bulkheads, pagination, CI gates — is judged by the Done-when of its own phase, not by a latency delta.) Structural changes touch only code pinned in the Safety Net Map, preserve behavior, and land in structure-only commits separate from behavior and optimization commits.

优先续推进。 首先读取
```
docs/ARCHITECTURE-OPTIMIZATION-PLAN.md
```
和流程地图中的所有产出物。若存在跟踪文件，用3-5行总结当前流程状态，并询问进入哪个阶段。用户确认入口点后完成此步骤。已有跟踪文件的流程需续推进，不得重启。
仅首次运行时收集信息。 无跟踪文件：执行下方的信息收集步骤，然后创建
```
docs/ARCHITECTURE-OPTIMIZATION-PLAN.md
```
，将每个阶段标记为
```
pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason
```
。跟踪文件创建完成且用户确认阶段计划后完成此步骤。
阶段进入。 告知：本阶段的作用、需做出的决策、产出的文档、大致工作量。提供继续/跳过/延期选项——标记为必经关卡的阶段可延期，但不得跳过。选择继续则将阶段标记为
```
in-progress
```
。用户做出选择后完成此步骤。
技能调用与备选方案。 加载当前阶段的技能并使用：每个阶段的调用行通过短名称指定技能——使用该技能推进阶段。若技能不可用，提供：
```
npx skills add wondelai/skills/<slug> --global
```
。若用户拒绝，使用该技能的简要说明推进阶段——即最小可行方法。说明当前使用的模式。
阶段内决策。 询问“与用户共同决策”下的所有问题——提供具体选项和推荐方案。将选择记录在跟踪文件的“关键决策”中。未明确做出的决策视为缺陷。
阶段退出。 在写入前展示文档草稿内容供用户确认。获批后：写入或扩展docs/文件夹中的文件，更新跟踪文件（状态、关键决策、下一步行动）。文件写入完成且阶段行显示
```
done
```
后完成此步骤。
文档规范。 先读后写；仅在文件不存在时创建，否则扩展——添加或更新您负责的章节，保留其他所有内容。docs/中的文件为大写。每条建议以复选框或带负责人和优先级的表格行呈现。首次创建docs/文件时，请参考references/artifact-templates.md——从完整框架（所有章节标题）创建，然后填充当前阶段指定的章节。
绝不优化未测量项，绝不重构未固化项。 每一项用于降低实测基准的变更都需引用该基准，并记录在PERFORMANCE.md的“优化台账”中，包含变更前后数据——未达到预期指标的变更需回滚，不得保留。（弹性和关卡工作——超时、断路器、隔离舱、分页、CI关卡——由自身阶段的完成标准判断，而非延迟增量。）架构变更仅触及“安全网地图”中已固化的代码，保留行为，并与行为变更和优化变更分开提交。

Intake

信息收集

Ask these before creating the tracker:

What does the system do, and what does "too slow" cost — lost users, SLA breaches, infra bills? (Frames which metric matters and how much effort the journey is worth.)
What is the evidence so far — APM traces, slow-query logs, p95 latencies, a cloud bill, or just complaints? (Feeds the Phase 1 baseline; complaints alone mean instrumentation comes first.)
Which flows or endpoints hurt most, and which modules implement them? (Picks the hot paths every phase works on.)
Do automated tests exist and run green? (Scopes the Phase 1 safety net — unpinned hot paths get pinned before anything touches them.)
What is the stack — language, framework, ORM, database, cache — and where does it run? (Gates Phases 5-6.)
What are the real load numbers — QPS average and peak, data volumes, growth rate? (Gates Phase 5 — sizing by numbers, not fear.)
How much of the journey do you want now? (Phases 1-4 make it safe and clean to change; 5-6 make it fast; 7-8 keep it that way.)

Skip heuristics: compress Phases 2-3 to an audit-only pass when the structure is sound and the pain is purely performance — record what the audit found either way and status the phase

done

with an "audit only, no changes" note; skip Phase 7 only when a prior journey's RELIABILITY.md Integration-Point Audit is verifiably current (check the file, don't assume). Never skip Phase 1 — an optimization without a baseline is a guess, and a restructure without a net is a gamble.

Then create

docs/ARCHITECTURE-OPTIMIZATION-PLAN.md

from the template and confirm the plan. Done when the tracker exists with every phase statused and the user has confirmed the plan.

创建跟踪文件前询问以下问题：

系统的功能是什么，“过慢”会造成什么损失——用户流失、SLA违约、基础设施账单增加？（确定关键指标，以及流程的投入价值。）
目前有哪些证据——APM跟踪、慢查询日志、p95延迟、云账单，还是仅用户反馈？（为阶段1的基准提供数据；仅用户反馈意味着首先需要部署监控工具。）
哪些流程或端点问题最严重，由哪些模块实现？（确定每个阶段需处理的关键路径。）
是否存在自动化测试且运行正常？（确定阶段1的安全网范围——未固化的关键路径在变更前需先固化。）
技术栈是什么——语言、框架、ORM、数据库、缓存——部署在哪里？（决定阶段5-6的可行性。）
实际负载数据是什么——平均和峰值QPS、数据量、增长率？（决定阶段5——基于数据而非预估进行扩容。）
您现在希望推进流程的哪部分？（阶段1-4让代码更安全、易修改；阶段5-6提升速度；阶段7-8维持优化状态。）

跳过规则：当架构合理，仅存在性能问题时，将阶段2-3压缩为仅审计流程——无论结果如何，记录审计发现，并将阶段标记为

done

，备注“仅审计，无变更”；仅当之前流程的RELIABILITY.md“集成点审计”可验证为最新时，才可跳过阶段7（需检查文件，不得假设）。不得跳过阶段1——无基准的优化是猜测，无安全网的重构是赌博。

然后从模板创建

docs/ARCHITECTURE-OPTIMIZATION-PLAN.md

并确认计划。跟踪文件创建完成且所有阶段已标记状态、用户确认计划后完成此步骤。

Phases

各阶段详情

Phases run in the listed order — each assumes the previous phase's artifact exists. Structure before speed is deliberate: Phases 2-4 make the hot paths safe and cheap to change, which is what makes the Phase 5-6 optimizations small diffs instead of surgery. Any phase can be entered, skipped, or deferred per the Operating Rules, but Phase 1 gates them all — as two independent nets: pinned behavior unlocks Phases 2-4, and a recorded baseline unlocks Phases 5-6, so structure work need not wait on a profile that takes weeks to gather. Phases 5 and 6 may be swapped when the Phase 1 profile shows the database dominating: fixing an N+1 or a missing index before adding a cache is the skill's own cheapest-first law. When running any phase from its Brief (constituent skill not installed), read references/methods.md first — it carries each phase's full method, checklists, formulas, and heuristics; the Brief is only the summary.

阶段按所列顺序运行——每个阶段都假设前一阶段的产出物已存在。先架构后性能是刻意设计的：阶段2-4让关键路径更安全、易修改，这使得阶段5-6的优化只需小幅度变更，而非大规模重构。根据操作规则，任何阶段都可进入、跳过或延期，但阶段1是所有阶段的必经关卡——分为两个独立的安全网：固化的行为解锁阶段2-4，记录的基准解锁阶段5-6，因此架构工作无需等待耗时数周的性能分析结果。当阶段1的分析显示数据库是主要瓶颈时，可交换阶段5和6的顺序：修复N+1查询或缺失索引比添加缓存更符合“成本优先”原则。当使用简要说明推进阶段（未安装对应子技能）时，先阅读references/methods.md——其中包含每个阶段的完整方法、检查清单、公式和启发式规则；简要说明仅为摘要。

Phase 1 — Pin it and measure it (working-with-legacy-code) — GATE

阶段1：固化行为并测量性能（working-with-legacy-code）—— 必经关卡

Purpose: Make every later change provable twice over — behavior pinned by tests, performance pinned by numbers. No phase touches unpinned code or optimizes an unmeasured path.

Brief (fallback): Two nets. Behavior: code without tests is legacy code — cover and modify, never edit and pray. Find the change points on the hot paths, break inline dependencies at the least-invasive seam (Parameterize Constructor with a production default; Extract and Override for one buried call), and write characterization tests that photograph actual behavior — assert something wrong, read the failure, pin the real value. Performance: profile before touching anything — the bottleneck is rarely where intuition points. Record p50/p95/p99 latency, throughput, and resource use per hot flow under realistic data volumes (dev-database timings lie), and work the USE method (Gregg) per resource: Utilization, Saturation, Errors for CPU, memory, disk, network, and connection pools. Set the budget each metric must meet, so "done" is a number, not a feeling.

Invoke: Use the

working-with-legacy-code

skill with the hot-path modules from intake. Ask for the seams and the smallest characterization-test set that pins current behavior of each flow to be optimized; then capture profiler or APM baselines for those flows.

Decide with the user: (1) Confirm the hot paths in scope — measured pain, not suspicion. (2) The budget per metric (e.g. checkout p95 < 500ms) and the tool of record (profiler, APM, load test) so before/after numbers stay comparable. (3) Bugs found while characterizing: pin the current behavior and ledger them, never silently fix — callers may depend on the quirk.

Artifact: Extend docs/TESTING.md

## Safety Net Map

and

## Characterization Backlog

; create docs/PERFORMANCE.md with

## Baselines & Budgets

## Load Reality

## Profile Findings

, and

## Optimization Ledger

; create-or-extend docs/TECH-DEBT.md

## Debt Ledger

and

## Sprout / Wrap Register

for bugs pinned as-is and untested hosts. Update the tracker.

Done when: every in-scope flow has pinned behavior (suite green) — which unlocks Phases 2-4 — and a recorded baseline with a budget, which unlocks Phases 5-6. Record the two separately; a profile still being gathered parks at

awaiting-evidence

with a Next Actions row rather than blocking the structure phases.

目标： 确保后续每一项变更都可双重验证——行为由测试固化，性能由数据固化。任何阶段都不得触碰未固化的代码，或优化未测量的路径。

简要说明（备选方案）： 两个安全网。行为方面：无测试的代码即为遗留代码——先覆盖测试再修改，绝不直接编辑。找到关键路径上的变更点，在侵入性最小的位置打破内联依赖（使用生产默认值参数化构造函数；对深层调用提取并覆盖），编写刻画测试记录实际行为——先断言错误结果，读取失败信息，再固化真实值。性能方面：变更前先分析——瓶颈很少出现在直觉判断的位置。记录真实数据量下每个关键流程的p50/p95/p99延迟、吞吐量和资源使用情况（开发数据库的时间数据不可信），并对每个资源使用USE方法（Gregg）：CPU、内存、磁盘、网络和连接池的利用率、饱和度、错误率。设定每个指标必须达到的预算，让“完成”有明确的数据标准，而非主观感受。

调用： 使用

working-with-legacy-code

技能，结合信息收集阶段确定的关键路径模块。询问打破依赖的位置，以及固化每个待优化流程当前行为所需的最小刻画测试集；然后捕获这些流程的分析器或APM基准数据。

与用户共同决策： (1) 确认范围内的关键路径——基于实测痛点，而非猜测。(2) 每个指标的预算（例如结账流程p95 < 500ms）和记录工具（分析器、APM、负载测试），确保变更前后数据具有可比性。(3) 刻画测试中发现的bug：固化当前行为并记录在台账中，不得静默修复——调用方可能依赖该异常行为。

产出物： 扩展docs/TESTING.md中的

## 安全网地图

和

## 刻画测试待办项

；创建docs/PERFORMANCE.md，包含

## 基准与预算

、

## 实际负载

、

## 分析结果

和

## 优化台账

；创建或扩展docs/TECH-DEBT.md中的

## 技术债务台账

和

## 问题记录

，用于记录固化的bug和未测试的模块。更新跟踪文件。

完成标准： 所有范围内的流程都已固化行为（测试套件运行正常）——解锁阶段2-4；且已记录带有预算的基准数据——解锁阶段5-6。分别记录这两项状态；若仍在收集分析数据，将阶段标记为

awaiting-evidence

并添加下一步行动，无需阻塞架构阶段。

Phase 2 — Re-draw the drifted boundaries (clean-architecture)

阶段2：修正偏移的边界（clean-architecture）

Purpose: Restore the Dependency Rule the codebase grew away from — mixed concerns are why changes feel risky and why the slow parts can't be optimized in isolation.

Brief (fallback): Source dependencies point inward: Frameworks → Interface Adapters → Use Cases → Entities; nothing inner names anything outer. In a grown codebase the drift is concrete: business logic importing the ORM, controllers computing domain rules, a vendor SDK called from everywhere. Map the actual dependency graph and list the violations; extract the hot-path business rules into framework-free use cases behind owned interfaces (Dependency Inversion) — this also enables Phases 5-6, because a boundary is where a cache or a queue can later be inserted without surgery. Draw full boundaries only at real volatility (DB, external services, delivery); collapse ceremony layers elsewhere — direction matters, not folder count.

Invoke: Use the

clean-architecture

skill with the module map and stack from intake. Ask for the dependency graph, every violation where business logic names the framework, ORM, or a vendor, and the extraction plan for the hot-path use cases — flagging which boundaries earn their cost.

Decide with the user: How far to push the boundary this pass — hot paths first, never a big-bang re-layering; which vendor gets wrapped behind an owned interface first; which violations get fixed now versus ledgered.

Artifact: Extend docs/ARCHITECTURE.md

## Layer Map & Dependency Rule

(violation | location | fix | status) and

## Decision Log

. Update the tracker.

Done when: the dependency graph is mapped, every violation is a tracked row, the hot-path business rules run in tests with no framework, and the suite is green.

目标： 恢复代码库逐渐偏离的依赖规则——关注点混合是变更风险高、慢代码无法独立优化的原因。

简要说明（备选方案）： 源码依赖向内指向：框架 → 接口适配器 → 用例 → 实体；内部模块不得引用外部模块。在成熟的代码库中，偏移是具体存在的：业务逻辑导入ORM、控制器计算领域规则、供应商SDK被随处调用。绘制实际的依赖图并列出违规项；将关键路径的业务逻辑提取到独立于框架的用例中，使用自有接口（依赖反转）——这也为阶段5-6提供支持，因为边界是后续插入缓存或队列无需重构的位置。仅在实际易变点（数据库、外部服务、交付层）绘制完整边界；其他位置简化层级——方向比文件夹数量更重要。

调用： 使用

clean-architecture

技能，结合信息收集阶段的模块图和技术栈。询问依赖图、所有业务逻辑引用框架/ORM/供应商的违规项，以及关键路径用例的提取方案——标记哪些边界值得投入成本。

与用户共同决策： 本次迭代推进边界修正的范围——优先处理关键路径，绝不进行大规模重构；优先为哪个供应商添加自有接口包装；哪些违规项现在修复，哪些记录在台账中。

产出物： 扩展docs/ARCHITECTURE.md中的

## 层级图与依赖规则

（违规项 | 位置 | 修复方案 | 状态）和

## 决策日志

。更新跟踪文件。

完成标准： 已绘制依赖图，所有违规项已记录为跟踪行，关键路径的业务逻辑可在无框架的测试中运行，且测试套件运行正常。

Phase 3 — Deepen the modules (software-design-philosophy)

阶段3：深化模块（software-design-philosophy）

Purpose: Cut the complexity tax — a grown codebase accretes shallow classes and leaked decisions, and every one of them slows the team down before it slows the code down.

Brief (fallback): Module depth = functionality ÷ interface complexity. Merge shallow pass-through classes that always travel together and share state; hide each design decision in exactly one place — information leakage (one decision reflected in many modules) is the top red flag; replace temporal decomposition (modules organized by order-of-execution) with modules organized by knowledge. Same-abstraction pass-throughs across layers signal a boundary that isn't earning its cost. This is the tactical→strategic flip: invest 10-20% now so every later phase touches fewer files. Consolidation also collapses call-chain ceremony on hot paths — but readability, not nanoseconds, is the reason.

Invoke: Use the

software-design-philosophy

skill with the modules mapped in Phase 2. Ask which classes are shallow, where one decision leaks across modules, and for a consolidation plan into deeper modules with smaller interfaces.

Decide with the user: Which consolidations happen now versus ledgered — guarding against over-merging genuinely unrelated concerns; the design conventions the team adopts going forward.

Artifact: Extend docs/TECH-DEBT.md

## Smell Inventory

(shallow-module and information-leakage entries with the consolidation applied) and

## Adopted Conventions

. Update the tracker.

Done when: each shallow-module cluster is consolidated or ledgered with a fix, every identified leaked decision is consolidated or a Smell Inventory row, and the suite is green.

目标： 降低复杂度成本——成熟的代码库会积累浅层次类和分散的决策，这些都会先拖慢团队效率，再拖慢代码运行速度。

简要说明（备选方案）： 模块深度 = 功能 ÷ 接口复杂度。合并总是一起使用且共享状态的浅层次透传类；将每个设计决策隐藏在唯一位置——信息泄露（一个决策体现在多个模块中）是最明显的危险信号；将按执行顺序组织的模块（时间分解）替换为按知识领域组织的模块。跨层级的同抽象透传信号表明该边界不值得投入成本。这是战术到战略的转变：现在投入10-20%的精力，让后续每个阶段只需修改更少的文件。合并还能减少关键路径上的调用链冗余——但可读性才是原因，而非微秒级的性能提升。

调用： 使用

software-design-philosophy

技能，结合阶段2绘制的模块图。询问哪些类是浅层次的、哪些决策存在信息泄露，以及合并为深度更大、接口更小的模块的方案。

与用户共同决策： 哪些合并现在执行，哪些记录在台账中——避免过度合并真正无关的关注点；团队后续采用的设计规范。

产出物： 扩展docs/TECH-DEBT.md中的

## 代码异味清单

（浅层次模块和信息泄露条目，记录已执行的合并）和

## 采用的规范

。更新跟踪文件。

完成标准： 每个浅层次模块集群已合并或记录修复方案，每个已识别的信息泄露已合并或记录在代码异味清单中，且测试套件运行正常。

Phase 4 — Refactor the hot paths (refactoring-patterns)

阶段4：重构关键路径（refactoring-patterns）

Purpose: Reshape the code you're about to optimize with named, behavior-preserving transformations — clean first, then fast, because you can't safely optimize what you can't safely change.

Brief (fallback): Each smell maps to a named refactoring: Extract Method for comment-sized blocks; Replace Nested Conditional with Guard Clauses; Replace Conditional with Polymorphism; Introduce Parameter Object; Replace Temp with Query. Workflow: tests green → one transformation → tests green → commit; a red test means revert, not debug. Fold in the clean-code disciplines as you pass: names that reveal intent, functions doing one thing at one level of abstraction, no null returns, errors carrying operation and state context. Preparatory Refactoring is the bridge to Phases 5-6: before each optimization, first make the change easy (restructure), then make the easy change (optimize) — in separate commits.

Invoke: Use the

refactoring-patterns

skill with the hot-path modules and the Phase 1 tests. Ask it to name each smell, cite the transformation, and apply one at a time with tests run between each.

Decide with the user: Scope — which smells this pass versus ledgered; which upcoming optimization warrants a Preparatory Refactoring at its insertion point first; whether the refactored modules join the CI gate list in TESTING.md.

Artifact: Extend docs/TECH-DEBT.md

## Smell Inventory

(smell | location | refactoring | status); extend docs/TESTING.md

## CI Gates

with any module promoted to the gate list. Update the tracker.

Done when: targeted smells show a named refactoring and

done

ticketed

status, tests are green, and structural commits contain no behavior changes.

目标： 使用可命名、保留行为的转换方式重构待优化的代码——先整洁，再快速，因为无法安全优化无法安全修改的代码。

简要说明（备选方案）： 每种代码异味对应一种命名重构：对注释级别的代码块提取方法；用卫语句替换嵌套条件；用多态替换条件；引入参数对象；用查询替换临时变量。工作流程：测试正常 → 一次转换 → 测试正常 → 提交；测试失败则回滚，而非调试。重构时融入整洁代码规范：揭示意图的命名、单一职责的函数、无空返回、携带操作和状态上下文的错误。预备重构是阶段5-6的桥梁：每次优化前，先让变更变得容易（重构），再执行简单的变更（优化）——分开发提交。

调用： 使用

refactoring-patterns

技能，结合关键路径模块和阶段1的测试。询问每种代码异味的名称、对应的重构方式，并逐个应用，每次应用后运行测试。

与用户共同决策： 范围——本次迭代处理哪些代码异味，哪些记录在台账中；哪些即将进行的优化需要先在插入点进行预备重构；重构后的模块是否加入TESTING.md中的CI关卡列表。

产出物： 扩展docs/TECH-DEBT.md中的

## 代码异味清单

（异味 | 位置 | 重构方式 | 状态）；扩展docs/TESTING.md中的

## CI关卡

，添加任何升级为关卡的模块。更新跟踪文件。

完成标准： 目标代码异味已标记对应的重构方式和

done

ticketed

状态，测试运行正常，且架构提交不包含行为变更。

Phase 5 — Attack the measured bottleneck (system-design)

阶段5：解决实测瓶颈（system-design）

Purpose: Spend optimization effort where the profile says the time goes, in cheapest-first order, sized by real numbers.

Brief (fallback): Amdahl's law caps every win: total speedup is bounded by the fraction of time the optimized part actually consumes — a 10× win on 5% of the request saves 4.5%. The profile, not the code review, picks the target. Back-of-envelope the load (QPS = daily-active-users × actions/day ÷ 86,400, peak 2-5× average) and confirm the gap against the budget. Then fix in order: the algorithm first (an O(n²) loop or chatty per-item I/O beats any infrastructure), vertical headroom, cache-aside with a TTL and explicit invalidation on read-heavy paths (measure the hit rate — a cold cache is pure overhead), a message queue to move slow work off the request path (Little's law: in-flight requests = arrival rate × latency, so cutting latency is also a capacity fix), then read replicas — and shard only with evidence. Re-measure after every change; keep what moves the number, revert what doesn't.

Invoke: Use the

system-design

skill with the Phase 1 profile and the load numbers from intake. Ask which component bottlenecks first, the cheapest ordered list of moves for the measured gap, and the machinery you explicitly do NOT need yet.

Decide with the user: Which moves ship now versus defer with the trigger number written down; the first workload, if any, to move behind a queue; the invalidation rule for each cached path — what event invalidates which key.

Artifact: Extend docs/PERFORMANCE.md

## Profile Findings

and

## Optimization Ledger

(change | before | after | verdict | date); extend docs/ARCHITECTURE.md

## Decision Log

(each adopt/defer with its trigger) and

## System Context

, which cites PERFORMANCE.md

## Load Reality

rather than repeating the numbers. Update the tracker.

Done when: the bottleneck is named from the profile, each move is applied with before/after in the ledger or deferred with a trigger, and no adopted move failed to beat its baseline.

目标： 按照分析结果，将优化投入放在耗时最多的地方，遵循成本优先原则，基于真实数据调整规模。

简要说明（备选方案）： Amdahl定律限制了所有优化的收益：总加速比受优化部分实际耗时占比的限制——对5%的请求路径实现10倍加速，仅能节省4.5%的时间。由分析结果而非代码评审选择优化目标。粗略计算负载（QPS = 日活跃用户数 × 每日操作数 ÷ 86400，峰值为平均的2-5倍），确认与预算的差距。然后按以下顺序修复：首先优化算法（O(n²)循环或逐项I/O比任何基础设施优化都有效），然后是垂直扩容，读多路径使用缓存（带TTL和显式失效策略，需测量命中率——冷缓存纯粹是额外开销），使用消息队列将慢操作移出请求路径（Little定律：在处理请求数 = 到达率 × 延迟，因此降低延迟也是容量优化），然后是读副本——仅在有证据时才进行分片。每次变更后重新测量；保留能提升指标的变更，回滚无效的变更。

调用： 使用

system-design

技能，结合阶段1的分析结果和信息收集阶段的负载数据。询问哪个组件首先成为瓶颈、针对实测差距的成本优先优化列表，以及明确不需要的基础设施。

与用户共同决策： 哪些优化现在上线，哪些延期并记录触发条件；哪些工作负载先移至队列后；每个缓存路径的失效规则——什么事件失效哪些键。

产出物： 扩展docs/PERFORMANCE.md中的

## 分析结果

和

## 优化台账

（变更 | 变更前 | 变更后 | 结论 | 日期）；扩展docs/ARCHITECTURE.md中的

## 决策日志

（每个采用/延期的优化及其触发条件）和

## 系统上下文

，引用PERFORMANCE.md中的

## 实际负载

而非重复数据。更新跟踪文件。

完成标准： 已根据分析结果确定瓶颈，每个优化已应用并在台账中记录变更前后数据，或已延期并记录触发条件，且所有采用的优化都达到了基准指标。

Phase 6 — Fix the data layer (ddia-systems)

阶段6：修复数据层（ddia-systems）

Purpose: The database is the usual suspect — most measured slowness is queries, and most correctness debt is isolation assumptions. Fix both by evidence.

Brief (fallback): Read the query plans, not the ORM code. The classics: N+1 queries (one per row — batch or join; ORMs generate these silently), missing indexes on real access paths (EXPLAIN the slow queries; index predicate and sort columns, but every index taxes writes), unbounded result sets (paginate every list), SELECT * over wide rows, and deep offset pagination (use keyset). Storage engines trade reads against writes (LSM write-throughput versus B-tree read-latency) — match the model to the access pattern before buying hardware. Correctness under concurrency: most databases default to read-committed or snapshot, not serializable — read-then-write paths get write skew; lock explicitly (

SELECT ... FOR UPDATE

) or use a serializable transaction where invariants demand it. A second read pattern (search, analytics, feeds) justifies derived data kept in sync by CDC — never dual writes; and replicas from Phase 5 force deliberate read-your-writes.

Invoke: Use the

ddia-systems

skill with the Phase 1 profile, the Phase 5 findings, and the database from intake. If no query-level source exists yet, enable one first (

pg_stat_statements

auto_explain

, slow-query log) — that is Phase 1 instrumentation deferred, not a reason to guess. Ask for a query-plan audit (N+1s, missing indexes, unbounded reads), the actual default isolation level and its anomalies on your paths, and a per-workload model and engine fit.

Decide with the user: Which indexes to add, weighing write cost; which paths get locks versus serializable transactions versus tolerated anomalies; whether any workload justifies a second datastore synced by CDC.

Artifact: Extend docs/ARCHITECTURE.md

## Data & Storage Decisions

and

## Decision Log

; extend docs/PERFORMANCE.md

## Profile Findings

and

## Optimization Ledger

with query before/afters. Update the tracker.

Done when: the slow queries are fixed with measured before/after, every list endpoint on the in-scope flows is paginated (the rest become Debt Ledger rows), the isolation level is documented with risky paths locked, and any derived data has a defined sync mechanism.

目标： 数据库通常是罪魁祸首——大多数实测慢问题源于查询，大多数正确性债务源于隔离性假设。基于证据修复这两方面问题。

简要说明（备选方案）： 查看查询计划，而非ORM代码。常见问题：N+1查询（每行一次查询——使用批量查询或关联查询；ORM会自动生成此类查询）、实际访问路径缺失索引（对慢查询执行EXPLAIN；为谓词和排序列创建索引，但每个索引都会增加写入成本）、无限制结果集（所有列表都分页）、SELECT *查询宽行、深度偏移分页（使用键集分页）。存储引擎在读写之间权衡（LSM引擎写入吞吐量高，B树引擎读取延迟低）——在购买硬件前，让存储模型匹配访问模式。并发下的正确性：大多数数据库默认隔离级别为读已提交或快照，而非可序列化——读-写路径会出现写倾斜；在不变量要求的情况下，显式加锁（

SELECT ... FOR UPDATE

）或使用可序列化事务。第二种读取模式（搜索、分析、信息流）需要通过CDC同步的衍生数据——绝不使用双写；阶段5的副本需要刻意处理“读自己写的数据”问题。

调用： 使用

ddia-systems

技能，结合阶段1的分析结果、阶段5的发现和信息收集阶段的数据库信息。若尚无查询级监控，先启用（

pg_stat_statements

、

auto_explain

、慢查询日志）——这是阶段1延迟部署的监控，而非猜测的理由。询问查询计划审计（N+1查询、缺失索引、无限制读取）、实际默认隔离级别及其在您的路径上的异常，以及每个工作负载的模型和引擎适配情况。

与用户共同决策： 添加哪些索引，权衡写入成本；哪些路径使用锁、可序列化事务，还是容忍异常；哪些工作负载需要通过CDC同步的第二个数据存储。

产出物： 扩展docs/ARCHITECTURE.md中的

## 数据与存储决策

和

## 决策日志

；扩展docs/PERFORMANCE.md中的

## 分析结果

和

## 优化台账

，记录查询的变更前后数据。更新跟踪文件。

完成标准： 慢查询已修复并记录变更前后数据，所有范围内流程的列表端点已分页（其余记录在技术债务台账中），隔离级别已记录，风险路径已加锁，任何衍生数据已定义同步机制。

Phase 7 — Keep it fast when things fail (release-it)

阶段7：故障时保持性能（release-it）

Purpose: A fast system that collapses under a slow dependency isn't fast — latency under failure is a performance property.

Brief (fallback): Integration points are the number-one killer, and a slow response is worse than none: one hanging dependency exhausts threads and pools with nothing in the logs. Non-negotiables: connect + read timeouts on every outbound call (a timeout is a latency budget); circuit breakers on critical dependencies (fail fast beats waiting); bulkheads so one slow dependency can't drain the shared pool; retry with exponential backoff and jitter (naive retries triple load exactly when the dependency is dying); steady-state cleanup for logs, temp data, and caches that grow forever. Wire RED metrics (rate, errors, duration) per endpoint and alert on symptoms (p95 over budget) — the Phase 1 budgets become production guardrails instead of a one-time snapshot.

Invoke: Use the

release-it

skill with the outbound dependencies from intake and the budgets from Phase 1. Ask for timeout values derived from the flow latency budgets, breaker and bulkhead placement, and the RED-metrics plus symptom-alert design.

Decide with the user: Timeout and breaker thresholds per dependency, tied to the flow budget; which dependencies get dedicated pools; how each core flow degrades when a non-critical dependency is down.

Artifact: Create-or-extend docs/RELIABILITY.md

## Integration-Point Audit

## Query & Resource Findings

, and

## Health Checks & Metrics

. Update the tracker.

Done when: every outbound call on the in-scope flows has a timeout inside its flow's budget (calls outside them become Debt Ledger rows), critical dependencies have breakers and bulkheads, unbounded result sets and blocked threads are recorded in

## Query & Resource Findings

, and RED metrics with symptom alerts guard the Phase 1 budgets in production.

目标： 依赖项变慢就崩溃的系统不算真正快速——故障下的延迟也是性能属性。

简要说明（备选方案）： 集成点是头号杀手，慢响应比无响应更糟：一个挂起的依赖项会耗尽线程和池，且日志中无记录。必备措施：每个 outbound 调用设置连接+读取超时（超时即延迟预算）；关键依赖项使用断路器（快速失败优于等待）；使用隔离舱，避免一个慢依赖项耗尽共享池；使用指数退避和抖动重试（ naive 重试会在依赖项故障时将负载增加三倍）；定期清理无限增长的日志、临时数据和缓存。为每个端点配置RED指标（速率、错误、持续时间），并针对症状设置告警（p95超过预算）——阶段1的预算成为生产环境的防护栏，而非一次性快照。

调用： 使用

release-it

技能，结合信息收集阶段的 outbound 依赖项和阶段1的预算。询问基于流程延迟预算得出的超时值、断路器和隔离舱的部署位置，以及RED指标+症状告警的设计。

与用户共同决策： 每个依赖项的超时和断路器阈值，与流程预算绑定；哪些依赖项使用专用池；非关键依赖项宕机时，每个核心流程如何降级。

产出物： 创建或扩展docs/RELIABILITY.md中的

## 集成点审计

（依赖项 | 超时 | 断路器 | 隔离舱 | 重试策略 | 状态）、

## 查询与资源发现

和

## 健康检查与指标

。更新跟踪文件。

完成标准： 所有范围内流程的 outbound 调用都设置了在流程预算内的超时（其余记录在技术债务台账中），关键依赖项已配置断路器和隔离舱，无限制结果集和阻塞线程已记录在

## 查询与资源发现

中，RED指标和症状告警已在生产环境中监控阶段1的预算。

Phase 8 — Lock in budgets and habits (pragmatic-programmer)

阶段8：锁定预算与习惯（pragmatic-programmer）

Purpose: Make the gains permanent — regressions arrive one innocent commit at a time unless a gate catches them.

Brief (fallback): Turn each Phase 1 budget into a CI gate: perf tests or query-count assertions on the hot paths, where a p95 budget breach fails the build like a failing test. DRY is about knowledge: the same rule computed in two places will drift — and the same query issued from two layers is both a bug farm and a performance tax. Broken Window Theory: the first unreviewed slow query or skipped index gets fixed or ticketed immediately, never left as ambient decay. Reversibility: vendors and infrastructure behind owned interfaces, so the next optimization — swapping the cache, changing the queue — stays a week's work instead of a rewrite. Set the debt budget per iteration and write the conventions down; the ledger, not memory, carries what was deferred.

Invoke: Use the

pragmatic-programmer

skill across the touched modules. Ask for duplicated-knowledge hits (including duplicated queries and rules), untracked TODOs and broken windows, and a CI-gate design for the performance budgets.

Decide with the user: Which budgets become blocking CI gates versus dashboard alerts; the debt budget per iteration; the broken-windows policy — what gets fixed now versus ticketed.

Artifact: Extend docs/PERFORMANCE.md

## Baselines & Budgets

(mark each budget's gate); extend docs/TECH-DEBT.md

## Debt Budget & Broken-Windows Policy

and

## Adopted Conventions

; extend docs/TESTING.md

## CI Gates

. Update the tracker.

Done when: each hot-path budget is a CI gate or an owned alert, duplicated knowledge is fixed or ledgered, and the conventions are written down.

目标： 让优化成果永久保持——除非有关卡拦截，否则回归会通过一次次看似无害的提交出现。

简要说明（备选方案）： 将每个阶段1的预算转换为CI关卡：对关键路径执行性能测试或查询计数断言，p95预算超标则构建失败，如同测试失败一样。DRY原则关乎知识：同一规则在两个地方计算会出现偏差——同一查询在两个层级执行既是bug来源，也是性能成本。破窗理论：第一个未审核的慢查询或遗漏的索引需立即修复或记录工单，绝不能放任其恶化。可逆性：将供应商和基础设施封装在自有接口后，下一次优化——更换缓存、修改队列——只需一周工作量，而非重构。为每个迭代设定技术债务预算，并将规范写入文档；由台账而非记忆记录延期的事项。

调用： 使用

pragmatic-programmer

技能，覆盖所有修改过的模块。询问重复知识（包括重复查询和规则）、未跟踪的TODO和破窗问题，以及性能预算的CI关卡设计。

与用户共同决策： 哪些预算成为阻塞性CI关卡，哪些成为仪表盘告警；每个迭代的技术债务预算；破窗政策——哪些问题现在修复，哪些记录工单。

产出物： 扩展docs/PERFORMANCE.md中的

## 基准与预算

（标记每个预算的关卡类型）；扩展docs/TECH-DEBT.md中的

## 技术债务预算与破窗政策

和

## 采用的规范

；扩展docs/TESTING.md中的

## CI关卡

。更新跟踪文件。

完成标准： 每个关键路径的预算已设置为CI关卡或自有告警，重复知识已修复或记录在台账中，规范已写入文档。

Optional Phases

可选阶段

Skill	Add when	Artifact
clean-code	readability is poor beyond the hot paths — the whole codebase needs the naming, function, and error-handling pass	Extends docs/TECH-DEBT.md `## Smell Inventory` , `## Adopted Conventions`
domain-driven-design	boundaries keep fighting the business language — modules split where the domain doesn't	Extends docs/ARCHITECTURE.md `## Bounded Contexts & Context Map` , `## Domain Glossary (Ubiquitous Language)`
high-perf-browser	the measured slowness is in the browser — page load, LCP, blocking resources — not the backend	Extends docs/METRICS.md `## Baselines & Targets` , docs/WEBSITE.md `## Audit Findings`
team-topologies	more than one team owns the system, so module boundaries must align with team boundaries (Conway)	Extends docs/OPERATIONS.md `## Team Structure`

Optional phases follow the same operating rules — load and use each listed skill exactly as a core phase would; insert where the Add-when condition first becomes true. They carry no inline Brief: standalone, run clean-code as a naming, function-size, and error-handling pass, domain-driven-design as a ubiquitous-language and bounded-context map, high-perf-browser as a Core Web Vitals audit (LCP, INP, CLS), and team-topologies as a cognitive-load and team-boundary review — or install the named skill for its full framework.

技能	添加时机	产出物
clean-code	关键路径外的可读性极差——整个代码库需要进行命名、函数和错误处理优化	扩展docs/TECH-DEBT.md中的 `## 代码异味清单` 、 `## 采用的规范`
domain-driven-design	边界与业务语言始终冲突——模块划分不符合领域逻辑	扩展docs/ARCHITECTURE.md中的 `## 限界上下文与上下文映射` 、 `## 领域术语表（通用语言）`
high-perf-browser	实测慢问题出现在浏览器中——页面加载、LCP、阻塞资源——而非后端	扩展docs/METRICS.md中的 `## 基准与目标` 、docs/WEBSITE.md中的 `## 审计发现`
team-topologies	多个团队负责该系统，因此模块边界需与团队边界对齐（康威定律）	扩展docs/OPERATIONS.md中的 `## 团队结构`

可选阶段遵循相同的操作规则——完全按照核心阶段的方式加载和使用列出的技能；在“添加时机”条件首次满足时插入。这些阶段无内置简要说明：独立运行时，clean-code为命名、函数大小和错误处理优化，domain-driven-design为通用语言和限界上下文映射，high-perf-browser为核心Web指标审计（LCP、INP、CLS），team-topologies为认知负载和团队边界评审——或安装对应技能使用完整框架。

Common Mistakes

常见错误

Mistake	Fix
Optimizing where intuition points instead of where the profiler does	Profile first (Phase 1); Amdahl's law caps any win by the fraction of time that code actually consumes.
Rewriting for speed without a safety net	Pin behavior with characterization tests first (working-with-legacy-code); a fast wrong answer is still wrong.
Keeping an optimization that didn't move the number	Every change gets before/after in the Optimization Ledger; revert what doesn't beat its baseline — complexity without payoff is pure debt.
Reaching for infrastructure before fixing the algorithm	An O(n²) loop or an N+1 query beats any cache; fix the code, then size the machinery (system-design).
Caching without an invalidation rule	Stale-data bugs cost more than the latency saved; every cached path names what event invalidates which key.
Trusting the ORM to write good SQL	EXPLAIN the slow queries (ddia-systems); N+1s and missing indexes hide behind innocent-looking code.
Calling it fast with no timeout on outbound calls	Latency under failure is a performance property (release-it); one hanging dependency erases every optimization.

错误	修复方案
凭直觉而非分析结果选择优化点	先进行性能分析（阶段1）；Amdahl定律限制了任何优化的收益，取决于该代码实际耗时占比。
无安全网就为提速重写代码	先用刻画测试固化行为（working-with-legacy-code）；快速但错误的结果仍然是错误的。
保留未提升指标的优化	每个变更都需在优化台账中记录变更前后数据；回滚未达到基准指标的变更——无收益的复杂度纯粹是技术债务。
未修复算法就寻求基础设施优化	O(n²)循环或N+1查询比任何缓存都影响性能；先修复代码，再调整基础设施规模（system-design）。
缓存但未设置失效规则	stale数据bug的成本超过延迟节省的收益；每个缓存路径都需明确什么事件失效哪些键。
信任ORM能生成优质SQL	对慢查询执行EXPLAIN（ddia-systems）；N+1查询和缺失索引隐藏在看似无害的代码背后。
outbound调用未设置超时就认为系统快速	故障下的延迟是性能属性（release-it）；一个挂起的依赖项会抵消所有优化成果。

Completing the Journey

流程完成

Match the dose to the pain: a slow-endpoint complaint may need only Phases 1, 5, and 6 — baseline, bottleneck, queries — a few days that pay immediately; a codebase where every change is slow and risky wants the structure phases first, because clean boundaries are what make the optimizations small. Either way the ledger keeps score: kept changes beat their baselines, everything else was reverted.

Exit checklist — every box tied to an artifact:

Every phase in

docs/ARCHITECTURE-OPTIMIZATION-PLAN.md

done

deferred: reason

, or

skipped: reason

Every hot flow has a baseline, a budget, and a current measurement inside it (PERFORMANCE.md Baselines & Budgets).
Every kept optimization shows measured before/after; nothing kept failed its baseline (PERFORMANCE.md Optimization Ledger).
Dependency Rule violations on the hot paths are closed or tracked rows (ARCHITECTURE.md Layer Map).
Slow queries are fixed by plan, lists are paginated, the isolation level is documented, and risky paths are locked (ARCHITECTURE.md Data & Storage Decisions).
Every outbound call has a timeout and the budgets are guarded by RED metrics and alerts — or CI gates (RELIABILITY.md, TESTING.md CI Gates).

Close the tracker: remaining Next Actions carried into the PERFORMANCE.md ledger and TECH-DEBT.md so nothing is lost. Then route forward: when the pain is fear of change rather than speed, continue with the

remove-technical-debt

skill; when a fresh untested prototype needs the full production pass,

improve-code-quality

; when the next system deserves this structure from day one,

design-code-architecture

根据痛点调整流程范围：仅存在慢端点问题时，可能只需阶段1、5、6——基准、瓶颈、查询——几天时间即可获得即时收益；若代码库每次变更都慢且风险高，优先推进架构阶段，因为清晰的边界让优化只需小幅度变更。无论哪种情况，台账都会记录成果：保留的变更都达到了基准指标，其余都已回滚。

退出检查清单——每个条目都关联产出物：

docs/ARCHITECTURE-OPTIMIZATION-PLAN.md

中的每个阶段都标记为

done

、

deferred: reason

或

skipped: reason

。

每个关键流程都有基准、预算，且当前测量值符合预算（PERFORMANCE.md的基准与预算）。
每个保留的优化都记录了变更前后数据；无未达到基准指标的优化被保留（PERFORMANCE.md的优化台账）。
关键路径上的依赖规则违规项已关闭或记录为跟踪行（ARCHITECTURE.md的层级图）。
慢查询已通过查询计划修复，列表已分页，隔离级别已记录，风险路径已加锁（ARCHITECTURE.md的数据与存储决策）。
每个outbound调用都设置了超时，预算由RED指标和告警——或CI关卡——监控（RELIABILITY.md、TESTING.md的CI关卡）。

关闭跟踪文件：剩余的下一步行动转移到PERFORMANCE.md的台账和TECH-DEBT.md中，确保无遗漏。然后引导后续操作：若痛点是害怕变更而非速度，继续使用

remove-technical-debt

技能；若未测试的原型需要完整的生产级优化，使用

improve-code-quality

；若新项目从一开始就需要此架构，使用

design-code-architecture

。