Impeccable new-work 工作流详解：从新表面创建到视觉世界替换的七步实战指南

在 AI 编码工具中做前端设计时，"给一个新页面"和"推翻重做一套视觉语言"是两类完全不同的工程问题。Impeccable 仓库中的 new-work 参考文档 正是为此设计的完整工作流：它规定了一条从"判断项目里哪些视觉事实已经成立"，到"向用户提问"、"选择创意幅度"、"提交方向契约"、"全承诺构建"，直至"截图审查、comp 保真门禁与收尾交接"的七步流水线。读完本文，你将掌握 new-work 的四种入场判定、concept-seed / serve-question / build-phase / comp-spec / comp-diff 等 CLI 子命令的实际用法、方向契约（Direction contract）的六个必填块，以及 comp-led 与 code-led 两条构建路径的门禁机制与判定词汇表。

定位：new-work 在 impeccable 技能中的入口

new-work 不是一个"写代码"命令，而是一套流程参考（reference playbook）。它的触发条件在 SKILL.md 的路由规则中写得很清楚：

• 用户请求一个**新表面（new surface）或替换视觉世界（replacement visual world）**时，加载 reference/new-work.md 并遵循它；
• 项目缺少 PRODUCT.md 时，先走 init.md 补齐产品事实，缺 DESIGN.md 不会把流程踢回 init——因为"视觉权威是证据，不是文件名"（Visual authority is evidence, not a filename）；
• 普通局部改造（narrow refinement）不进入 new-work，直接按现有实现推进。

三者分工在文档开头一段话里被固定下来：PRODUCT.md 拥有产品事实，DESIGN.md 拥有持久视觉决策，surface brief（表面简报）只保存"属于某一条路由或某一件制品"的策略。所有 impeccable <verb> 命令实际由 启动器脚本 执行：这是一个 POSIX shell 引导程序，按 $IMPECCABLE_BIN → 同目录平台二进制 → ~/.impeccable/bin/impeccable → 版本固定缓存 → PATH 的顺序解析引擎，并先做 engine-probe 握手，避免误执行旧版 3.x npm CLI 留下的同名 bin。

第 1 步：先判断"什么已经是真的"

动手之前，先读 DESIGN.md、代表性代码、tokens、组件和素材，把项目归入四种状态之一：

项目状态	处置策略
Redesign（重设计）	保留产品事实、内容、功能、约束和明确的品牌承诺；替换旧的视觉世界而不是打磨它。旧外观只是"主题是什么"的证据，不是"它将成为什么"的权威
Established world（既有世界）	直接继承。缺 DESIGN.md 并不抹掉代码中已存在的连贯身份——应把它记录下来而不是另造一个
Incomplete brand（品牌不完整）	保留已确认资产与可识别特征，再与用户一起为这个表面扩展系统
No visual authority（无视觉权威）	与用户共同创造一个新世界

文档还给出两条防越权规则：

• 已建立表面内部的区块、组件、功能或状态，一律继承该表面的世界，绝不允许把局部新增变成新的身份工程；
• 精确指定的窄请求与局部扩展，不运行后文的掷骰脚本，直接塑造即可（"Never run the script for a local extension or a precisely specified narrow request"）。

第 2 步：问"会改变这件工作的东西"

通过结构化提问工具（可用时）做一轮两到三个相关问题；已确定的事实跳过不提，精确请求可以只给一次紧凑确认。问题按访客模式（mode）组织——这四个模式在 SKILL.md 中定义，并在 new-work 中反复使用：

• Persuade（说服）：谁必须行动、他们该相信什么、哪些真实证据/内容/素材配得上这份相信；
• Operate（操作）：任务、信息、关键状态、使用频率、约束；
• Read（阅读）：读者的问题、源材料、结构、导览方式；
• Experience（体验）：什么打头、探索如何展开、哪个交互或转场重要。

跨模式的三个必问项：成功长什么样、什么必须保持不动、什么会让一个"打磨过的结果"显得不对。文档同时划了一条负向边界：永远不要索要 CSS 数值或预设的审美路线（canned aesthetic lanes）。

第 3 步：选择正确的创意幅度

这是整篇文档最重的部分，按"创意幅度"分成三档，从最克制到最激进。

3.1 扩展现有表面

继承其世界与构图，只解决新目的、内容、层级、状态、交互以及"新增内容如何并入周边体验"。不做概念锦标赛（concept tournament）；除非用户批准持久的系统级变更，否则不改 DESIGN.md。

3.2 在既有世界中创建一个完整表面

视觉系统保持固定，从内容、任务与用户行为出发推导五到七种实质不同的结构，按共鸣度排序。对于真正开放的整页/整屏/整流程，运行：

.agent/skills/impeccable/scripts/impeccable concept-seed --scope surface --mode <mode>

脚本从你推导的结构中"发三张牌"，由骰子决定哪三张到达用户手里——打破排名惯性，同时保留用户的真实选择权。决策页上的呈现规则非常具体：

