用途：把既有代码库整理成清晰、可追溯的文档，说明应用是什么、如何构建、各部分如何组合，以及面向用户时的功能行为。输出位于 docs/architecture/，必要时含 functional/domain 文档，作为其他 incu-way 流程 Phase 0 的上下文。
两种调用模式：作为 incu-way-init（brownfield 接入）的一部分，写入当前 init 分支/工作树，随 init PR 发布，不单独建分支或 PR；独立运行（刷新或记录某模块）时使用自己的分支 docs/{slug} → PR 到 develop。该流程不维护 .ways/state.json。
流程：先做仓库资格检查，查看 ~/.ways/config.yaml 黑名单，命中则询问是否例外继续或停止。Phase 0 只读调研与接收，确认范围（整仓或某模块）、深度（仅架构或架构+功能）、全新还是刷新，盘点语言/框架、入口点、模块分层、数据存储、外部集成、构建运行测试部署、横切关注点。Gate 1 提出文档地图清单，用户确认前不写文档。独立模式需先询问用当前检出分支还是单独 git worktree，未提交改动时先停下询问。Phase 2 按确认地图撰写，要求可追溯（指向文件:行、模块或配置键）、不臆造、冲突显式记录、简洁、刷新即对账。Phase 3 生成 Mermaid 图（上下文/容器、组件、关键序列、ERD），须通过 Mermaid 解析器验证。Gate 2 提交索引与待确认问题，等待用户审阅。独立模式 Phase 4 建议调用 incu-way-prepare-pr 推送并开 PR，不自行推送或创建 PR。
限制：Gate 1 确认前不得写文档；不可验证内容放入 Open questions；渲染失败的图不得收尾；被 incu-way-init 调用时不另开 PR；独立模式不得直接写 develop 或 main。具体命令与分支操作以资料为准。