用途
fmway-arch 用于评估软件架构：对象可以是整个系统、某个模块，也可以是当前分支相对 develop 的变更（git diff develop...HEAD）。评估依据是明确的质量属性和设计原则，目标是产出一份可追溯、按优先级排序、团队可以据此行动的架构评估。
评估既可以针对已实现的代码（审计既有构建），也可以针对尚未实现的设计（评审计划、PRD 或方案）。
主要能力
- 以关口（gate）引导的评估流程，必须经用户确认范围与标准后才产出评估结果。
- 只读调研，覆盖：分解结构（分层、端口与适配器、按功能划分目录、微服务）、依赖方向与循环、耦合热点、领域逻辑与基础设施/框架代码之间的边界及泄漏、横切关注点（认证、配置、日志与可观测性、错误处理、事务）、数据与外部集成、测试覆盖层次与形式。
- 产出 docs/assessments/arch/{slug}/ASSESSMENT.md，内容包括：范围与标准、执行摘要、按质量属性的评级表（含证据）、优势、发现表（含严重程度与建议）、技术债登记、待确认问题；必要时附 Mermaid 组件/依赖图与目标状态图，以及按“现在做 / 之后做 / 考虑”排序的建议。
- 每条发现都必须可追溯到文件与行号、模块、依赖边或配置项；无法核实的内容归入待确认问题，不得臆断评级。
- 严重程度反映架构风险（影响范围、引发缺陷的概率、后期修改成本），而非风格偏好。
使用方式
流程分阶段推进：
- 第 0 阶段（范围与调研）：只读，确认评估对象、是审计已构建代码还是评审设计，先阅读既有架构文档，并做结构调研。
- 关口 1：提出拟评估的范围与质量属性清单（可维护性/模块化、耦合与内聚、层次与边界完整性、可扩展性与性能、可测试性、结构性安全、可观测性与可运维性、与文档架构的一致性等），等待用户确认后继续。
- 隔离设置（仅自主模式）：询问用户是在当前检出中新建分支，还是创建独立的 git worktree；未提交的改动需先停下询问。
- 选项 A（当前检出新建分支）：git switch develop && git pull --ff-only && git switch -c assess/arch-{slug}
- 选项 B（独立 worktree，仅放在 .worktrees/ 下）：git fetch origin develop && mkdir -p .worktrees && git worktree add .worktrees/assess-arch-{slug} -b assess/arch-{slug} origin/develop
- 第 2 阶段：撰写 ASSESSMENT.md（评级需附证据，不臆测，不实施修复，冲突需明确记录）。
- 第 3 阶段：按需绘制图表，并用 Mermaid 解析器验证；给出按优先级排序的建议。
- 关口 2：交付路径、执行摘要、主要发现与待确认问题，等待用户评审。
- 第 4 阶段（仅自主模式）：建议调用 fmway-pr 推送 assess/arch-{slug} 并开 PR，PR 标题形如 assess(arch): {objetivo}，正文包含范围、摘要、建议与待确认问题；分享 PR 链接后停下，未经用户批准不合并。
两种调用模式：
- 自主模式：审计系统或设计，使用独立分支 assess/arch-{slug}，提 PR 到 develop。
- 嵌入其他流程：写入调用方的分支或 worktree，评估随该流程的 PR 一起提交，不单独建分支或 PR（例如 fmway-dev 在其关口 2 评审规划中的设计、fmway-docs 在写文档时指出结构风险、fmway-init 评估遗留代码库）。
适用场景
- 对既有代码库或某个模块做架构审计。
- 评审尚未实现的设计方案或 PRD。
- 评估当前分支变更对架构质量的影响。
- 作为其他开发、文档或初始化流程中的架构评审环节。
限制
- 只做评估与建议，不实施修复；落实建议需要另建 fmway-dev 或 fmway-bugs 工作项。
- 不维护 .ways/state.json（与 fmway-docs 类似）。
- 在关口 1 确认范围与标准前不得产出评估结果。
- 无法验证的结构、意图或评级不得臆造，只能列入“待确认问题 / 需核实”。
- 严重程度不得依据风格偏好设定，须反映架构风险。
- 渲染失败的 Mermaid 图不得交付。
- 嵌入模式不得另开 PR；自主模式不得直接写入 develop 或 main。
- 安全方面的深入检查不在本流程范围内（文中提到交由 fmway-security）。
暂未提供
工具的具体技术实现、支持的运行环境与依赖、安装方式、价格与许可信息、性能指标等，资料中暂未提供。