描述受众真正需要理解的内容。Archify 会推荐一个有边界的视觉配方，同时给出证据清单、禁用条件和可复制提示词。
写清场景，不要只写图表类型。系统事实越具体，推荐越可靠。
每个配方只回答一个技术问题。清晰的边界让图更易读、可评审，也不会掩盖证据缺口。
这些配方直接来自当前构建的 CLI 源码。通过源码和成品链接，可以检查每条推荐的具体含义。
系统里有什么、归谁负责、彼此如何连接？
用一张有边界的图展示核心组件、外部依赖、主路径和信任边界。
分析这个仓库，然后用 Archify 生成高层系统架构图。展示 8–12 个核心运行时组件、一条主要请求或数据路径、外部依赖、归属或信任边界；支持性细节放进卡片，不要继续堆连线。
每个工作负载运行在哪里，哪些连接跨越了边界？
围绕 Region、网络、集群、工作负载、存储和跨边界机制组织部署图。
用 Archify 绘制生产部署拓扑。按区域、网络、集群和负责人分组，展示工作负载与有状态服务，并标注每一种跨边界机制。不要编造部署事实，不确定的区域要明确标出。如果用户需要失败即阻断的部署评审，先征得确认，再把 meta.engineering_profile 设为 deployment-ownership；否则不要启用工程画像。
智能体如何规划、获批、执行、恢复并汇报？
用泳道表达策略门、工具执行、异常恢复、证据和最终回复。
用 Archify 工作流模式解释这段智能体工具调用。把用户界面、Agent Runtime、策略边界、异常处理、工具执行和可观测性分成泳道；突出成功主路径，并明确展示审批、重试、阻塞和证据路径。
一次变更如何安全地从提交走到生产？
展示构建、检查、环境、审批、冒烟、回滚和负责人泳道。
用 Archify 工作流模式绘制从代码提交到生产发布的流程。拆分开发者、CI、审批、环境和异常泳道；标出阻断检查、冒烟测试、负责人和回滚路径，并保留一条一眼可见的成功主路径。
响应者如何发现、分诊、缓解、验证并升级？
把信号、响应者、缓解动作、沟通和恢复证据拆成可执行流程。
用 Archify 工作流模式把事故处置预案画成响应者泳道。展示发现、分诊、缓解、升级、沟通、回滚和恢复验证；把决策门与操作分开，并让缺失的负责人清晰可见。
谁调用谁、顺序如何、最终返回什么？
按时间展示鉴权、缓存回退、持久化、返回流量和异步追踪。
用 Archify 时序模式展示从调用方到最终响应的完整请求。包含鉴权、缓存命中或未命中、持久化回退、返回消息，以及异步 Trace 或事件上报；消息标签保持简短，顺序必须明确。
初始请求返回之后，后台还会发生什么？
按时间展示入队、确认、后台处理、回调、重试、超时和最终一致。
用 Archify 时序模式解释这段异步往返链路。展示初始确认、入队或调度、后台处理、回调或轮询、重试与超时，以及调用方何时能观察到最终一致结果。
数据从哪里来、如何变化、最终被谁消费？
从来源经过同意、转换、敏感存储、数仓直到消费者的治理路径。
用 Archify 数据流模式梳理这段数据血缘。为每个数据资产和转换命名，展示用户同意或数据分类边界，区分流式与批处理路径，并标明存储和下游消费者；所有数据流都必须有标签。
哪些事件经过哪些 Topic、处理器、消费者组和失败路径？
展示生产者、Topic、有序处理器、消费者组、状态、重放和 DLQ。
用 Archify 数据流模式绘制这段事件流拓扑。命名生产者、事件、Topic、有序处理器、消费者组、状态存储、重放路径和 DLQ；只有在证据充分时才标注归属和投递语义。
有哪些状态、什么事件触发流转、最终如何结束？
展示执行、等待、重试、取消、失败以及明确终态的状态模型。
用 Archify 生命周期模式建模这个对象。分开主进度、等待或中断状态和终态；用事件标注转换，并在真实存在时展示重试、取消、超时、成功和失败，不能隐藏任何结束方式。
一次发布当前处于什么状态，下一步可能发生什么？
覆盖排队、构建、验证、审批、晋级、回滚和终态的部署状态模型。
用 Archify 生命周期模式建模部署对象。展示排队、构建、验证、等待审批、晋级、回滚以及所有终态，并标注允许每次状态转换的事件和守卫条件。
现有图为什么仍然溢出、重叠或连线穿过节点，应该先修什么？
保留现有图表模式，依据验证诊断、途经点语义和实测桌面视口预算修复布局。
用 Archify 修复这张现有图，保留图表类型、拓扑、有意义的标签和表现设置。遵循 references/authoring-contract.md 的顺序：(1) schema 错误及缺失或无效的 meta.quality_profile；(2) 节点重叠或越界；(3) 连线穿过节点及端点方向错误；(4) 交叉、含混的共享通道、贴边走线、过度绕行和转弯节奏；(5) 标签与节点、标签与标签、标签与连线的间距。每次修改后运行 validate，依据 diagnostics[] 的 code、subject、evidence 和 supportedFixes，每次只应用一项有诊断依据的几何控制。当前 schema 支持 via 时，它是按顺序排列的绝对 SVG [x, y] 中间点数组：路径为 [start, ...via, end]，起终点由节点锚点提供。显式 via 会覆盖自动路由，不是偏移量，也不会请求自动绕障。修复正交走线时，相邻点应共享 x 或 y，首尾线段应遵守 fromSide/toSide；只使用当前模式支持的控制字段。视口预算遵循 references/delivery-contract.md：检查 1440×900、1600×1000、1920×1080 和 2048×1320，要求 document.documentElement.scrollWidth <= window.innerWidth。优先满足 document.documentElement.scrollHeight <= window.innerHeight；如果 browser-check 明确确认 Reader 已达到投影文字下限并接受可读的页面纵向滚动，则保留该滚动。预算覆盖整页，包括标题、主图和必要卡片。其他溢出先通过移除冗余内容或压缩间距修复，不得靠隐藏溢出、裁切、内部滚动区、拉伸 SVG 或缩小字体强行通过。让 finalize 执行必需的浏览器证据；只在用户要求或 delivery contract 规定的升级条件下进行感知视觉审阅。