ss-build

执行此工作流前，请遵循每个会话一次的更新预检。

使用组合式 StyleSeed 方法构建

以注册表为先的产物边界

当 .styleseed/project.json 和 .styleseed/artifacts/index.json 存在时，先解析请求的产物 ID，然后只读取 .styleseed/bundles/<artifact-id>.md 和 .styleseed/manifests/<artifact-id>.json。对于注册表项目，绝不回退到全局旧版 bundle。只有在不存在注册表时，旧版项目才可使用 .styleseed/effective-rules.md。

构建方法本身就是产品。评分和截图只是辅助证据，而非设计判断的依据。

步骤 1 — 编写代码前确定规则集

如果 .styleseed/project.json 或 .styleseed/artifacts/index.json 中任一文件存在，则必须要求注册表完整且有效，并使用已安装的解析器通过 scripts/resolve-context.mjs --project-root . --artifact <artifact-id> --agent <agent> 解析请求的产物。读取 .styleseed/bundles/<artifact-id>.md，并保留 .styleseed/manifests/<artifact-id>.json 作为来源记录。不要创建 STYLESEED.md、重新开始设置，或因为注册表不完整、无效或缺少编译输出而使用旧版 bundle。若范围缺失，请与用户确认。若变更涉及多个产物，请分别解析并检查每个受影响的产物。

只有在两个注册表文件都不存在时，才使用旧版路径：如果缺少 STYLESEED.md，请在编写 UI 代码前运行 /ss-setup；否则保留该文件。使用 --from-lock STYLESEED.md --agent <agent> 调用 /ss-resolve（Claude Code）或 $ss-resolve（Codex），读取 .styleseed/effective-rules.md，并保留 .styleseed/manifest.json。

如果提供的视觉参考未被所选语法涵盖，请在所选项目边界内使用 /ss-reference。绝不要把不熟悉的参考简化为只更换调色板，也不要在未经人工批准的情况下替换已批准的项目选择。解析成功后，不要加载 llms-full.txt。

步骤 2 — 组合，而非即兴发挥

编译后的 bundle 已按权威顺序组合各项内容：核心不变量 → 所选语法 → 表面适配器 → 领域/页面 → 品牌配方 → 可选配置文件 → 有界锁定 → 工艺基线。使用清单中的选择和源哈希检测偏移。只有当 bundle 指向真正的歧义时，才打开完整源文档；不要临时重新拼装手册。

编写代码前，用一行说明生效规则集，例如：

operations-console × SaaS × dashboard × enterprise-workbench × swiss × locked brand tokens

按权威性解决冲突。配置文件或锁定规则不得豁免任务适配性、一致性或无障碍要求。

步骤 3 — 运用设计判断进行构建

• 在首屏展示语法所对应的用户任务和主要决策。
• 确立一个视觉焦点；避免使用权重相同的模板网格。
• 遵循语法对构图、密度、字体、颜色、表面、图像/数据、操作、状态、响应式布局和动效的约定。
• 使用配方中的容纳方式、几何形态、控件、集合和导航形态。使用捆绑模式组件时，在产物根节点设置 data-styleseed-recipe="<id>"。
• 使用产品专属的内容和证据。绝不要复制 StyleSeed 演示内容或参考界面。
• 在相关场景中实现加载、空状态、错误、焦点、减少动态效果和响应式行为。

调整间距时，请使用解析器的空间角色指南。 选择间距前，先阅读任何已编译的 spacing 部分。将其作用域变量映射到现有组件，并保留未声明的角色。刻意组织相关内容；不要叠加多层内边距，也不要缩小字体来实现高密度。实现必须实际使用这些变量；仅配置变量不会改变渲染后的布局。

第 4 步 — 代码门禁循环

对于交互式工作，在测试前明确用户所需的结果：例如，已保存的设置在重新加载后仍然保留，保存失败时草稿得以保留，或者查看者无法执行编辑者操作。复用项目实际使用的实现和测试工具；与项目脱节的演示或对源文本的断言，无法证明该操作确实有效。

构建注册表时，将适用的结果记录为产物中的 validation.functional.scenarios，并通过 implementation.sourceRoots 覆盖测试及其实现依赖项。使用已安装的 ss-score 参考文档 references/functional-checks.md 运行并保留证据。任何必需场景失败、跳过、缺失或未执行，都会阻止任务完成，即使代码分数很高也不例外。如果现有运行器无法执行该项目，请准确报告未经验证的结果；不要为了获得通过结果而省略该要求。静态产物可以省略功能场景，但必须明确说明不适用的原因。

对实际实现运行 /ss-score。分数必须注明生效的规则集，并检查核心不变量和特定语法的特征。修复收益最高的问题，并重新评分，最多进行三轮修正；若分数达到 ≥80，则提前停止。优先处理损坏的流程和核心问题，再考虑可选的分数提升。如果无法通过，请报告实际分数和剩余问题；不要通过调用其他技能来重新开始修正轮次计数。

第 5 步 — 像素门禁循环

对于每个可渲染的产物，运行 /ss-verify：使用适配器渲染器，检查每个必需的视口、帧、页面及相关状态，修复感知层面的问题，然后重新渲染。如果没有可用的渲染器，请说明视觉门禁已跳过；绝不要声称已通过。

第 6 步 — 提交并提供证据

报告：

• 生效的规则集及其适用原因；
• 最终代码分数；
• 视觉验证状态和视口；
• 门禁期间进行的重要修复；
• 项目／产物配置路径（或旧版 STYLESEED.md）以及任何编译后的语法路径。

规则

• 先处理语法，再编写代码；构建后运行代码门禁；最后运行像素门禁。
• 输出语法是功能性的。品牌配方是形态学的。美学配置文件是可选的。两者都不能替代语法，也不能用于克隆品牌。
• 必须始终能识别主要操作；只有当语法赋予额外颜色稳定的语义或类别含义时，才允许使用这些颜色。
• 每次修改 UI 后，都要重新阅读锁定文件和语法。