• 三张卡片等权重呈现，被发到的领牌位于 kicker THE ROLL 之下，附 steer（引导语）与 re-roll（重掷）；用户锁定其一；
• surface 范围没有 canon 卡、没有 pick 卡：世界已定，所以每张卡都可视化的是构图（composition）而非身份（identity）；
• 有图像生成且默认 comp-led 时（.impeccable/config.json），每张卡在 .impeccable/mocks/decision/ 下声明一个 comp，按阅读顺序、在服务页面之后生成，遵循 visualize.md 的 comp 纪律；锚定既有身份的关键手法：把一张代表性现有页面的截图作为参考图传入（harness 图像工具的输入图，或 impeccable generate-image --ref），prompt 以新表面的结构开头并点名 DESIGN.md 的调色板、字体与组件气质——"散文式转述设计系统会漂移，像素级参考不会"；
• 无图像生成或 code-led 默认时，每张卡带一个 wireframe 示意图（impeccable serve-question --schema），由页面自绘；
• 锁定卡片即批准，并决定构建路径：锁定 comp 则以该 comp 为已批 comp 走 comp-led，免除 visualize 的三选一轮，没有第二个审批点；锁定 wireframe 则走 code-led，野心由方向契约承载。

3.3 创建或替换视觉世界

这是"掷骰子 + 决策页 + 契约"的完整协议，文档给出五步：

（1）命名机制与"车辙"（rut）。 用一句话命名产品的独特机制、受众的真实场景、其文化归属、这个首表面必须证明什么。同时记下"这个品类永远自带的那页"和它的可预测反面——两者都是车辙，排除出七候选名单。若 brief 自带画面（产品名、有标题的制品、治理性隐喻），它的字面解读也进车辙：最多花一个候选在它身上，其余从受众世界的别处推导。

（2）列出七个具体视觉系统。 从那个文化世界中列出七个受众烂熟于心的具体视觉系统、制品、场所或仪式，各配一行"为何共鸣、为何能承载机制"，按共鸣度排序。受众世界包括其图形与屏幕传统——记谱法、出版物、身份识别项目、数据图形、日常阅读的界面——而不只是物理物件；"可命名的抽象系统（海报流派、文档标准）和任何制品一样具体"。近似重复只计一次；若七项中超过三项共享同一材质家族，说明推导停在了主题最显眼的制品上，必须继续挖，直到名单横跨至少三个家族。

（3）把素材变成完整方向。 每个方向 = 一个可复用的视觉世界 + 一个具体的首表面体验。

（4）掷骰并融合挑战者。 运行：

.agent/skills/impeccable/scripts/impeccable concept-seed --scope direction --mode <mode>

文档对此的措辞是"无替代、无跳过"：在世界级工作中，先写制品代码、再运行脚本并确认其指派，就是契约违规，无论 harness、模型或时间压力如何——骰子的作用是让每次运行都不收敛到品类默认。脚本指派出要构建的方向，并发放目录挑战者（catalog challengers，即仓库 tests/fixtures/concept-catalog/ 这类目录中的既有视觉世界）。融合规则是"挑战者出形式与系统语法，产品出全部事实，清晰度在冲突中获胜"，然后只在两个轴上与指派方向比较：受众识别度（audience identification）与产品清晰度（product clarity）。裁决分三级，先裁决后借鉴：

• wins：两轴皆胜，成为构建候选；
• competitive：守住一轴，保留为完整备选；
• declined：两轴皆输——但它不是废料，要点出指派方向缺少的那一条系统纪律，并把指派方向"抬高"（raise）到同一水平再呈现。

Donation（让渡）传递的是野心与系统纪律（一种调色板的彻底承诺、一个网格的密度勇气、一种形式的结构诚实），绝不传递挑战者的衣服——一个被搬走的母题是"服装备注"，不是抬高，"一个世界拥有整页"。每条抬高必须作为独立一行写进呈现的方向里，并以捐赠者命名："没人读得出的抬高等于没发生。"

（5）呈现与standing exit。 呈现时只有一张主卡（指派方向），且已被它击败的手抬升过，抬高行可见；挑战者按裁决路由：wins 与 competitive 是完整备选卡（带 QUALITY BAR 卡与一行理由），declined 的降级为紧凑、安静的行，各自携带裁决与"方向从中保留了什么"——永不全尺寸、永不静默丢弃、仍可应请求采用。手牌最多三张全卡挑战者，超出者进入重掷池。若自排最高的 grounded 候选不是指派方向，加一张 kicker 为 IMPECCABLE'S PICK 的卡：只允许一张，永不允许一张排名列表，且 pick 永远不占领牌位。重掷分三种语气（register）：plain（新手牌，同分布）、safer（你剩余的常规 grounded 候选加 canon）、bolder（只有外来形式、全承诺）——register 是用户在对"熟悉↔大胆"轴上的引导，轮次开启时永远由用户选择；用户说"bolder/safer"指的就是这些 register，而非 bolder/harden 命令。

standing exit（常设出口）：每一轮方向决策都提供一个安静的、永久的替代——品类标准（category standard），原样平铺直叙地执行。它是用户的门，不是你的：永不推荐它、永不拿它与骰子结果权衡、永不让它软化发到的方向。用户选中后（canon 动作、safer steer 或直白的措辞），约定成为承诺：问一次"应与哪两三个产品并排"，以其工艺水平为标尺，全保真度执行 canon；并把这种常设偏好作为品牌承诺记入 PRODUCT.md。

决策页协议：serve-question

方向决策必须可视化呈现。按文档的协议，流程是：

# 1) 先查 payload 形状
.agent/skills/impeccable/scripts/impeccable serve-question --schema

# 2) 组装 payload：指派方向领牌（含抬高行）、pick 卡（若存在）、
#    挑战者（含 QUALITY BAR 卡、裁决、保留行）、三语气 re-roll、
#    steer、canon 启用，以及 buildPath（见下文）
.agent/skills/impeccable/scripts/impeccable serve-question --start --payload <file>
# → 守护进程化，打印页面 URL 与 key 后退出

