design-studio

设计工作室

角色边界

角色	来源	先前评分	负责事项
规划者	是	否	范围和成功标准
视觉总监	否	否	视觉方向和选定的视觉契约
构建者	是	否	实现保真度
评估者	否	否	渲染后的观察结果和评分
协调者	视情况而定	是	SELECT / REFINE / PIVOT / SHIP / ESCALATE / HALT

• 视觉总监绝不会收到 HTML、CSS、JSX、选择器、实现差异、文档源代码／渲染器元数据或无人值守任务索引。
• 评估者绝不会收到源代码、实现工作量、完整设计描述或先前评分。文档评估也不包含渲染器身份／构建元数据。
• 构建者负责实现选定的方向；不得悄悄将其替换为更稳妥的方向。
• 协调者是唯一的决策负责人。评估者／审阅者提供证据，而非工作流决策。

加载和路由

对于 Studio、Review 和 Document 请求：

1. 加载 invocation.md、design-intent-contract.json、references/design-intent.md、runtime-contract.md、references/context.md 和 references/runtime-integrity.md。这些是通用输入、权限、来源／证据、恢复、降级和验收约束，而非流程分支操作规程。
2. 将宿主输入和当前权限证据映射到一个 Design Intent，并在加载 workflow.yaml、Review／Document 操作规程或任何专业方法文件之前完成验证。分类无效时，既阻止加载流程分支，也阻止执行。
3. 将验证后的结果映射到现有的 task、surface、interaction 和 evidence 信号，然后读取 method-router.json。任务信号必须属于所选流程分支和当前阶段；补充的文案或证据信号不会改变该流程分支。
4. 即使没有匹配的专业路由，也要解析规范的 selectedProcedures。路由上的每个已填充信号维度都是必需条件。加载前，检查每条匹配路由的 procedure 是否与 Design Intent 一致；信号冲突时，必须先修正才能继续。然后加载选定的操作规程及匹配的 leaves 并集，并对路径去重。
5. 加载所需上下文后，执行选定的操作规程。需要时，操作规程会公开特定阶段的角色指令和参考资料。默认情况下，绝不加载完整的专业目录。

method-router.json 是路由数据，不是方法权限依据。其 coreAuthorities 是所有流程分支共用的通用集合。仓库 ADR／权限映射路径仅作为来源元数据；已安装的运行不依赖仓库文档。宿主适配器使用此加载契约，而不是第二套加载图。

必需参考资料

• invocation.md
• design-intent-contract.json
• references/design-intent.md
• runtime-contract.md
• method-router.json
• references/context.md
• references/runtime-integrity.md
• 有条件加载的 Studio 操作规程：workflow.yaml
• 有条件加载的 Review 操作规程：references/review/polish.md
• 有条件加载的 Document 操作规程：references/document/document.md
• 有条件加载的已接受系统边界：references/design-authority/lifecycle.md

前七项加上此索引构成通用热路径。流程分支操作规程和方法按需加载；仅列出其路径并不等于加载。

Lanes

通道 / 操作	触发条件	分支权限
Studio	创建、扩展或彻底改造交互界面	所选的 workflow.yaml；与阶段匹配的 direction/extend/build/overhaul 分支
Review	在保留交互式视觉世界的同时进行审查／润色	所选的 references/review/polish.md；匹配的只读审查视角
Document	报价单、发票、SOW、提案、报告、简报、印刷／PDF 或其他分页文档	所选的 references/document/document.md；层级／具体性及其页面评估视角
Design system	将已接受的系统编纂成规范	已接受通道的编纂权限
Meta	改进 Design Studio	路由至 references/meta.md

Design Intent 负责消歧 Studio/Review/Document。Meta 维护直接使用现有的 meta/method-intake 路由；编纂基于已接受的通道结果，而不是新的意图。即使交互式报告可以导出 PDF，它仍属于 Studio/Review。范围有限的组件／CSS 修正不需要 Studio。

Studio

对于已验证的 Studio 意图，端到端执行 workflow.yaml。它负责规划、预先承诺的无人值守分配、盲于源内容的方向设计、结合源内容的构建、机械证据、盲评、不可变迭代，以及编纂前对最终树的验收。其专用分支按当前阶段加载，而不是在启动时全部加载。对于 extend，使用路由到的 references/extend.md：继承已接受的权限，并仅探索本地新增部分。本地完成后保留原有权限；可复用的差异通过 references/design-authority/lifecycle.md 单独接受并纳入系统编纂。Create 和 overhaul 会保留方向设计工作的分歧。

Document

对于已验证的 Document 意图，执行 references/document/document.md，不要加载 Studio 工作流。它负责实体页面系统方向设计、完整且有序的渲染页面评估、分页／表格／页面装饰／印刷视角，以及已接受的 document-visual-contract.json 发布。在页面评估时加载这些视角；交互式请求不需要加载。

Design Studio 负责视觉页面系统意图和渲染页面判断。它不负责转录解读、业务语气、会计事实、具有约束力的商业／法律条款，也不负责渲染器／生成器。

Review

Review 不会运行 Studio 创建循环，也不会加载其工作流。执行所选的 references/review/polish.md，然后仅添加匹配的视角。审查者应先报告证据；实施阶段只接收一个范围明确的修复计划。缺少渲染证据时，结论为 unverified，而不是通过。

Evidence and degradation

• roots.json/capabilities.json 是操作事实来源；events.jsonl 是只追加的恢复事实来源。
• PRODUCT.md 存储已确认的产品事实；COPY.md 存储持久语言规则；DESIGN.md 仅存储已验证并接受的视觉权限。
• 机械快照是完整的当前状态证据。缺失的证据必须明确说明，绝不能视为通过。
• 验收，而非目录是否存在或高分，才能证明权限。

所有创建通道都需要文件 I/O、shell 和隔离角色。交互式视觉决策还需要可运行的目标／浏览器；Document 决策需要来自现有文档或宿主提供的渲染器的完整渲染页面证据。

• Studio 缺少浏览器：完成一次构建和机械证据收集，然后停止，不选出胜者。
• Review 缺少交互式视口：证据不完整，视觉状态为未验证。
• Document 缺少完整页面：绝不能根据源文件推断质量；遵循 Document 故障约定。
• 没有用户回答机制：使用预先承诺的确定性分配。
• 无法生成图像：使用规格同样明确的文字方向说明。
• 任何失败／缺失的操作都必须记录确切原因。

方法归属

Design Studio 没有上游设计方法运行时依赖。采用的外部理念以路由到本地的方法形式存在，并标注来源；观察／拒绝记录仅作为研究证据。不要引入其他命令分类体系、提示词库或回退运行时。

Growth Arsenal 仍位于此方法内核之外，可通过组合边界提供经批准的、限定角色范围的报价／文案产物。新方法必须指出可复用的缺口，符合权限要求或说明理由，在相关时固定外部来源／许可证，仅改编最小的连贯部分，并通过评估／契约／实际试用结果证明其价值。