CSF

版本: v0.5 | 最后修订: 2026-07-06 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。 关键词: [立项, 计划, TP, SP, 任务窗口, 三元组, 窗口切换, 全景图, 红点] 适用场景: 新建任何计划（TP/SP/ad-hoc）/ 任务窗口切换

项目立项与任务窗口

本文件覆盖两件事：立项（为将要做的事建结构）和任务窗口（任务阶段的切换机制）。 两者放在一起，因为立项有时会触发窗口切换，两件事需要衔接理解。

---

§ 0 任务窗口是什么

任务窗口 = cos-context.md §B 全景图中的当前焦点区域。 三元组（目的/方法/资源）存放在独立的 triplets/ 文件中，§B 通过指针引用活跃三元组。

在一个窗口内：

• 目的统一，方法稳定可复用，资源边界固定——这些由三元组文件承载
• 多个会话共享同一个三元组文件——变的只有 §C/§D 和红点位置
• 三元组文件不动，红点动，是正常状态

窗口 vs 三元组：窗口（§B）提供全景导航（全景图 + 三元组指针 + 通用资源），三元组文件提供执行内容（目的/方法/资源/进度/备忘）。两者解耦：切换三元组不触发窗口切换，只需修改 §B 指针。

立项 ≠ 立三元组（两个独立动作）：

• 立三元组 = 为一段工作建三元组文件（triplets/triplet-NNN-主题.md）。任何工作都需三元组（不建文件也要心里有；项目内可多个并存）；随时可立，该立则立。不必伴随立项。
• 立项 = 有了“项目”（短期有明确目标的计划行动）才做——建 workspace/ 文件夹 + index（todolist/内部事项）+ 全景图写未来（本协议 §3）。
• 三元组文件永远在 triplets/，不进立项文件夹；立项 index 是 todolist，不当三元组进度表。

滑入 / 滑出：

• 滑入 = 当前三元组文件的方法和资源能覆盖接下来一段时间的工作
• 滑出 = 需要装载不同的三元组文件，即将进入不同工作模式

---

§ 1 何时立项 / 何时不立项

不是所有事都需要立项。判断标准：

维度	立项	不立项（用 todolist 追踪即可）
复杂度	跨多个会话、需分步推进	一两个会话内能做完
业务意义	有独立业务目的、值得未来回溯	辅助性、工具性、一次性
重要性	失败/遗漏有显著后果	做不做影响有限
可追踪性	需要在全景图中有位置	完成即遗忘

灰区决断：如果参谋长不确定，向 Owner 提议两个选项（立项 vs todolist），说明理由，让 Owner 决断。

---

§ 2 立项触发

触发方式	典型场景
Owner 指令	“建立一个 TP 来做 X” / “起个计划” / “我们制定一个新的计划”
参谋长提议	发现缺口 / 评估复杂度后建议立项，经 Owner 确认
流程驱动	FLDD 按队列取下一个主题包进入 TP 周期

---

§ 3 立项动作序列

无论何种计划（SP / TP / 子 TP / ad-hoc），立项 = 依次完成以下步骤：

Step 1：建文件夹 + README

文件夹命名：{类型}-{NNN}-{主题简述}/

• NNN = 立项时的会话编号（不是预计开始执行的会话编号）
• 类型：sp / tp / ad-hoc
• 位置：
  • 根 = csf-lite/workspace/ —— 顶层计划（SP / ad-hoc）建在此目录下。（项目根目录常混有与管理目标无关的内容，workspace/ 专为管理目标准备。）
  • 子计划（TP / 子 TP）建在父任务文件夹内（如 sp-008 下的 TP 建在 workspace/sp-008-.../ 内）

⚠️ 建完文件夹后，立即将该文件夹路径写入对应三元组文件的资源段。 这是后续会话 AI 找到 TP 工作文件的唯一途径——三元组资源段是开局时的视野边界，不写进去 = 下次会话的 AI 不知道这个文件夹存在。