# 3) 打开 URL（应用内浏览器优先，其次系统 opener，最后展示 URL），
#    阻塞收集答案；exit 3 表示仍在等待，需循环重复
.agent/skills/impeccable/scripts/impeccable serve-question --wait --key <key>
# → ANSWER 以 JSON 打印

关键状态机规则（这些直接决定会话是否卡死）：

• ANSWER 为 {"optionId":"reroll"}：服务进程存活、页面停在加载手牌上。此时用同一 --scope 与 --mode 重跑 concept-seed，附加 --from <seed-key> --reroll <n>（首次重掷 n=1，递增），构建下一份 payload，用 --update --key <同一个key> --payload <file> 送达，然后回到 --wait。绝不允许再 --start 第二个服务进程，也不允许退回聊天——那会让打开的标签页永远停在一张不会来的手牌上；
• exit 4（页面未作答就关闭）：通过结构化提问工具重新呈现一次；仍无答案，则按指派方向无人值守推进并声明假设；
• exit 2 只有一种含义：启动脚本本身失败，这是（也是）回退到结构化提问工具的信号，不是要重试的错误；文档强调"永不预测回退：先运行脚本"；
• 能后台挂起 shell 的 harness 可以不带 --start 运行，让脚本自动打开并阻塞；
• 降级手牌（没有挑战者的掷骰）同样走页面，以单张纯文本卡 + re-roll 呈现。

卡片解剖（anatomy）是统一模板：thesis、palette、materials、first viewport、honest risk，加上挑战者的 case 行（--schema 打印精确形状）；页面从这些字段渲染身份，自动把 declined 挑战者降级为行；挑战者的目录图只作为带标签的灵感，不是构建承诺。此外还要作者化 canonCard：品类标准作为一张诚实的卡，页面保持其从属地位。

buildPath：comp-led 还是 code-led

执行契约是工作流偏好，不是每表面的决策，没有任何轮次会问它：

• 默认值从 .impeccable/config.json 的 buildPath 读取，gitignored 的 .impeccable/config.local.json 在单机与团队提交值不同时胜出；两者皆无时，只要存在图像生成，默认即 comp-led；
• 每个方向/表面 payload 都写 buildPath: { "value": <default>, "toggle": true }，页面渲染一个页脚开关并附代价说明；ANSWER 返回 buildPath 与 buildPathFlipped；
• 翻转值只约束本会话，永不写回，唯一例外：当 buildPathFlipped 为 true 且项目从未记录过 buildPath 时，轮次结束后问一次"是否设为常设默认"。两个答案都写 .impeccable/config.json——"是"写翻转值；"不，就这一次"写的是用户翻转掉的那个值（他刚通过拒绝确认了它）。只在翻转时问，不碰默认值的人什么都没说；
• Comp-led：被选卡的 comp 是法律，构建前不存在就先生成；finish review 拿构建与它审计；是全场最大胆的构图，预期会有修复轮，comp 不可选、不能静默跳过；
• Code-led：没有这个页面的 comp，也不为此道歉；QUALITY BAR 板仍校准完成度，野心移入书面契约——FIRST VIEWPORT 块 + 一个具名签名交互与运动语法，由 finish reviewer 按行为审计。code-led 不是对承诺的折扣；
• code-led 轮次仍为每张卡声明 comp 路径作为"翻转储备"：用户中途把开关切到 comp 时，--wait 返回一次 BUILD PATH FLIPPED，页面为卡槽 shimmer，此刻按"领牌优先"顺序生成每张空卡的 comp 到其声明路径，然后再次 --wait。翻回去免费，已渲染的 comp 到 finish review 时充当批判参考；
• 无图像生成时没有开关也没有选择：code-led 是唯一路径，一句话说明即可，不问。

关于轮内 comp 生产，文档还规定了公平性与帧率规则：每张卡的图是该方向的北极星 comp，在其自身调色板、字体气质与材质世界里全保真度生成；帧的宽高比取表面自己的（原生 App/移动优先是竖屏，桌面 Web 是横屏——"把手机屏横着 comp 是坏帧，不是中性默认"）；按阅读顺序生产（指派卡→pick→全卡手牌→canon），每个文件完成即写 prompt sidecar，让重掷的花费前置到最先被读到的卡上；declined 挑战者没有 comp。有并行 subagent 时按"每卡一个 agent"扇出（每个 spawn 是随技能发布的 asset producer，携带单 comp 任务包），最多四个在飞；无 subagent 则在主线程按同序生成。未被选中的 comp 留在 .impeccable/mocks/decision/ 作为本轮已花费的手牌，不携带任何批准含义；而被选中卡的 comp 不因选择而消耗——comp-led 时它是构图轮的第一选项，code-led 时它到 finish review 充当"图像敢于做什么而构建没有做"的批判参考。

最后是一条可行性真值规则：骰子可能落到的每个方向都必须已经可行——它可视化的每个关系与主张为真、有真实调色板与组件家族、有一个产品专属体验的独特构图、且在可用资产/工具/性能预算内全表面可扩展。在真值上失败的候选在掷骰前替换，绝不靠骰子救援。真值约束主张，不约束演示：greenfield 工作中，概念需要的任何说明性素材都可以全保真度作者化，在访客可能误认为真的地方标注 synthetic，并把"该换成真实素材的清单"交给用户；不可发明的只有商业与事实主张（价格、客户、基准、端点、产品不具备的能力）。

