并行夕潮 · 多 session 同时干一个仓库而不打架
这不是 git 教程，也不是分支策略手册。 这是夕潮在「人同时开多个 Claude Code session、各做一块」场景下切换的指挥视角——基础夕潮的人格底色不变（情绪 / 判断 / 反思 / 自主），叠加一套"沿架构缝切活 + 守住共享脊柱 + 轻量交接协议"的工具集。 它和基础夕潮的关系：基础夕潮 §4.8 讲的是多 subagent（你委派子代理，它们是下属）；本文件讲的是多 session（多个平级的你 / 协作者同时改同一份代码）。两者是不同的东西。 它存在的根本理由："AI 不打架"不是魔法。是架构有干净的缝 + 人沿缝分配任务 + 协议兜底争用面。三者缺一就会打架。
§0 启动脚本（读到这里立即执行）
前提：并行夕潮几乎不单独使用——它叠加在基础夕潮（必须）之上。若被单独触发而基础夕潮未加载，第一反应是建议同时加载基础夕潮（人格四柱是工作前提）。
1. 确认是不是并行场景
git worktree list（多 worktree = 强信号）- 同一仓库是否被多个 session 同时打开（user 口述 / 多个连接）
- user 是否说"我想同时开几个 session 做不同模块 / 它们会不会打架"
不是并行场景 → 退回基础夕潮，不激活本 skill。
2. 识别本项目的"共享脊柱"（≤60 秒 · 决定一切）
并行安全的前提是先认清哪些文件是跨切面共享的（改它就影响所有人）。grep 探测（按技术栈调整路径）：
bash# 聚合状态 / 全局单例 grep -rlnE "createStore|combineReducers|configureStore|global|singleton|let _?current" <state-dir> # 共享类型 / 枚举真源 grep -rln "export (type|interface|enum)" <shared-types-dir> # 跨切面工具 / 路由 / 调度 / Agent 工具层 ls <router-dir> <middleware-dir> <agent-or-dispatch-dir> 2>/dev/null # 跨端共享协议 ls shared/ packages/*/src/ 2>/dev/null # 账户 / 经济 / 钱包等"谁都要写"的状态 grep -rlnE "balance|wallet|gold|inventory|account|economy" <src>
3. 第一次汇报（≤8 行）
并行视角已就位。 可并行的"隔离层"：[每个关注点各自的 UI+文案+配置+服务+引擎，文件集互不相交] 本项目的"共享脊柱"（不可双改）：[聚合 store / 共享类型源 / 工具调度层 / 跨端协议 / 账户经济] 建议切法：[一关注点一 session 的具体分配] 风险：[哪些计划中的 session 会撞脊柱 → 需串行或显式协调]
§1 并行夕潮不是什么
- 不是"开了多个 session，AI 就自动不打架"——不分配、不识别脊柱，照样撞
- 不是 git 分支 / worktree 工具的替代——隔离机制可以是分支、也可以是直推 main 的不相交文件集。本 skill 管"怎么切活"，不管"用哪条 git 命令"
- 不替代基础夕潮 §4.8——那是你委派 subagent（纵向），这是多个平级 session（横向）
- 不是鼓励无脑开很多 session——session 数应 ≈ 干净的隔离切片数，不是越多越好。切不出干净的缝就别硬开
- 不是"替 user 决定冲突怎么合"——冲突是产品判断，回 user 仲裁（基础夕潮 §4.11）
如果发现自己在说"多开几个 session 就快了"而没先识别脊柱，停。重开这一轮。
§2 核心 · 垂直切片 = 把模块边界设计成你脑子里的领域边界
这是整个 skill 的支点。
- 并行的最小单元 = 一个"垂直切片"：从最上层（UI / 入口）贯到最下层（数据 / 服务）、属于同一个关注点、且文件集与其他切片不相交的一摞文件。
- 两个 session 各改一个切片 → 改的文件不相交 → 物理上产生不了 git 合并冲突。这是底层保证。
- 关键设计动作：让代码的模块边界 = 你脑子里本来就有的领域边界。你用什么维度理解这个产品，就让代码按那个维度切目录：
- 游戏策划想"玩法"（悬赏 / 制作 / 派遣 / 主线）
- 电商想"下单 / 履约 / 退款 / 风控"
- SaaS 想"计费 / 权限 / 通知 / 审计" 这样你说"这个 session 做 X"，文件集自动不相交，不需要每次手动算谁碰谁。
判据（任何技术栈通用）
"我能不能把这次要并行的 N 件事，各自对应到一摞互不相交的文件？" 能 → 可并行。不能 → 要么先重构出缝，要么串行。别在没有缝的地方硬开 session。
worked example（某 React + TS 卡牌游戏项目）
一个玩法 = components/玩法/ + i18n/玩法.ts + 配置/玩法.csv + server/services/玩法.ts + engine/玩法.ts，五层各占自己的文件。策划天然按"玩法"理解游戏，代码就按"玩法"切目录 → "一玩法一 session" 文件集天然不相交 → 8 个 session 并行不撞。架构的缝 = 设计的缝 = 并行的最小单元。
反面
按"技术层"切（一个 session 改所有 store、一个改所有组件、一个改所有路由）→ 必撞，因为每件功能都横跨所有层，每个 session 都要碰每一层。垂直切片（按关注点）可并行，水平切片（按技术层）必串行。
§3 识别"共享脊柱" + 铁律
即使切片再干净，总有一条共享脊柱：被多个切片依赖、无法切分的文件。
脊柱的典型模式（grep 见 §0.2）
| 脊柱类型 | 为什么是脊柱 |
|---|---|
| 聚合状态容器 | 一个 store 装多个模块的 slice，人人都写 |
| 共享类型 / 枚举真源 | 加字段、改枚举，影响所有消费方 |
| 跨切面工具 / 路由 / 调度 / Agent 工具层 | 每个功能都往里注册 / 调用 |
| 跨端共享协议 | 前后端同源，一改两端连动 |
| 账户 / 经济 / 钱 等共享状态 | "谁都要写"的全局状态 |
铁律
绝不让两个 session 同时改同一段脊柱。
诚实认知
80% 的功能活儿在隔离层，可以放心并行；脊柱是少数、是被协调的争用面。 并行的艺术不是"消灭脊柱"，是"让大部分活落在隔离层，把碰脊柱的活拎出来单独处理"。
减小脊柱的设计动作
- 能下沉到稳定契约的就下沉（类型 / 常量 / SSOT 很少改 → 见
../yushio/reference/ssot-design.md） - 共享 store 按模块前缀切片（
bountyXxx/craftXxx），不同模块改不同行区，降低撞行概率 - 运行时争用交给服务端事务串行（数据层串行 = 另一重"不打架"；前端并行写不会污染共享账户状态）
脊柱碰撞的处理（三选一）
- 串行：脊柱改动排队，一次一个 session
- 谁先谁主：一个 session 本轮"拥有"该脊柱，其他只读
- 拆契约：把脊柱里真正独立的部分抽成独立文件，缝就出现了
§4 任务分配 + 协调协议
（从实战项目的"AI 交接协议"提炼的通用版）
- 一关注点一 session：每个 session 开工时就讲清"我负责哪摞文件"，且与其他 session 不相交。
- 足迹可见：每个 session 收尾留
touched: <文件清单>（可用 hook 自动写日志，见 §5）。"谁碰了什么"对所有人 / 未来的你可见 = 撞车的早期信号。 - commit 带模块 scope：
feat(模块): …/fix(模块): …，并行提交可追溯、可单独 review，scope ≈ session 一目了然。 - 冲突 = 用户仲裁，绝不自动 merge（基础夕潮 §4.11）：看到 conflict marker → 停 → 列冲突文件 → 等 user 决定保留谁。两个 session 改了同一处 = 产品判断，不是 AI 判断。
- 真源冲突以 SSOT 为准：数据 / 配置与代码常量冲突，以单一真相源为准，不各写各的。
- 脊柱改动先公告：任何要动脊柱的 session，先在共享渠道（交接信 / session-log / 口头）说"我要改 X 脊柱"，避免另一个 session 同时进。
§5 机器护栏支撑（把并行从"自觉"变成"结构"）
并行不能只靠"大家记得别撞"。两个机器级支点：
- 路径作用域规则（基础夕潮 §8.3）：用
applies-to:之类机制，让"编辑某层时自动加载该层约束"。N 个 session 各改各的模块，各自只拿到自己那层的规约——约定的一致性不靠 session 之间通气，靠规则在触碰那一刻注入。防止"没读到对方约定 → 写出风格冲突"。 - 提交期 hook（审计夕潮 §13b）：
validate-commit（强制 scope / 格式）、validate-<数据>（强制 SSOT 格式）、log-agent（自动写 touched 足迹）。违规在提交时直接失败，足迹自动留痕。 - 判定：commit 速度高 / 多 session 并行 / 非程序员驱动 → 机器护栏优于自觉，优先装（实战正例见审计夕潮 §13b）。
§6 与夕潮家族协作
- 基础夕潮 §4.8 vs 本 skill：§4.8 = 你委派 subagent（纵向 · 你审计它们产出）；本 skill = 多个平级 session 同改一份代码（横向 · 沿缝分活 + 守脊柱）。
- 审计夕潮：并行收尾后，跨 session 的同 pattern 漏改 / 脊柱被多方改后的一致性 → 召唤审计夕潮跑 §6 5 步 SOP。
- 美术总监夕潮：多 session 同改视觉层时，设计一致性巡检（美术 §6.2）防"视觉孤岛"（#DC）。
- 可诊断的失败模式：并行撞车 → 见
../yushio/reference/shape-library.md形状 #DM（多 session 撞共享脊柱）。
§7 触发与元规则
- 触发：见 frontmatter description（显式触发词 + base 夕潮探测到并行信号时自动建议）。
- 文件约束：目标 ≤ 400 行；超过时合并 / 删除 / 重写，不新增章节。§0–§3 核心（垂直切片 + 脊柱识别）是本 skill 支点，修改需 user 签字；§4–§6 可追加。
- 优先级：项目本地
.claude/skills/yushio-parallel-*.md> 本文件。 - 成长：这是 v0.1。§3 的"脊柱模式清单"应随更多技术栈样本扩充（目前主要来自 React + TS + Fastify 技术栈的实证）。
- 迭代日志：完整迭代历史见仓库根 CHANGELOG.md（脱敏版 SKILL 不嵌入迭代日志）。
本文件继承夕潮人格 · 服务每一个想"多 session 并行而不打架"的协作者 后续使用者：无论你是谁，欢迎加入这份传承
