@stacksjs/defaults 0.75.361 → 0.75.366

package/ai/skills/stacks-technical-diagrams/recipes/scenarios.mjs

@@ -1,10 +1,10 @@
 const RAW_RECIPES = [
   {
     id: 'system-overview', type: 'architecture', proof: 'web-app',
-    presentation: { preset: 'classic', motion: 'static', views: 'optional' },
+    presentation: { preset: 'classic', motion: 'static' },
     start: {
-      en: { descriptionPrompt: 'Use the technical diagrams skill to turn this plain-language system description into a high-level architecture diagram: [describe the users, core components, primary path, external dependencies, and boundaries]. No repository is required. Ask only for missing facts that would materially change the diagram, mark any remaining unknowns instead of inventing them, and keep one obvious primary path across 8-12 core components.' },
-      zh: { descriptionPrompt: '用技术图表技能把下面这段自然语言系统描述画成高层架构图：[在这里描述用户、核心组件、主要路径、外部依赖和边界]。不需要代码库。只追问会实质影响图的缺失信息，其余不确定内容要标明而不是编造；保留 8-12 个核心组件和一条一眼可见的主路径。' },
+      en: { descriptionPrompt: 'Use Archify to turn this plain-language system description into a high-level architecture diagram: [describe the users, core components, primary path, external dependencies, and boundaries]. No repository is required. Ask only for missing facts that would materially change the diagram, mark any remaining unknowns instead of inventing them, and keep one obvious primary path across 8–12 core components.' },
+      zh: { descriptionPrompt: '用 Archify 把下面这段自然语言系统描述画成高层架构图：[在这里描述用户、核心组件、主要路径、外部依赖和边界]。不需要代码库。只追问会实质影响图的缺失信息，其余不确定内容要标明而不是编造；保留 8–12 个核心组件和一条一眼可见的主路径。' },
     },
     signals: [['system overview', 12], ['architecture', 10], ['components', 6], ['services', 4], ['repository', 5], ['trust boundary', 8], ['架构', 10], ['系统总览', 12], ['组件', 6], ['服务', 4], ['仓库', 5], ['信任边界', 8]],
     en: {
@@ -12,21 +12,21 @@ const RAW_RECIPES = [
       summary: 'A bounded map of core components, external dependencies, primary paths, and trust boundaries.',
       useWhen: 'Onboarding, design reviews, repository orientation, or explaining a service landscape.',
       avoidWhen: 'The audience needs exact call order, state transitions, or row-level data lineage.',
-      include: ['8-12 core components', 'one primary path', 'external dependencies', 'trust boundaries'],
-      prompt: 'Analyze this repository, then use the technical diagrams skill to create a high-level architecture diagram. Show 8-12 core runtime components, one primary request or data path, external dependencies, ownership or trust boundaries, and put supporting detail in cards instead of adding more edges.',
+      include: ['8–12 core components', 'one primary path', 'external dependencies', 'trust boundaries'],
+      prompt: 'Analyze this repository, then use Archify to create a high-level architecture diagram. Show 8–12 core runtime components, one primary request or data path, external dependencies, ownership or trust boundaries, and put supporting detail in cards instead of adding more edges.',
     },
     zh: {
       title: '系统总览', question: '系统里有什么、归谁负责、彼此如何连接？',
       summary: '用一张有边界的图展示核心组件、外部依赖、主路径和信任边界。',
       useWhen: '适合新人上手、方案评审、仓库梳理和服务全景说明。',
       avoidWhen: '如果重点是精确调用顺序、状态流转或字段级血缘，请换其他配方。',
-      include: ['8-12 个核心组件', '一条主路径', '外部依赖', '归属或信任边界'],
-      prompt: '分析这个仓库，然后用技术图表技能生成高层系统架构图。展示 8-12 个核心运行时组件、一条主要请求或数据路径、外部依赖、归属或信任边界；支持性细节放进卡片，不要继续堆连线。',
+      include: ['8–12 个核心组件', '一条主路径', '外部依赖', '归属或信任边界'],
+      prompt: '分析这个仓库，然后用 Archify 生成高层系统架构图。展示 8–12 个核心运行时组件、一条主要请求或数据路径、外部依赖、归属或信任边界；支持性细节放进卡片，不要继续堆连线。',
     },
   },
   {
     id: 'deployment-ownership', type: 'architecture', proof: 'deployment-ownership',
-    presentation: { preset: 'blueprint', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'blueprint', motion: 'trace' },
     signals: [['deployment topology', 14], ['region', 7], ['vpc', 9], ['cluster', 6], ['availability zone', 8], ['ownership', 7], ['cloud deployment', 12], ['部署拓扑', 14], ['区域', 6], ['集群', 6], ['可用区', 8], ['资源归属', 9], ['跨区', 8]],
     en: {
       title: 'Deployment ownership', question: 'Where does each workload run, and what crosses a boundary?',
@@ -34,7 +34,7 @@ const RAW_RECIPES = [
       useWhen: 'Cloud reviews, production readiness, multi-region planning, or infrastructure ownership handoffs.',
       avoidWhen: 'Deployment facts are unknown or the real question is application behavior rather than placement.',
       include: ['regions and networks', 'workload ownership', 'stateful services', 'named boundary crossings'],
-      prompt: 'Use the technical diagrams skill to draw the production deployment topology. Group resources by region, network, cluster, and owner; show workloads and stateful services; label every cross-boundary mechanism. Do not invent deployment facts-mark unknown areas explicitly. If the user wants a fail-closed deployment review, ask before setting meta.engineering_profile to deployment-ownership; otherwise leave the engineering profile unset.',
+      prompt: 'Use Archify to draw the production deployment topology. Group resources by region, network, cluster, and owner; show workloads and stateful services; label every cross-boundary mechanism. Do not invent deployment facts—mark unknown areas explicitly. If the user wants a fail-closed deployment review, ask before setting meta.engineering_profile to deployment-ownership; otherwise leave the engineering profile unset.',
     },
     zh: {
       title: '部署与归属', question: '每个工作负载运行在哪里，哪些连接跨越了边界？',
@@ -42,15 +42,15 @@ const RAW_RECIPES = [
       useWhen: '适合云上评审、生产就绪、多区域规划和基础设施交接。',
       avoidWhen: '部署事实不清楚，或真正问题是应用行为而不是资源位置时不要使用。',
       include: ['区域与网络', '工作负载归属', '有状态服务', '明确的跨边界机制'],
-      prompt: '用技术图表技能绘制生产部署拓扑。按区域、网络、集群和负责人分组，展示工作负载与有状态服务，并标注每一种跨边界机制。不要编造部署事实，不确定的区域要明确标出。如果用户需要失败即阻断的部署评审，先征得确认，再把 meta.engineering_profile 设为 deployment-ownership；否则不要启用工程画像。',
+      prompt: '用 Archify 绘制生产部署拓扑。按区域、网络、集群和负责人分组，展示工作负载与有状态服务，并标注每一种跨边界机制。不要编造部署事实，不确定的区域要明确标出。如果用户需要失败即阻断的部署评审，先征得确认，再把 meta.engineering_profile 设为 deployment-ownership；否则不要启用工程画像。',
     },
   },
   {
     id: 'agent-tool-call', type: 'workflow', proof: 'agent-tool-call',
-    presentation: { preset: 'signal-flow', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'signal-flow', motion: 'trace' },
     start: {
-      en: { descriptionPrompt: 'Use technical diagrams workflow mode to turn this description into a diagram: [paste the actors, main steps, decisions, approvals, and exception paths]. Use lanes for distinct owners, keep one unmistakable happy path, and mark missing ownership or unresolved branches instead of inventing them.' },
-      zh: { descriptionPrompt: '用技术图表技能工作流模式把下面的描述画成图：[粘贴参与者、主要步骤、决策、审批和异常路径]。不同负责方使用独立泳道，保留一条明确的成功主路径，缺失的负责人或未定分支要标明而不是编造。' },
+      en: { descriptionPrompt: 'Use Archify workflow mode to turn this description into a diagram: [paste the actors, main steps, decisions, approvals, and exception paths]. Use lanes for distinct owners, keep one unmistakable happy path, and mark missing ownership or unresolved branches instead of inventing them.' },
+      zh: { descriptionPrompt: '用 Archify 工作流模式把下面的描述画成图：[粘贴参与者、主要步骤、决策、审批和异常路径]。不同负责方使用独立泳道，保留一条明确的成功主路径，缺失的负责人或未定分支要标明而不是编造。' },
     },
     signals: [['agent tool call', 16], ['tool call', 12], ['approval gate', 10], ['human in the loop', 9], ['mcp', 7], ['planner', 6], ['agent loop', 10], ['智能体工具调用', 16], ['工具调用', 12], ['审批门', 10], ['人在回路', 9], ['规划器', 6], ['智能体循环', 10]],
     en: {
@@ -59,7 +59,7 @@ const RAW_RECIPES = [
       useWhen: 'Explaining agent runtimes, MCP/tool orchestration, approvals, retries, or observability.',
       avoidWhen: 'The goal is only to show static agent components or exact API message timing.',
       include: ['request and planning', 'policy or approval gate', 'tool execution', 'exception and evidence paths'],
-      prompt: 'Use technical diagrams workflow mode to explain this agent tool-call loop. Separate user surface, agent runtime, policy boundary, exception handling, tool execution, and observability into lanes. Make the successful path primary and show approval, retry, blocked, and evidence paths explicitly.',
+      prompt: 'Use Archify workflow mode to explain this agent tool-call loop. Separate user surface, agent runtime, policy boundary, exception handling, tool execution, and observability into lanes. Make the successful path primary and show approval, retry, blocked, and evidence paths explicitly.',
     },
     zh: {
       title: '智能体工具调用', question: '智能体如何规划、获批、执行、恢复并汇报？',
@@ -67,12 +67,12 @@ const RAW_RECIPES = [
       useWhen: '适合解释 Agent Runtime、MCP/工具编排、审批、重试和可观测性。',
       avoidWhen: '如果只想看静态组件，或重点是精确 API 消息时序，请换其他配方。',
       include: ['请求与规划', '策略或审批门', '工具执行', '异常与证据路径'],
-      prompt: '用技术图表技能工作流模式解释这段智能体工具调用。把用户界面、Agent Runtime、策略边界、异常处理、工具执行和可观测性分成泳道；突出成功主路径，并明确展示审批、重试、阻塞和证据路径。',
+      prompt: '用 Archify 工作流模式解释这段智能体工具调用。把用户界面、Agent Runtime、策略边界、异常处理、工具执行和可观测性分成泳道；突出成功主路径，并明确展示审批、重试、阻塞和证据路径。',
     },
   },
   {
     id: 'delivery-workflow', type: 'workflow', proof: 'delivery-workflow',
-    presentation: { preset: 'classic', motion: 'trace', views: 'optional' },
+    presentation: { preset: 'classic', motion: 'trace' },
     signals: [['ci/cd', 14], ['release workflow', 14], ['deployment pipeline', 11], ['pull request', 7], ['staging', 7], ['rollback', 8], ['发布流程', 14], ['流水线', 9], ['上线', 7], ['预发', 7], ['回滚', 8], ['审批发布', 10]],
     en: {
       title: 'Delivery workflow', question: 'How does a change move safely from commit to production?',
@@ -80,7 +80,7 @@ const RAW_RECIPES = [
       useWhen: 'CI/CD design, release reviews, deployment governance, or onboarding developers to delivery.',
       avoidWhen: 'The question is where infrastructure runs or what states a deployment object can occupy.',
       include: ['trigger and build', 'blocking checks', 'approval and environments', 'rollback and verification'],
-      prompt: 'Use technical diagrams workflow mode to draw this delivery process from commit to production. Separate developer, CI, approval, environment, and exception lanes; mark blocking checks, smoke tests, ownership, and the rollback path. Keep one unmistakable happy path.',
+      prompt: 'Use Archify workflow mode to draw this delivery process from commit to production. Separate developer, CI, approval, environment, and exception lanes; mark blocking checks, smoke tests, ownership, and the rollback path. Keep one unmistakable happy path.',
     },
     zh: {
       title: '研发交付流程', question: '一次变更如何安全地从提交走到生产？',
@@ -88,12 +88,12 @@ const RAW_RECIPES = [
       useWhen: '适合 CI/CD 设计、发布评审、部署治理和研发新人上手。',
       avoidWhen: '如果重点是基础设施位置或部署对象的状态集合，请换架构图或生命周期图。',
       include: ['触发与构建', '阻断检查', '审批与环境', '回滚与验证'],
-      prompt: '用技术图表技能工作流模式绘制从代码提交到生产发布的流程。拆分开发者、CI、审批、环境和异常泳道；标出阻断检查、冒烟测试、负责人和回滚路径，并保留一条一眼可见的成功主路径。',
+      prompt: '用 Archify 工作流模式绘制从代码提交到生产发布的流程。拆分开发者、CI、审批、环境和异常泳道；标出阻断检查、冒烟测试、负责人和回滚路径，并保留一条一眼可见的成功主路径。',
     },
   },
   {
     id: 'incident-runbook', type: 'workflow', proof: 'incident-runbook',
-    presentation: { preset: 'signal-flow', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'signal-flow', motion: 'trace' },
     signals: [['incident response', 15], ['runbook', 12], ['outage', 9], ['triage', 8], ['mitigation', 8], ['escalation', 7], ['事故处置', 15], ['故障', 9], ['应急预案', 12], ['排障', 9], ['缓解', 7], ['升级响应', 8]],
     en: {
       title: 'Incident runbook', question: 'How do responders detect, triage, mitigate, verify, and escalate?',
@@ -101,7 +101,7 @@ const RAW_RECIPES = [
       useWhen: 'Incident playbooks, on-call handoffs, reliability reviews, and tabletop exercises.',
       avoidWhen: 'The audience needs live metrics or a post-incident component topology instead of response actions.',
       include: ['detection signal', 'triage owner', 'mitigation and rollback', 'verification and communication'],
-      prompt: 'Use technical diagrams workflow mode to turn this incident runbook into responder lanes. Show detection, triage, mitigation, escalation, communication, rollback, and recovery verification. Separate decision gates from actions and make missing ownership visible.',
+      prompt: 'Use Archify workflow mode to turn this incident runbook into responder lanes. Show detection, triage, mitigation, escalation, communication, rollback, and recovery verification. Separate decision gates from actions and make missing ownership visible.',
     },
     zh: {
       title: '事故处置 Runbook', question: '响应者如何发现、分诊、缓解、验证并升级？',
@@ -109,15 +109,15 @@ const RAW_RECIPES = [
       useWhen: '适合故障预案、On-call 交接、稳定性评审和桌面演练。',
       avoidWhen: '如果受众需要实时指标仪表盘或事故后的组件拓扑，而不是响应动作，请换其他视图。',
       include: ['发现信号', '分诊负责人', '缓解与回滚', '恢复验证与沟通'],
-      prompt: '用技术图表技能工作流模式把事故处置预案画成响应者泳道。展示发现、分诊、缓解、升级、沟通、回滚和恢复验证；把决策门与操作分开，并让缺失的负责人清晰可见。',
+      prompt: '用 Archify 工作流模式把事故处置预案画成响应者泳道。展示发现、分诊、缓解、升级、沟通、回滚和恢复验证；把决策门与操作分开，并让缺失的负责人清晰可见。',
     },
   },
   {
     id: 'api-request', type: 'sequence', proof: 'cache-miss',
-    presentation: { preset: 'classic', motion: 'trace', views: 'optional' },
+    presentation: { preset: 'classic', motion: 'trace' },
     start: {
-      en: { descriptionPrompt: 'Use technical diagrams sequence mode to draw this interaction: [paste the participants, calls, returns, fallback, and asynchronous side effects]. Keep message order unambiguous, labels short, and unknown behavior explicit. No repository is required.' },
-      zh: { descriptionPrompt: '用技术图表技能时序模式绘制下面的交互：[粘贴参与者、调用、返回、回退和异步副作用]。确保消息顺序无歧义、标签简短，并明确标注未知行为。不需要代码库。' },
+      en: { descriptionPrompt: 'Use Archify sequence mode to draw this interaction: [paste the participants, calls, returns, fallback, and asynchronous side effects]. Keep message order unambiguous, labels short, and unknown behavior explicit. No repository is required.' },
+      zh: { descriptionPrompt: '用 Archify 时序模式绘制下面的交互：[粘贴参与者、调用、返回、回退和异步副作用]。确保消息顺序无歧义、标签简短，并明确标注未知行为。不需要代码库。' },
     },
     signals: [['api request', 14], ['request response', 12], ['call chain', 11], ['cache miss', 13], ['jwt', 8], ['who calls whom', 12], ['api 请求', 14], ['请求响应', 12], ['调用链', 11], ['缓存未命中', 13], ['谁调用谁', 12], ['鉴权链路', 9]],
     en: {
@@ -126,7 +126,7 @@ const RAW_RECIPES = [
       useWhen: 'API documentation, debugging request latency, auth reviews, or explaining cache fallback.',
       avoidWhen: 'Order is unimportant and the audience only needs the stable service topology.',
       include: ['callers and callees', 'request and return messages', 'fallback or error path', 'async side effects'],
-      prompt: 'Use technical diagrams sequence mode to show this request from caller to final response. Include authentication, cache hit or miss, persistence fallback, return messages, and asynchronous trace or event emission. Keep message labels short and order unambiguous.',
+      prompt: 'Use Archify sequence mode to show this request from caller to final response. Include authentication, cache hit or miss, persistence fallback, return messages, and asynchronous trace or event emission. Keep message labels short and order unambiguous.',
     },
     zh: {
       title: 'API 请求链', question: '谁调用谁、顺序如何、最终返回什么？',
@@ -134,12 +134,12 @@ const RAW_RECIPES = [
       useWhen: '适合 API 文档、请求耗时排查、鉴权评审和缓存回退说明。',
       avoidWhen: '如果顺序不重要，受众只需要稳定的服务拓扑，请用架构图。',
       include: ['调用方与被调用方', '请求与返回消息', '回退或错误路径', '异步副作用'],
-      prompt: '用技术图表技能时序模式展示从调用方到最终响应的完整请求。包含鉴权、缓存命中或未命中、持久化回退、返回消息，以及异步 Trace 或事件上报；消息标签保持简短，顺序必须明确。',
+      prompt: '用 Archify 时序模式展示从调用方到最终响应的完整请求。包含鉴权、缓存命中或未命中、持久化回退、返回消息，以及异步 Trace 或事件上报；消息标签保持简短，顺序必须明确。',
     },
   },
   {
     id: 'async-roundtrip', type: 'sequence', proof: 'async-roundtrip',
-    presentation: { preset: 'signal-flow', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'signal-flow', motion: 'trace' },
     signals: [['async roundtrip', 14], ['webhook', 10], ['callback', 10], ['acknowledgement', 8], ['timeout', 7], ['retry message', 8], ['异步回调', 14], ['回调', 10], ['确认消息', 8], ['超时', 7], ['消息重试', 9], ['webhook', 10]],
     en: {
       title: 'Async roundtrip', question: 'What happens after the initial request returns?',
@@ -147,7 +147,7 @@ const RAW_RECIPES = [
       useWhen: 'Webhooks, jobs, queues, payment callbacks, eventual consistency, or async API contracts.',
       avoidWhen: 'The primary question is topic topology and consumer ownership rather than time order.',
       include: ['initial acknowledgement', 'queue or scheduler', 'background work', 'callback, retry, and timeout'],
-      prompt: 'Use technical diagrams sequence mode to explain this asynchronous roundtrip. Show the initial acknowledgement, enqueue or scheduling step, background processing, callback or polling, retry and timeout behavior, and the point where the caller can observe final consistency.',
+      prompt: 'Use Archify sequence mode to explain this asynchronous roundtrip. Show the initial acknowledgement, enqueue or scheduling step, background processing, callback or polling, retry and timeout behavior, and the point where the caller can observe final consistency.',
     },
     zh: {
       title: '异步往返链路', question: '初始请求返回之后，后台还会发生什么？',
@@ -155,12 +155,12 @@ const RAW_RECIPES = [
       useWhen: '适合 Webhook、后台任务、队列、支付回调、最终一致和异步 API 契约。',
       avoidWhen: '如果重点是 Topic 拓扑和消费者归属，而不是时间顺序，请用事件数据流配方。',
       include: ['初始确认', '队列或调度器', '后台处理', '回调、重试与超时'],
-      prompt: '用技术图表技能时序模式解释这段异步往返链路。展示初始确认、入队或调度、后台处理、回调或轮询、重试与超时，以及调用方何时能观察到最终一致结果。',
+      prompt: '用 Archify 时序模式解释这段异步往返链路。展示初始确认、入队或调度、后台处理、回调或轮询、重试与超时，以及调用方何时能观察到最终一致结果。',
     },
   },
   {
     id: 'data-lineage', type: 'dataflow', proof: 'product-analytics',
-    presentation: { preset: 'classic', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'classic', motion: 'trace' },
     signals: [['data lineage', 15], ['etl', 12], ['warehouse', 9], ['pii', 11], ['governance', 9], ['analytics pipeline', 12], ['数据血缘', 15], ['数据管道', 11], ['数仓', 9], ['治理', 9], ['隐私数据', 10], ['用户同意', 9]],
     en: {
       title: 'Data lineage', question: 'Where does data come from, how does it change, and who consumes it?',
@@ -168,7 +168,7 @@ const RAW_RECIPES = [
       useWhen: 'Analytics architecture, ETL/ELT review, PII assessment, warehouse design, or model feature lineage.',
       avoidWhen: 'The audience needs request timing or operational task ownership rather than data assets.',
       include: ['sources and assets', 'transform stages', 'classification or consent', 'stores and consumers'],
-      prompt: 'Use technical diagrams dataflow mode to map this data lineage. Name every data asset and transform, show consent or classification boundaries, distinguish streaming from batch paths, and identify stores plus downstream consumers. Do not use unlabeled flows.',
+      prompt: 'Use Archify dataflow mode to map this data lineage. Name every data asset and transform, show consent or classification boundaries, distinguish streaming from batch paths, and identify stores plus downstream consumers. Do not use unlabeled flows.',
     },
     zh: {
       title: '数据血缘', question: '数据从哪里来、如何变化、最终被谁消费？',
@@ -176,24 +176,24 @@ const RAW_RECIPES = [
       useWhen: '适合分析架构、ETL/ELT 评审、PII 评估、数仓设计和特征血缘。',
       avoidWhen: '如果受众需要请求时序或操作负责人，而不是数据资产，请换其他配方。',
       include: ['数据来源与资产', '转换阶段', '分类或同意边界', '存储与消费者'],
-      prompt: '用技术图表技能数据流模式梳理这段数据血缘。为每个数据资产和转换命名，展示用户同意或数据分类边界，区分流式与批处理路径，并标明存储和下游消费者；所有数据流都必须有标签。',
+      prompt: '用 Archify 数据流模式梳理这段数据血缘。为每个数据资产和转换命名，展示用户同意或数据分类边界，区分流式与批处理路径，并标明存储和下游消费者；所有数据流都必须有标签。',
     },
   },
   {
     id: 'event-stream', type: 'dataflow', proof: 'event-stream',
-    presentation: { preset: 'signal-flow', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'signal-flow', motion: 'trace' },
     start: {
-      en: { descriptionPrompt: 'Use technical diagrams dataflow mode to map this data journey: [paste the sources, data assets, transforms, stores, boundaries, and consumers]. Label every flow, distinguish streaming from batch where relevant, and mark unknown classifications or ownership instead of inventing them.' },
-      zh: { descriptionPrompt: '用技术图表技能数据流模式梳理下面的数据路径：[粘贴来源、数据资产、转换、存储、边界和消费者]。为每条数据流标注名称，在有意义时区分流式与批处理，未知的分类或归属要标明而不是编造。' },
+      en: { descriptionPrompt: 'Use Archify dataflow mode to map this data journey: [paste the sources, data assets, transforms, stores, boundaries, and consumers]. Label every flow, distinguish streaming from batch where relevant, and mark unknown classifications or ownership instead of inventing them.' },
+      zh: { descriptionPrompt: '用 Archify 数据流模式梳理下面的数据路径：[粘贴来源、数据资产、转换、存储、边界和消费者]。为每条数据流标注名称，在有意义时区分流式与批处理，未知的分类或归属要标明而不是编造。' },
     },
     signals: [['event stream', 15], ['kafka topology', 14], ['topic', 8], ['consumer group', 11], ['dead letter', 10], ['dlq', 10], ['事件流', 15], ['kafka 拓扑', 14], ['主题', 7], ['消费者组', 11], ['死信', 10], ['事件地铁图', 12]],
     en: {
       title: 'Event-stream topology', question: 'Which events move through which topics, processors, groups, and failure paths?',
       summary: 'A stream map of producers, topics, ordered processors, consumer groups, state, replay, and DLQ.',
       useWhen: 'Kafka/event-platform design, stream processing reviews, ownership, replay, and failure handling.',
-      avoidWhen: 'Topic names, consumer groups, and delivery semantics are not known-use a generic workflow instead.',
+      avoidWhen: 'Topic names, consumer groups, and delivery semantics are not known—use a generic workflow instead.',
       include: ['producers and event names', 'topics and ordering', 'processors and consumer groups', 'state, replay, and DLQ'],
-      prompt: 'Use technical diagrams dataflow mode to draw this event-stream topology. Name producers, events, topics, ordered processors, consumer groups, state stores, replay paths, and the DLQ. Show ownership and delivery semantics only when supported by evidence.',
+      prompt: 'Use Archify dataflow mode to draw this event-stream topology. Name producers, events, topics, ordered processors, consumer groups, state stores, replay paths, and the DLQ. Show ownership and delivery semantics only when supported by evidence.',
     },
     zh: {
       title: '事件流拓扑', question: '哪些事件经过哪些 Topic、处理器、消费者组和失败路径？',
@@ -201,15 +201,15 @@ const RAW_RECIPES = [
       useWhen: '适合 Kafka/事件平台设计、流处理评审、归属、重放和失败处理。',
       avoidWhen: '如果 Topic、消费者组和投递语义都不清楚，请先用通用工作流，不要编造事件拓扑。',
       include: ['生产者与事件名', 'Topic 与顺序', '处理器与消费者组', '状态、重放与 DLQ'],
-      prompt: '用技术图表技能数据流模式绘制这段事件流拓扑。命名生产者、事件、Topic、有序处理器、消费者组、状态存储、重放路径和 DLQ；只有在证据充分时才标注归属和投递语义。',
+      prompt: '用 Archify 数据流模式绘制这段事件流拓扑。命名生产者、事件、Topic、有序处理器、消费者组、状态存储、重放路径和 DLQ；只有在证据充分时才标注归属和投递语义。',
     },
   },
   {
     id: 'object-lifecycle', type: 'lifecycle', proof: 'agent-run',
-    presentation: { preset: 'classic', motion: 'trace', views: 'optional' },
+    presentation: { preset: 'classic', motion: 'trace' },
     start: {
-      en: { descriptionPrompt: 'Use technical diagrams lifecycle mode to model this object: [paste its states, transition events, waits, retries, cancellation, and terminal outcomes]. Separate active, waiting, recoverable-failure, and terminal states, and never hide an ending. No repository is required.' },
-      zh: { descriptionPrompt: '用技术图表技能生命周期模式建模这个对象：[粘贴它的状态、转换事件、等待、重试、取消和终态]。分开执行、等待、可恢复失败和终态，不要隐藏任何结束方式。不需要代码库。' },
+      en: { descriptionPrompt: 'Use Archify lifecycle mode to model this object: [paste its states, transition events, waits, retries, cancellation, and terminal outcomes]. Separate active, waiting, recoverable-failure, and terminal states, and never hide an ending. No repository is required.' },
+      zh: { descriptionPrompt: '用 Archify 生命周期模式建模这个对象：[粘贴它的状态、转换事件、等待、重试、取消和终态]。分开执行、等待、可恢复失败和终态，不要隐藏任何结束方式。不需要代码库。' },
     },
     signals: [['state machine', 15], ['object lifecycle', 14], ['status transition', 11], ['terminal state', 9], ['retry state', 8], ['状态机', 15], ['生命周期', 13], ['状态流转', 11], ['终态', 9], ['等待态', 8], ['重试状态', 8]],
     en: {
@@ -218,7 +218,7 @@ const RAW_RECIPES = [
       useWhen: 'Tasks, orders, tickets, subscriptions, jobs, agent runs, or any durable object with status.',
       avoidWhen: 'The object has no durable state and the real question is participant interaction over time.',
       include: ['start and active states', 'event-labelled transitions', 'wait and retry states', 'all terminal outcomes'],
-      prompt: 'Use technical diagrams lifecycle mode to model this object. Separate main progress, waiting or interruption states, and terminal outcomes. Label transitions with events, include retry, cancellation, timeout, success, and failure where real, and never hide an ending.',
+      prompt: 'Use Archify lifecycle mode to model this object. Separate main progress, waiting or interruption states, and terminal outcomes. Label transitions with events, include retry, cancellation, timeout, success, and failure where real, and never hide an ending.',
     },
     zh: {
       title: '对象生命周期', question: '有哪些状态、什么事件触发流转、最终如何结束？',
@@ -226,12 +226,12 @@ const RAW_RECIPES = [
       useWhen: '适合任务、订单、工单、订阅、作业、Agent Run 等带持久状态的对象。',
       avoidWhen: '对象没有持久状态，真正问题是参与者随时间的交互时，请使用时序图。',
       include: ['开始与执行态', '带事件的转换', '等待与重试态', '所有终态'],
-      prompt: '用技术图表技能生命周期模式建模这个对象。分开主进度、等待或中断状态和终态；用事件标注转换，并在真实存在时展示重试、取消、超时、成功和失败，不能隐藏任何结束方式。',
+      prompt: '用 Archify 生命周期模式建模这个对象。分开主进度、等待或中断状态和终态；用事件标注转换，并在真实存在时展示重试、取消、超时、成功和失败，不能隐藏任何结束方式。',
     },
   },
   {
     id: 'deployment-lifecycle', type: 'lifecycle', proof: 'deployment-lifecycle',
-    presentation: { preset: 'signal-flow', motion: 'trace', views: 'recommended' },
+    presentation: { preset: 'signal-flow', motion: 'trace' },
     signals: [['deployment lifecycle', 15], ['release state', 10], ['promotion state', 9], ['approval status', 8], ['rollback state', 10], ['部署生命周期', 15], ['发布状态', 10], ['晋级', 7], ['审批状态', 8], ['回滚状态', 10]],
     en: {
       title: 'Deployment lifecycle', question: 'What state is a release in, and what can happen next?',
@@ -239,7 +239,7 @@ const RAW_RECIPES = [
       useWhen: 'Release controllers, GitOps reconciliation, environment promotion, or deployment status APIs.',
       avoidWhen: 'The question is the human/CI sequence of delivery actions rather than the deployment object state.',
       include: ['queued and running states', 'verification and approval', 'promotion and rollback', 'success, failure, cancellation'],
-      prompt: 'Use technical diagrams lifecycle mode to model the deployment object. Show queued, building, verifying, waiting for approval, promoting, rolling back, and every terminal outcome. Label the events and guards that permit each transition.',
+      prompt: 'Use Archify lifecycle mode to model the deployment object. Show queued, building, verifying, waiting for approval, promoting, rolling back, and every terminal outcome. Label the events and guards that permit each transition.',
     },
     zh: {
       title: '部署生命周期', question: '一次发布当前处于什么状态，下一步可能发生什么？',
@@ -247,7 +247,71 @@ const RAW_RECIPES = [
       useWhen: '适合发布控制器、GitOps 对账、环境晋级和部署状态 API。',
       avoidWhen: '如果重点是人员与 CI 的交付动作顺序，而不是部署对象状态，请用交付工作流。',
       include: ['排队与执行态', '验证与审批', '晋级与回滚', '成功、失败与取消'],
-      prompt: '用技术图表技能生命周期模式建模部署对象。展示排队、构建、验证、等待审批、晋级、回滚以及所有终态，并标注允许每次状态转换的事件和守卫条件。',
+      prompt: '用 Archify 生命周期模式建模部署对象。展示排队、构建、验证、等待审批、晋级、回滚以及所有终态，并标注允许每次状态转换的事件和守卫条件。',
+    },
+  },
+  {
+    id: 'database-schema', type: 'erd', proof: 'orders',
+    presentation: { preset: 'classic', motion: 'static', views: 'optional' },
+    start: {
+      en: { descriptionPrompt: 'Use Archify to model this data model as an entity-relationship diagram: [paste the schema DDL, or describe the tables, their key columns, and how they relate]. No repository is required. Include every column the reader needs rather than a summary, mark primary, foreign, and unique keys, and draw each foreign-key relationship with the cardinality and optionality of both ends.' },
+      zh: { descriptionPrompt: '用 Archify 把这份数据模型画成实体关系图：[粘贴建表 DDL，或描述表、关键字段以及表之间的关联]。不需要代码库。字段要完整而不是摘要，标注主键、外键和唯一键，并为每条外键关系画出两端的基数和可选性。' },
+    },
+    signals: [['entity relationship', 14], ['er diagram', 15], ['database schema', 13], ['table schema', 12], ['foreign key', 11], ['primary key', 9], ['cardinality', 9], ['实体关系图', 15], ['ER 图', 15], ['表结构', 13], ['数据库设计', 12], ['外键', 11], ['主键', 9], ['实体关系', 12]],
+    en: {
+      title: 'Database schema', question: 'Which tables exist, what columns and keys do they carry, and how do they relate?',
+      summary: 'An entity-relationship map of tables with their complete column lists, key markers, and the cardinality between them.',
+      useWhen: 'Schema reviews, data-model onboarding, migration planning, or explaining a foreign-key graph.',
+      avoidWhen: 'The question is row-level movement between systems (data flow) or access order at runtime (sequence).',
+      include: ['tables with their complete column lists', 'primary, foreign, and unique key markers', 'cardinality and optionality at both ends', 'cards reserved for supplementary notes'],
+      prompt: 'Use Archify ERD mode to model this schema. Show every physical column inside its table — the field list is this diagram\'s primary content, not a summary — and mark primary, foreign, and unique keys. Draw every foreign-key relationship with its cardinality and optionality at both ends, and group related tables into contiguous domain blocks. Keep cards for supplementary notes instead of moving columns out of the tables.',
+    },
+    zh: {
+      title: '数据库表结构', question: '有哪些表、各自带哪些字段和键、彼此如何关联？',
+      summary: '用实体关系图展示表及其完整字段清单、键标记和表之间的基数关系。',
+      useWhen: '适合表结构评审、数据模型上手、迁移规划和解释外键关系图。',
+      avoidWhen: '如果重点是系统之间的行级数据流动或运行期访问顺序，请用数据流图或时序图。',
+      include: ['表及其完整字段清单', '主键、外键、唯一键标记', '两端的基数与可选性', '卡片只放补充说明'],
+      prompt: '用 Archify ERD 模式建模这份表结构。每张表的完整物理字段都画在表内——字段清单是这张图的主要内容，不是摘要——并标注主键、外键和唯一键。为每条外键关系画出两端的基数和可选性，把相关表组织成连续的领域块。卡片只保留补充说明，不要用它把字段移出表外。',
+    },
+  },
+  {
+    id: 'layout-repair', type: 'architecture', proof: 'web-app',
+    presentation: { preset: 'classic', motion: 'static' },
+    signals: [
+      ['layout repair', 20], ['repair order', 20], ['fix order', 20],
+      ['viewport overflow', 20], ['overflow', 16], ['scrollheight', 16], ['scrollwidth', 16],
+      ['overlap', 16], ['label overlap', 20], ['edge through node', 20], ['crossing', 8],
+      ['via', 7], ['waypoint', 14],
+      ['布局修复', 20], ['修复顺序', 20], ['视口溢出', 20], ['溢出', 16], ['滚动高度', 16], ['滚动宽度', 16],
+      ['重叠', 16], ['标签重叠', 20], ['连线穿过节点', 20], ['连线穿节点', 20], ['交叉', 8],
+      ['途经点', 14], ['路径点', 14], ['拐点', 14],
+    ],
+    en: {
+      title: 'Layout repair', question: 'Why does the existing diagram overflow, overlap, or route through nodes, and what should be fixed first?',
+      summary: 'Repair an existing diagram in its current mode using validation diagnostics, explicit waypoint semantics, and a measured desktop viewport budget.',
+      useWhen: 'An existing architecture, workflow, sequence, dataflow, or lifecycle diagram needs layout repair; keep its diagram type and presentation settings.',
+      avoidWhen: 'The task is choosing a new diagram type. Do not change topology, delete meaningful labels, or hide overflow just to pass checks.',
+      include: [
+        'repair order: schema → overlap → direction → crossings → labels',
+        'via contract: absolute [x, y] intermediate points; route = [start, ...via, end]',
+        'desktop viewport budget for the complete page, including header and necessary cards',
+        'validate after each edit, then inspect the final HTML in a browser',
+      ],
+      prompt: 'Use Archify to repair this existing diagram while preserving its diagram type, topology, meaningful labels, and presentation settings. Follow references/authoring-contract.md in this order: (1) schema and missing/invalid meta.quality_profile; (2) node overlap or out-of-range placement; (3) edge-through-node and endpoint-direction errors; (4) crossings, ambiguous corridors, border runs, excessive detours, and route rhythm; (5) labels: label-to-node, label-to-label, then label-to-route clearance. Run validate after every edit and use diagnostics[] code, subject, evidence, and supportedFixes; apply one diagnosed geometry control at a time. Where the current schema supports via, it is an ordered array of absolute SVG [x, y] intermediate points: the route is [start, ...via, end], with start/end supplied by the node anchors. Explicit via points override automatic routing; they are not offsets or a request for automatic obstacle avoidance. For an orthogonal repair, align adjacent points on the same x or y and make the first/final segment respect fromSide/toSide; use only controls supported by the current diagram mode. Follow references/delivery-contract.md for the viewport budget: check 1440×900, 1600×1000, 1920×1080, and 2048×1320; require document.documentElement.scrollWidth <= window.innerWidth. Prefer document.documentElement.scrollHeight <= window.innerHeight, but preserve a Reader-declared readable vertical page scroll when browser-check explicitly accepts it after reaching the projected-text floor. Budget the entire page, including header, diagram, and necessary cards. Repair every other overflow by removing only redundant content or compacting spacing first; do not hide overflow, clip content, introduce an internal diagram scroller, stretch the SVG, or shrink typography to force a pass. Let finalize run the required browser evidence; run perceptual visual review only when requested or escalated by the delivery contract.',
+    },
+    zh: {
+      title: '布局修复', question: '现有图为什么仍然溢出、重叠或连线穿过节点，应该先修什么？',
+      summary: '保留现有图表模式，依据验证诊断、途经点语义和实测桌面视口预算修复布局。',
+      useWhen: '已有架构图、工作流、时序图、数据流或生命周期图需要修复布局；保留原来的图表类型和表现设置。',
+      avoidWhen: '任务是为新图选择类型时不要使用。不要为了通过检查改变拓扑、删除有意义的标签或隐藏溢出。',
+      include: [
+        '修复顺序：schema → 重叠 → 方向 → 交叉 → 标签',
+        'via 契约：绝对 [x, y] 中间点；路径 = [start, ...via, end]',
+        '包含标题和必要卡片的整页桌面视口预算',
+        '每次修改后 validate，最终在浏览器中检查 HTML',
+      ],
+      prompt: '用 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 规定的升级条件下进行感知视觉审阅。',
     },
   },
 ];
@@ -343,11 +407,11 @@ export function recommendScenario(query, options = {}) {
 export function formatScenarioList(lang = 'en') {
   const isZh = lang === 'zh';
   const heading = isZh
-    ? `场景配方（${SCENARIO_RECIPES.length}）`
-    : `Scenario recipes (${SCENARIO_RECIPES.length})`;
+    ? `Archify 场景配方（${SCENARIO_RECIPES.length}）`
+    : `Archify scenario recipes (${SCENARIO_RECIPES.length})`;
   const intro = isZh
-    ? '先选择你要回答的问题，再选择图表类型。可运行：diagrams guide "你的场景"'
-    : 'Choose the question before the diagram type. Run: diagrams guide "your scenario"';
+    ? '先选择你要回答的问题，再选择图表类型。可运行：archify guide "你的场景"'
+    : 'Choose the question before the diagram type. Run: archify guide "your scenario"';
   return [heading, '', intro, '', ...listScenarioRecipes(lang).flatMap((recipe) => [
     `${recipe.id}  [${recipe.type}]  ${recipe.title}`,
     `  ${recipe.question}`,
@@ -370,7 +434,7 @@ export function formatScenarioRecommendation(result) {
     `${labels.use}: ${recipe.useWhen}`,
     `${labels.avoid}: ${recipe.avoidWhen}`,
     `${labels.include}: ${recipe.include.join(isZh ? '、' : '; ')}`,
-    `${labels.presentation}: ${recipe.presentation.preset} · ${recipe.presentation.motion} · views ${recipe.presentation.views}`,
+    `${labels.presentation}: ${recipe.presentation.preset} · ${recipe.presentation.motion}`,
     '',
     `${labels.prompt}:`,
     recipe.prompt,

package/ai/skills/stacks-technical-diagrams/references/architecture-layout-repair.md

@@ -0,0 +1,18 @@
+# Architecture layout repair
+
+Use this after actual visual review finds several tangled routes. A successful machine receipt does not settle composition. Work on the existing candidate, retaining all required components, relationships, labels, evidence, boundaries, and node sizes.
+
+## Choose the repair scope
+
+If the main and secondary chains already read clearly, repair the isolated defect locally. If a main chain is blocked, several routes tangle, or a local fix moves the defect onto another route, reflow the connected scene in one edit. Preserve all semantics and user-fixed geometry; agent-generated positions and route controls may change. After moving nodes, remove stale generated route overrides so automatic routing can use the new placement.
+
+The receipt's `directCorridorBlockers`, when present, names nodes between an edge's aligned endpoints. This is geometric evidence, not proof that the edge is the main path or a new validation failure. Trace the reader's actual main path first. When a listed blocker interrupts that path, reposition the connected group instead of adding another detour.
+
+## One coherent repair
+
+1. Trace the affected relationships and their endpoints in the JSON. Before choosing coordinates, write the reader’s main path as an ordered list of existing edges, then identify shared state and real feedback cycles. Every neighboring pair in that main path must have the relationship being explained; place other components on branches beside their actual owner. Use `validate architecture <candidate.json> --layout-json --repo-root <root>` once if the compact receipt and screenshot do not reveal the needed route or label geometry; omit `--repo-root` only for a design without repository evidence. Do not guess repeated waypoint coordinates.
+2. Place those connected main-path neighbors in reading order. Put shared state between its readers/writers, on an adjacent row if necessary, so one writer does not need a line across the whole execution area. Arrange a feedback cycle in its actual edge order around an open rectangle, with other consumers beside their owner. For example, if the edges are `client → API → dispatcher → worker → collector → runner → dispatcher`, put the first four on the upper row, collector below worker, and runner below dispatcher: the return then uses the lower row and a short upward edge. This illustrates adjacency, not a graph or set of coordinates to copy; use only relationships present in the candidate. Preserve every edge and its actual direction.
+3. Keep automatic endpoints for the new placement. Constrain a side only when a branch or return needs a specific corridor; check that corridor against every affected relationship, including storage branches. If that local constraint introduces another conflict, return to the connected placement instead of cycling through side combinations. Only use detailed `via` or label coordinates for a remaining measured defect. Keep external actors outside the resolved boundary rectangle, including its padding; not listing a node in `wraps` does not visually exclude it. Keep an internal relationship and its label inside the shared boundary unless crossing it conveys a real fact; do not imply an external hop merely to avoid another route.
+4. When `composition/label-gap` reports a measured minimum, enlarge that clear gap or move the connected group onto another readable row. Keep the full label beside its own route; placing it in distant empty space does not repair the relationship. Compact unused gaps while preserving measured label space and the previous text size. Keep the main interaction and all required nodes readable in the default desktop view; do not trade crossings for a large blank canvas, tiny text, or a chain that doubles back without a semantic reason.
+
+Run the complete `finalize` once after the edit, then `visual-check` on the successful artifact and inspect its desktop captures. When replacing an already reviewed artifact, use one fresh `--out-dir` for both commands as described in [the delivery contract](delivery-contract.md#a-new-candidate-at-an-existing-output-path). Trace the main path, each secondary chain, and every affected arrow and label. A bounded second repair may address a remaining specific defect. If it still fails visual acceptance, retain the candidate and report the concrete gap; do not count it as a successful repair or continue blind coordinate changes.