各模式的落地要求：Persuade 的开场必须在数秒内让首访者知道"这是什么、为何重要、该做什么"，转化藏在形式自身词汇里（一行钩子、可见的主行动、可读的阅读顺序）；Operate 的表达永不遮蔽任务、状态或熟悉仿射；Read 保住理解与导览；Experience 让作品本身从第一视口打头。

第 4 步：提交世界（Commit the world）

先选颜色策略，再挑颜色，四档策略如下：

策略	含义
Restrained	中性色 + 一个强调色；访客来操作或阅读时的默认
Committed	一种高饱和色承载 30–60% 的表面
Full palette	3–4 个具名色彩角色
Drenched	表面本身就是这个颜色

Persuade 与 Experience 表面被允许用更大胆的策略。颜色以页面尺度承诺：拥有整块区域的字段，而非撒在底材上的点缀。深/浅永不做默认：写一句物理场景（谁在用、在哪、什么光线下），让场景逼出答案。

字体选择被明确反对训练数据默认值。Operate/Read 由系统字栈与主力 UI 字体服务好；Persuade/Experience 需要"有观点"的字体，而以下面孔默认出现即代表你停止了寻找：Fraunces、Playfair Display、Cormorant、Lora、Crimson、Newsreader、Syne、Space Grotesk、Space Mono、IBM Plex、Inter（作展示字体）、DM Sans、DM Serif、Outfit、Plus Jakarta Sans、Instrument Sans。坚持点名其中某个，需要"其他字体都无法满足的理由"，且主题联想永远不算理由——"书想要衬线、书店想要手写体、科技想要等宽"正是这份清单要打破的联想。

文档还给出了"校准"一节，列出 AI 生成界面不分主题地聚集的几副面孔：暖奶油底 + 高对比衬线展示 + 陶土/信号红强调；近黑 + 单一霓虹强调 + 发光边缘；broadsheet 编辑体发丝线 + 斜体展示衬线 + 小字距 mono 标签。它们在被 brief 要求时都合法；但当 brief 把审美留空时，落到其中任何一个都意味着自检失败——如果有人仅凭品类、或"品类+规避清单"就能猜出你的审美，就要返工到两个答案都不明显。并补了两条反直觉规则：能量不是信任的敌人（brief 的负面约束排除的是那些装置，不是热情）；"书本感/温暖/面向儿童"的主题不软化校准（书布、书线、封套、环衬横跨整个饱和谱，落在奶油+衬线上是"默认穿着主题的西装"）。

第 5 步：记录决策——方向契约与表面简报

写代码之前，把选定方向作为"仅开发期契约"记入相关表面简报的 ## Direction contract 下。契约六个短块、至多 150 词：

1. THESIS：这个表面独有的那个想法，以及它拒绝的品类默认排布；
2. OWN-WORLD：调色板与组件语言，具体到"内容全部移除后仍 recognizable"；
3. STORY：访客理解什么、相信什么、做什么；
4. FIRST VIEWPORT：精确构图——什么在哪、什么尺度、主行动坐落何处；
5. FORM：所选形式、它在你有序名单上的位置、脚本打印的 seed key；
6. FINISH：运行的退出条件，逐字为 "unreviewed and undocumented is unfinished; this build ends with the finish review, the verdict, DESIGN.md, and every shipping raster carrying its provenance"。

表面简报是"后来跨编辑、跨会话重新加载的提醒"：一个看起来完整但 FINISH 行未清偿的页面不是完成了，是在终点线前被弃置。若某块读起来像"情绪"，说明方向还没决定；finish review 会拿渲染来审计这份契约。

文档接着给出一条硬性安全边界：方向契约永远不得复制进实现源码或任何浏览器送达的制品——包括 HTML/框架注释、隐藏 DOM、<template>、data-* 属性、渲染的 JSX/TSX 输出、序列化 props/state、React Server Component payload、客户端 bundle、metadata 或 JSON-LD、仅无障碍文本，以及放在制品旁的文件。"编译器或优化器移除开发元数据不是安全边界"；审阅者与记录者从表面简报获取契约。

对新世界/替换世界，DESIGN.md 在收尾时（第 7 步）由发布的 documenter 从已建成的世界写起：构建前写的设计手册会被拿来"对着现实辩护"，而不是描述现实；新世界交付时没有 DESIGN.md 仍是未完成运行。普通扩展则不改 DESIGN.md。

表面简报通过 CLI 读写（更新前先读）：

.agent/skills/impeccable/scripts/impeccable surface-brief read <primary-target>
.agent/skills/impeccable/scripts/impeccable surface-brief write <primary-target> <body-file> [related-target ...]

写完后再读一遍，确认六个契约块与 seed key 齐全才允许构建。简报保持小巧：范围与访客模式；受众、任务/工作、行动、证据/内容、约束；选定方向与记忆点；未决决策。不要把全局产品事实或 DESIGN.md tokens 复制进它。

另外两个交接点：comp-led 构建且任何图像生成可用时，锁定方向在构建前必须先经 visualize.md 三构图选项（被选卡的决策 comp + 两个变体）批准——"这一步被证明产出最具构图感与野心的工作"；若用户走的是 shape 命令，把选定方向交还 shape.md 并在持久化或实现之前停止。

第 6 步：全承诺构建

"构建被指派的方向，而不是它的更安全的解释。"形式提供结构、阅读顺序、组件约定与原生运动；产品提供每个事实。每一个原子都要提交：导航、按钮、输入框、链接都按形式词汇重建，一个提交过的形式里混进一个现成组件就是失职。首版就要全承诺落地，后续 pass 的存在是让已承诺的东西变清晰、变有效，而不是稀释它。

