团队项目 Repo：产品 MVP 形态

核心结论

当前这个仓库不只是 OrgReOrg / Harness 的研发仓库，也是未来产品形态的最小 Demo。

未来一个项目组、部门或客户团队，可以拥有一个类似的团队项目 repo。这个 repo 不只是存代码或文档，而是承载：

• 当前状态看板。
• 团队知识库。
• 决策记录。
• 实验报告。
• 任务技能包。
• 测试和 benchmark。
• 发布网站。
• 企微 / 飞书 / Web 的交互入口。

换句话说，未来产品不是单纯给团队一个聊天机器人，而是给团队一个可演进的 Agentic Knowledge Workspace。

为什么 repo 是 MVP 容器

P0 阶段，一个 repo 已经能提供很多企业协作所需的基础能力：

能力	repo 中的实现
版本管理	Git commit、branch、PR、review
知识生产	workspaces/variai/evidence/inbox、workspaces/variai/evidence/raw、workspaces/variai/knowledge/wiki
决策追溯	workspaces/variai/knowledge/decisions、workspaces/variai/site/knowledge/decision-log.md
状态同步	workspaces/variai/registry/project-status.json -> workspaces/variai/site/project-progress.md
发布阅读	workspaces/variai/site/、MkDocs、Cloudflare Pages
实验验证	framework/evals、scripts/ wrapper、tests/、workspaces/variai/outputs
Agent 工作规则	AGENTS.md、CLAUDE.md、任务技能包
质量门禁	vault_lint、MkDocs strict build、pytest、CI

这不是最终产品的全部形态，但它是最小可运行形态。

真实实践 Case 不是临时 Demo

当前 repo 里的 demo、benchmark 和 case study 应优先来自真实协作中已经暴露的问题，而不是为了展示能力临时编造。

这条原则很重要：Harness 要做的是团队上下文管理和协作 loop 工程，只有真实问题才能暴露权限、来源、成本、review、发布、CI、外部链接、Agent 循环和人机协作边界上的风险。编造样例可以做单元测试，但不能证明产品能落地。

因此，真实问题进入项目时要按固定路径处理：

真实触发
  -> Evidence 保留必要来源线索
  -> Ontology 抽象成对象、关系、规则、Skill、Workflow 或实验制品
  -> Runtime Projection 变成可复跑 demo、benchmark、case study、CI gate 或 review queue
  -> Review 判断是否是缺陷、取舍、文档缺口或真实 adapter handoff
  -> Publish 发布脱敏结论、验证结果和下一步

当前已经可以作为真实实践 case 的类型包括：

• GitHub Actions / MkDocs / Cloudflare 构建失败：验证 CI 状态采样、失败摘要、retry policy 和项目 timeline。
• GitGuardian 告警：验证 secret lint、发布前脱敏和安全边界。
• 微信临时链接追溯失败：验证外部资料 closure，避免 Agent 因必须找到稳定原文链接而循环。
• Agent 在同一点重复处理：验证 loop 的退出条件、handoff 和 Review Queue。
• 团队成员追问“现在进度是什么”：验证项目状态看板、实验导航和发布站点是否真的可读。

进入 demo 的 case 必须写清三件事：真实来源类型、脱敏边界、工程验证目的。发布层只展示可复核的摘要和验证信号，不保留原始聊天全文、截图、临时 token、完整日志、完整 SHA、个人隐私或客户资料。一旦真实问题已经转换为可复跑检查，就由检查和 Review Queue 接管，不能继续围着同一张截图或同一封邮件反复循环。

最小团队空间结构

未来给一个团队或部门创建空间时，最小结构可以是：

team-project/
  AGENTS.md
  CLAUDE.md
  packaging.manifest.json
  framework/
    connectors/
    context/
    dashboard/
    evals/
    governance/
    policy/
    task_skills/
    templates/
    workflows/
  workspaces/
    <workspace-id>/
      evidence/
        inbox/
        raw/
        ingestion/
        registry/
      knowledge/
        wiki/
        projects/
        decisions/
        system/
      registry/
        workspace-topology.json
        project-status.json
        experiment-reports.json
      site/
        index.md
        project-progress.md
        knowledge/
      connectors/
        wecom/
      outputs/
  mkdocs.yml
  scripts/
    vault_lint.py
    package_boundary_lint.py
    generate_project_progress.py
    eval_*.py
  tests/
  workspaces/variai/connectors/wecom/

P0 已经开始用结构化状态数据生成 project-progress.md：当前 Demo 的私域状态写在 workspaces/variai/registry/project-status.json，通用生成器在 framework/dashboard/project_status.py，CLI wrapper 是 scripts/generate_project_progress.py。产品化后，应该继续从项目计划、实验报告、ADR、issue、PR、知识卡片和工具日志中自动生成更多字段。

可打包层与私域层

