用途：对整体系统、单个模块或当前分支改动进行架构评估，对照明确的质量属性与设计原则，形成可追溯、按优先级排序、团队可执行的评估结论。评估流程只做评估与建议，不实现修复；落实建议需另开 incu-way-development 或 incu-way-bugs 工作项。
两种调用模式：独立模式（审计系统或设计）使用 assess/arch-{slug} 分支并向 develop 提 PR；嵌入其他流程时写入调用方当前分支/工作树，随该流程的 PR 一起提交，不单独建分支或 PR。
流程要点：开始前先检查 ~/.ways/config.yaml 黑名单，命中则询问是否例外或停止。Phase 0 只读调研，确认目标（整库、模块或 git diff develop...HEAD）、as-built 审计或 as-designed 评审，先读 docs/architecture/、README.md、PRD.md、ADR 等既有文档，梳理分解、依赖方向、边界、横切关注点、数据与集成、测试。Gate 1 提出评估范围与质量属性（可维护性、耦合与内聚、分层/边界、可扩展性、可测试性、安全姿态、可观测性、与文档一致性等），需用户确认后才继续。独立模式需先询问用当前检出分支还是独立 worktree，命令如 git switch -c assess/arch-{slug} 或 git worktree add .worktrees/assess-arch-{slug} -b assess/arch-{slug} origin/develop。Phase 2 撰写 ASSESSMENT.md，要求每条发现可追溯到文件行/模块/依赖边/配置键，按架构风险而非风格定严重度，记录与文档的冲突。Phase 3 可加 Mermaid 图并做 do-now/do-next/consider 优先级排序。Gate 2 等待用户评审；独立模式随后建议调用 incu-way-prepare-pr 提 PR，不自行推送或合并。限制：不编造结构与评级，不可验证项列入待确认；不实现修复；图无法渲染不得收尾；嵌入模式不另开 PR；独立模式不直接写 develop 或 main。