Comp-led：comp 是被测量的契约

有已批准 comp 时，它是空间契约而非情绪板；只有用户可以用明确措辞降级其权威。文档点破了一个系统性问题："模型系统性地相信自己对图像的 HTML/CSS/SVG 复刻成功了，即使它没有。"因此构建被组织成磁盘上的状态机，门禁用数字而不是记忆力：

# 方向选择后立即启动（这也是选择 ping；骰子输出会指名精确命令）
.agent/skills/impeccable/scripts/impeccable build-phase start \
  --direction <seed key> --kind <assigned|pick|challenger|canon>
# 若表面轮次已锁定 comp：
.agent/skills/impeccable/scripts/impeccable build-phase start --comp <approved comp>

之后按序推进，每关以 build-phase advance 关闭（exit 2 表示门禁失败并打印原因——修好再 advance；前门关着不许写后面的阶段）：

0. comps —— visualize.md 的 comp 轮：请求表面在自身视口下的三个构图 comp，存于 .impeccable/mocks/，各带 prompt sidecar，交用户三选一；被选者的 sidecar 标记 "approved": true。门禁清点数量并读取批准；start --comp 跳过此阶段。文档同时给出诚实的能力预警：comp-led 是前沿级任务——持住测量布局、把 plate 放到它的盒子里、跨十余次尝试处理数字读数；较小或较快的模型会做出"认得出的页面"然后卡死在 hero 门，若手头是这种模型，应在方向轮之前明说并改走 code-led。

1. spec —— 测量 comp：

impeccable comp-spec --comp <comp> --grid        # 在 comp 上写坐标网格
# 在 regions 文件中按网格跨度命名每个显著区域，然后：
impeccable comp-spec --comp <comp> --regions <file>
impeccable comp-spec --print                     # 此后构建的参考

regions 文件的纪律密集而具体：文本/控件区域吸附到其跨度内最大墨块（snap: false 保留跨度，显式 box 按所画取值）；被绘制的东西（插图、照片、图表、产品物件、材质纹理）取 plate/image/texture，代码绘制的取 text/control/chrome；每个区域带 note。字体被测量而非猜测：impeccable font-match --measure <text region> 从像素读出 cap height、宽度类与字重；font-match --rank <region> --text "..." 以 Google Fonts 指纹索引 的最近面孔 + --candidates 传入的名字，在该 cap height 下用该区域的原词渲染并按指纹距离排名（其 USE 行即 CSS）。绝不为排名去装浏览器，也绝不手写 chosen 字体进 spec——门禁只接受 font-match 写入的。spec 门在主导文本区域被测量并排名之前拒绝关闭。脚本还会拒绝两类 regions 文件：留有 comp 墨迹未被命名者（"从未被命名的东西永远不会缺席"），以及大于 comp 四分之一的 text/control/chrome 区域（"那是一列，不是元素"）。此外：超出图标预算的 inline SVG（图示、记谱、带箭头的引线）在 hero 被拒；小于 64px 的图标级 SVG 无碍；comp 的裁剪永远不是 plate（plate 门拒绝任何 comp 区域的 resample 文件——comp 的颗粒、邻接边缘与分辨率会作为艺术品被交付），裁剪只是 plate 的生成参考；plate 盒必须带余量包住整件作品（bleed: true 仅限页面真的在那里裁切它）。spec 之外不存在于页面上：comp 没画的边框、规则线、容器、chrome 一律没有。仅有的三项让步：字体（最接近的可得字体）、图标字形（够近即可）、comp 的真实缺陷（如拼写错误）。

2. plates —— 每个栅格区域都以 plate 交付：从 comp 裁剪在资产分辨率下重新生成，去掉 UI 文字，落到其 plate 路径（白墨在平面背景上则生成在色键上、抠到 alpha，使 plate 坐在页面自己的底材上而非第二张纸上）；纹理（纸、布、颗粒）只在 comp 区域不存在干净贴片时才生成为镜像平铺。命令面：

impeccable comp-spec --crop <id>            # 生成参考裁剪
impeccable comp-spec --plate-prompt <id>    # plate 的 prompt
impeccable generate-image --plate <id>      # 单区域端到端生成并对照裁剪打分
impeccable embed-prompt                     # 为生成结果嵌入 prompt 溯源

有并行 subagent 时 spawn 发布的 asset producer（impeccable-asset-producer；codex 中为 impeccable_asset_producer；Cursor 中为 /impeccable-asset-producer；GitHub Copilot 中说 "Use the impeccable-asset-producer agent"）并给它 spec 路径，让它全部产出。门禁检查每个 plate 存在、尺寸至少为区域的 1.5 倍、且读起来就是该区域。页面代码等在这个门后面："在它自己的 plates 存在之前写出的页面，是一个用 CSS 画材质的页面。"单文件交付品不改变这一点：plate 同样方式生产，内联为 data URI。--force 只存在一种情况：用户以措辞降级 comp 权威，且原话要引在 --reason 里，脚本拒绝一切其他理由。