当前 repo 是完整 MVP，但未来产品化时不能把整个 repo 原样打包。它要拆成两层：

• 可打包层：Agent 工作规则、workspace 模板、Evidence/Knowledge/Registry/Site 看板结构、SearchConnector、Tool Gateway、WeCom adapter contract、eval harness、任务技能包规范、权限和审计规则。
• 私域层：当前 OrgReOrg / Harness 的项目讨论、路线图、实验语境、真实 owner、组织职责、业务资料和团队知识库内容。

当前 MVP 的领域知识是“如何开发这个 Demo”。未来某个部门或项目组使用产品时，这部分会替换成它自己的部门知识、项目状态、业务流程和组织事实。

因此后续新增文件时需要先判断：

文件类型	默认归属	说明
adapter contract、schema、lint、generator、eval harness	可打包	用合成 fixture 验证
任务技能包 manifest、模板和 lint	可打包	包内不存组织事实，只存任务工作流和验证方法
workspaces/variai/evidence/inbox、workspaces/variai/evidence/raw、项目 ADR、真实讨论	私域	不进入通用产品包
workspaces/<workspace-id>/registry/project-status.json	私域	每个团队替换成自己的状态数据
workspaces/variai/site/project-progress.md	混合	页面结构由 generator 生成，当前状态内容不可打包
企业微信接口代码	混合	adapter 可打包，真实通讯录和消息不可打包

当前 repo 已经前置建立 framework/、workspaces/variai/registry/ 和 packaging.manifest.json。后续不再把新的可打包代码继续堆在 scripts/；稳定模块应迁入 framework/，scripts/ 只保留 CLI wrapper 和兼容入口。

状态看板应该回答什么

团队成员进入项目空间后，第一眼应该知道：

• 当前项目处在什么阶段。
• 预期目标是什么。
• 哪些模块已经完成。
• 哪些模块正在进行。
• 哪些模块被阻塞。
• 每个实验结论是什么。
• 决策依据在哪里。
• 下一步应该做什么。

所以 workspaces/variai/site/project-progress.md 不是普通文档，而是未来产品里的项目状态视图原型。

与企微 / 飞书 / Web 的关系

未来普通团队成员不一定直接打开 GitHub。

更合理的入口是：

企业微信 / 飞书 / Web
  -> 查看项目状态
  -> 提问或补充资料
  -> 接收主动询问
  -> 审核知识卡片
  -> 跳转到 Site 页面阅读稳定内容

repo 仍然是底座：Agent、工程成员和发布系统在 repo 中维护知识、决策、测试和发布内容。

当前 repo 的自审

当前已经具备：

• workspaces/variai/site/project-progress.md：研发进度总览。
• workspaces/variai/registry/project-status.json：结构化项目状态数据。
• framework/dashboard/project_status.py / scripts/generate_project_progress.py：项目状态页生成器和 CLI。
• workspaces/variai/evidence/：原始证据、来源线索和入库样例。
• workspaces/variai/knowledge/：知识生产和决策沉淀。
• workspaces/variai/registry/：机器可读状态、路由、权限和实验索引。
• workspaces/variai/site/：团队阅读网站源码。
• framework/ / scripts/ / tests/：本地实验、可复用实现、CLI wrapper 和验证。
• 双远程 GitHub 推送和 Cloudflare Pages 发布镜像。
• ADR-014 自试用自演进闭环。
• ADR-015 任务技能包治理。

当前还缺：

• 从 ADR、issue、PR、知识卡片和工具日志自动汇总更多看板字段。
• 真实企微入口。
• 结构化 owner / module / status 数据。
• 真实 SearchConnector 和 Tool Gateway。
• 面向非工程团队成员的 Web 状态界面。
• 跨多个项目 repo 的组织级汇总视图。
• 新团队 scaffold 已能生成最小 Site、Knowledge、workspace topology、project status、experiment registry 和 Semantic Review seed；后续还要接入真实 repo 创建流程。

产品化方向

下一步不应只继续堆文档，而要把 repo 空间产品化：

1. 继续完善 project_status 数据结构，把 owner、阻塞项、质量信号和更新时间拆成可查询字段。
2. 定义 experiment_report 数据结构。
3. 定义 knowledge_card 提升流程。
4. 让 dashboard generator 聚合 project status、实验报告、ADR 和知识卡片。
5. 通过企业微信或 Web 展示同一份状态数据。
6. 支持项目空间模板，一键创建新团队的 repo / workspace / CI，并自动替换 scaffold seed。

相关页面

• 研发进度总览
• Framework 与 Workspace 边界
• Repo、Evidence、Knowledge、Site 与企微
• 讨论-记录-开发-测试循环
• 任务技能包与可执行知识治理
• ADR-016：采用团队项目 Repo 作为产品 MVP 形态
• ADR-017：Framework 与 Workspace 边界，支持未来产品打包
• ADR-020：采用结构化 project_status 生成研发进度页