docs: add complete features guide and rewrite LAN Pipes docs#246
Conversation
- Add docs/features/all-features-guide.md — comprehensive guide covering all 18 features across 13 PRs (Buddy, Remote Control, Voice, Chrome, Computer Use, GrowthBook, Ultraplan, Daemon, Pipe IPC, LAN Pipes, Monitor, Workflow, Coordinator, Proactive, History/Snip, Fork, etc.) - Rewrite docs/features/lan-pipes.md — user-facing guide with step-by-step quickstart, firewall config (Windows/macOS/Linux), command reference, keyboard shortcuts, routing modes, permission forwarding, FAQ - Rewrite docs/features/lan-pipes-implementation.md — developer reference with updated architecture (hook extraction, ndjsonFramer, module singletons), corrected code references, NDJSON protocol spec, attach flow sequence
📝 WalkthroughWalkthroughThis pull request adds a comprehensive 13+ features documentation guide and substantially rewrites the LAN pipes documentation. The changes include a new all-features guide summarizing capabilities with feature flags, a refactored implementation guide focusing on hooks and utilities, and a restructured user-facing LAN pipes guide emphasizing operational workflows and configuration steps. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/features/all-features-guide.md`:
- Line 251: The doc sentence stating “首个启动的实例成为 main” is incorrect; update the
wording to reflect that the main/sub role is determined by the registry binding
to machineId (see pipeRegistry.ts and the machineId-based main logic) rather
than startup order; revise this sentence and any related sections to say the
instance whose machineId is registered as main will act as main and others
register as sub, and add a brief note pointing to pipeRegistry (machineId) for
deterministic role assignment.
- Around line 165-170: The markdown table starting with "| 平台 | 截图 | 键鼠 | 应用管理
|" (and the other table around lines 191-196) violates MD058; fix by adding one
blank line immediately before the table block and one blank line immediately
after the table block so each table is separated from surrounding content and
passes the MD058 check.
- Around line 84-88: The fenced code block showing the schedule CLI examples
(lines with "/schedule create ...", "/schedule list", "/schedule delete <id>")
is unlabeled and triggers markdownlint MD040; update this block (and the other
listed blocks at the noted ranges) by adding an appropriate info string like
"bash" or "text" after the opening triple backticks (e.g., ```bash) so each
fenced code block has a language label for linting and improved readability
while leaving the commands themselves unchanged.
- Around line 519-538: The feature-flag table in
docs/features/all-features-guide.md currently marks many flags as “✅ dev/build”
but doesn’t match the actual defaults defined in build.ts (the default flag list
in build.ts lines ~7-45); update the table so it either (A) lists each flag’s
true default according to build.ts (e.g., ensure flags like LAN_PIPES,
UDS_INBOX, COORDINATOR_MODE, KAIROS, BUDDY, BRIDGE_MODE appear with their real
default state) or (B) split the column into explicit “dev” vs “build” columns
and populate each flag according to the defaults in build.ts (reference the flag
names shown in the diff such as LAN_PIPES, UDS_INBOX, COORDINATOR_MODE, KAIROS,
BUDDY, BRIDGE_MODE, etc., and the default list in build.ts) so the documentation
matches the source-of-truth.
In `@docs/features/lan-pipes-implementation.md`:
- Around line 9-26: The unlabeled fenced code blocks containing the ASCII
diagram (the Machine A / Machine B PipeServer diagram with entries like
"PipeServer", "UDS: ~/.claude/pipes/", "TCP: 0.0.0.0:<random>") and the
protocol-frame examples should be annotated with a language tag to satisfy
MD040; label the ASCII diagrams as ```text and any protocol frames as ```json or
```text as appropriate (e.g., the UDP/TCP diagram as text, protocol frames as
json if they are JSON snippets), updating the fenced blocks referenced in the
diff so the linter and renderer treat them correctly.
- Line 30: The docs claim that LAN_PIPES is enabled in the DEFAULT_FEATURES of
both scripts/dev.ts and build.ts, but build.ts does not include it; update the
documentation to accurately state where the feature is enabled by referencing
the DEFAULT_FEATURES constant: either remove the assertion that build.ts enables
LAN_PIPES or change it to reflect that only scripts/dev.ts lists LAN_PIPES in
DEFAULT_FEATURES, and ensure the doc text names the constant DEFAULT_FEATURES
and the feature symbol LAN_PIPES so readers can verify the source.
In `@docs/features/lan-pipes.md`:
- Around line 67-69: The markdown has unlabeled fenced code blocks (MD040) such
as the block containing "/pipes" and others at the mentioned ranges; update each
triple-backtick block to include an appropriate language tag (e.g., ```bash for
shell commands or ```text for plain output) so the fences are labeled; locate
the blocks by their contents (e.g., the block showing "/pipes" and the blocks
spanning the ranges around lines 72-81 and 92-95) and append the proper language
identifier after the opening backticks.
- Around line 160-163: Update the docs so the `main` role description matches
runtime semantics in pipeRegistry: change the `main` entry from "first-start
instance" to indicate it is the instance bound to the machineId (as implemented
in src/utils/pipeRegistry.ts), and ensure `sub` is described as other/non-bound
instances; reference the `machineId` binding behavior and the `main`/`sub` role
names when making the text change.
- Line 13: The docs claim that the feature flag LAN_PIPES is default-enabled for
dev/build, but the build defaults in build.ts do not include LAN_PIPES; verify
the intended default and either update the docs text in
docs/features/lan-pipes.md to state the correct scope (dev-only or opt-in for
build) or change the default in the feature flag definitions inside build.ts to
enable LAN_PIPES by default for build; reference the LAN_PIPES flag and the
build.ts feature/defaults block when making the correction so both doc and code
remain consistent.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 114379e8-bfcc-4d7f-89b1-345ef3f02f14
📒 Files selected for processing (3)
docs/features/all-features-guide.mddocs/features/lan-pipes-implementation.mddocs/features/lan-pipes.md
| ``` | ||
| /schedule create "每天检查依赖更新" --cron "0 9 * * *" --prompt "检查 package.json 中的过期依赖并创建更新 PR" | ||
| /schedule list — 列出所有定时任务 | ||
| /schedule delete <id> — 删除指定任务 | ||
| ``` |
There was a problem hiding this comment.
Add fenced code block languages for markdownlint compliance.
Several fenced blocks are unlabeled (MD040). Add bash, text, or powershell as appropriate to keep docs lint-clean and improve readability/tooling.
Also applies to: 208-210, 267-278, 339-345, 360-364, 406-408, 412-414, 427-429, 448-450, 463-466, 469-471, 484-486
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 84-84: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/all-features-guide.md` around lines 84 - 88, The fenced code
block showing the schedule CLI examples (lines with "/schedule create ...",
"/schedule list", "/schedule delete <id>") is unlabeled and triggers
markdownlint MD040; update this block (and the other listed blocks at the noted
ranges) by adding an appropriate info string like "bash" or "text" after the
opening triple backticks (e.g., ```bash) so each fenced code block has a
language label for linting and improved readability while leaving the commands
themselves unchanged.
| | 平台 | 截图 | 键鼠 | 应用管理 | | ||
| |------|------|------|----------| | ||
| | macOS | ✅ | ✅ | ✅ | | ||
| | Windows | ✅ | ✅ | ✅ | | ||
| | Linux | ⏳ | ⏳ | ⏳ | | ||
|
|
There was a problem hiding this comment.
Surround tables with blank lines.
Tables at these ranges trigger MD058. Add one blank line before and after each table block.
Also applies to: 191-196
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 165-165: Tables should be surrounded by blank lines
(MD058, blanks-around-tables)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/all-features-guide.md` around lines 165 - 170, The markdown
table starting with "| 平台 | 截图 | 键鼠 | 应用管理 |" (and the other table around lines
191-196) violates MD058; fix by adding one blank line immediately before the
table block and one blank line immediately after the table block so each table
is separated from surrounding content and passes the MD058 check.
| **Feature Flag**: `UDS_INBOX` | ||
|
|
||
| ### 说明 | ||
| 同一台机器上的多个 Claude Code 实例通过 UDS(Unix Domain Socket / Windows Named Pipe)自动发现并协作。首个启动的实例成为 main,后续自动注册为 sub。 |
There was a problem hiding this comment.
Main-role description conflicts with registry behavior.
Line 251 says “首个启动的实例成为 main”, but src/utils/pipeRegistry.ts documents main role as bound to machineId, not startup order. This can mislead multi-instance troubleshooting; please correct wording here and in related sections.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/all-features-guide.md` at line 251, The doc sentence stating
“首个启动的实例成为 main” is incorrect; update the wording to reflect that the main/sub
role is determined by the registry binding to machineId (see pipeRegistry.ts and
the machineId-based main logic) rather than startup order; revise this sentence
and any related sections to say the instance whose machineId is registered as
main will act as main and others register as sub, and add a brief note pointing
to pipeRegistry (machineId) for deterministic role assignment.
| | `BUDDY` | ✅ dev/build | 伴侣系统 | | ||
| | `BRIDGE_MODE` | ✅ dev/build | 远程控制 | | ||
| | `VOICE_MODE` | ✅ dev/build | 语音模式 | | ||
| | `CHICAGO_MCP` | ✅ dev/build | Computer Use + Chrome | | ||
| | `AGENT_TRIGGERS_REMOTE` | ✅ dev/build | 定时任务 | | ||
| | `SHOT_STATS` | ✅ dev/build | API 统计 | | ||
| | `TOKEN_BUDGET` | ✅ dev/build | Token 预算 | | ||
| | `PROMPT_CACHE_BREAK_DETECTION` | ✅ dev/build | 缓存检测 | | ||
| | `ULTRAPLAN` | ✅ dev/build | 高级规划 | | ||
| | `DAEMON` | ✅ dev/build | 后台守护 | | ||
| | `UDS_INBOX` | ✅ dev/build | Pipe IPC | | ||
| | `LAN_PIPES` | ✅ dev/build | LAN 群控 | | ||
| | `MONITOR_TOOL` | ✅ dev/build | 后台监控 | | ||
| | `WORKFLOW_SCRIPTS` | ✅ dev/build | 工作流脚本 | | ||
| | `FORK_SUBAGENT` | ✅ dev/build | 子 Agent | | ||
| | `KAIROS` | ✅ dev/build | Kairos 调度 | | ||
| | `COORDINATOR_MODE` | ✅ dev/build | 多 Worker | | ||
| | `HISTORY_SNIP` | ✅ dev/build | 历史管理 | | ||
| | `CONTEXT_COLLAPSE` | ✅ dev/build | 上下文折叠 | | ||
|
|
There was a problem hiding this comment.
Feature-flag default table appears inaccurate against build defaults.
Lines 519–538 mark many flags as “✅ dev/build”, but build.ts default list (source snippet: build.ts:7-45) includes only a subset and does not include entries like LAN_PIPES, UDS_INBOX, COORDINATOR_MODE, KAIROS, BUDDY, BRIDGE_MODE. Please align the table with actual defaults (or split into dev vs build explicitly) to avoid misleading users.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/all-features-guide.md` around lines 519 - 538, The feature-flag
table in docs/features/all-features-guide.md currently marks many flags as “✅
dev/build” but doesn’t match the actual defaults defined in build.ts (the
default flag list in build.ts lines ~7-45); update the table so it either (A)
lists each flag’s true default according to build.ts (e.g., ensure flags like
LAN_PIPES, UDS_INBOX, COORDINATOR_MODE, KAIROS, BUDDY, BRIDGE_MODE appear with
their real default state) or (B) split the column into explicit “dev” vs “build”
columns and populate each flag according to the defaults in build.ts (reference
the flag names shown in the diff such as LAN_PIPES, UDS_INBOX, COORDINATOR_MODE,
KAIROS, BUDDY, BRIDGE_MODE, etc., and the default list in build.ts) so the
documentation matches the source-of-truth.
| ``` | ||
| Machine A (192.168.1.10) Machine B (192.168.1.20) | ||
| Machine A (192.168.50.22) Machine B (192.168.50.27) | ||
| ┌───────────────────────────┐ ┌───────────────────────────┐ | ||
| │ PipeServer │ │ PipeServer │ | ||
| │ UDS: cli-abc.sock │ │ UDS: cli-def.sock │ | ||
| │ TCP: 0.0.0.0:<random> │◄──TCP───►│ TCP: 0.0.0.0:<random> │ | ||
| │ UDS: ~/.claude/pipes/ │ │ UDS: ~/.claude/pipes/ │ | ||
| │ cli-abc.sock │ │ cli-def.sock │ | ||
| │ TCP: 0.0.0.0:<random> │◄──TCP───►│ TCP: 0.0.0.0:<random> │ | ||
| ├───────────────────────────┤ ├───────────────────────────┤ | ||
| │ LanBeacon │ │ LanBeacon │ | ||
| │ UDP multicast │◄──UDP───►│ UDP multicast │ | ||
| │ 224.0.71.67:7101 │ mcast │ 224.0.71.67:7101 │ | ||
| │ UDP 224.0.71.67:7101 │◄──UDP───►│ UDP 224.0.71.67:7101 │ | ||
| ├───────────────────────────┤ ├───────────────────────────┤ | ||
| │ PipeRegistry │ │ PipeRegistry │ | ||
| │ registry.json (local) │ │ registry.json (local) │ | ||
| │ + mergeWithLanPeers() │ │ + mergeWithLanPeers() │ | ||
| │ usePipeIpc (hook) │ │ usePipeIpc (hook) │ | ||
| │ initPipeServer │ │ initPipeServer │ | ||
| │ registerMessageHandlers │ │ registerMessageHandlers │ | ||
| │ runMainHeartbeat │ │ runSubHeartbeat │ | ||
| │ cleanupPipeIpc │ │ cleanupPipeIpc │ | ||
| └───────────────────────────┘ └───────────────────────────┘ | ||
| ``` |
There was a problem hiding this comment.
Specify language on fenced blocks.
These fences are unlabeled (MD040). Add languages (text for diagrams/flows, json or text for protocol frames) to satisfy lint and improve rendering.
Also applies to: 254-257, 263-276
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 9-9: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/lan-pipes-implementation.md` around lines 9 - 26, The unlabeled
fenced code blocks containing the ASCII diagram (the Machine A / Machine B
PipeServer diagram with entries like "PipeServer", "UDS: ~/.claude/pipes/",
"TCP: 0.0.0.0:<random>") and the protocol-frame examples should be annotated
with a language tag to satisfy MD040; label the ASCII diagrams as ```text and
any protocol frames as ```json or ```text as appropriate (e.g., the UDP/TCP
diagram as text, protocol frames as json if they are JSON snippets), updating
the fenced blocks referenced in the diff so the linter and renderer treat them
correctly.
| ## Feature Flag | ||
|
|
||
| ### 2.1 注册 | ||
| `LAN_PIPES` — 在 `scripts/dev.ts` 和 `build.ts` 的 `DEFAULT_FEATURES` 中启用。 |
There was a problem hiding this comment.
Default-feature statement for LAN_PIPES is likely incorrect.
Line 30 says LAN_PIPES is enabled in build.ts DEFAULT_FEATURES, but provided build.ts:7-45 does not list it. Please correct this to avoid incorrect operational expectations in production builds.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/lan-pipes-implementation.md` at line 30, The docs claim that
LAN_PIPES is enabled in the DEFAULT_FEATURES of both scripts/dev.ts and
build.ts, but build.ts does not include it; update the documentation to
accurately state where the feature is enabled by referencing the
DEFAULT_FEATURES constant: either remove the assertion that build.ts enables
LAN_PIPES or change it to reflect that only scripts/dev.ts lists LAN_PIPES in
DEFAULT_FEATURES, and ensure the doc text names the constant DEFAULT_FEATURES
and the feature symbol LAN_PIPES so readers can verify the source.
| ## 架构 | ||
| - 两台或以上机器在同一局域网 | ||
| - 每台机器安装了 CCB 并能 `bun run dev` | ||
| - Feature flag `LAN_PIPES`(dev/build 默认开启) |
There was a problem hiding this comment.
LAN_PIPES default-enabled claim should be verified/corrected.
Line 13 states dev/build default enabled, but provided build.ts defaults do not include LAN_PIPES. Please clarify whether this is dev-only or opt-in for build.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/lan-pipes.md` at line 13, The docs claim that the feature flag
LAN_PIPES is default-enabled for dev/build, but the build defaults in build.ts
do not include LAN_PIPES; verify the intended default and either update the docs
text in docs/features/lan-pipes.md to state the correct scope (dev-only or
opt-in for build) or change the default in the feature flag definitions inside
build.ts to enable LAN_PIPES by default for build; reference the LAN_PIPES flag
and the build.ts feature/defaults block when making the correction so both doc
and code remain consistent.
| ``` | ||
| /pipes | ||
| ``` |
There was a problem hiding this comment.
Add fence languages to example blocks.
These blocks are unlabeled (MD040). Use bash/text as appropriate.
Also applies to: 72-81, 92-95
🧰 Tools
🪛 markdownlint-cli2 (0.22.0)
[warning] 67-67: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/lan-pipes.md` around lines 67 - 69, The markdown has unlabeled
fenced code blocks (MD040) such as the block containing "/pipes" and others at
the mentioned ranges; update each triple-backtick block to include an
appropriate language tag (e.g., ```bash for shell commands or ```text for plain
output) so the fences are labeled; locate the blocks by their contents (e.g.,
the block showing "/pipes" and the blocks spanning the ranges around lines 72-81
and 92-95) and append the proper language identifier after the opening
backticks.
| | 角色 | 说明 | | ||
| |------|------| | ||
| | `main` | 首个启动的实例 | | ||
| | `sub` | 同机后续启动的实例 | |
There was a problem hiding this comment.
Role model definition for main is inconsistent with registry semantics.
Line 162 defines main as first-start instance; src/utils/pipeRegistry.ts indicates main is bound to machineId. Please update this section to match runtime behavior.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/features/lan-pipes.md` around lines 160 - 163, Update the docs so the
`main` role description matches runtime semantics in pipeRegistry: change the
`main` entry from "first-start instance" to indicate it is the instance bound to
the machineId (as implemented in src/utils/pipeRegistry.ts), and ensure `sub` is
described as other/non-bound instances; reference the `machineId` binding
behavior and the `main`/`sub` role names when making the text change.
Summary
docs/features/all-features-guide.md— 覆盖 13 个 PR 共 18 项功能的完整使用指南(Buddy、Remote Control、Voice、Chrome、Computer Use、GrowthBook、Ultraplan、Daemon、Pipe IPC、LAN Pipes、Monitor、Workflow、Coordinator、Proactive、History/Snip、Fork 等)docs/features/lan-pipes.md— 面向用户的 LAN 群控指南(快速开始 4 步、三平台防火墙配置、命令参考、快捷键、路由模式、权限转发、FAQ)docs/features/lan-pipes-implementation.md— 面向开发者的技术文档(更新 hook 架构、ndjsonFramer、module singleton、纠正过时的代码引用、补充 NDJSON 协议规范和 attach 流程时序)Changes
docs/features/all-features-guide.mddocs/features/lan-pipes.mddocs/features/lan-pipes-implementation.md纯文档变更,不涉及代码修改。
Summary by CodeRabbit