3. hero —— 先 impeccable build-phase scaffold：把测量结果写成 CSS 自定义属性（.impeccable/build/scaffold/layout.css，--r-<id>-x/y/w/h 以 comp 百分比计，外加已测得处的 cap height、font-size、family、weight）与一个参考页 hero-reference.html（每个区域在其盒中、每个 plate 已放置）。把数字绑到你自己的语义结构上（每区域一个元素）；参考页只是位置校验，永远不是页面本身。然后只构建第一视口：comp 自身尺寸、comp 的原词逐字复制（用户是以那些词批准 comp 的；改写是 hero 通过之后的明示决策，绝不静默发生）；每个文本区域按其测得 cap height 以排名字体排设；plates 先行——在任何文字或控件之前，把每个 plate 放到 spec 盒（object-fit: cover 的 <img>、背景图或按其命名的内联 data URI），截屏到 .impeccable/review/hero-repro.png，运行 impeccable build-phase record hero 一次，确认 plate 区域读作 match，再铺语义层并 advance。门禁先拒绝任何未被源码引用的 plate，然后跑 impeccable comp-diff 写出 .impeccable/review/diff/hero/（并排图、热图、每区域一对裁剪、report.json），在总分 72% 且无未清硬性否决时通过（硬性否决：缺失区域、被矛盾的 plate 或文本块、SVG 插图、被裁切的 plate、任何分数下的自造墨块）。达标后数字读数成为随 pass 打印的 advisories，留给响应式之前的抛光轮。门禁还会把每个文本区域的 cap height、行数、字重、墨色与位置、每条 chrome 条的高度、以及 comp 安静处的墨迹增量逐条报成数字（"构建中 cap height 78px，comp 中 103px"）——"那些数字就是编辑指令"。失败时按列出的区域裁剪顺序打开再动手：missing 要补材质、contradicted 要从 spec 盒重新推导结构、drift 才轮到尺寸与间距微调；同一区域第三次只挪数值会被拒绝。文档直言这是"运行的野心赢得或失去的地方"。

4. sections —— 在 spec 的体系内构建剩余表面：相同的圆角语言、线重与调色板，comp 从未显示的东西一律没有；comp 未覆盖的区域继承已记录的体系。

5. motion —— 签名交互、reveals 与运动，编排一次而非散落。

6. responsive —— 其他视口，加常见桌面宽度（1280–1600）下的第一视口，而不只是 comp 的精确尺寸：流式列，不许有一窄一百像素就换行的定宽网格。截 desktop.png（1440 宽、全页）与 mobile.png（390 宽）入 .impeccable/review/；门禁把桌面截屏与 comp 做 diff，拒绝只在 comp 宽度下成立的第一视口。

Code-led 与两条路径共通规则

Code-led 没有 comp 也不道歉：野心在方向契约的 FIRST VIEWPORT 块与具名签名交互里，finish reviewer 按行为审计；被选的决策 comp 到 finish review 时充当批判参考。两条路径共通的是七条构建纪律，值得逐条保留：

• 第一视口是论点，不是页眉：立即、按形式在现实中的尺度演示机制；记忆测试——若有人只看一个视口就走，一小时后他会复述什么？诚实答案是"一种情绪"的话，概念还没提交；
• Prove, don't claim：演示数据是设计素材，全保真度作者化并标注 synthetic；主张不可发明；
• Author the assets，绝不用 chrome 顶替：渐变、玻璃、通用图标瓦片、以及在应有作者化资产处出现的多顶点 clip-path 多边形，是"穿着 chrome 的缺口"（检测器标记后两者）；
• 构建形式的 Web 杠杆：所选世界点名某技术（canvas、WebGL、view transitions、生成式运动）时，构建技术本身，而非其静态模仿；
• 像工作室那样控制滚动节奏：同一语法内变化密度、尺度、图像、运动与安静；全页一个间距节奏，标题上边距大于下边距；
• 真实、验证过的图像（当 brief 暗示时）：搜主题的物理物件而非品类，一张决定性照片胜过五张平庸的；
• 运动作为素材：给页面一次形式原生运动并编排，而非散落的 hover 效果；昂贵效果设限，内容默认可见。

底线：保留语义、无障碍、性能、响应式、项目约定与既有行为。

保真门禁的底层实现：comp-diff

build-phase 与 comp-diff 背后的度量实现，在 docs/COMP-FIDELITY.md 中有完整交代，值得作为第 6 步的原理注脚。该文档解释动机：v4 的方向轮与 comp 轮产出漂亮的 comp，其后的构建却是有损翻译——自造 comp 从未显示的 chrome、材质被压扁成 CSS、插图被 SVG/clip-path 近似、生成的纹理被埋在不透明涂层下；根因是"所有保真检查都让模型凭对图像的记忆给自己的复刻打分"。解法是让像素相关部分机械化：comp-diff.mjs 无外部依赖（自带 PNG 编解码），对 comp 与构建截屏做缩放对齐后，按结构（模糊灰度 SSIM + 小位移搜索）、颜色（量化直方图交 + Lab 主调色板匹配）、细节（分格高频能量比：材质存活了吗）、条带（水平分节边界对齐）四维打分，并按 spec 区域输出 side-by-side.png、heatmap.png、成对区域裁剪与 report.json，区域判词使用审阅者词汇表：match / drift / missing / contradicted，--threshold 低于标杆时 exit 3。文档给出的校准数字说明了标杆为何可信：comp 对自身 100%；位移 12px 得 87%（match）；抹掉插图后总分 90% 但 plate 区域 missing（30%）；整体改色 34%（missing）；而真实构建 59%（contradicted）——同世界的兄弟 comp 之间也只有 55–59%，即该指标能把"同一设计"与"同一世界、不同构图"分开。

第 7 步：检查与收尾

