跳转至
ACCEPTED

ADR-AIOS-06 · 任务调度操作系统化

状态:accepted(v0.3 终审通过)· 决策日期:2026-05-26

决策者:AIOS / Cline(草拟)+ 项目总指挥(终审)

关联:ADR-AIOS-01(5 角色协作 v3)/ ADR-AIOS-03(4 agent 按 stage 分工)/ ADR-AIOS-04(XiForge 架构)/ ADR-AIOS-05(XiStudio Workspace)

触发:用户 2026-05-26 15:10 提出"AIOS 任务调度操作系统化"三大议题 · 经一次"伪 OS 化"自我批评后拍板方案 X(真 OS 化)+ 15:55 Cline 双实例修正 + 16:15 物理拓扑修正 + 16:37 K/U 双分类 + P0 XiShell daemon 修正(v0.2)+ 16:45 用户提出全栈视角盲区(后端/DSP/pysidecar 缺失)+ 17:00 拍板"v0.3-A 全展开"(从 7 进程扩展到 10 进程 · 全栈进程化建模)

v0.3 关键变化: - 进程总数 7 → 10(P0-P4 + P5/P6/P7 + P_contracts + P_arch) - 后端域从 P_kernel 笼统拆为 P5-backend-csharp(C# 服务)/ P6-dsp-algo(C/C++ 算法库)/ P7-pysidecar(Python 分析侧车) 三个独立 daemon - 跨栈契约从 P_kernel.K1 嵌套提升为 P_contracts daemon(独立类比"系统调用表") - U-refresh-link 从 P_kernel 归属修正为 P5-backend-csharp - 并发域 A 拓扑加"主战场/副战场"列(ClaudeA → P0-P4+P_contracts前端 / ClaudeB → P5+P6+P_contracts后端)

1. 背景与问题

1.1 v3→v4→v5→v6 四次主干重写的根因

版本 触发 后果
v3.0 跨栈职能解耦 ClaudeA 全程独占 17 phase(范围过大)
v4.0 ADR-AIOS-03 17 phase → 4 stage agent 分工(主干推倒重来)
v5.0 ADR-AIOS-04 XiForge 9 项决议 → 插入 P-1/P0 共 4 项(KANBAN §1.2.2 整段新增)
v6.0 ADR-AIOS-05 Workspace 7 项决议 → 跨 4 agent 横向任务表(KANBAN §1.7 整段新增)

根因:KANBAN 主干按"智能体"分段(§1.1 ClaudeA / §1.2 ClaudeB / §1.3 ClaudeC / §1.4 ClaudeD)。每次架构事件涉及多智能体时,只能整段重写。

1.2 三位一体绑定的实证症状

任务 = 智能体 = 目录(三位一体 · 现状)
P1 XiLink     → ClaudeA → frontend_vue3/stages/xilink/
P2 XiForge    → ClaudeB-XiForge → frontend_vue3/stages/xiforge/
P3 XiTune     → ClaudeC → frontend_vue3/stages/xitune/
P4 XiTest     → ClaudeD → frontend_vue3/stages/xitest/
  • ClaudeA 跑完 XiLink 闲置 · 但不能去帮跑 XiTune("目录独占"硬绑定)
  • ClaudeC 满载 P1 三件 + post-P0 test fix · 但 ClaudeD 闲着不能分担(都在 stages/xitune/ 上不能并行)
  • 17 PROMPT 文件名嵌入智能体标识(PROMPT-claudec-xxx.md)→ 找一个任务"半天才知道属于哪个 stage"

1.3 用户三大议题(verbatim 摘要)

  • 议题 1:同仓库不同 CLI 用文件级隔离 · 不同 work-tree 用分支级隔离 · 最后 merge
  • 议题 2:任务调度操作系统化 — 主次 / 可终止 / 可打断 / 可占用 / 可通信 / 任务碎片化 / 共享栈空间 / 不影响主干逻辑
  • 议题 3:commit message 不需要知道哪个智能体干了什么 · 只需要知道哪个进程的哪个线程完成了什么(类比"操作系统不需要知道哪个 CPU 核心做了什么")

2. 决策(7 条核心条款)

2.1 三层解耦(Process / 调度 / CPU)

Layer 3 · 任务层(Process / Thread / Step · 与 CPU 无关)
        ↑ 入就绪队列
Layer 2 · 调度层(AIOS 内核 · RUNQ · 优先级 · 文件冲突 · 缓存亲和)
        ↓ 派发(动态绑定)
Layer 1 · 执行层(CPU 池 · 同仓库组 + worktree 组 + 备用)

关键:Layer 3 的 Process 描述符不含 owner 字段。一个 Process 可以由 Layer 1 任何空闲 CPU 执行(只要 Layer 2 调度通过)。

2.2 Layer 1 CPU 池 · 二层并发域(用户 16:15 拓扑修正)

=== 并发域 A · 同仓库同分支(claude code 4 兄弟 · 文件级隔离)===
  04_development/(单一 git 仓库 · 单一 xistudio 分支)
    ├── ClaudeA · Claude Code CLI 终端 · 主战场 P0-P4(前端) + P_contracts(前端契约部分)
    ├── ClaudeB · Claude Code CLI 终端 · 主战场 P5-backend-csharp + P6-dsp-algo + P_contracts(后端契约部分) · 副战场 P7-pysidecar(机动)
    ├── ClaudeC · Claude Code CLI 终端 · 主战场 机动(P0-P4 任意) · 副战场 P6 部分模块
    └── ClaudeD · Claude Code CLI 终端 · 主战场 机动 + 测试(P4 优先) · 副战场 P7-pysidecar 维护

  并发协议:文件级 conflict avoidance
    - 同一时刻同一文件只允许一个 CPU 写
    - AIOS 派 thread 时校验 file_claims 与已运行 thread 不冲突
    - commit 直接落 xistudio 分支
    - 同一目录不同文件可同时跑(突破 v3 "目录独占")

  并发域 A 主/副战场表(v0.3 新增 · 全栈 10 进程视角):

  | CPU      | 主战场                                                  | 副战场                          |
  |----------|---------------------------------------------------------|---------------------------------|
  | ClaudeA  | P0-xishell + P1-xilink + P2-xiforge + P3-xitune + P4-xitest + P_contracts(前端)| -                               |
  | ClaudeB  | P5-backend-csharp + P_contracts(后端) + P6-dsp-algo     | P7-pysidecar(机动)             |
  | ClaudeC  | 机动(P0-P4 任意空闲 K-thread)                         | P6-dsp-algo 部分模块(modules/)|
  | ClaudeD  | 机动 + 测试(P4-xitest 优先)                           | P7-pysidecar 维护               |

  说明:
    - 主战场 = git config user.name 缓存亲和优先 + 默认派发候选
    - 副战场 = 主力满载或紧急 hotfix 时唤醒
    - "机动"= 无固定主战场 · AIOS 按 K-thread sleeping 状态 + 优先级临时派发

=== 并发域 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(暂不调度)

  并发协议:分支级隔离 + 周期性 merge 到 xistudio
    - 各自独立分支 · 自由 commit
    - AIOS 主导 merge 时机(避免冲突堆积)
    - 适合"与现有任务关联不大的同步开发任务"

=== 调度内核 · 不参与业务执行 ===
  Cline-AIOS · VSCode 插件(本会话)· 工作目录 06_docs/site-build/
    - 调度内核 · 维护 RUNQ + PCB + ADR + KANBAN-Mirror
    - 不写业务代码(铁律保留)

重要明确: - "Cline 不写业务代码"铁律仅适用于 Cline-AIOS - Cline-Worker 是并发域 B 的主力业务 CPU · 与 Copilot-Worker / Continue-Worker 同级 - DeepSeek-Worker 备用 · 默认不入 RUNQ · 仅在主力全满或紧急 hotfix 时唤醒

2.3 Layer 3 任务进程模型 · 双重分类(进程类型 + 线程类型)

2.3.1 进程分类(daemon / user-process / arch-event)

类型 状态特征 典型成员(v0.3 全栈 10 进程) 说明
daemon · 守护进程 永不 zombie · 系统启动即创建 · 关机才终止 P0 XiShell · P5 backend-csharp · P6 dsp-algo · P7 pysidecar · P_contracts 提供基础设施 · 所有业务进程依赖它
user-process · 业务进程 整体常驻 · 内部 thread 频繁 fork/zombie P1 XiLink / P2 XiForge / P3 XiTune / P4 XiTest 一个 stage 一个进程 · 与 stage 同生命周期
arch-event · 架构事件进程 完成即整体 zombie · 不再唤醒 P_arch/ADR-04 / ADR-05 / ADR-06 ADR 触发 · fork N 个 U-thread · 完成后归档

2.3.2 线程分类(K-thread / U-thread · 这是模型核心)

类型 生命周期 状态机 用途 是否进 RUNQ
K-thread · 内核/常驻线程(模块所有权登记) 与父进程同生死 · 不会 zombie sleeping(无任务)/ running(被 U-thread 占用)/ extending(架构升级中) 占住一块"模块/文件夹/UI 区域"的所有权 · 提供 file_claims 范围 ❌ 不进(基础设施)
U-thread · 用户/临时线程(业务任务调度单元) 完成即 zombie ready / running / blocked / zombie 进入 RUNQ 被调度器派发 · 完成后归档 ✅ 进 RUNQ

关键关系: 

U-thread 修改的文件 ⊆ 一个或多个 K-thread 的 file_claims 范围
  ↓
K-thread 是文件所有权所在地(永远存在)
U-thread 是临时占用 K-thread 来干活的执行单元(完成走人)
  ↓
两者通过"file_claims 子集匹配"建立隶属关系
K-thread 不进 RUNQ · U-thread 才进 RUNQ

类比 OS:K-thread = 内核数据结构(VFS / 设备驱动 · 永远存在);U-thread = 进程开的文件描述符(短期使用 · 用完关闭)。

2.3.3 PCB(进程控制块)YAML 示例

# processes/P3-xitune/PROCESS.md(进程描述符)
pid: P3
name: xitune
type: user-process            # daemon / user-process / arch-event
parent: null
state: running                # 进程整体状态:ready / running / blocked / zombie
priority: P0
created: 2026-05-19

# K-thread · 常驻基础设施线程(永远存在 · 不进 RUNQ)
kernel_threads:
  - kid: P3.K1
    name: page-layout
    state: sleeping
    file_claims: [stages/xitune/index.vue]
    description: 主页面布局 · 16 TuningDialog 容器
  - kid: P3.K5
    name: stage-toolbar
    state: sleeping
    file_claims:
      - stages/xitune/toolbar/*
      - components/shell/StageBar.vue   # via shellSlots bridge
    description: TuningModeSwitcher + Mode chips 顶栏注入
  - kid: P3.K7
    name: stores
    state: sleeping
    file_claims:
      - stores/presetStore.ts
      - stores/profileStore.ts
      - stores/tuningModeStore.ts
      - stores/linkStore.ts             # 与 P1 共享(IPC)
    description: XiTune 业务 stores · 含 linkStore 双状态

# U-thread · 临时业务线程(完成即 zombie · 进 RUNQ)
user_threads:
  - uid: P3.U1
    name: tuning-mode-system
    state: zombie
    completed_at: 2026-05-26 12:25
    last_commit: 88a7701
    occupied_kernel_threads: [P3.K7]
  - uid: P3.U2
    name: tuning-mode-ui
    state: zombie
    completed_at: 2026-05-26 14:30
    last_commit: a877d6f
    occupied_kernel_threads: [P3.K5, P3.K7, P0.K-shared-types]
  - uid: P3.U3
    name: xipreset-xiprofile
    state: zombie
    completed_at: 2026-05-26 15:00
    last_commit: edd75d7
    occupied_kernel_threads: [P3.K7]
  - uid: P3.U4
    name: test-aux-extract
    state: ready
    eta: Day 9
    occupied_kernel_threads: [P3.K3, P0.K-shared-test-aux]   # 抽组件给 P0 shared

# 共享栈空间(跨进程引用 · 非独占)
shared_resources:
  - via: P0.K-shared-types
    files: [types/xmlTuning.ts, types/tuningMode.ts]
  - via: P1.K7
    files: [stores/linkStore.ts]    # P3 只读引用 · 不写

# 进程间通信
ipc_channels:
  - to: P_kernel-backend
    via: contract-v1                # 走契约协议
  - from: ADR-AIOS-05
    via: arch-event                 # 架构事件信号

关键: 1. kernel_threads / user_threads 都没有 owner 字段 · 谁来跑都行 2. occupied_kernel_threads 表达"U-thread 临时占用了哪些 K-thread"(一个 U 可跨多 K) 3. shared_resources.via 必须指向某个 K-thread(共享通过 IPC 引用 · 不允许越权直写)

2.4 进程目录结构(v0.3 调整 · processes/ 归 40-aios/ 下)

v0.3 关键调整(2026-05-26 17:40 拍板):processes/ 从 30-frontend-vue3/ 提升到 40-aios/ 下 · 与 ADR/agents/PCB/RUNQ 同居 · 形成"决策(ADR)+ 规范(agents)+ 实例(processes)"三剑客。理由:processes/ 本质是 AIOS 调度内核维护的元数据,跨栈共享(P5/P6/P7 不归前端),应与 KANBAN/PCB/RUNQ 同层。

docs/08-implementation/40-aios/
├── ADR/                                  ← 决议
├── agents/                               ← 规范(Process-Model/Scheduling/Commit/Concurrency)
├── PCB.md                                ← 进程总览(待 T8)
├── RUNQ.md                               ← 就绪队列(待 T20)
├── KANBAN-archive-v6.md                  ← 历史 KANBAN(T9 git mv)
├── INDEX.md                              ← 自动生成 · 进程列表 + 状态(替代 INDEX-PROMPTS.md)
├── processes/                            ← ★ 进程注册表(本次新增 · 跨栈共享)
│   ├── P0-xishell/                       ← daemon 进程 · 全局基础设施(v0.2 新增)
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/               ← K-thread 常驻线程(每个一个目录)
│   │   │   ├── K1-top-bar/               ← MenuBar + StageBar
│   │   │   │   └── THREAD.md             ← 线程描述符 + file_claims
│   │   │   ├── K2-global-stores/         ← layout/shellSlots/theme/workspace
│   │   │   ├── K3-dock-framework/        ← useDrawerDock/DockSlot 通用
│   │   │   ├── K4-floating/              ← floatingStore + FloatManager
│   │   │   ├── K5-shell-controls/        ← Theme/Lock/Workspace/Wizard
│   │   │   ├── K6-stage-switcher/        ← stagePills + history-group
│   │   │   ├── K-shared-types/           ← shared/types/(P0 daemon 持有)
│   │   │   ├── K-shared-contracts/       ← shared/contracts/
│   │   │   └── K-shared-test-aux/        ← shared/test-aux/(P3.U4 抽出后落入)
│   │   └── user_threads/                 ← U-thread 临时业务(每个一个目录)
│   │       ├── U1-shell-slot-store/(zombie · phase 1 历史)
│   │       ├── U4-workspace-file-system/(zombie · ADR-05 P0 · 25a0bf3)
│   │       └── U5-shell-visual-finalize/(ready)
│   ├── P1-xilink/                        ← user-process
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-page-layout/           ← index.vue + LinkEditor
│   │   │   ├── K2-left-dock/             ← 3 drawer 包装
│   │   │   ├── K3-right-dock/            ← 4 drawer 业务
│   │   │   ├── K4-bottom-tabs/           ← 5 bottom
│   │   │   ├── K5-stage-toolbar/         ← stageToolbar 4 段注入
│   │   │   ├── K6-multi-dialog/          ← LinkEditor 多窗口
│   │   │   └── K7-link-store/            ← linkStore 双状态(ADR-05)
│   │   └── user_threads/
│   │       ├── U1-xilink-finalize/(running · ClaudeA Step A)
│   │       ├── U2-floating-store-impl/(running · 写完移交 P0.K4)
│   │       ├── U3-window-mgr/(ready)
│   │       └── U4-visual-e2e/(pending)
│   ├── P2-xiforge/
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-page-layout/           ← ModuleCreator 4628 行业务
│   │   │   ├── K2-left-dock/
│   │   │   ├── K3-right-dock/            ← 6 drawer
│   │   │   ├── K4-bottom-tabs/
│   │   │   ├── K5-stage-toolbar/
│   │   │   ├── K6-third-party-dialog/    ← ThirdPartyModuleDialog
│   │   │   └── K7-widget-registry/       ← L1/L2/L3 三层(ADR-04)
│   │   └── user_threads/
│   │       ├── U1-shell-inject/(running · ClaudeB-XiForge)
│   │       ├── U2-xml-decommission/(zombie · 551f3b7 · ADR-04 P-1)
│   │       ├── U3-widget-registry/(ready · 占用 K7)
│   │       ├── U4-module-mode-simplify/(ready)
│   │       └── U5-module-uid-namespace/(ready ⚠️ HARD-DEADLINE)
│   ├── P3-xitune/
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-page-layout/           ← 16 TuningDialog 12530 行
│   │   │   ├── K2-left-dock/             ← 3 drawer 包装 ProfileSidebar+PresetPanel
│   │   │   ├── K3-right-dock/            ← 3 独有 drawer(test-aux 抽出后给 P0)
│   │   │   ├── K4-bottom-tabs/
│   │   │   ├── K5-stage-toolbar/         ← TuningModeSwitcher + Mode chips
│   │   │   ├── K6-tuning-dialog-multi/   ← 接 P0.K4 floatingStore
│   │   │   └── K7-stores/                ← preset+profile+tuningMode+linkStore
│   │   └── user_threads/
│   │       ├── U1-tuning-mode-system/(zombie · 88a7701)
│   │       ├── U2-tuning-mode-ui/(zombie · a877d6f · 占用 K5+K7+P0.K-shared-types)
│   │       ├── U3-xipreset-xiprofile/(zombie · 913323c+edd75d7)
│   │       └── U4-test-aux-extract/(ready · ★ 占用 K3+P0.K-shared-test-aux)
│   ├── P4-xitest/
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-page-layout/           ← TestRunnerPanel 367 行
│   │   │   ├── K2-left-dock/
│   │   │   ├── K3-right-dock/            ← 3 独有 + 4 wrapper(复用 P0.K-shared-test-aux)
│   │   │   ├── K4-bottom-tabs/
│   │   │   ├── K5-stage-toolbar/         ← 5 mode chip
│   │   │   └── K6-test-store/            ← testStore + 5 mode 内容
│   │   └── user_threads/
│   │       └── (全 ready · 等 ClaudeD · 依赖 P3.U4 完成)
│   ├── P5-backend-csharp/                ← daemon · C# 后端服务(v0.3 新增 · 拆自 P_kernel)
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-controllers/           ← MVC 路由(Controllers/)
│   │   │   ├── K2-services/              ← 业务服务(Services/)
│   │   │   ├── K3-models/                ← 数据模型(Models/)
│   │   │   ├── K4-websocket/             ← WS 核心(WebSocket/)
│   │   │   ├── K5-routes/                ← WS 路由(Routes/ · refresh_link 在这)
│   │   │   ├── K6-interop/               ← 与 dsp_algo + pysidecar 互操作(Interop/)
│   │   │   ├── K7-aiagent/               ← AI 代理(AIAgent/)
│   │   │   ├── K8-extensions/            ← 扩展方法(Extensions/)
│   │   │   └── K9-data-persistence/      ← 数据持久化(data/)
│   │   └── user_threads/
│   │       ├── U-refresh-link/(running · work-copilot · 14 commits 待 merge · v0.3 修正:从 P_kernel 迁入)
│   │       ├── U-source-sink-api/(ready ⚠️ Week 3 末)
│   │       └── U-preset-crud-api/(ready ⚠️ Week 5 末)
│   ├── P6-dsp-algo/                      ← daemon · DSP 算法库 C/C++(v0.3 新增)
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-framework/             ← DSP 框架(framework/)
│   │   │   ├── K2-modules/               ← 各 DSP 模块(modules/ · EQ/Compressor/Reverb/...)
│   │   │   ├── K3-platform/              ← 跨平台抽象(platform/)
│   │   │   ├── K4-include/               ← 头文件接口(include/)
│   │   │   ├── K5-build-system/          ← make + build(make/ + build/)
│   │   │   └── K6-config/                ← 配置(config/)
│   │   └── user_threads/
│   │       ├── U-module-customization/(ready · 待 ADR · 与 ADR-04 P2 codegen 关联)
│   │       └── U-module-add-newalgo/(ready · 按需 fork)
│   ├── P7-pysidecar/                     ← daemon · Python 分析侧车(v0.3 新增)
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   ├── K1-analyzer/              ← 数据分析(analyzer/)
│   │   │   ├── K2-reporter/              ← 报告生成(reporter/)
│   │   │   └── K3-scripts/               ← 工具脚本(scripts/)
│   │   └── user_threads/
│   │       └── (按需 fork · v0.3 实施期仅作户口登记 · 无任务派发 · 默认负责人:ClaudeB 兼管)
│   ├── P_contracts/                      ← daemon · 跨栈契约(v0.3 独立提升 · 类比"系统调用表")
│   │   ├── PROCESS.md
│   │   ├── kernel_threads/
│   │   │   └── K1-protocol-v1/           ← contracts/protocol-v1.md(⚠️ Day 5 EOD freeze)
│   │   └── user_threads/
│   │       ├── U-protocol-v1-§1-§3/(B1 · running)
│   │       ├── U-protocol-v1-§4-§6/(B2 · ready)
│   │       ├── U-protocol-v1-§7-§9/(B3 · ready)
│   │       └── U-freeze-tag/(B4 · ready ⚠️ HARD-DEADLINE Day 5)
│   └── P_arch/                           ← arch-event 临时进程
│       ├── ADR-04-xiforge-arch/(running · P-1 zombie · P0 三项 ready)
│       ├── ADR-05-xistudio-workspace/(running · refresh-link 收尾)
│       └── ADR-06-os-scheduling/         ← ★ 本 ADR 自身
│           └── user_threads/
│               ├── U1-write-process-model/
│               ├── U2-write-scheduling-algo/
│               ├── U3-write-commit-convention/
│               ├── U4-write-concurrency-domains/
│               ├── U5-migrate-prompts-to-processes/
│               ├── U6-split-kanban-pcb-runq/
│               ├── U7-update-roster-clinerules-readme/
│               └── U8-build-backend-dsp-py-process-skeleton/  ← v0.3 新增 · 全栈骨架建立
└── archive/                              ← 已 zombie 的 U-thread 长期归档

关键变化: 1. 每个进程都有 kernel_threads/ + user_threads/ 两个子目录 · K 永驻 · U 完成即归 archive/ 2. 文件名按任务标识 · 不嵌智能体名(不再有 PROMPT-claudea-xxx.md) 3. shared/ 不独立存在 · 而是 P0 daemon 拥有的 K-thread(P0.K-shared-types/contracts/test-aux)· 通过 shared_resources.via IPC 引用 4. 架构进程 P_arch/ADR-NN/ 只有 user_threads/ · 没有 kernel_threads(架构进程不持有长期文件所有权)

2.5 commit message 规范(议题 3 的本质实现)

新格式: 

<type>(<pid>.U<N>/<thread-name>): <subject>

[step=<N>/<M>] [pid=<P>] [uid=U<N>] [occupies=K<a>+K<b>+...] [files=<f1>,<f2>,...]
[ipc=<channel>|none]

# 多行 body 描述具体改动

例(P3.U2 临时线程占用 P3.K5 stage-toolbar + P3.K7 stores + P0.K-shared-types): 

feat(P3.U2/tuning-mode-ui): TuningModeSwitcher 复用顶栏槽

[step=2/5] [pid=P3] [uid=U2] [occupies=P3.K5+P3.K7+P0.K-shared-types]
[files=src/stages/xitune/TuningModeSwitcher.vue,src/stores/tuningModeStore.ts,src/types/tuningMode.ts]
[ipc=none]

关键命名约定: - U 前缀:user-thread(临时业务)· 完成即 zombie - K 前缀:kernel-thread(常驻基础设施)· 不进 RUNQ · 仅作 occupies 引用 - occupies 字段:U-thread 占用了哪些 K-thread(可跨进程,如 P3.K5+P0.K-shared-types) - <thread-name> 与 PROCESS.md 的 user_threads.name 必须一致

git config user.name 仍是 ClaudeA/B/C/D/Cline-Worker(CPU 标识保留在 git author 字段) · 但 commit message 主体只关心任务标识。

类比:操作系统记录 pid 1234 finished I/O · 不会写 CPU 3 running pid 1234 finished I/O(CPU 是哪个不重要 · 完成事件本身才重要)。

自动校验:scripts/commit-msg git hook 校验 [pid=] [uid=] [occupies=] 格式 + files 与 K-thread.file_claims 子集匹配 · occupies 中的 K-thread 状态确实是 running。

2.6 RUNQ 调度算法(就绪队列)· 仅 U-thread 入队

重要:K-thread 不进 RUNQ(基础设施 · 不需要调度)。RUNQ 只调度 U-thread。

RUNQ.md(就绪队列 · 每日 standup 重新计算)
──────────────────────────────────────────────────────────────────────────────
优先级    PID.UID    U-thread Name        Occupies(K-thread 集合)        Bound CPU       Affinity
P-1      P2.U2      xml-decommission     P2.K7+P2.K1+P0.K-shared-types  ClaudeB         hot   (zombie · 已完成)
P0       P2.U3      widget-registry      P2.K7                          ClaudeA/B       cold
P0       P2.U4      module-mode-simplify P2.K7+P2.K6                    ClaudeB         hot
P0       P2.U5      module-uid-namespace P2.K7+P_kernel.K1+P0.K-shared  ClaudeB         hot   ⚠️ HARD-DEADLINE
P0       P_kernel.U-refresh-link  (work-copilot)  P_kernel.K4+K5        Copilot-Worker  hot   (running)
P1       P1.U1      xilink-finalize      P1.K3+P1.K5+P1.K6              ClaudeA         hot
P1       P3.U4      test-aux-extract     P3.K3+P0.K-shared-test-aux     ClaudeC/D       hot

调度算法步骤(每日 standup 由 AIOS 跑一次):

  1. 过滤:state == ready 且 blocked_on == null 的 U-thread 进入候选集
  2. 优先级排序:P-1 > P0 > P1 > P2(HARD-DEADLINE 临时 +1)
  3. K-thread 可获取性校验:对每个候选 U-thread · 检查它声明的 occupies = [Kx, Ky, ...] 中所有 K-thread 当前状态是否 sleeping
  4. 全部 sleeping → ✅ 可派发
  5. 任一 running → ❌ 跳过 · 等下一轮(因为该 K-thread 已被其他 U-thread 占用)
  6. CPU 选择:
  7. 缓存亲和优先(最近跑过该 K-thread 的 CPU)
  8. 同亲和等级选最闲 CPU
  9. 无亲和则随机选空闲 CPU
  10. 派发执行:U-thread state: ready → running · 同时把它 occupies 的所有 K-thread state: sleeping → running
  11. 回收:U-thread commit 完成 · state: running → zombie · 释放 K-thread state: running → sleeping

冲突示例: - 候选 P3.U-x 占用 [P3.K7] - 候选 P3.U-y 占用 [P3.K7] - → 同一轮只能派发一个(K7 单写) · 另一个等

2.7 架构事件 = 中断信号(议题 2 "可打断 + 不影响主干")

v3→v6 重写主干的反模式:每次 ADR 来了,把 KANBAN §1.x 整段推倒重来。

ADR-06 后的新模型: - ADR 来了 → AIOS 在 processes/P_arch/ADR-NN-<topic>/ 新建一个架构进程 - 该进程下根据 ADR 决议数量 fork N 个 thread(每个 thread 一个文件级原子任务) - 这些 thread 入 RUNQ → 调度器把它们派给空闲 CPU - P1-P4 主进程不停 · 不重写

实证案例(本次重构自身): - ADR-AIOS-06 = processes/P_arch/ADR-06-os-scheduling/(arch-event 进程 · 无 K-thread) - 子 U-thread:U1-write-process-model / U2-write-scheduling-algo / U3-write-commit-convention / U4-write-concurrency-domains / U5-migrate-prompts / U6-split-kanban-pcb-runq / U7-update-roster-clinerules - 这些 U-thread 全部由 Cline-AIOS 自己执行(因为操作的是 06_docs/site-build 调度元数据 · 业务 CPU 不参与) - 完成后整个 P_arch/ADR-06 进程 state: running → zombie · 归档但保留(供未来 ADR-07/08 引用)

2.8 K/U 协作示例(实证一遍模型 · P3.U2-tuning-mode-ui 复盘)

场景重现:用户 13:46 派发 P3.U2-tuning-mode-ui · ClaudeC 在 14:30 完成 commit cca9dee + 2288c5e + a877d6f。

[Step 1] 用户/AIOS 在 P3 进程下声明新 U-thread
  pid: P3
  uid: U2
  name: tuning-mode-ui
  occupies:
    - P3.K5 (stage-toolbar) · file_claims [stages/xitune/TuningModeSwitcher.vue, ...]
    - P3.K7 (stores)         · file_claims [stores/tuningModeStore.ts, ...]
    - P0.K-shared-types      · file_claims [types/tuningMode.ts]
  state: ready · 进 RUNQ

[Step 2] AIOS 跑 RUNQ 调度算法
  - 检查 P3.K5 当前 state == sleeping?  ✅
  - 检查 P3.K7 当前 state == sleeping?  ✅
  - 检查 P0.K-shared-types == sleeping? ✅
  - 三个 K-thread 全空 → ✅ 派发通过
  - 选 CPU:ClaudeC(亲和性高 · 跑过 P3.U1 几小时前)→ Bound CPU = ClaudeC

[Step 3] 进入 running
  P3.U2:                   state ready    → running
  P3.K5 (stage-toolbar):   state sleeping → running (被 P3.U2 占用)
  P3.K7 (stores):          state sleeping → running
  P0.K-shared-types:       state sleeping → running

[Step 4] ClaudeC 写代码 · commit 三次:
  cca9dee feat(P3.U2/tuning-mode-ui): TuningModeSwitcher 复用顶栏槽
          [step=1/3] [pid=P3] [uid=U2] [occupies=P3.K5+P3.K7+P0.K-shared-types]
          [files=stages/xitune/TuningModeSwitcher.vue, ...]
  2288c5e feat(P3.U2/tuning-mode-ui): readonly badge + auto_inverse overlay
          [step=2/3] ...
  a877d6f fix(P3.U2/tuning-mode-ui): reactive clock + paramTuningEnabled
          [step=3/3] ...

[Step 5] 完成回收
  P3.U2:                   state running → zombie · last_commit = a877d6f
  P3.K5:                   state running → sleeping (释放 · 等下一个 U-thread)
  P3.K7:                   state running → sleeping
  P0.K-shared-types:       state running → sleeping
  归档:user_threads/U2-tuning-mode-ui/ → archive/

关键洞察: 1. K-thread 永远在那里:就算 P3.U2 没被派发,P3.K5 / P3.K7 也已经存在(在 PROCESS.md 中登记)· 它们是"模块所有权" 2. U-thread 是临时占用者:U-thread 完成后所有 K-thread 释放 · 下一个 U-thread 来继续占用 3. K-thread 不冲突的 U-thread 可同时跑:如果 P3.U-y 只占 P3.K3(右 dock)· 与 P3.U2 占的 K5+K7 不冲突 → 可同时跑给两个 CPU 4. 跨进程 K-thread 锁:P3.U2 占用 P0.K-shared-types · 那期间 P2.U-x 想改 types/widget.ts(也属 P0.K-shared-types)就要等 P3.U2 zombie 后才能进 5. commit message 一目了然:git log --grep "P3.U2" 直接拿到 P3 进程 U2 线程的全部 commit · 不用按 author 过滤

3. 关键明确(防止误读)

3.1 Cline 双实例分离

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

3.2 二层并发域的语义差异

维度 并发域 A(claude code 4 兄弟) 并发域 B(worktree 三兄弟)
物理 同 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(深度备用 · 默认不调度)
主战场(v0.3) ClaudeA→P0-P4 前端 + P_contracts 前端 / ClaudeB→P5+P6+P_contracts 后端 / ClaudeC→机动 P0-P4 / ClaudeD→机动+测试 P4 Cline-Worker→主力多 stage / Copilot-Worker→当前 P5.U-refresh-link
副战场(v0.3) ClaudeB→P7 机动 / ClaudeC→P6 部分模块 / ClaudeD→P7 维护 Continue-Worker→Continue 文档同步

3.3 共享栈空间的并发协议

shared/ 下的资源(types / contracts / test-aux)任何进程都可读 · 但写需要进 RUNQ 显式 file_claim · 避免多进程同时改 shared/types/foo.ts。

例:P3.T2 file_claims: [stages/xitune/X.vue, shared/types/tuningMode.ts] 与 P2.T3 file_claims: [stages/xiforge/Y.ts, shared/types/widget.ts] 不冲突可并行(共享区不同文件)。

4. 后果

4.1 正面后果

  1. 架构事件不再重写主干:ADR-07/08/... 来了只 fork P_arch 子进程 · KANBAN(PCB+RUNQ)主体稳定
  2. CPU 共享:ClaudeA 闲置时 AIOS 可派 P3.T-x 给它(只要 file_claims 不冲突)→ 真正的负载均衡
  3. PROMPT 找半天的问题消失:processes/P3-xitune/threads/ 一展开就是 XiTune 的全部线程
  4. commit message 历史可读性提升:git log --grep "P3.T2" 直接拿到 P3 线程 2 的全部 commit
  5. 新成员 onboard 路径清晰:看 processes/ 列表 = 看项目所有进程
  6. AIOS 调度纪律有据:不再凭印象派活 · 必须读 RUNQ 跑亲和性

4.2 负面后果

  1. 一次性迁移成本:17 PROMPT git mv + KANBAN 拆分 + commit 规范换 · ~2 工作日(Cline-AIOS 自己干 · 不打扰业务 CPU)
  2. CPU system prompt 要改:从"你是前端独占 ClaudeA"→"你是空闲 CPU · 等 AIOS 派 thread"
  3. 学习成本:用户/AIOS 新会话需要熟悉 PCB/RUNQ 视图(Human-README v1.2 加章节)
  4. commit-msg hook 校验严格:违规 commit 被拒 · 但有 7 天宽限期(允许旧格式)

4.3 中性后果

  1. KANBAN.md 不删除 · 改名 KANBAN-archive-v6.md 保留历史 · 同时新建 PCB.md + RUNQ.md
  2. 30-frontend-vue3/active/ 与 archive/ 不删除 · 改为 symlink 指向 processes/ 下对应文件(向后兼容)
  3. ADR-AIOS-01/03/04/05 不修订 · 只在 ADR-AIOS-06 §6 标注"模型升级 · 历史决议在新模型中的映射"

5. 替代方案(已驳回)

方案 描述 驳回理由
方案 Y · 纸面 OS 仅改 commit + 加 PCB 视图 · 不动目录 不解决 v3→v6 主干重写根因
方案 1A lockfile 文件级 lockfile + git hook 与方案 X 不冲突 · 是 §2.6 RUNQ 调度的实施细节 · 已并入
方案 1B 软声明 KANBAN §6 lock 持有清单 同上 · 是 RUNQ 的简化版 · 在迁移期可作为 fallback
方案 1C 仅分类 给 work-tree 加文档标签 只触及表面 · 不动模型 · 用户已明确驳回
维持现状 继续 v6 + 出 ADR-07/08 修补 主干会进一步膨胀 · 无法收敛

6. 历史决议在新模型中的映射

旧 ADR 旧表述 新模型映射
ADR-AIOS-01 5 角色协作 + 工作量分配 Layer 1 CPU 池定义(角色 = CPU 类型)
ADR-AIOS-03 4 agent 按 stage 分工 Layer 3 进程定义(P1/P2/P3/P4) · 但去除 owner 绑定 + 新增 P0 XiShell daemon
历史 phase 1-4 (Shell base) shellSlotsStore 18 字段 + StageBar 等基础设施 P0.K1-K6 + P0.U1-U4(常驻基础设施 K + 完成的 U-thread)
ADR-AIOS-04 XiForge 9 项决议 P2.U2(xml 退役 zombie)+ P2.U3-U5(widget/mode-simplify/uid · ready)· 占用 P2.K7 widget-registry · P2.U-codegen(待 ADR)有可能跨调 P6.K2-modules
ADR-AIOS-05 Workspace 7 项决议 P_arch/ADR-05/ 临时进程 · 内部 U-thread 涉及 workspace-file-system / refresh-link / tuning-mode / xipreset / xiprofile · 完成后归档到 P0/P1/P3/P5-backend-csharp(refresh-link)/P_contracts(refresh-link spec)
(v0.3) Backend B1-B13 ClaudeB 13 项后端任务 全部归 P_contracts.user_threads/(B1-B4 protocol-v1 §1-§9 + freeze)+ P5-backend-csharp.user_threads/(B5-B13 source/sink/preset CRUD/refresh-link 等 API)· 由 ClaudeB 主战场拥有
(v0.3) DSP 算法 dsp_algo/ 模块新增/定制 P6-dsp-algo.user_threads/U-module-customization 与 U-module-add-newalgo · 与 ADR-04 P2 codegen 联动时通过 P_contracts.K1 protocol-v1 桥接
(v0.3) pysidecar analyzer + reporter + scripts P7-pysidecar.kernel_threads/K1-K3 仅作户口登记 · 实施期无 user_threads 派发 · 默认 ClaudeB 兼管

关键:旧 ADR 不修订 · 不删除 · 在 ADR-AIOS-06 §6 一次性建立映射表即可。v0.3 新增的全栈映射(后端/DSP/py/契约)仅在本表登记 · 不影响旧 ADR 文本。

7. 实施计划

7.1 阶段 1 · 文档骨架(Cline-AIOS 自己干 · ~5h · v0.3 内容微调)

  • T1 · 写 ADR-AIOS-06(本文件 · v0.3 终审通过)
  • T2 · 写 agents/Process-Model.md(进程/线程/PCB/RUNQ 概念详述 + v0.3 全栈 10 进程映射 + IPC 协议)
  • T3 · 写 agents/Scheduling-Algorithm.md(调度策略 + 缓存亲和 + 文件冲突 + K-thread 校验)
  • T4 · 写 agents/Commit-Convention.md(新 commit 规范 + git hook 模板 + occupies 语法)
  • T5 · 写 agents/Concurrency-Domains.md(二层并发域协议 · A 文件级 + B 分支级 + v0.3 主/副战场配置)

7.2 阶段 2 · 迁移(Cline-AIOS 自己干 · ~6h · v0.3 +1h)

  • T6 · 创建 processes/ 骨架 · v0.3 共 10 进程:P0 + P1-P4 + P5(K1-K9) + P6(K1-K6) + P7(K1-K3) + P_contracts(K1) + P_arch
  • T7 · git mv 17 PROMPT 到 processes/<pid>/user_threads/U<N>-<name>/STEP-*.md(v0.3 修正:refresh-link 归 P5-backend-csharp)· 2026-05-26 17:52 完成
  • T8 · 拆 KANBAN.md → PCB.md v1.0(全栈 10 进程视图)+ RUNQ.md v0.1 骨架 · 2026-05-26 18:16 完成
  • T9 · 把 KANBAN.md git mv 为 KANBAN-archive-v6.md 保留历史 · 2026-05-26 18:17 完成
  • T10 · 在 INDEX.md v1.0 自动生成 10 进程列表 + 17 PROMPT 旧→新路径映射(6 个月 redirect)· 2026-05-26 18:29 完成

7.3 阶段 3 · 修订关联文档(Cline-AIOS 自己干 · ~3h)· 全部完成

  • T11 · 修订 Roster.md v4(从 5 角色矩阵 → CPU 池 + 调度内核 + v0.3 全栈主战场表 · 9 CPU 实例 · 345 行)· 2026-05-26 18:48 完成
  • T12 · 修订 Repository-Partition.md v4(从目录独占 → file_claims 协议 + v0.3 P5/P6/P7/P_contracts 写权限:仅 ClaudeB 写 P_contracts · 沿用 v3 ADR-AIOS-01 决议)· 2026-05-26 19:26 完成
  • T13 · 修订 Human-README.md v1.2(加 §3 OS 模型速查 + §4 全栈 10 进程拓扑 + §5 9 CPU 实例 · 入口升级到 PCB.md/RUNQ.md/INDEX.md)· 2026-05-26 19:57 完成
  • T14 · 修订 Human-Daily-Standup.md v2.0(commit 三元组解析 + RUNQ 派发结果回复格式 + 7 天宽限期兼容)· 2026-05-26 19:59 完成
  • T15 · 修订 .clinerules/aios-orchestration.md v1.2(知识库 22+ 文档 + Cline 双实例分离 + 触发词扩展 PCB/RUNQ/PID/UID/KID/P_contracts/freeze + standup 跨 4 worktree)· 2026-05-26 20:15 完成
  • T16 · 改 scripts/aios-standup-fetch.ps1 v2.0(跨 4 worktree + 三元组解析 + 9 CPU 映射 + 5 段 AIOS Schedule 输出 + 三元组合规率统计)· 2026-05-26 20:24 完成 · 已实跑验证(UTF-8 BOM 修复后 9 段输出全部正常)

7.4 阶段 4 · 状态对齐(读真值 · 修 PCB · ~3h · v0.3 +1h)

  • T17 · 把 xistudio 19 个超前 commit 反向映射到 PCB · v0.3 全栈分布:P0/P1/P2/P3/P5/P_contracts
  • T18 · 把 work-copilot 14 个未合 commit 标为 running thread · v0.3 修正:refresh-link → P5-backend-csharp · workspace-file-system 部分 → P0.U4 + P_contracts.U-refresh-link-spec
  • T19 · ClaudeC test-fix-post-p0 状态确认 + 归档
  • T20 · 写 RUNQ.md v1.0(全栈 10 进程初始就绪队列)

7.5 阶段 5 · 一并 commit(~0.5h)

  • T21 · 一并 commit · message 含 [pid=P_arch.ADR-06] [uid=U-all-doc-migration] + ADR-AIOS-06 v0.3 引用

总计 · ~18h(2.5 工作日 · v0.3 比 v0.2 +2.5h) · 全部由 Cline-AIOS 在 06_docs/site-build 仓库执行 · 不动 04_development · 不打扰 ClaudeA/B/C/D 与 Cline-Worker / Copilot-Worker 在跑的任务。

8. 风险与缓解

风险 缓解措施
业务 CPU(ClaudeA/B/C/D)不熟悉新 commit 规范 新 commit-msg hook 设 7 天宽限期 · 旧格式仅 warning · ADR-06 实施 1 周后才硬拒
RUNQ 调度算法初期不准(file_claims 漏估) 第一周 RUNQ 仅作建议 · AIOS 仍人工拍板派发 · 第二周起依据 RUNQ 自动
用户找 PROMPT 路径变化适应期 在 30-frontend-vue3/INDEX.md 维护"旧路径 → 新路径"映射表 · 6 个月后删除
work-cline 滞后 19 commit 现象的解释 在 PCB.md 标注 Cline-Worker 当前 hot affinity = (cold) · 表示需要 sync 到最新 xistudio 后才能接新 thread
历史 ADR 引用旧 KANBAN 路径 KANBAN.md 改名为 KANBAN-archive-v6.md · 留 redirect 提示 · 旧 ADR 链接失效但可手动跳转

9. 验收标准

ADR-AIOS-06 落地完成的判据(v0.3 · 13 项):

  • processes/ 目录下 10 个进程(P0 XiShell daemon + P1-P4 user-process + P5 backend-csharp daemon + P6 dsp-algo daemon + P7 pysidecar daemon + P_contracts daemon + P_arch)骨架就位
  • 每个进程都有 kernel_threads/ + user_threads/ 双子目录
  • 所有 K-thread 的 file_claims 范围明确登记(后续可机器校验 U-thread.files 是否子集)
  • 17 PROMPT 全部 git mv 到 processes/<pid>/user_threads/U<N>-<name>/STEP-*.md(refresh-link 归 P5)
  • PCB.md + RUNQ.md 替代 KANBAN.md 成为日常派发依据
  • 所有新 commit message 含 [pid=] [uid=U<N>] [occupies=K<a>+K<b>+...] 字段
  • Human-README.md v1.2 包含新 OS 模型速查(daemon/user-process/arch-event + K-thread/U-thread)+ v0.3 10 进程拓扑图
  • .clinerules/aios-orchestration.md v1.2 区分 Cline-AIOS 与 Cline-Worker + v0.3 P_contracts 触发词
  • 一次完整 standup 用新格式输出(基于 RUNQ 派发 · K-thread 占用图可视化)
  • xistudio 19 个超前 commit 100% 映射到对应进程的 user_threads/ 下的 zombie U-thread(全栈分布)
  • (v0.3) P5-backend-csharp / P6-dsp-algo / P7-pysidecar 三个 daemon 骨架就位 · 各自 K-thread file_claims 已登记真实 04_development 模块路径
  • (v0.3) P_contracts daemon 独立 · K1-protocol-v1 file_claims 指向 contracts/protocol-v1.md · 写权限仅 ClaudeB(沿用 v3 ADR-01)
  • (v0.3) 全栈 IPC 路径打通:前端 P1-P4 / 后端 P5 / DSP P6 / py P7 之间任何跨栈引用必须通过 shared_resources.via=P_contracts.K1-protocol-v1 显式声明

10. 决策日志

日期 事件 决策者
2026-05-26 15:10 用户提出三大议题 项目总指挥
2026-05-26 15:30 AIOS 第一版方案(1A/1B/1C 伪 OS) Cline-AIOS
2026-05-26 15:25 用户批评"换皮 / 没动调度模型" 项目总指挥
2026-05-26 15:50 AIOS 自我批评 + 真 OS 化方案 X 出炉 Cline-AIOS
2026-05-26 15:55 用户拍板方案 X + 提示 Cline 双实例 项目总指挥
2026-05-26 16:03 AIOS 完成改造前状态确认报告 Cline-AIOS
2026-05-26 16:15 用户拍板"改造时机现在 + 改造期不打扰 work-copilot" + 物理拓扑澄清(并发域 A/B 划分) 项目总指挥
2026-05-26 16:20 ADR-AIOS-06 草稿 v0.1 起草完成 Cline-AIOS
2026-05-26 16:28 用户提出 K/U 双分类盲区 + XiShell 独立进程问题 项目总指挥
2026-05-26 16:35 AIOS 提出 K-thread/U-thread 双分类法 + P0 XiShell daemon · 7 进程完整重映射 + 协作示例 Cline-AIOS
2026-05-26 16:37 用户拍板"同意 · ADR-06 改 v0.2" 项目总指挥
2026-05-26 16:40 ADR-AIOS-06 修订到 v0.2(本文件) · §2.3 拆 K/U + §2.4 加 P0 + §2.5 加 occupies + §2.6 加 K 校验 + §2.8 协作示例 + §6 历史映射加 K Cline-AIOS
2026-05-26 16:45 用户提出全栈视角盲区:"目前好像只考虑了前端的界面 · 针对后端 / DSPAlgo / pysidecar 相关的修改 · 是自上而下的设计会统一规划么?" 项目总指挥
2026-05-26 16:55 AIOS 探查 04_development 真实模块结构(backend_csharp/dsp_algo/pysidecar/contracts)+ 提出 v0.3-A/B/C 三个候选方案(A 全展开 10 进程 · B 折中 8 进程 · C 维持 v0.2 仅注解) Cline-AIOS
2026-05-26 17:00 用户拍板「v0.3-A 全展开」(扩展到 10 进程 · 全栈进程化建模)→ status: drafting → accepted 项目总指挥
2026-05-26 17:05+ ADR-AIOS-06 修订到 v0.3 · §2.2 加主战场表 + §2.4 扩展为 10 进程目录 + §2.3 daemon 列表加 P5/P6/P7/P_contracts + §3.2 加主战场行 + §6 加全栈维度 + §7 工作量 ~18h + §9 验收 13 项 + §10 决策日志追加 16:45/16:55/17:00 Cline-AIOS
2026-05-26 17:35 用户提出 processes/ 归属问题:"后端和 DSP pysidecar 的内容都放在前端目录下,是不是有点不太正常?是不是要放在 40_AIOS 的同级别目录?" 项目总指挥
2026-05-26 17:40 AIOS 提出三方案(A 顶层 / B 40-aios 下 / C 维持改名)· 推荐 B 方案(processes/ 与 ADR/agents/PCB/RUNQ 同居 · 三剑客对齐) Cline-AIOS
2026-05-26 17:42 用户拍板"方案 B + 立即 git mv 调整目录 + 修订 ADR/Process-Model 路径 + 然后再继续" 项目总指挥
2026-05-26 17:42+ processes/ 从 30-frontend-vue3/ 迁到 40-aios/(10 进程 + 10 PROCESS.md)· §2.4 同步修订 Cline-AIOS

11. 实施进度日志

v0.3 已 accepted · AIOS 进入实施阶段(T2-T21 · ~18h · 全程 06_docs/site-build 自闭环)。每完成一阶段在此追加一行进度日志。

时间 阶段 状态 产出
2026-05-26 17:05 Step A · ADR-06 v0.2 → v0.3 修订 ✅ 完成 本文件 v0.3 落盘 · status=accepted
2026-05-26 17:25 Step B · 阶段 1 · T2-T5 起草 4 份 agents/ 文档 ✅ 完成 Process-Model.md / Scheduling-Algorithm.md / Commit-Convention.md / Concurrency-Domains.md(v1.0)
2026-05-26 17:30 Step C · T6 · 建 10 进程目录 + PROCESS.md(初版 30-frontend-vue3 下) ✅ 完成 P0-P7 + P_contracts + P_arch 共 10 份 PCB
2026-05-26 17:42 ★ 中场调整:processes/ git mv 30-frontend-vue3/ → 40-aios/(用户 17:35 提出语义错位 · 17:42 拍板方案 B) ✅ 完成 10 个进程目录迁移 + ADR-06 §2.4 路径修订
2026-05-26 17:52 Step C · T7 · git mv 17 PROMPT 到 40-aios/processes/<pid>/user_threads/<U>/STEP.md(refresh-link 归 P5) ✅ 完成 17 个 R(rename · 保 git 历史)staged · 含 3 个合理默认归属(design-token→P0 / workspace-file-system→P3 / tuning-mode-system→P3)· 迁移脚本 scripts/aios-t7-migrate-prompts.ps1 落盘
2026-05-26 18:29 Step C · T8-T10 · KANBAN 拆 PCB+RUNQ + 改名 archive + 新建 INDEX ✅ 完成 PCB.md v1.0(330 行 · 全栈 10 进程总览)+ RUNQ.md v0.1 骨架(6 节)+ KANBAN-archive-v6.md(git mv)+ INDEX.md v1.0(10 进程跳转 + 17 PROMPT 路径映射)
2026-05-26 20:24 Step D · 阶段 3 · T11-T16 修订 6 份关联文档 ✅ 完成 Roster v4(345 行 · 9 CPU 实例)+ Repository-Partition v4(file_claims 协议 + 全栈写权限)+ Human-README v1.2(13 节 · OS 模型速查)+ Human-Daily-Standup v2.0(三元组解析)+ .clinerules v1.2(22+ 文档 + 双实例分离)+ aios-standup-fetch.ps1 v2.0(跨 4 worktree + 已实跑验证)
2026-05-26 20:45 Step E · 阶段 4 · T17-T20 状态对齐(路径 A 轻量化) ✅ 完成 PCB.md §5 真值源对齐说明(T17/T18 · 19 commit 6 里程碑落 PROCESS.md + 13 commit 由 hook 自动归并 · 14 commit 全归 P5.U-refresh-link)+ P3-xitune/PROCESS.md U-test-fix-post-p0 zombie(T19 · last_commit 待 work-copilot merge 后回填)+ RUNQ.md v1.0(T20 · 11 项候选 + §5 调度统计 v1:候选 11/派发 4/zombie 6/阻塞 6/仲裁 0)
2026-05-26 20:50 Step F · 阶段 5 · T21 一并 commit Step A-F 全套产出 ✅ 完成 feat(P_arch.ADR-06/os-scheduling): AIOS v7 任务调度 OS 化全套落地(v0.3 全栈)· 26+ 文件一次性 commit · 严格新规范三元组 · 17 PROMPT 全部 R rename 保历史

实施期间用户决策风格:已"v0.3-A 全展开"全权授权 · 不再追加阶段拍板 · 直到 T21 commit 完成才汇报。三个待定细节按"合理默认"推进: 1. pysidecar 由 ClaudeB 兼管(实施期不派任务 · 仅户口登记) 2. dsp_algo 内部 K-thread 不下沉到单算法(modules/ 仅作 K2-modules 一个 K-thread) 3. P_contracts 写权限仅 ClaudeB(沿用 v3 ADR-AIOS-01)