Merge remote-tracking branch 'origin/main' into claude/issue-5855-wire-remaining-six-entries

Author: claude

.claude/skills/pm-dispatch/SKILL.md

@@ -178,7 +178,7 @@ git show origin/main:<path>                  # 看某个文件在 main 上的现
 > 与 `.github/workflows/rerun-safety-nightly.yml` **无关**:那个查的是「同一 checkout
 > 里跑两遍是否自洽」的测试污染,不是重跑语义。
 
-**6. 读数纪律 —— 三条各自产出过一个「我信了并据此行动」的错读数。** 第 4 条管的是
+**6. 读数纪律 —— 四条各自产出过一个「我信了并据此行动」的错读数。** 第 4 条管的是
 「在哪棵树上读」,这一条管的是「命令本身是否在回答你以为的那个问题」。
 
 - **`cd X && cmd` 会短路。** Bash 工具每次调用 cwd 重置;`cd /home/user/objectui &&
@@ -190,6 +190,14 @@ git show origin/main:<path>                  # 看某个文件在 main 上的现
   裸名命中的是仍然活着的 `EmailTemplateDefinition` 一族。退役核验一律**带引号精确
   名**;更硬的判据是查**声明式**(`^(export )?(const|type|interface) <Name>\b`)而不是
   查提及 —— 注释、pin 测试的断言词、迁移散文里出现该名是**正常且应当的**。
+- **浅检出(shallow clone)上的历史读数不可信 —— 一个假「非祖先」加两个被截断的数。**
+  队列管家核跨仓 pin 链时实测:`git merge-base --is-ancestor <pin> origin/main` 以
+  **exit 1** 退出(直接读作「不是祖先」)、`git rev-list --count <pin>..origin/main`
+  给出被浅历史截断的值(实测 50)、`git branch -r --contains <pin>` **零输出**;
+  `git fetch origin main --deepen=<N>` 之后同样三条给出 exit 0、79、有输出。⇒ 跨仓
+  pin 核验先 deepen 再判,或直接走 REST `compare`(多仓协调 rule 2 第一条同源,论证
+  不重复 —— 那里讲的是 `fatal:` 退出在 `&&` 链里被读成「不是祖先」,这一条讲它还能
+  不报错地给出一个**看起来正常的错数字**)。
 
 统一原则:**零命中必须用一个「确定存在的邻近词」反查**,证伪「扫描器坏了 / 路径错了」
 这个解释。没有这个反查,零命中不成立。
@@ -1092,6 +1100,16 @@ connector grant 只能传递调用会话自身持有的,CCR 平台注入的 gith
   禁用工具侧改模型):Routine **继承环境默认模型**,环境默认变了它跟着变;
   要硬钉同样走 Routines UI。
 
+**现役两例(都由维护者从 UI 创建、都先过一轮烟测)。** 首例是**分诊座位**(#5474):
+只扫/分类/打标签,⛔ 永不认领。第二例是维护者 2026-08-06 拍板的**三仓队列管家**(锚点
+#5810,#4604 已登记行,cron 与分诊错开半个周期),管「入队与落地 B」里入队之后的那一
+半:签名分诊四分支、队列停滞检测、跨仓 pin 链观测。**档位按职责挑,不按重要性挑** ——
+管家的正确性主要来自**查表**(#5810 的签名台账 + 座位表说明列,两者都优先于它的现场
+判断)与**机械兜底**(每轮限量、双向让行、只守落地的授权面),判断面窄、判例法已写死,
+因此**不需要最强档**;吃最强档的是要现场设计取舍的执行座位。档位与 cron 一样是维护者
+在 UI 上的可调项(上一条),试点判据不达标即升档 —— 本文 ⛔ 不复制其当前值,座位表
+#4604 的那一行才是现状。
+
 **跨 fire 的长流程照旧可行,因为它们的状态本来就在 GitHub 上。**「串行接力」
 (step 7)一棒就是一整圈、棒间还夹一次 PM 复核,必然跨多个 fire;能跨得过去的
 原因是接力的交接物全是 GitHub 上的读数 —— draft/ready 状态、`auto-merge` 是否
@@ -1343,11 +1361,37 @@ content/docs/references/**
   被清场,不是 rest 坏了)。派发词里直接给解法:`pnpm --filter @objectstack/spec
   gen:openapi` 补回,或重跑一次完整 spec build。
 
-**B. 跟到 MERGED 为止,不是跟到「已入队」为止。** 「auto-merge 已挂上」不是终点,
-维护者对此有过明确纠正。每轮同时读**队列分支**与 `origin/main`(Operational notes
-1);红了先分签名,再在「原样重投 / 推新提交 / 重新诊断」三者里选(notes 2 与 5)。
-落地之后**再核一次落地判据本身** —— 队列的合并同样走 os-regen 驱动,A 里那个静默
-吞并在队列合并这一步一样能发生。
+**B. 跟到 MERGED 为止,不是跟到「已入队」为止 —— 但入队之后的看护已归专责座位。**
+「auto-merge 已挂上」不是终点,维护者对此有过明确纠正;2026-08-06 起这一段按下表分工
+(维护者拍板设**三仓队列管家** Routine 座位,锚点 #5810,#4604 已登记行):
+
+| 谁 | 管什么 |
+|---|---|
+| **车道 PM**(权责不变) | 验收(step 7);**首次入队**(转 ready + 挂 auto-merge);确认 **MERGED** —— 每轮同时读**队列分支**与 `origin/main`(Operational notes 1) |
+| **队列管家**(三仓一座,#5810) | 入队之后的看护:红/踢出的**签名分诊四分支**、队列停滞检测、跨仓 pin 链观测 |
+
+车道 PM 因此**不再自挂 flaky 盯守定时器** —— 已入过队的 PR 被踢出后,认签名与原样重投
+是管家的活。管家的四分支照 #5810 的签名台账机械执行:**已知 flaky** ⇒ 原样重投;
+**已修签名再现** ⇒ ⛔ 不重投,按 notes 2 判为新问题、通知车道重新诊断;**基上缺一个
+已合入的修复**(notes 5) ⇒ 指引 `merge origin/main` 推新提交、⛔ 重跑无效;**新签名**
+⇒ ⛔ 不重投,在 PR 与其 `Fixes` issue 各留完整签名与初步判读。收到「新签名」或「已修
+签名再现」通知的车道 PM 按**原纪律**处置(notes 2 与 5,一字未改)—— 通知只换了谁先
+发现,没换谁负责修。
+
+管家的授权面是**只守落地**:⛔ 永不合并、永不 ready/draft 切换、永不把没入过队的 PR
+入队、不碰代码、不动认领。所以落地之后**再核一次落地判据本身**仍是车道 PM 的活 ——
+队列的合并同样走 os-regen 驱动,A 里那个静默吞并在队列合并这一步一样能发生。
+
+**签名台账 ⛔ 只有人工能升级。** 台账在 #5810 正文(三仓分表 + 跨仓通用共四张),是四
+分支的唯一判据,优先于任何一侧的现场判断;管家发现疑似新 flaky **只能在锚点单留一行
+提请**,⛔ 不自行加表,车道 PM 同样不加。追记纪律照 notes 2:纯计数不记,只有改变修法
+作用域时才记。
+
+**双向让行 —— 同一个红两个座位都可能动手,谁先动谁处置。** 管家在处置任一 PR 前先读它
+**最近 30 分钟的评论**:车道已在处置就让行,留一行「队列管家让行」不再介入;车道反过来
+在动手前同样读一遍,管家已留处置评论的不重复诊断。双方**每次动作都留审计评论**(重投
+写签名与台账依据、拦截写判定、让行写让行),让行判据因此始终是 GitHub 上的一个读数,
+不靠猜 —— 实测最紧的一次是车道回报早于管家读数 50 秒,少了这条纪律就是两份诊断。
 
 **依赖前棒才能转绿的 PR:draft 停放 + 一份精确的预期红清单。** 串行链里后棒常常先行
 实现(#5365 的四条进一致性表依赖 #5323 的 mongodb 归约才成立)。这种 PR **停在

content/docs/api/client-sdk.mdx

@@ -143,9 +143,9 @@ surface ever mounted their routes, so every call was a guaranteed 404.
 ([`route-ledger.ts`](https://github.com/objectstack-ai/objectstack/blob/main/packages/runtime/src/route-ledger.ts))
 records the audited disposition of every server route, and conformance tests
 on both sides fail when a route lands without a reviewed disposition or the
-ledger names a client method that doesn't exist. Integration test
-specifications live in
-[`CLIENT_SERVER_INTEGRATION_TESTS.md`](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/CLIENT_SERVER_INTEGRATION_TESTS.md).
+ledger names a client method that doesn't exist. The client-side integration
+tests that exist today are listed in
+[`packages/client/tests/integration/README.md`](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/tests/integration/README.md).
 </Callout>
 
 ---
@@ -687,7 +687,7 @@ pnpm test:integration
 Integration tests verify end-to-end communication with a live ObjectStack server across the client's API namespaces.
 
 <Callout type="info">
-**Test coverage**: Integration test specifications cover discovery/connection, authentication, metadata operations, CRUD operations (basic, batch, advanced queries), permissions, workflow, realtime, notifications, AI services, i18n, analytics, packages, views, storage, and automation.
+**Test coverage**: the client's *unit* tests are what cover the API namespaces broadly. Integration tests against a live server are far narrower — only discovery/connection is written today; the remaining namespaces are listed as a backlog in [`packages/client/tests/integration/README.md`](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/tests/integration/README.md). Per-route coverage is asserted by code in CI — [`packages/runtime/src/route-ledger.ts`](https://github.com/objectstack-ai/objectstack/blob/main/packages/runtime/src/route-ledger.ts) plus its conformance tests — not by integration tests and not by a hand-maintained table.
 </Callout>
 
 ---
@@ -697,7 +697,7 @@ Integration tests verify end-to-end communication with a live ObjectStack server
 For detailed information about the client's protocol implementation:
 
 - **[Protocol Compliance Matrix](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/CLIENT_SPEC_COMPLIANCE.md)** — Method-by-method verification of all API methods across 13 namespaces
-- **[Integration Test Specifications](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/CLIENT_SERVER_INTEGRATION_TESTS.md)** — Comprehensive test cases for client-server communication
+- **[Integration Tests](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/tests/integration/README.md)** — What client-server integration coverage exists today, and the backlog of namespaces still unwritten
 - **[Package README](https://github.com/objectstack-ai/objectstack/blob/main/packages/client/README.md)** — Developer navigation and API reference
 
 ---