# Loom Vision

## 愿景

Loom 希望成为智能体优先软件项目的 agent-first project operating layer。

它要复用的，不是业务代码，而是项目如何被组织、如何进入执行、如何跨多轮持续推进、如何进入 merge-ready、以及如何收口的能力。

如果 Loom 成立，新项目将不再从“空仓库 + 临时约定 + 分散上下文”开始，而是从一套可持续、可验证、可由 agent 直接操作的运行结构开始。

## 核心判断

Loom 建立在以下判断上：

1. 真正稀缺的不是代码生成，而是持续有序执行。
   当人和智能体都能更快产出代码时，真正决定项目质量的，是执行秩序、状态连续性和审查收口能力。

2. 治理真相必须成为 operating plane，而不能只停留在会话里。
   如果目标、边界、风险、验证和恢复信息没有进入版本控制，项目就无法长期协作；但治理真相只是 Loom operating layer 的一个 plane，不等同于整个产品定位。

3. 长任务与宿主控制面都必须依赖 harness，而不是依赖上下文记忆。
   对多轮推进事项而言，checkpoint、resume、状态查看、受控入口，以及对 GitHub / review / merge / closeout 的统一编排都不是附加功能，而是基础设施。

4. `SKILLS` 应成为可执行系统入口，而不只是路由说明。
   `SKILLS` 应直接帮助人和智能体启动新项目、接手老项目、打开执行回合、进入 review、推进 merge-ready 和执行 closeout，但不应替代治理真相源。

5. Behavior-first 执行应成为 Loom 的外部契约。
   Work Item、spec、plan、build checkpoint、review、merge-ready 和 closeout 都应能消费行为证据与测试证据；BDD 描述外部可观察行为，TDD 驱动内部实现证据，但纯文档事项不应被强行套成单一实现仪式。

6. Spec-driven development 可以作为执行纪律内化，但不能收窄 Loom。
   对 formal spec、新功能、高风险变更和跨模块事项，SDD 的阶段化、产物化、模板约束和一致性分析可以成为 Loom 的强执行路径；但 adoption、resume、handoff、review、merge-ready、closeout、repo companion 和 host binding 仍属于 project operating layer 的独立能力，不应被 SDD-only 流程替代。

7. 可复用的对象应是运行模型。
   大多数项目不共享产品代码，但共享许多执行问题。Loom 要复用的是这些问题的解决结构。

8. 项目吞吐应围绕 `merge-ready` 收敛，而不是把 final review 当作第一次系统性发现问题的地方。
   review、guardian、CI、merge gate 与 closeout 应被拆成不同层级，并在受控流程中提前暴露问题。

9. Loom 不要求自研所有底层宿主能力。
   只要治理真相和编排语义由 Loom 持有，`gh`、`git worktree`、review engine、CI、project API 等都可以作为 Loom harness 的被编排对象。

## Loom 的 Operating Planes

Loom 的 operating layer 由以下 planes 协同组成：

- `Governance Truth`
  - 负责事项、状态机、checkpoint、成熟度、关闭语义与审查职责的制度真相
- `Harness Orchestration`
  - 负责 repo 内执行机制与宿主能力编排，包括工作现场、恢复、review/merge/closeout、GitHub 与 host tooling 的统一调用语义
- `Behavior and Test Evidence`
  - 负责把 BDD/TDD 双重证据循环带入 Work Item、spec、plan、build checkpoint、review、merge-ready 和 closeout
- `Spec Discipline`
  - 负责把 SDD 的 story/spec/plan/breakdown/evidence/analyze 思想作为 formal spec 路径的执行纪律内化，但不替代 adoption、resume、review、merge-ready、closeout 或宿主绑定
- `Executable SKILLS`
  - 负责按场景暴露一等入口，让 agent 可以直接进入 adopt、resume、review、merge-ready、closeout 等动作

Loom 的目标不是让这些 planes 混在一起，而是让它们边界清晰、协同工作，并最终表现为一套可执行的项目运行层。

## Loom 不解决什么

Loom 不试图解决以下问题：

- 项目本身做什么产品
- 产品架构应该如何设计
- 业务领域如何建模
- 所有项目都必须采用完全相同的目录结构
- 通过一套 prompt 取代工程治理
- 从零重写 GitHub、CI、review engine 或 `git worktree` 的底层产品实现

换句话说，Loom 关心的是项目运行方式，不是业务本身。

## 长期目标

Loom 的长期目标是让一个项目可以稳定获得以下能力：

- 可复用的治理内核
- 可持续演进的 harness 编排层
- 面向人和智能体的统一可执行 `SKILLS` 入口
- 可版本化的升级路径
- 脱离单一业务仓库独立演进的治理能力

## 成功信号

当出现以下现象时，说明 Loom 走在正确方向上：

- 新项目可以快速采用 Loom，而不是复制一堆历史文档
- 新项目启动和老项目接手都可以通过 Loom `SKILLS` 直接进入受控执行回合
- 治理和 harness 可以作为上游能力独立迭代
- 行为证据与测试证据可以被 review、gate、status 和 closeout 稳定消费
- 项目在多轮执行中仍然能保持清晰状态
- 审查、门禁、merge-ready 和收口在不同仓库中保持稳定一致
- 团队认为 Loom 的价值是“让项目能长期有序运行”，而不只是“提供了一些自动化脚本”

## 指导原则

Loom 的目标不是让项目看起来更正式。

Loom 的目标，是让项目真正具备：

- 可进入执行
- 可持续推进
- 可恢复交接
- 可审查验证
- 可进入 merge-ready
- 可一致收口

它服务的是长期执行能力，而不是短期文档整齐度。