| name | task-asset-review |
| description | 非简单 Workspace 任务开始探索、设计、诊断、实现或验证时，持续收集可能影响长期 Rule、Skill、capability Contract 或产品能力的轻量信号；用户要求复盘或沉淀，或 Task Finish 触发 finalize 时也使用。负责 observation、资格审查、人工决定和新任务交接，不保存完整轨迹。 |
Task Asset Review Skill
本 Skill 是 buildr.task-asset-review/v2 的默认 provider。它从任务期间的公开、可观察节点维护轻量 observation，在任务结束时完成审查并请求人工 accept/reject；它不读取隐藏推理，不保存完整轨迹，也不在原任务修改长期资产。
职责边界
- 本 Skill 拥有：是否创建 observation、信号筛选、持续更新、资格审查、候选分类、人工决定、去向交接和删除条件。
task-finish 只触发 selected provider 的 finalize 并等待结果；不得汇总信号、执行资格门禁或判断最终沉淀什么。- accept 只建立新任务 handoff。后续必须重新进入
task-triage，原任务保持结束。
- provider optional 不可用或本地状态不可写时，报告降级；不得用最终总结伪造持久化 observation。
- 不为简单问答、翻译、单一稳定事实查询或没有 Workspace 资产含义的对话机械创建 observation。
共享位置与写入者
内部 helper 位于：
scripts/observation.mjs
它从 --workspace-root 向上定位 .buildr/workspace.yml，按稳定 workspace.id 解析：
<Buildr user state>/asset-review/<workspace-id>/inbox/<observation-id>.md
这是用户级共享 inbox：同一 Workspace 的所有 worktree 与非 worktree 任务使用同一位置。每个任务使用独立 observation id；root Agent 是单一写者，--owner 必须稳定且与文件 owner 匹配。不要让 subagent 直接写 observation；由 root Agent 吸收其可验证报告。owner mismatch 必须停止，不得覆盖或选择任意文件。helper 对文件使用同目录临时文件加 rename 的原子替换。
helper 是 Skill 内部资源，不是公共 Buildr CLI。不要为该生命周期启动 Hook、daemon、watcher、事件总线、数据库、全局索引、CAS 或复杂锁。
何时开始观察
进入非简单 Workspace 探索、设计、诊断、实现或验证任务后，先判断当前可见事实是否可能暴露长期资产差距。高价值信号包括：
- 用户纠正了长期边界、职责、scope、授权或领域语义；
- 初始假设被代码、文档、命令、测试或用户反馈推翻；
- 同类失败、重试、回退或无效重复暴露了稳定根因；
- 现有 Rule、Skill 或 capability Contract 只部分覆盖真实流程或资源；
- consumer/provider guarantees、effects、authorization 或 result evidence 需要变化；
- 任务暴露了产品行为、API、状态、数据模型或体验缺口；
- 并发 task environment 与共享本机状态的 owner、identity、隔离或 cleanup 发生可复现冲突；
- 某个可复用动作显著降低风险或成本。
不要把特定 CLI、Launcher、daemon、端口或 registry 当成固定检查清单。它们只有在体现更一般的共享状态、所有权或并发边界时才成为信号。
首次命中后执行：
node "<skill-root>/scripts/observation.mjs" start \
--workspace-root "<workspace-root>" \
--observation-id "<task-or-thread-stable-id>" \
--owner "<root-agent-task-owner>" \
--source '{"task":"...","thread":"...","worktree":"...","branch":"...","change":"...","commit":"...","project":"...","service":"..."}'
来源字段只填实际存在的值。observation id 和 owner 使用稳定的字母、数字、点、下划线或连字符。
持续记录
任务出现新的高信息量节点时追加一条精炼 observation：
node "<skill-root>/scripts/observation.mjs" observe \
--workspace-root "<workspace-root>" \
--observation-id "<id>" \
--owner "<owner>" \
--message "<已验证事实及其潜在长期含义>" \
--evidence "<用户决定、文件、命令、diff、测试或稳定引用>"
只保存会改变资产审查结论的精炼事实和证据引用。不得保存完整原始对话、完整工具日志、逐节点回放、模型隐藏推理、chain-of-thought 或内部 deliberation。一次性失误、偶发机器状态和已被现有资产完整覆盖的事实可以不记录。
Finalize 与资格审查
显式任务结束、Task Finish finalize 或用户要求复盘时：
- 读取当前 observation 和仍可访问的最终证据。
- 重建简短执行轮廓，选择高信息量转折点；不逐条复述。
- 核验候选目标源资产及其正文、manifest、模板、脚本、metadata、contract 和必要的真实产物。
- 对覆盖度给出：完整覆盖、部分覆盖、存在冲突、尚无资产。
- 只有同时具有明确证据、长期有效、可操作、可复用、scope 可确定且未被完整覆盖的发现才合格。
- 将结论限制为四类：
rule：长期价值、边界、约束或禁止事项；skill：可复用专业动作、流程、命令、检查和完成标准；capability-contract：consumer/provider 的 guarantees、effects、authorization、decision points 或 result evidence；product-followup：产品行为、API、数据模型、状态流或用户体验变化。
- Command、Component 和普通 docs 不作为直接候选；只分析其背后的四类语义。
执行：
node "<skill-root>/scripts/observation.mjs" finalize \
--workspace-root "<workspace-root>" \
--observation-id "<id>" \
--owner "<owner>" \
--review "<覆盖核验、候选类型、证据和建议动作>"
若任务从未产生 observation，返回 no-observation。若现有 observation 经审查没有价值，明确向用户说明建议 reject；不要把它升级为 tracked 记录。存在候选时返回 awaiting-human 并请求明确 accept/reject。
人工决定
Reject
用户明确认为无价值或拒绝候选时：
node "<skill-root>/scripts/observation.mjs" reject \
--workspace-root "<workspace-root>" --observation-id "<id>" --owner "<owner>"
精确删除 observation；不创建 tombstone、Git 记录或“调查无修改”日志。
Accept
用户接受候选时：
node "<skill-root>/scripts/observation.mjs" accept \
--workspace-root "<workspace-root>" --observation-id "<id>" --owner "<owner>" \
--candidate-type "<rule|skill|capability-contract|product-followup>" \
--summary "<用户接受的明确范围>"
然后结束原任务并创建新的 task-triage。根据新任务自身语义决定 main checkout 或 task worktree；accept 不自动扩大写入授权。
新任务 Handoff 与长期记录
新任务确定位置后记录 destination：
node "<skill-root>/scripts/observation.mjs" handoff \
--workspace-root "<workspace-root>" --observation-id "<id>" --owner "<owner>" \
--destination '{"task":"...","worktree":"...","branch":"...","change":"...","assetType":"...","assetId":"..."}'
Rule、Skill、capability Contract
只有新任务实际修改目标资产时，才从 templates/asset-maintenance-record.md 创建：
asset-maintenance/
rules/<rule-id>/records/<date>-<record-id>.md
skills/<skill-id>/records/<date>-<record-id>.md
capability-contracts/<contract-id>/records/<date>-<record-id>.md
维护记录包含 observation 来源、正式核验结论、实际修改、OpenSpec change、验证、commit 和集成去向，并与资产修改一起提交。不要创建 asset.yml；当前资产事实继续来自已有 manifest、frontmatter 和 contracts。
只有记录与资产变更成功集成后，才能执行：
node "<skill-root>/scripts/observation.mjs" complete ... --outcome asset-integrated
新任务暂停或失败时保留 observation。正式调查后不修改资产时不保留 tracked 记录，记录 destination 后以 --outcome no-change 删除 observation。
Product follow-up
product follow-up 重新使用 task-triage 和 OpenSpec。新 proposal 或 design 必须吸收必要来源事实；不得再复制 asset-maintenance 历史。facts 安全进入 artifacts 后，以 --outcome product-absorbed 删除 observation。
输出契约
显式复盘或 awaiting-human 时向用户输出：
- 简短执行轮廓与关键转折；
- 执行质量反馈及证据；
- 候选类型、覆盖结论、目标 scope/asset 和建议动作；
- observation identity 与共享 inbox 状态；
- 明确的 accept/reject 请求。
Task Finish 调用时返回：
no-observation：没有 observation，继续收尾；discarded：审查无价值且用户已 reject，继续收尾；awaiting-human：必须在 cleanup 前等待决定；- degradation：provider/helper 不可用，报告原因但不伪造结果。
不要把“收尾”解释为长期资产写入授权，也不要在原任务自动实施接受的建议。