README 模板（最小必备结构）：

# {类型}-{NNN} {主题名}

> 创建：coslog-NNN / {日期}
> 性质：{功能开发 / 架构设计 / 打岔修复 / 探索 / ...}
> 来源：{为什么立项——一句话}
> 优先级：{P0/P1/P2/— }

---

## § 1 目的

{做什么 + 为什么重要。完成后世界有什么不同。}

## § 2 分解

{预计分几步完成（IT / sub-TP / milestone），每步一句话描述业务能力。
  允许粗略——随推进细化。但立项时至少给出骨架。}

## § 3 资源

{精简列出：完成此计划需要访问/精读的文件路径。
  原则：尽量少且必要。不需此刻访问，但需明确知道在哪。}

额外章节（设计决策、活跃防御、依赖图等）视复杂度按需添加，不强制。

Step 2：更新全景图

立项 = 全景图「写未来」操作（全景图.md 头部 · 五操作之二）。在全局版 全景图.md 正文与 cos-context.md §B 缩略版中插入新节点：

• 在适当的层级位置（SP 下 / TP 下 / 独立分支）；与已有节点无时序依赖的并行线用 ‼️ 前缀（同级 ‼️ 自动同组，随时可加）
• 展示预计的子步骤/子计划（前瞻视角），新节点标 ⬜
• 不移动红点（红点唯一，是否前移见 Step 5）
• 两层同步：全局版求全（只增不减），§B 缩略版随焦点滚动、可滞后

全景图的作用 = 前瞻：读者看到全景图时应能理解”接下来大致要走哪几步”。不必精确，但要有骨架。token / 记法 / 纪律的完整定义见 全景图.md 头部。

Step 3：三元组归入判断

判断新 TP 能否归入已有三元组文件：

判断	操作
新 TP 的工作类型与某已有三元组一致	在该三元组文件的进度表中追加一行
新 TP 需要不同的目的/方法/资源组合	新建三元组文件（triplets/triplet-NNN-主题.md，NNN=当前会话号；参考 _TEMPLATE.md）+ 更新 triplets/_index.md。 ⚠️ 新建时强制：目的段必须以一行显式说明从 GP 目的的派生关系。 格式：> 本目的从 cos-context §A GP 派生：[一句说清本三元组在 GP 路径上的位置，不是抄 GP，是说明"GP 的这一段由本三元组承接"]。不写 = 立项未完成。目的从 GP 断裂是后续会话 CoS 迷失方向的第一根因。
不确定	默认归入最接近的已有三元组。执行中发现不适配再拆分

原则：三元组按工作类型（目标类型）划分，不按 TP 1:1 划分。一个三元组可承载多个 TP，一个 TP 也可使用多个三元组（TP 分解出的细分任务若涉及不同工作类型，可分别归入对应的三元组）。新 TP ≠ 新三元组。

如果 Step 3 判断需要使用与当前活跃不同的三元组文件 → 标记待处理，Step 7 执行切换。

Step 4：更新进度表

在对应三元组文件的进度表中追加一行（新 TP 及其预计 IT 分解）。

Step 5：移动红点

参谋红点是否移到新计划 = 视优先级判断：

• 新计划是 P0 / 插队 → 红点移过来
• 新计划是排队 → 红点不动，仅注册

Step 6（条件步骤）：更新开发者进度表

如果新计划涉及开发工作，在 dev-context.md §B 进度表中插入对应行（待出 STB 状态）。不涉及开发则跳过。

Step 7：判断是否需要切换三元组

判断标准：新计划使用的是当前活跃三元组文件，还是不同的三元组文件？

情况	处理
新计划归入了当前活跃三元组	不切换。更新 §B 三元组指针无需改动
新计划使用了不同的三元组文件	在 §D 中标注下次会话使用的三元组文件；下次开局回合 1 时切换指针（见 §4）
不确定	默认保持当前三元组。如果执行中发现不适配，再切换

