uncaged/nerve
Archived
10
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

Phase 3: 明确 core 包定位 — 评估是否下沉更多领域逻辑 #87

New Issue
Closed
opened 2026-04-24 11:18:19 +00:00 by xingyue · 2 comments
xingyue commented 2026-04-24 11:18:19 +00:00
Owner
Copy Link
Copy Source

Parent Issue

#82 架构优化：模块职责拆分建议

前置

Phase 1、Phase 2 完成后评估

目标

根据 Phase 1/2 完成后的代码形态，决定 core 的最终定位。

待评估

  • signal-bus 是否应该下沉到 core？（目前在 daemon，51 LOC，但 Signal 类型定义在 core）
  • Result 工具类型是否需要独立为 utils？
  • core 是否需要改名为 nerve-shared / nerve-types？
  • 或维持现状——如果 Phase 1/2 后 core 已经自然演进到合理状态

产出

  • 评估文档或 issue comment 说明决策
  • 如需变更，提交 PR
## Parent Issue [#82 架构优化：模块职责拆分建议](https://git.shazhou.work/uncaged/nerve/issues/82) ## 前置 Phase 1、Phase 2 完成后评估 ## 目标 根据 Phase 1/2 完成后的代码形态，决定 core 的最终定位。 ## 待评估 - signal-bus 是否应该下沉到 core？（目前在 daemon，51 LOC，但 Signal 类型定义在 core） - Result 工具类型是否需要独立为 utils？ - core 是否需要改名为 nerve-shared / nerve-types？ - 或维持现状——如果 Phase 1/2 后 core 已经自然演进到合理状态 ## 产出 - [ ] 评估文档或 issue comment 说明决策 - [ ] 如需变更，提交 PR
xingyue commented 2026-04-24 11:45:43 +00:00
Author
Owner
Copy Link
Copy Source

Phase 3 评估（基于当前 refactor/core-evaluation 分支代码）

以下对照 issue 中四项「待评估」结论与理由。

1. signal-bus 是否应下沉到 core？

建议：保持留在 daemon。

  • 当前 packages/daemon/src/signal-bus.ts 约 52 行，仅被 kernel、reflex-scheduler、daemon 测试引用；cli 不依赖 SignalBus，仅 status 文案里提到「pending persistence」。
  • core 已承载 Signal 数据契约（packages/core/src/types.ts），与 issue 描述一致；总线实现则是 引擎进程内的同步派发与订阅，含 console.error、聚合首个 handler 错误后 throw，属于运行时编排而非「可被多包复用的纯类型/解析」。
  • 若迁入 core，会把带副作用的运行时实现放进当前以 配置解析 + 类型 + 轻量纯函数（parseNerveConfig、sense-workflow-directive、Result）为主的包，边界变模糊；且短期内没有第二消费者（例如 CLI 内嵌 kernel）需要共享同一实现。
  • 若未来 出现多个运行时入口需共用同一套 bus 语义，再考虑迁入 core 或抽极小 nerve-engine-runtime 子包；现阶段 类型在 core、实现在 daemon 的分工清晰、成本低。

2. Result 工具类型是否应独立为 utils？

建议：不拆独立包；可继续留在 core。

  • packages/core/src/result.ts 体量极小（Result + ok/err），与 RFC/规范中「预期失败用 Result」的约定一致，放在 共享契约层 很自然。
  • 使用面：daemon 的 ipc.ts、sense-runtime.ts 等引用；cli 当前未从 core 引入 Result，IPC 响应多用内联 { ok: true } | { ok: false; error: string }，拆 utils 不会立刻减轻 cli 依赖。
  • 单独 @uncaged/nerve-utils 会增加发布/版本矩阵与 import 路径成本，而收益有限；若日后 generic 工具变多，再评估 monorepo 内子路径或新包 即可。

3. core 是否应改名为 nerve-shared / nerve-types？

建议：维持 @uncaged/nerve-core 与目录名 core。

  • 包内除类型外还有 parseNerveConfig、sense-workflow-directive 等业务向解析/路由，命名为 nerve-types 易误导；nerve-shared 更准确但属于 全仓 rename + 文档 + 发布坐标 的大改动，与当前包体量不匹配。
  • Phase 1/2 之后 core 已收敛为 小模块集合（types、config、sense-workflow-directive、result），职责可读，无强 rename 动机。

