createWorkingTreeCommands()
function createWorkingTreeCommands(database, patch): WorkingTreeCommands;
Defined in: packages/rxdb-plugin-working-tree/src/working-tree/working-tree-commands.ts:205
把十二个命令接到状态格子上。
Parameters
| Parameter | Type | Description |
|---|---|---|
database | RxDB | 宿主库；命令取的是它的 workingTree 与 versionManager 两个入口 |
patch | WorkingTreeStatePatch | 每一次相位变化的落点；见 WorkingTreeStatePatch |
Returns
Remarks
命令把错误原样继续抛（§1「抛同一组错误码」）。只记进状态、不抛，会让
await entry.commit(msg, opts) 在提交失败时静静地往下走——调用方拿到的是一个已经
resolve 的 promise，而工作树一个字节都没动。状态与异常在这里不是二选一：状态供模板
直接绑，异常供调用方的控制流用。
CommitConflict 不翻译成异常：ok: false 是一次成功调用的结果，§4 说它是
「可重试的返回值，不是崩溃」。它落在 success 相位，界面读 result.ok 决定要不要
提示重试。restore() 的四个被拒成因同理：脏工作树与不兼容要用户去处理，不可达是问错了
节点，冲突要重来一次——四者都不是崩溃。
restore() 之后不顺手重读会话。 它重读 status（工作树刚从 clean 变脏），但不发第二轮
restoreSession()：刚建的那个 sessionId 已经在返回值里，而「这个会话还成不成立」的唯一
出口是 status() 的 restoring / conflicted 两位——那份摘要上一行已经重读过了。
同理，commit() / discard() 也不重读会话，尽管两者都会结束它：三处各加一轮查询，换来的
是一份没有任何判定依赖它的补充信息。
收整个库而不是只收 workingTree。 清单第十一项 switchBranch 挂在 versionManager 上
（contracts/core-api.md §6 把它钉在那里，判定才走系统贡献口子回到本插件）；只收工作树入口
的话，这一项只能由三端各自去取 versionManager 再各自接一遍状态——而「切完要不要重读
status」这类判定正是本文件存在的理由，三份实现迟早有一份忘了重读。