Step 8：Owner 校验

向 Owner brief 立项结果：

• 一句话说目的
• 列出分解骨架
• 说明归入的三元组文件（新建立 or 已有）
• 说明优先级和红点位置
• 等 Owner 确认或纠偏

---

§ 4 三元组切换规程

触发条件

Owner 宣布切换方向 / 参谋长报告”当前三元组内计划事项已全部完成”后 Owner 决断。

AI 不自行判断三元组边界：话题游移是正常的，Owner 在掌舵。只有 Owner 明确决定方向切换后，才执行本规程。

关键纪律：三元组切换不能用普通收尾（只覆写 §C/§D）来代替。切换是独立操作，往往值得单独一个会话完成。

Leave（离开当前三元组）

1. 更新当前三元组文件：进度表 + 备忘（即正常收尾动作，见 cos-context.md §A 收尾协议）
2. 确认会话日志已归档
3. 三元组文件本身不删除、不封存——保留为完整回溯链

Enter（进入新三元组）

1. 确认三元组文件已存在：如果 §3 Step 3 已新建，直接使用；否则先用 §3 Step 3 建文件
2. 主动要求 Owner 补充/确认新三元组的目的和资源（尤其是资源——资源定义了 AI 的视野边界，不明确就是盲区）
3. 更新 cos-context.md §B 三元组指针 → 指向新三元组文件
4. 填写 §D（新三元组下第一个会话的计划）

Return（回归之前的三元组）

当新工作完成或暂停、需要回到之前的三元组时：

1. 更新 cos-context.md §B 三元组指针 → 指回之前的三元组文件
2. 精读该三元组文件，检查进度表和备忘是否仍然准确（期间可能有变化）
3. 恢复红点到合适位置
4. 填写 §D

三元组文件即快照：旧模型需要在父 README 中备份”窗口快照”以防丢失；新模型下三元组文件始终独立存在，进度表持续累积——切换只是改指针，不丢任何信息。

---

§ 5 全景图与红点（指针）

全景图的 token、结构记法（顺序 / 并行 ‼️ / 打岔 / 变迁）、五操作、四纪律、红点唯一规则——全部由 全景图.md 头部自宿主承载。

决策（coslog-008 Owner）：全景图 > 立项协议。全景图是更高位的存在；立项协议不重复头部规则，只保留指针 + 立项特有动作。

立项协议只负责两个立项特有的全景图动作：

• 登记新节点：立项时在全景图插入 ⬜ 节点（见 §3 Step 2）
• 红点是否移动：视优先级判断（见 §3 Step 5）——红点唯一，默认不动，仅 P0 插队才前移

全景图是活的：历史结构锁定（只追加、只降级 token），未来节点可增删，表达粒度可调。完整规则读 全景图.md 头部。

---

§ 7 立项完成判定

立项 = 以下全部完成：

• README 存在且 §1（目的）+ §2（分解）非空
• 全景图中有对应节点（⬜）
• 三元组归入已完成（归入已有 or 新建三元组文件）
• 对应三元组文件的进度表已追加行
• 三元组目的段已写 GP 派生关系（新建三元组文件时强制；归入已有则检查是否已有）
• 红点位置已检查/更新
• 开发者进度表有对应行（如涉及开发）
• 三元组切换已处理（如需要，见 §4）
• Owner 已校验

---

§ 8 与其他规程的关系

规程	本协议的角色
FLDD-开发执行.md §3	FLDD 中的”TP 立项”是本协议在 FLDD 场景下的特化应用（额外增加一致性 checklist + 主题包精读）
cos-context.md §B	本协议 §3-§4 是任务窗口维护与三元组切换的权威版本；全景图规则以 全景图.md 头部为准
cos-context.md §A 收尾协议	收尾时需检查：本次会话是否有未完成的立项步骤（漏更新全景图等）

This site is open source. Improve this page.