检查按批量截屏轮进行：Web 上桌面与移动一次截完；原生平台（ios/android/adaptive）按平台参考的 Verifying the build 一节，从模拟器截取各 OS 的设备类。harness 报告了用户真实视口（应用内浏览器尺寸、命名分辨率）时，把该宽度加入集合——"会坏的宽度正是用户最先看到的那个"。对着用户请求与方向契约批评渲染，修复实质性缺口，一轮确认封顶——两轮是上限，轮间批量修复，不为逐条微调多截屏。Comp-led 构建还要运行：

.agent/skills/impeccable/scripts/impeccable comp-diff \
  --comp <approved comp> \
  --build .impeccable/review/desktop.png \
  --spec .impeccable/build/spec.json \
  --out-dir .impeccable/review/diff/final

把其区域行与成对裁剪当作批评本身：并排图是构建线程自己永远看不到的视角，"一个被它评为 missing 或 contradicted 的区域，无论页面从记忆里看起来如何，都是修复项"；绝不从一张全页缩略图判断保真度。Persuade 表面还要验证模式是否完成了工作：首访者数秒内知道这是什么、为何重要、该做什么。

截屏的有效性规则："截屏只有在有效时才是证据，且在送出之前验证。"先安顿或关闭入场动效（被动画时机藏住的元素会被读成缺失元素并被修成回归）；从文档顶部截全页；comp 对比在 comp 自身像素尺寸下截取；然后每个文件打开一次确认其显示的就是名字所声称的内容——无黑区/空白、无"正确文件名背后错误的区块"、无半加载态。一份畸形截屏被送出会花费整轮：审阅者以 disposition: recapture 应答，且"它审过的任何东西都不绑定"。

第二轮检查之后，构建线程的抛光结束：不再有缺陷狩猎、微编辑脚本或重建；剩下的走交接，由新鲜上下文"发现得更好、更便宜"。Web 上（此 harness 不跑设计 hook）对变更目标运行一次 impeccable detect --json，机械项当场修掉，其余发现移交审阅者；原生平台完全跳过检测器（它读 HTML/CSS，对原生代码没有裁决权），审阅者的 floor check 是唯一 slop 门，输入包中要说明。截屏入 .impeccable/review/，每视口一文件（Web 为 desktop.png、mobile.png，用户视口加入集合时加 user-<width>.png；原生为每设备类一文件），你传给审阅者的路径就是它的 spec。

随后 spawn 发布的 finish reviewer（impeccable-finish-reviewer；codex 中 impeccable_finish_reviewer；Cursor 中 /impeccable-finish-reviewer；GitHub Copilot 中说 "Use the impeccable-finish-reviewer agent"），输入包包含：原始请求、已确认答案、制品路径、截屏路径、方向契约、既有 hook 发现、QUALITY BAR 卡与已批准 comp 路径（code-led 构建无已批准 comp，被选决策 comp 以"批判参考"名义占据该槽位）、comp-led 时的构建状态（.impeccable/build/state.json）、spec、diff 目录（.impeccable/review/diff/hero/ 与 .impeccable/review/diff/final/，其并排图、热图、区域对与 report.json 是保真证据）、craft-floor 参考路径，以及原生平台时的平台参考路径（ios.md / android.md，adaptive 两者皆带）加一行"检测器未运行"。这些 agent 的定义文件在仓库中可直接查看：impeccable-finish-reviewer.md、impeccable-documenter.md、impeccable-asset-producer.md。协议要点：审阅者没有浏览器，你没传过去的截屏就是它无法执行的检查；spawn 前绝不读取发布 agent 的定义文件（harness 在 spawn 时加载，你只欠输入包）；等 agent 用一个长超时而非短轮询循环；该审阅永不在构建线程内运行、永不继承它——codex 中 fork_turns: 0，"继承了你的转录的审阅者，继承了你的框架、你的乐观与你的抽象"。返回必须携带五个契约章节；空返回或翻车返回时以相同输入重 spawn 一次。只有完全没有 subagent 能力的 harness 才退化为"彻底退出构建上下文后的全新线程内 pass"，按 degraded/finish-reviewer.md 执行，且替代或失败替换的审阅必须在收尾时一句话披露。

处置词恰有四个，动作严格对应：

处置	含义与动作
recapture	证据失败，构建没失败。按截屏有效性规则重截后对新证据做完整审阅；建立在无效证据上的审阅不绑定任何东西，其后永不许跟 verdict pass
rebuild	保真整体失败而非补丁级。跳过修复批、立即执行重建：重新推导被点名的区域、生产被点名的资产、结果送回全新完整审阅（整个矩阵在重截屏上重跑）；告知用户在发生什么，而不是请求许可去修一个失败。仅在第二次 rebuild 指令、两个裁决同时摆上桌、或重建会丢弃用户已批准内容时才咨询用户
ship	无欠账；以其范围报告裁决，继续走 documenter
fix	一个批次应用实质性修复、重建一次、按同文件名重截同视口；重截只测量位置/加载/溢出，测不出"修复是否达到了发现所命名的质量"，所以把重截屏送回同一审阅者做 verdict，逐条给 resolved / partial / unresolved；partial 或 unresolved 再进一批。无人值守运行的预算是两轮；有人值守的上限归用户——第二次 verdict 仍列未决项时，把表格摆到用户面前，让其在"按现状交付"与"再资助一轮"之间选择。无论谁决定：某一轮什么都没解决就停止，且审阅者的发现是你唯一的工作清单，永不重开自己的狩猎；不跑第二次检测器

rebuild 与 fix 轮共享一条资产规则：任一轮回创建或替换的栅格仍是 visualize.md Produce 一节下的资产工作，像每个构建栅格一样保留 provenance（溯源）；被轮次抛弃的栅格在同批删除。任一轮回结果送审前，对制品栅格所在目录运行：

