用途：当开发小组（pod）开始或交接实现、QA、设计工作时使用，将分配的用户成果转化为可运行软件。构建者、QA和设计师属于能力角色，相邻角色可由同一人承担，除非明确选择独立。
主要能力与用法：先运行 rig whoami --json，再按 project.yaml -> mission.yaml -> active slice.yaml -> 所选组件或波次图 -> addressed context 的顺序解析。完整查找与优先级规则见 docs/reference/product-journey-sdlc.md#resolve-the-selected-path（已安装：$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path）。只阅读选定地址和本任务所需源码；档案中的技能是能力，不是必读清单。无组合时为轻量 Part A。角色名和空闲席位不增加关卡；明确选定的严谨性和编写的波次边界保留其命名检查。
构建与验证：澄清有重大影响的不确定性，检查现有接缝，完成一个连贯成果。修复缺陷前先复现；使用能区分失败的测试，并通过公共表面验证。在成果和文件范围允许下保持较大块。TDD是反馈回路，不是双席位协议。构建者报告确切候选项、变更行为、命令和观察结果，以及剩余不确定性。不隐含通用编辑前提案、QA批准或编辑后关卡；明确选择时遵守其边界并将相关证据直接发给其负责人。
QA与设计：QA将交付行为与实际契约比较，阅读差异并实际运行结果，避免只重复实现的测试。微小变更时构建者可兼任QA；选择独立QA时排除作者。波次在其编写边界获得独立审查，而非每个切片。设计在成果需要时澄清用户流程和模糊行为。浏览器和 dogfood 技能只在相关UI旅程加载，不是每项任务。在分配的 dogfood 中，仅在授权范围内修复并重测；只读任务保持只读。若测试者成为作者，在需要独立评估时保留该归属。
阻塞与返回：意外失败使用 systematic-debugging，声称成功前使用 verification-before-completion。权限提示是具体阻塞；报告命令和后果，不要标为进展。缺失决策交给能解决它的负责人。通过所选交接返回候选项和证据。不要仅为让空闲QA、守卫或审查者忙碌而创造义务。质量是带诚实证据的可运行产品，而非转交次数。