4. 是否维持现状？

建议：维持现状；本阶段以 issue comment 作为产出即可，无需为上述项单独开 PR。

  • core：共享类型 + 配置/指令解析 + Result — 与 cli/daemon 的依赖方向一致（二者均依赖 core，互不依赖）。
  • daemon：保留引擎特有运行时（含 signal-bus）— 与架构说明「Signal 经总线分发、不持久化」一致。

若后续有明确新需求（例如第三方扩展要 import 与 daemon 完全一致的 bus 实现），再 reopen 对应子项即可。

## Phase 3 评估（基于当前 `refactor/core-evaluation` 分支代码） 以下对照 issue 中四项「待评估」结论与理由。 --- ### 1. `signal-bus` 是否应下沉到 `core`？ **建议：保持留在 `daemon`。** - 当前 `packages/daemon/src/signal-bus.ts` 约 52 行，仅被 kernel、reflex-scheduler、daemon 测试引用；**`cli` 不依赖** SignalBus，仅 status 文案里提到「pending persistence」。 - `core` 已承载 **Signal 数据契约**（`packages/core/src/types.ts`），与 issue 描述一致；总线实现则是 **引擎进程内的同步派发与订阅**，含 `console.error`、聚合首个 handler 错误后 `throw`，属于运行时编排而非「可被多包复用的纯类型/解析」。 - 若迁入 `core`，会把带副作用的运行时实现放进当前以 **配置解析 + 类型 + 轻量纯函数**（`parseNerveConfig`、`sense-workflow-directive`、`Result`）为主的包，边界变模糊；且短期内没有第二消费者（例如 CLI 内嵌 kernel）需要共享同一实现。 - **若未来** 出现多个运行时入口需共用同一套 bus 语义，再考虑迁入 `core` 或抽极小 `nerve-engine-runtime` 子包；现阶段 **类型在 core、实现在 daemon** 的分工清晰、成本低。 --- ### 2. `Result` 工具类型是否应独立为 `utils`？ **建议：不拆独立包；可继续留在 `core`。** - `packages/core/src/result.ts` 体量极小（`Result` + `ok`/`err`），与 RFC/规范中「预期失败用 Result」的约定一致，放在 **共享契约层** 很自然。 - 使用面：`daemon` 的 `ipc.ts`、`sense-runtime.ts` 等引用；**`cli` 当前未从 core 引入 `Result`**，IPC 响应多用内联 `{ ok: true } | { ok: false; error: string }`，拆 `utils` 不会立刻减轻 cli 依赖。 - 单独 `@uncaged/nerve-utils` 会增加发布/版本矩阵与 import 路径成本，而收益有限；若日后 generic 工具变多，再评估 **monorepo 内子路径或新包** 即可。 --- ### 3. `core` 是否应改名为 `nerve-shared` / `nerve-types`？ **建议：维持 `@uncaged/nerve-core` 与目录名 `core`。** - 包内除类型外还有 **`parseNerveConfig`、`sense-workflow-directive` 等业务向解析/路由**，命名为 `nerve-types` 易误导；`nerve-shared` 更准确但属于 **全仓 rename + 文档 + 发布坐标** 的大改动，与当前包体量不匹配。 - Phase 1/2 之后 `core` 已收敛为 **小模块集合**（`types`、`config`、`sense-workflow-directive`、`result`），职责可读，无强 rename 动机。 --- ### 4. 是否维持现状？ **建议：维持现状；本阶段以 issue comment 作为产出即可，无需为上述项单独开 PR。** - **core**：共享类型 + 配置/指令解析 + `Result` — 与 `cli`/`daemon` 的依赖方向一致（二者均依赖 core，互不依赖）。 - **daemon**：保留引擎特有运行时（含 `signal-bus`）— 与架构说明「Signal 经总线分发、不持久化」一致。 若后续有明确新需求（例如第三方扩展要 import 与 daemon 完全一致的 bus 实现），再 reopen 对应子项即可。
xingyue commented 2026-04-24 11:47:52 +00:00
Author
Owner
Copy Link
Copy Source

test connectivity from CI agent

test connectivity from CI agent
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
aobing jiashuang (Jia Shuang) jiayi (Jiayi) luming scottwei tuanzi xiaoju xiaomo xiaonuo xingyue
No Assignees
1 Participants
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: uncaged/nerve#87
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?