ACCEPTED

AIOS · 二层并发域协议规范 v1.0

关联:本文件是 ADR-AIOS-06 §2.2 + §3.1 + §3.2 的展开实施手册。 配合 Process-Model.md(K/U 线程)+ Scheduling-Algorithm.md(RUNQ)+ Commit-Convention.md(commit 校验)使用。

---

1. 二层并发域总览

=== 并发域 A · 同仓库同分支(文件级隔离)===
  04_development/(单一 git 仓库 · 单一 xistudio 分支)
    ClaudeA / ClaudeB / ClaudeC / ClaudeD · 4 个 Claude Code CLI 终端

=== 并发域 B · 多 worktree(分支级隔离 + merge)===
  AlgoDepartment/work-cline/      · cline 分支     ← Cline-Worker(主力)
  AlgoDepartment/work-copilot/    · copilot 分支   ← Copilot-Worker(辅助)
  AlgoDepartment/work-continue/   · continue 分支  ← Continue-Worker(备用)
  AlgoDepartment/work-deepseek/   · deepseek 分支  ← DeepSeek-Worker(深度备用 · 默认不调度)

=== 调度内核(不参与业务执行)===
  Cline-AIOS · VSCode 插件本会话 · cwd=06_docs/site-build/

1.1 二层并发域语义对比

维度	并发域 A	并发域 B
物理	同 git 仓库 · 同 xistudio 分支 · 同步 4 个 CLI 终端	同仓库不同 worktree · 各自独立分支
隔离粒度	文件级 · file_claims 不冲突即可并发	分支级 · merge 时解决冲突
适用任务	紧耦合多文件协作(如 ADR-04 P-1 的 11 文件 commit 链)	关联弱的并行任务(如文档 / 备份 / 实验性架构)
集成	直接 commit 到 xistudio	merge 到 xistudio
主力 CPU	ClaudeA / ClaudeB / ClaudeC / ClaudeD	Cline-Worker(主) + Copilot-Worker(辅)
备用 CPU	(无)	Continue-Worker + DeepSeek-Worker(默认不调度)
冲突协议	RUNQ Step 3 K-thread 校验	git merge + AIOS 主导时机

---

2. Cline 双实例分离(防止误读)

2.1 两个 Cline 实例的物理与角色

实例	物理	角色	业务代码红线
Cline-AIOS	VSCode 插件本会话 · cwd=06_docs/site-build/	调度内核	❌ 严禁写业务代码(原铁律保留)
Cline-Worker	Claude Code CLI 在 work-cline/	业务执行 CPU(主力)	✅ 与 ClaudeA/B/C/D 同级可写业务代码

2.2 实例识别方式(避免误判)

信号	Cline-AIOS	Cline-Worker
pwd / cwd	06_docs/site-build/	AlgoDepartment/work-cline/
启动方式	VSCode Cline 扩展	终端启动 claude CLI(profile=cline)
.clinerules/ 是否激活	✅(本仓库 aios-orchestration.md)	❌(work-cline 不带 .clinerules/)
git config user.name	"AIOS" / "Cline-AIOS"	"Cline-Worker"
操作	调度元数据(PCB/RUNQ/ADR/standup)	业务实现(stages/ / WebSocket/ / ...)

2.3 红线对照

