跳到主要内容

Work Packets

状态：基线收束草案 最后更新：2026-05-08 用途：定义本仓库中轻量需求 / 变更包 / 任务协同层的边界、对象和状态机

1. 本目录定位​

packets/ 是建立在生态事实源和产品知识库之上的轻量工作承载层。

它用于承载需要人类参与者、项目 owner、个人域 Agents 或团队域多 Agent 协作框架共同推进的生态级、产品级、边界级、风险级或验收级工作。

一句话：packets/ 负责“什么工作值得被生态看见、领取、推进、审计和验收”；具体工作内部如何澄清、拆解、执行、验证和归档，可以交给项目 repo、个人域 Agents、团队域 Agents 或 open-cowork。

2. 先轻量协议，后工具集成​

当前阶段优先采用仓库内 Markdown + YAML frontmatter 的轻量协议。

原因是：

  • 先稳定 FinTec AI Ecosystem 自己的需求、变更、任务、验收和状态语义；
  • 避免被第三方 issue / task / project 工具的模型反向塑形；
  • 保持人类和 Agents 都能直接读写、审计和回放；
  • 等真实协作样本足够后，再决定是否集成成熟开源任务 / 看板 / 协同系统。

后续可集成的外部系统应服务本目录的对象模型，而不是替代本目录的事实边界。

3. Packet 类型​

当前先保留最小类型集合：

类型用途当前入口
sync项目实践向生态层低强度回流信号、发现、接口线索或复用机会sync/README.md
escalation项目实践请求生态层正式判断、裁决、边界更新或基线更新escalation/README.md
requirement后续用于承载生态级或产品级需求包待真实需求触发
change后续用于承载会影响事实源、产品定义、接口、路线或风险边界的变更包待真实变更触发
task后续用于承载可领取、可执行、可审计、可验收的工作包待真实协作触发

当前不急于创建 requirements/、changes/ 或 tasks/ 子目录。只有当真实协作需要稳定承载时，再按类型扩展。

当前也不需要创建示例 packet。第一批真实 packet 应等本仓库完成核心文档收束，并开始与 Labs 团队实际并行推进的产品 / 系统 / 项目实施线衔接时，再从真实需求、真实变更和真实协作任务中自然生成。

截至 2026-05-09，FinClaw 已进入与实际工程仓库衔接的准备阶段，因此已产生第一批真实 sync：

这两份 sync 不是示例，也不是日常任务看板；它们用于把 FinClaw 专属 Program Controller 会话和 open-cowork 后续迭代输入接入当前事实源。

4. 最小元数据​

后续真实 packet 建议使用以下最小 frontmatter：

packet_id:
type: sync | escalation | requirement | change | task
status: draft | ready | claimed | in_progress | review | accepted | returned | archived
project:
scope: ecosystem | product | interface | research | implementation | risk | governance
owner:
contributors:
reviewers:
priority: P0 | P1 | P2 | P3
source_refs:
target_refs:
open_cowork_ref:
created:
updated:

字段含义：

  • packet_id：稳定编号，便于门户、图谱和外部协作系统引用；
  • type：工作包类型；
  • status：当前状态；
  • project：相关生态对象或项目，例如 finclaw、data-horizon、ecosystem；
  • scope：影响范围；
  • owner / contributors / reviewers：责任与审计角色；
  • source_refs：来源材料、讨论、项目实践或参考文档；
  • target_refs：完成后应回写或影响的正式文档；
  • open_cowork_ref：若具体执行交给 open-cowork 或其他协同框架，记录外部任务 / workspace / evidence 引用。

5. 状态机​

推荐状态流：

draft
  -> ready
    -> claimed
      -> in_progress
        -> review
          -> accepted
          -> returned
  -> archived

状态含义：

  • draft：尚在形成，不能领取；
  • ready：已具备背景、范围、验收口径，可以领取；
  • claimed：已有 owner 或 agent 接手；
  • in_progress：正在执行；
  • review：等待审计、验收或生态 / 项目 owner 判断；
  • accepted：已验收，并完成必要回写；
  • returned：验收未通过或需要补充；
  • archived：不再推进，保留追溯。

6. 与 open-cowork 的衔接​

packets/ 不替代 open-cowork。

推荐分工：

  • 本仓库负责：生态事实、产品约束、工作包入口、状态、验收口径和回写位置；
  • open-cowork 负责：复杂任务内部的意图澄清、任务契约、分派、执行、验证、评审和归档；
  • 个人域 / 团队域 Agents 负责：在自己的执行环境中完成具体工作，并把 evidence、结果和待回写结论返回 packet。

如果某个 packet 交由 open-cowork 执行，应在 open_cowork_ref 中记录对应任务、workspace、evidence 或验收结果。

7. 回写规则​

packet 不是新的事实源本身。

当 packet 被接受后，稳定结论必须回写到至少一个正式位置：

  • baseline/
  • contexts/
  • registry/
  • projects/*
  • governance/
  • 接口 / 对象 / 产品定义 / MVP 定义 / 验收文档

packet 本身保留状态、证据、审计和追溯链接，但不应成为第二套长期事实体系。

8. 收束原则​

后续扩展 packet 能力时，应遵守：

  • 只承载值得被生态或产品层看见的工作；
  • 不记录每个工程子任务、临时 todo 或个人执行细节；
  • 不把所有项目 backlog 搬进本仓库；
  • 不让 packet 替代正式文档回写；
  • 不让第三方工具模型反向决定生态语义；
  • 优先让门户和图谱读取 packet metadata 自动生成状态视图。