餐厅演示协调器是做什么的？

从潜在客户输入开始，运行一个可恢复的工单，直到本地验证的私有演示。将此技能和主代理视为控制平面；使用三个有界的工作代理和四个专业技能作为执行平面。

在更改阶段模型、工件类型或转换规则之前，请阅读 references/orchestration-contract.md。

启动或恢复工单

在浏览之前，先阅读项目上下文并检查本地潜在客户数据。
使用 scripts/workflow.py init 初始化工单。当可用时，填充表单行、Place ID、Maps URL 和本地潜在客户快照。
运行 scripts/workflow.py resume 以获取每个活动或依赖就绪的阶段、其工作通道、分配的技能、预期工件以及阶段特定的提示。
在主代理中完成 intake、research、design_lock 和 image_slots 阶段，然后再进行分发。
当子代理可用时，生成一个设计工作器、一个食物工作器和一个外观工作器。同时启动三个依赖就绪的通道；每个工作器记录真实的工件，并仅将其分配的阶段标记为 passed、blocked，或者仅对可选分支标记为 skipped 并附上原因。
合并所有工作器。主代理运行合约验证，集成其输出，解决冲突，执行最终 QA，并记录私有演示。
在转换后运行 scripts/workflow.py validate。在调色板、食物或外观清单通过后，使用 --run-contracts。
重复直到 private_demo 通过或证据创建了真实的阻塞。如果子代理不可用，则顺序执行相同的通道并在阶段备注中记录回退。

不要要求用户单独调用每个技能。当用户说构建、运行、继续或恢复演示时，继续通过同一任务中的所有未阻塞阶段。在切换专业技能时给出简洁的进度更新。

维护专家边界

使用分配的技能，而不是在协调器内部复制其工作：

research、design_lock、image_slots、site_design、implementation 和 qa：$restaurant-demo-builder
brand_palette：$restaurant-brand-palette
food_images：$restaurant-food-image-studio
exterior_image：$restaurant-exterior-image-studio
intake 和 private_demo：此技能

在调度专家阶段之前，主代理必须完全阅读该技能。每个工作器还必须阅读其分配的技能并遵循其证据和验证门控。阶段仅在其所需工件存在时才能通过。工作流记录的专家清单状态永远不会覆盖专家验证器的判断。

并行代理合约

最多使用三个工作代理，位于以下隔离通道中：

design：运行 brand_palette，然后创建响应式的 site_design 外壳，其中包含合约定义的图像占位符。写入调色板/锁定/交接文件和站点外壳；不集成工作器图像输出或执行最终 QA。
food：运行 food_images。仅写入食品图像工作室工单和清单；不编辑站点外壳或最终演示。
exterior：运行 exterior_image。仅写入外观图像工作室工单和清单；不编辑站点外壳或最终演示。

主代理拥有 intake、research、所有通道共享的锁定、最终 implementation、QA、存储库操作、发布决策和用户交接。只有主代理可以将选定的工作器资产复制到最终演示中，解决副本/布局/资产冲突，或声明演示就绪。

工作器可以通过 workflow.py set-stage 更新自己的工作流阶段；状态工具序列化并发写入。工作器不得编辑其他通道的文件或状态。在工作器完成后，检查实际工件并运行验证器，而不是仅信任消息。

阶段规则

按以下顺序执行：

intake
  -> research
  -> design_lock
  -> image_slots
  -> [design: brand_palette -> site_design]
     [food: food_images]                 (parallel)
     [exterior: exterior_image]
  -> implementation by main agent
  -> qa
  -> private_demo

food_images 和 exterior_image 是决策分支，不是静默省略。当生成合格的资产时，让它们通过；当页面仍以文本为主或外观未增加到达价值时，在证据支持下跳过它们。切勿跳过 brand_palette；当餐厅证据不足以支持品牌派生的调色板时，使用其明确标记的 Recipe 回退。

仅使用这些状态。最多三个依赖独立的工作器阶段可以处于 in_progress，但每个工作通道只有一个；主代理阶段从不与工作器阶段重叠：

pending：未开始
in_progress：正在执行；一次只能有一个阶段
passed：依赖项、工件和相关验证器通过
blocked：无法继续；记录具体的阻塞
skipped：可选分支被故意省略；记录原因

切勿将未完成的工作标记为 passed 以推进工作流。当终端的证据或输出发生变化时，使用 --reopen 重新打开终端阶段。

命令

将 <orchestrator-skill> 替换为此已安装的技能文件夹。从您的餐厅项目目录运行工单命令。

初始化：

python3 <orchestrator-skill>/scripts/workflow.py init \
  --project-root . \
  --restaurant "Restaurant Name" \
  --slug restaurant-name \
  --place-id "PLACE_ID" \
  --maps-url "GOOGLE_MAPS_URL" \
  --lead-json output/leads.json \
  --source-sheet-id "SHEET_ID" \
  --source-sheet-title "Sheet title" \
  --source-tab Sheet1 \
  --source-row 28 \
  --sheet-checked-at 2026-07-13

检查和恢复；resume 可能在分发后返回多个可操作的阶段：

python3 <orchestrator-skill>/scripts/workflow.py status \
  --workflow orchestration/restaurant-name/workflow.json

python3 <orchestrator-skill>/scripts/workflow.py resume \
  --workflow orchestration/restaurant-name/workflow.json

记录阶段：

python3 <orchestrator-skill>/scripts/workflow.py set-stage \
  --workflow orchestration/restaurant-name/workflow.json \
  --stage research --status passed \
  --artifact research_record=orchestration/restaurant-name/research/RESEARCH.md \
  --artifact restaurant_profile=orchestration/restaurant-name/research/restaurant-profile.json

验证：

python3 <orchestrator-skill>/scripts/workflow.py validate \
  --workflow orchestration/restaurant-name/workflow.json --run-contracts

防护措施

默认将每个新工单保持为 private-local。
不添加自动部署、上传、电子邮件、Messenger 或外联命令。
保持已验证的事实、快照事实、推断、创意决策和未解决问题的区别。
在页面上使用之前，重新检查当前营业时间、菜单、评分、评价数量、网站状态、服务和联系链接。
不要将密钥、服务帐户文件、令牌或私有凭据放入工单中。
在 private_demo 处停止；发布和外联需要单独明确的用户授权。

交接

报告工单路径、当前阶段、本地演示路径或 URL（如果可用）、验证结果、阻塞项、需要所有者确认的项目以及发布审批方面的缺失。明确说明未发生发布或外联，除非另行授权。

餐厅演示协调器