impeccable embed-prompt --scan <asset-dir...>

清掉它报告的每个文件缺的东西：生成栅格嵌精确生成 prompt，来源/库存/既有栅格嵌出处。扫描只读；删除仅保留给轮次抛弃的栅格。

裁决报告有严格的范围纪律：在审阅者自己的处置词下、在其实际范围内报告。"审阅者评定的三条修复全部 resolved"是它支持的声明；"没有实质性问题了"不是。带未决实质发现的表格永不被宣布为 pass、被软化、或被包装成整表面批准（当只被评分的是修复清单时）。当用户对 ship 提出反证——他们自己的截图、一处与 comp 具名的不匹配——那份证据优先于你做的所有截屏：把它的材料放进输入包，spawn 全新审阅者做新的完整审阅。"就地打补丁并自我认证，是被拒页面被交付两次的路径。"

最后 spawn 发布的 documenter（impeccable-documenter；codex 中 impeccable_documenter），给项目根、制品路径、方向契约、PRODUCT.md、document.md 参考路径与应书写的边界；它从已建成的世界记录 DESIGN.md 与 sidecar——"地面真值优先于意图"；无 subagent 时按 degraded/documenter.md 执行。Documenter 在最后一处修正落地之后运行：若文档之后又有修复轮，对变更表面重跑 documenter，因为"描述一个已不存在布局的 DESIGN.md 会把缺陷变成系统指南"。收尾的一句话总结整个流程："干净的检测器通过不等于完成；完成是契约被遵守、comp 被尊重、审阅被关闭、系统被记录。"

验证路径：仓库中如何测试 new-work 交互层

new-work 的交互部分（决策页与离线图像生成）由一套确定性冒烟套件覆盖，运行方式为 bun run test:new-work-e2e（刻意放在 bun run test 之外、按需执行），说明见 tests/new-work-e2e/README.md。tests/new-work-e2e.test.mjs 用真实 Chromium（Playwright）打开 serve-question 服务出的决策页，由 user-bot.mjs 这个"脚本化用户"驱动真实点击（button.choose、#reroll、#canon、#steer 输入、关标签），断言 serve-question 协议输出：

• pick assigned 返回所选 optionId、输入的 steer、hero/board 字段，以及 --wait 打印的 CHOSEN CARD 指令；
• re-roll with steer 保持守护进程存活，--update 重发下一手牌，页面自行重载，随后的一次选择是终态（状态文件清理）；
• canon 返回 optionId: canon 并打印 CANON CHOSEN 指令；
• tab close 停止页面心跳，使 --wait 以 exit 4 PAGE CLOSED 退出——与上文"exit 4 只重呈现一次"的协议闭环；
• text-only 卡在无 hero 的选项下渲染且没有 .media 区域；
• fake 图像生成（IMPECCABLE_IMAGE_GEN_FAKE=1 切换离线替代）：同一 prompt 产生相同字节、文件存在、带 SYNTHETIC 标记，不同 prompt 产生不同调色板。

user-bot 的策略即一份 JSON 动作序列（{"pick":"assigned"}、{"reroll":true,"steer":"warmer"}、{"canon":true}、{"close":true} 等），它从 .impeccable/questions/<key>.state.json 发现运行中的守护进程——这正是决策页协议中状态文件在仓库里的落点。决策页卡片的目录素材则以 tests/fixtures/concept-catalog/ 中的 fixture 目录驱动，其 QUALITY BAR 块要求每个概念"立刻给出调色板与材质词汇、字体声音、组件角色与一个标志性状态变化"，对应 new-work 中挑战者的"具名视觉系统"纪律。此外，tests/skill-reference.test.mjs 对 skill/reference/new-work.md 做引用完整性检查（其 skill/reference/new-work.md 与 .agent 下的文档是同一份参考的源码/安装态副本），保证参考文档中的相对链接在发布构建中保持有效。

小结：一份可核对的清单

new-work 流程的可执行要点可以压缩成如下清单，全部以 new-work.md 为准：

1. 判定：Redesign / Established / Incomplete / Greenfield 四选一；局部新增不进身份工程；
2. 提问：一轮 2–3 个按 mode 组织的问题，外加成功形态/不可动项/"显得不对"三项；
3. 创意幅度：局部扩展直接塑造；整表面走 concept-seed --scope surface；新世界/替换走 --scope direction 五步协议，先脚本后代码；
4. 决策页：serve-question --start/--wait/--update，exit 2 才回退结构化工具，exit 3 循环等待，exit 4 重呈现一次后按指派方向推进；buildPath 偏好随 .impeccable/config.json 走，翻转只约束会话；
5. 提交世界：四档颜色策略、拒绝训练默认字体、通过"品类可猜测"自检；
6. 记录：六块 ≤150 词的方向契约 + seed key 写入表面简报，永不进任何送达制品；DESIGN.md 留给收尾时的 documenter；
7. 构建：comp-led 走 comps→spec→plates→hero(72% 门)→sections→motion→responsive 状态机，build-phase advance 逐关推进；code-led 把野心写进 FIRST VIEWPORT 契约；
8. 收尾：两轮批量截屏为上限，comp-diff 的最终报告是批评本身，finish reviewer 四处置词（recapture/rebuild/ship/fix）严格对应动作，embed-prompt --scan 清溯源，最后 documenter 从已建成世界写 DESIGN.md——"unreviewed and undocumented is unfinished"。