jetlinks-boundary

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Chinese

Read

references/module-reference.md

first.

请先阅读

references/module-reference.md

。

Identify the capability boundary that the task needs to cross.
If this is a new backend feature, large cross-boundary behavior change, or boundary decision that affects data ownership, permissions, transactions, or external messages, first follow
```
../jetlinks-router/references/backend-design-test-driven-rules.md
```
: write the design draft and realistic test goals to the appropriate docs directory and wait for explicit user confirmation.
Confirm whether the current workspace already has command services, proxies, support IDs, or concrete command classes.
Read
```
references/cross-service-call-rules.md
```
before implementing providers or consumers.
Keep the chosen pattern aligned with the module's execution model, existing naming scheme, and local command invocation style.

明确任务需要跨越的能力边界。
如果是新增后端功能、大规模跨边界行为变更，或是涉及数据归属、权限、事务或外部消息的边界决策，请首先遵循
```
../jetlinks-router/references/backend-design-test-driven-rules.md
```
：将设计草案和实际测试目标写入对应文档目录，并等待用户明确确认。
确认当前工作区是否已存在命令服务、代理、支持ID或具体命令类。
在实现服务提供者或消费者之前，请阅读
```
references/cross-service-call-rules.md
```
。
确保所选模式与模块的执行模型、现有命名规范及本地命令调用风格保持一致。

Do not invent command IDs, service IDs, support IDs, or proxy contracts.
Do not directly inject another boundary's internal implementation class.
When local command classes already exist, prefer explicit command objects with
```
commandSupport.execute(...)
```
over shortcut calls such as
```
executeToMono(...)
```
.
In reactive modules, keep the cross-boundary call non-blocking.
Do not implement a large boundary change before the design draft, rejected options, data permission implications, and realistic test goals have been documented and confirmed.
Do not fake boundary tests by mocking away the contract being selected; verify request payloads, permission context, success and failure semantics, and fallback behavior that matter to the caller.
When boundary code changes are made, run relevant validation when possible; otherwise state the exact pending commands and cross-boundary risks.