Cline-AIOS:
  ✅ 维护 PCB / RUNQ / KANBAN-archive
  ✅ 起草 ADR / 修订 agents/* 文档
  ✅ 派发提示词 · 仲裁冲突 · 跑 standup
  ❌ 改 frontend_vue3/* / backend_csharp/* / dsp_algo/* / pysidecar/*
  ❌ 改 contracts/* (这是 ClaudeB 的 P_contracts 写权限)

Cline-Worker:
  ✅ 业务实现(任何 P0-P7 + P_contracts 的 K-thread 占用)
  ✅ 在 work-cline 分支自由 commit
  ❌ 跳过 RUNQ 派发自行接活(必须等 AIOS 派提示词)
  ❌ 直接 push 到 xistudio(merge 必须 AIOS 主导)

2.4 v0.3 例外:Cline-AIOS 下场写业务代码

唯一允许 Cline-AIOS 写业务代码的场景(沿用 ADR-AIOS-01 v3 决议):

紧急 hotfix 且 ClaudeA/ClaudeB 双 CLI 都宕机超过 24h · 必须同步写 ADR 备案。

实施细节: - 用 [uid=U-cline-aios-emergency-<timestamp>] 标记 - 事后立即起草 ADR-AIOS-NN 备案此次例外 - 在 PCB 对应进程 user_threads 补登 zombie 记录

---

3. 并发域 A 主/副战场表(v0.3 核心)

3.1 主战场 / 副战场表

CPU	主战场	副战场	说明
ClaudeA	P0-xishell + P1-xilink + P2-xiforge + P3-xitune + P4-xitest + P_contracts(前端契约部分)	-	前端全栈主力 · 含 shell 基础设施
ClaudeB	P5-backend-csharp + P6-dsp-algo + P_contracts(后端契约部分)	P7-pysidecar(机动)	后端全栈主力 · pysidecar 兼管
ClaudeC	机动(P0-P4 任意空闲 K-thread)	P6-dsp-algo 部分模块(modules/)	灵活补位 · 突发任务
ClaudeD	机动 + 测试(P4-xitest 优先)	P7-pysidecar 维护	测试主战场 · 跨栈兼差

3.2 主战场的语义(三层含义)

1. 缓存亲和性默认值:U-thread 第一次出现且 last_modified_by 字段为空时,AIOS 派给主战场 CPU
2. 派发优先级:同优先级两个候选 U-thread,主战场匹配的优先派发
3. standup 派发提示词的默认接收者:AIOS 抓取 standup 时,默认按主战场推送提示词

3.3 副战场的语义

副战场是fallback 候选,触发条件: - 主战场 CPU 满载(已绑定 ≥ 2 个 running U-thread) - 主战场 CPU 不在线(进程崩溃 / 终端关闭) - 紧急 hotfix 需要分流

3.4 "机动"的语义

ClaudeC / ClaudeD 标"机动"= 无固定主战场 · AIOS 按以下优先级临时派发: 1. P-1 / P0 优先级的 ready U-thread(无视主战场) 2. 主战场缓存亲和的 U-thread(辅助 ClaudeA/B) 3. 文档 / 测试类低优先级任务

---

4. 并发域 A 文件级隔离协议

4.1 协议核心

同一时刻同一文件只允许一个 CPU 写

实施机制: - 通过 RUNQ 6 步算法 §3 K-thread 可获取性校验保证(详见 Scheduling-Algorithm.md) - K-thread.state == running 时 · 该 K 持有的所有 file_claims 文件被锁 - 多 U-thread 想改同一文件 → 同一轮 RUNQ 只能派发一个

4.2 file_claims 重叠时的写权限协议

当多个 K-thread 的 file_claims 范围重叠(如 stores/linkStore.ts 同时被 P1.K7 和 P3.K7 声明):

• 唯一写所有者:全局每个文件只能由一个 K-thread声明 read-write 权限
• 其他 K-thread 必须声明 read-only
• 在 K-thread THREAD.md 中通过 access 字段明示

例:

# processes/P1-xilink/kernel_threads/K7-link-store/THREAD.md
kid: P1.K7
file_claims:
  - stores/linkStore.ts
access: read-write     ← 唯一写所有者

# processes/P3-xitune/kernel_threads/K7-stores/THREAD.md
kid: P3.K7
file_claims:
  - stores/linkStore.ts   ← 与 P1.K7 重叠
access: read-only        ← 仅引用 · 不写

4.3 同一目录不同文件可并发(突破 v3 "目录独占")

ClaudeA · U-task-x · 改 stages/xiforge/ModuleCreator.vue   (P2.K1)
ClaudeC · U-task-y · 改 stages/xiforge/widgets/Slider.vue  (P2.K7)
                                                              │
                          ↑ 不冲突 · 同时跑(K1 与 K7 file_claims 不重叠)

这是 v3 → v7(ADR-06)最大的并发解放。

---

5. 并发域 B 分支级隔离 + merge 协议

5.1 分支级隔离的工作流程

开发期(各自独立):
  Cline-Worker     → work-cline/    分支:cline       · 自由 commit
  Copilot-Worker   → work-copilot/  分支:copilot     · 自由 commit
  Continue-Worker  → work-continue/ 分支:continue    · 自由 commit

集成期(AIOS 主导):
  AIOS 触发 merge:
    1. 先 git fetch 各 worktree 最新状态
    2. 评估冲突复杂度(file overlap / 行级 conflict)
    3. 选择 merge 顺序(通常按依赖图拓扑序)
    4. 在 04_development/ xistudio 分支上依次 merge
    5. 冲突时 AIOS 调度对应 worker 解冲突

5.2 AIOS 主导 merge 时机的判断

触发条件	merge 时机
Worker 完成 U-thread commit 链 + push	立即 merge(无冲突时)
Worker 累计 ≥ 5 个 commit 未 merge	AIOS 提醒并安排 merge
多 Worker 同时改同区域	高优先 Worker 先 merge · 后者 rebase
HARD-DEADLINE 硬截止前 24h	强制 merge · 冻结其他 Worker push

5.3 work-cline 滞后场景(实战 case)

当前实战:work-cline/ HEAD=88a7701 · 比 xistudio HEAD=551f3b7 滞后 19 commit

处理流程: 1. AIOS 通知 Cline-Worker:"开新 U-thread 前必须先 sync" 2. Cline-Worker 在 work-cline/ 执行:

git fetch origin xistudio
git rebase origin/xistudio
# 或 merge: git merge origin/xistudio

3. 解决冲突(若有) → push 更新 work-cline 远端 4. AIOS 在 RUNQ 重算时把 Cline-Worker affinity 从 cold 升回 normal 5. 才能接新 U-thread 派发

5.4 work-copilot 当前实战(refresh-link 收尾)

work-copilot HEAD=879ab07 · 领先 14 commit · 8 dirty file

ADR-AIOS-06 v0.3 实施期不打扰原则: - Cline-AIOS 不动 04_development - 不催 Copilot-Worker · 让其自然完成 refresh-link 收尾 - 完成后 AIOS 主导 merge 14 commit 到 xistudio - merge 时按 v0.3 拓扑映射: - refresh-link 相关 → P5.U-refresh-link 归档为 zombie - workspace-file-system 部分 → P0.U4 + P_contracts.U-refresh-link-spec

---

6. 跨域协作场景(A ↔ B)

6.1 场景 1:并发域 A 主力 + 并发域 B 备援

情况:Day 4 · P_contracts.U-protocol-v1 仓促 · ClaudeB 满载

AIOS 派发:
  - ClaudeB(并发域 A · P_contracts 主战场)继续主写 protocol-v1.md
  - Cline-Worker(并发域 B)在 work-cline/ 起 review-protocol-v1 草稿
  - 完成后 push 到 work-cline · 不直接进 xistudio
  - ClaudeB 接到 [need: Cline-Worker review] trailer 后整合

6.2 场景 2:实验性架构在并发域 B 试水

情况:用户提议把 P3 stage 拆为子 stage · 风险高

AIOS 派发:
  - 不动 04_development xistudio 主干
  - 在 work-continue/ 让 Continue-Worker 起实验分支 experiment/p3-substages
  - 验证可行后再走 ADR 流程升级到 xistudio
  - 不可行直接丢弃 · 主干无影响

6.3 场景 3:并发域 A K-thread 锁导致并发域 B 等待

情况:并发域 A 的 ClaudeA 占了 P0.K-shared-types(running)
     并发域 B 的 Copilot-Worker 想改 types/refresh-link.ts(也属 P0.K-shared-types)

处理:
  1. AIOS RUNQ Step 3 校验:Copilot-Worker U-thread 占的 P0.K-shared-types 已 running
  2. 该 U-thread 留在 ready 队列等下一轮
  3. ClaudeA 完成 commit · K-thread 释放
  4. AIOS 重算 RUNQ · 派给 Copilot-Worker

关键洞察:K-thread 锁是全局的,跨并发域生效。这就是 ADR-06 §2.6 的设计意图。

---

7. 并发域 B 的 worker 启用规则

7.1 默认调度优先级

Worker	默认调度状态	启用触发
Cline-Worker	✅ 主动调度	永远在 RUNQ 候选池
Copilot-Worker	✅ 主动调度	永远在 RUNQ 候选池
Continue-Worker	⚠️ 被动调度	仅 ClaudeA/B + Cline + Copilot 全满载时启用
DeepSeek-Worker	❌ 不调度	仅紧急 hotfix · 用户显式拍板才启用

7.2 启用 Continue-Worker 的判断

trigger:
  Cline-Worker  satisfied with N≥2 running U
  Copilot-Worker satisfied with N≥2 running U
  ClaudeA/B/C/D each ≥ 1 running U
  AND RUNQ.ready 仍有 P0/P-1 待派
  ↓
  AIOS 通知 Continue-Worker:"接 1 个 U-thread"

7.3 启用 DeepSeek-Worker 的判断

trigger(任一):
  - 紧急 hotfix · ClaudeA/B 双双崩溃 24h+
  - 用户显式说"用 DeepSeek 也上"
  ↓
  AIOS 写 ADR-AIOS-NN 临时启用决议 · 等用户拍板 · 然后入 RUNQ

---

8. RUNQ 与并发域的视图关系

8.1 RUNQ.md 中的 Bound CPU 字段

| PID.UID | Bound CPU | 域 | Affinity |
|---|---|---|---|
| P_contracts.U-freeze-tag | ClaudeB | A | hot |
| P5.U-refresh-link | Copilot-Worker | B | hot |
| P3.U2 | ClaudeC | A | warm |

8.2 standup 输出的并发域分组

AIOS 抓取 standup 时按并发域分组输出:

🎯 今日聚焦(并发域 A · claude code 4 兄弟):
  - ClaudeA → P2.U5 module-uid-namespace(P0 · HARD-DEADLINE)
  - ClaudeB → P_contracts.U-freeze-tag(P-1 · Day 5 EOD)
  - ClaudeC → P3.U4 test-aux-extract(P1)
  - ClaudeD → 机动 · 等 P3.U4 完成后接 P4.U1

🎯 今日聚焦(并发域 B · worktree 三兄弟):
  - Cline-Worker → 先 sync xistudio · 再接 P0.U5 shell-visual-finalize
  - Copilot-Worker → 继续 P5.U-refresh-link(待 14 commit merge)
  - Continue-Worker → 暂无派发(主力未满载)

---

9. 文件锁与冲突解决 FAQ

Q1:两个 CPU 都想写同一个文件怎么办?

A:RUNQ Step 3 校验阶段就被卡住了。同一时刻只有一个 U-thread 能占住该 K-thread → 另一个等。

Q2:并发域 A 与 B 同时改同一文件?

A:K-thread 锁全局生效。例如 ClaudeA 改 types/foo.ts(占 P0.K-shared-types running)期间,Cline-Worker 在 work-cline 也想改 types/foo.ts: - AIOS 派发 Cline-Worker 的 U-thread 时校验失败 - Cline-Worker 等 ClaudeA 释放 - 解锁后 Cline-Worker 派发 → 自动走 sync(rebase 拿到 ClaudeA 的最新 commit)→ 改

Q3:AIOS 自己同时改多个文件冲突?

A:Cline-AIOS 几乎只在 06_docs/site-build/ 工作 · 全是 P_arch 进程的 user_threads(无 K-thread)· 不存在 K-thread 锁冲突。

Q4:work-deepseek/ 没有任务时是否要保持同步?

A:不需要。备用 worktree 不调度时可以滞后 · 启用前由 AIOS 触发一次完整 sync。

Q5:多 Worker 同时改 protocol-v1.md(P_contracts.K1)?

A:禁止。沿用 ADR-AIOS-01 v3 + v0.3 决议: - P_contracts.K1 写权限仅 ClaudeB(并发域 A) - 其他 worker 仅 read-only 引用 - 涉及 protocol-v1.md 修改的 U-thread 必须派给 ClaudeB

---

10. 验收清单

任何并发域操作完成后需通过以下校验:

• 每个 CPU 的 git config user.name 与并发域内身份一致
• 并发域 A 的 commit 直接落 xistudio · 无中间 merge
• 并发域 B 的 commit 落对应 worktree 分支 · merge 由 AIOS 主导
• Cline-AIOS 工作目录始终是 06_docs/site-build/ · 不动 04_development
• Cline-Worker 在 work-cline 接新 U-thread 前已 sync xistudio
• 主战场表配置在 Roster.md v4 + Repository-Partition.md v4 中持久化
• standup 输出按并发域 A/B 分组(详见 Human-Daily-Standup.md)
• P_contracts.K1 写权限仅 ClaudeB · 其他 worker 引用为 read-only

---

11. 文档元信息

• 创建:2026-05-26 17:25 · Step B · T5(ADR-AIOS-06 v0.3 实施)
• 版本:v1.0
• 同栈姊妹文档:Process-Model.md / Scheduling-Algorithm.md / Commit-Convention.md
• 后续文档:Roster.md v4 / Repository-Partition.md v4 将引用本文件主战场表