[wenshao]

What this PR does

This is the record-contract half of slice H4e of the managed child-agent work (#12827, Stage H), tracked by #13745. The issue asked for three items: the team record domains (E1), detach to an independent durable owner (E2), and the close cascade under teams (E3). The issue's triage left three questions for a human, and the design settles them. H4e is split like H4d: this PR lands E1 as records, and the runtime follows as H4e-b, together with E3 and everything else the H4a delivery map gives to H4e (the seven team tools, plan resolution, member shutdown, the mailbox relay that H4d-a moved here, legacy team import, and the managed Agent tool's name for teammate routing). Detach stays the separate "Detach" follow-up that the H4a map already lists, and the stale pointer in the H4 design that sent its owner question to H4c now points there. The team domains are the durable form of the existing Legacy team model, not a parallel one: they keep its sanitized names, the reserved leader, the board statuses, the mailbox message types and plan approval.

Four record bodies are added, all held in the lead Session's journal and all disabled for submission. The team state is the roster and the lifecycle: members are append-only, join one per revision and only while the team is active, and the lifecycle runs active, closing, deleted, one step at a time. A team task is one board item with the Legacy fields; in_progress needs an owner, deletion is terminal, and dependencies are stored once, as blockedBy, and only grow, so a write never has to update two tasks to keep one edge. Whether a dependency still blocks is read from the blocker's status. A team message is one mailbox message to one recipient, shaped like the H4d-a outbox entry: settled from its first revision, with a session delivery line, a target fixed at handover, and the target's input named once accepted. Its kind is plain text or one of the six Legacy mailbox types, each with a fixed direction between the leader and a member. A team plan is the approval state of one plan request, keyed by the D6 action that asks the leader: it waits, then settles with a decision, or is cancelled when the plan is withdrawn or superseded.

Commit-time rules in both the TypeScript authority and the Java store bind every team record to its lead. The team must be led by this Session. A joining member must be a live child Session run of this Session that no other team lists. A task, message or plan request opens only in an active team of this Session, so a closing team drains without taking new work. A task number is unique in its team, an owner is the leader or a member, and a new dependency stays in the team and closes no cycle. A message travels between the leader and members and targets the lead Session or the Session its member's run attached, so a message to a member not attached yet stays planned. A plan request comes from a member that requires plan mode. The authority also checks these when it rebuilds a reopened log, and the bodies' content references join the resource closure on both sides.

Shared fixtures (125 cases, 57 successor pairs) replay identically in both languages. No team record projects a task. There is no migration and no public contract change. The design is recorded in both languages, and the H4, H4a and H4d-a designs point to it.

Why it's needed

Teams are what let several child agents work together, and on the Managed path they do not exist: the four team domains are registered names with no body, so nothing about a team can be committed, rebuilt or checked. The Legacy team model works, but it lives in the lead's process and its local files. On the Managed path the Runtime can be reclaimed and the Harness replaced, so every team fact the runtime will rely on has to be a committed record first. This PR pins those facts and the rules that keep them consistent, ahead of the runtime that will produce them, in the same server-first order as the earlier slices.

Reviewer Test Plan

How to verify

• Shared fixtures: every team state, task, message and plan case and successor pair is accepted or refused identically in TypeScript and Java, and each invalid case is refused on the clause the fixture names. Every existing contract corpus replays unchanged.
• Gate: the real domain gate refuses each of the four domains before anything is published.
• Authority, with the gate lifted only to plant records: a team opens, gains members one at a time, closes and is deleted; its tasks, messages and plan requests chain to their ends; a reopened log rebuilds every chain. Each commit-time rule refuses its violation, and a record opened while the team was active still moves after the team starts closing.
• Java store: the same chains commit over H2 in MySQL mode, the same rules refuse with the store's rejection code, and no team row projects a task.

Evidence (Before & After)

N/A: a record contract that stays disabled for submission, so nothing is user-visible. Verification output:

• Core: the whole managed-runtime directory, 58 files and 3160 tests, all passing.
• Java managed-agent-server: the full clean verify checkstyle:check: 1625 surefire tests, 0 failures, 2 skipped; 0 Checkstyle violations; 0 SpotBugs findings.
• Mutation checks: every new guard was disabled in turn and its witness went red in its own language: 22 of 22 authority mutants and 22 of 22 Java store and validator mutants were killed, plus 6 TypeScript validator spot checks.
• npm run typecheck, ESLint and Prettier on the changed files: clean.

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

Unit and contract suites only: vitest for core, Maven surefire on H2 (MySQL mode) for managed-agent-server, JDK 25. No MySQL/MariaDB integration lane was run locally, and this change has no migration.

Risk & Scope

• Main risk or tradeoff: the record rules are frozen ahead of their producers, so H4e-b inherits them. The design records four questions H4e-b still owes: the member-side receipt for a message, the input binding of a message to the leader, what a closing lead may still commit, and how a continued member stays on the roster. In Java, the task-number check reads the Session's team tasks when a task opens and the one-team check reads its teams when a member joins, because no index holds those values; both happen far less often than ordinary revisions.
• Not validated / out of scope: the H4e-b runtime (team tools, teammate routing, mailbox relay, plan resolution, member shutdown, the close cascade over members, legacy import, enablement); detach; cross-workspace teams; a public team resource (Multi-Agent API: an agent-identity dimension on the public contract, so multi-agent execution is attributable, tree-shaped and interruptible #13785). The MySQL/MariaDB integration lanes run in CI.
• Breaking changes / migration notes: none. There is no migration and no OpenAPI change, and no team domain is enabled. team_state:<n>, team_task:<n>, team_message:<n> and team_plan:<n> event ids are now reserved for Stage H records, as every registered body's are; no writer produces those id shapes.

Design: English · 简体中文

Linked Issues

Part of #13745 (E1; E2 moves to the Detach follow-up and E3 to H4e-b, so the issue stays open). Part of #12827.

中文说明

这个 PR 做了什么

这是 managed child-agent 工作(#12827,Stage H)中 H4e 切片的记录契约那一半,由 #13745 跟踪。该 issue 提了三项:团队记录 domain(E1)、detach 到独立的持久所有者(E2),以及团队下的关闭级联(E3)。issue 的分诊留下了三个需要人来定的问题,本设计给出了答案。H4e 像 H4d 一样一分为二:本 PR 以记录的形式落地 E1,运行时随后作为 H4e-b,连同 E3 以及 H4a 交付地图分给 H4e 的其余内容(七个团队工具、计划裁决、成员关停、H4d-a 移到这里的 mailbox 中继、旧团队导入,以及用于 teammate 路由的 managed Agent 工具 name)。detach 仍是 H4a 地图中已单列的 "Detach" 后续工作,H4 设计中把其所有者问题交给 H4c 的过时指向现已改为指向那里。团队 domain 是现有 Legacy 团队模型的持久形态,而不是并列的另一套:它沿用经过清洗的名字、保留名 leader、任务板状态、mailbox 消息类型与计划审批。

新增四个记录体,全部保存在 lead Session 的 journal 中,且全部不开放提交。团队状态是名册与生命周期:成员只追加,每个修订加入一个,且只能在团队为 active 时加入;生命周期为 active、closing、deleted,每次一步。团队任务是一个带 Legacy 字段的任务板条目;in_progress 需要 owner,删除是终态,依赖只按 blockedBy 保存一次且只增不减,因此一次写入永远不需要为维持一条边而更新两个任务。依赖是否仍在阻塞,由阻塞方的状态读出。团队消息是发给一个接收方的一条 mailbox 消息,形状与 H4d-a 的 outbox 条目一致:从第一个修订起就是 settled,带一条 session 投递线,目标在交接时固定,并在 accepted 后写明目标的 input。其 kind 是纯文本,或六种 Legacy mailbox 类型之一,每种都有 leader 与成员之间的固定方向。团队计划是一个计划请求的审批状态,以请 leader 做决定的 D6 action 为键:它先等待,然后带着决定 settled,或在计划被撤回或被取代时 cancelled。

TypeScript authority 与 Java store 中的提交时规则把每条团队记录绑定到其 lead。团队必须由本 Session 领导。加入的成员必须是本 Session 一个存活的、没有其他团队列出的 child Session run。任务、消息或计划请求只能在本 Session 一个 active 的团队中开启,因此 closing 中的团队在收尾时不再接收新工作。任务编号在团队内唯一,owner 是 leader 或成员,新依赖留在团队内且不形成环。消息在 leader 与成员之间传递,目标是 lead Session 或该成员 run 所 attach 的 Session,因此发给尚未 attach 的成员的消息停留在 planned。计划请求来自要求 plan mode 的成员。authority 在重建重新打开的日志时也会检查这些规则,记录体中的内容引用在两侧都纳入资源闭包。

共享 fixture(125 个用例、57 个后继对)在两种语言中给出完全相同的结果。团队记录不投影 task。没有迁移,也没有公共契约变更。设计以两种语言记录,H4、H4a 与 H4d-a 的设计均已指向它。

为什么需要

团队让多个 child agent 能够协同工作,而 Managed 路径上并不存在团队:四个团队 domain 只是没有记录体的已登记名字,因此团队的任何事实都无法提交、重建或检查。Legacy 团队模型可以工作,但它只存在于 lead 的进程及其本地文件中。在 Managed 路径上,Runtime 可能被回收、Harness 可能被替换,因此运行时将依赖的每个团队事实都必须先成为已提交的记录。本 PR 在产生这些事实的运行时之前,先把这些事实及维持其一致的规则固定下来,遵循与之前切片相同的 server 先行顺序。

评审测试计划

如何验证

• 共享 fixture:团队状态、任务、消息与计划的每个用例和后继对,在 TypeScript 与 Java 中被同样地接受或拒绝,每个无效用例都按 fixture 指名的子句被拒绝。现有的每个契约语料都原样回放通过。
• 门禁:真实的 domain 门禁在任何内容发布之前拒绝四个 domain 中的每一个。
• Authority(只为写入记录而放开门禁):团队开启、逐个加入成员、进入 closing 并被删除;其任务、消息与计划请求的链各自走到终点;重新打开的日志会重建每条链。每条提交时规则都拒绝相应的违规,而团队仍为 active 时开启的记录,在团队开始 closing 之后仍能前进。
• Java store:同样的链在 MySQL 模式的 H2 上提交,同样的规则以 store 的拒绝码拒绝,团队行不投影 task。

证据(前后对比)

不适用:这是保持禁用的记录契约,没有用户可见的变化。验证输出:

• Core:整个 managed-runtime 目录,58 个文件、3160 个测试,全部通过。
• Java managed-agent-server:完整的 clean verify checkstyle:check:surefire 1625 个测试,0 失败、2 跳过;Checkstyle 0 违规;SpotBugs 0 问题。
• 变异检查:依次禁用每个新增守卫,其见证测试在各自语言中变红:authority 的 22 个变异与 Java store 及校验器的 22 个变异全部被杀死,另有 6 个 TypeScript 校验器抽查。
• 变更文件上的 npm run typecheck、ESLint 与 Prettier:无问题。

测试平台

OS	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境(可选)

只跑了单元与契约测试:core 用 vitest,managed-agent-server 用 H2(MySQL 模式)上的 Maven surefire,JDK 25。本地没有跑 MySQL/MariaDB 集成测试,本变更也没有迁移。

风险与范围

• 主要风险或取舍:记录规则先于其生产者被固定,因此 H4e-b 将继承它们。设计记录了 H4e-b 仍欠的四个问题:成员一侧的消息回执、发给 leader 的消息的 input 绑定、closing 中的 lead 还能提交什么,以及被续跑的成员如何留在名册中。在 Java 中,任务编号检查在任务开启时读取本 Session 的团队任务,单一团队检查在成员加入时读取本 Session 的团队,因为没有索引保存这些值;这两者的发生频率都远低于普通修订。
• 未验证/不在范围内:H4e-b 运行时(团队工具、teammate 路由、mailbox 中继、计划裁决、成员关停、对成员的关闭级联、旧团队导入、启用);detach;跨工作区团队;公共团队资源(Multi-Agent API: an agent-identity dimension on the public contract, so multi-agent execution is attributable, tree-shaped and interruptible #13785)。MySQL/MariaDB 集成测试在 CI 中运行。
• 破坏性变更/迁移说明:无。没有迁移,没有 OpenAPI 变更,也没有启用任何团队 domain。team_state:<n>、team_task:<n>、team_message:<n> 与 team_plan:<n> 形式的事件 id 现在保留给 Stage H 记录,与每个已登记记录体一样;没有写入方产生这些 id 形状。

关联 Issue

属于 #13745(E1;E2 移到 Detach 后续工作,E3 移到 H4e-b,因此该 issue 保持打开)。属于 #12827。

[qwen-code-review-bot]

⚠️ Deferred approval not posted — the PR head moved (or the PR closed) after the review of 12be226; approving now would attest to unreviewed code. Re-run @qwen-code /triage on the new head. finalize run

⚠️ 延迟审批未提交 —— 审查 12be226 之后 PR head 已变更（或 PR 已关闭），此时审批会为未审查的代码背书。请在新 head 上重新运行 @qwen-code /triage。查看 finalize 运行

[wenshao]

Reviewed commit 12be226486ae50183be37c1e068167fcc389eff6.

One P2 finding: a malformed team-message successor dereferences a missing recipient before the immutable-field check can reject it. The same defect was reproduced through the TypeScript authority and the Java store; the inline comment covers both implementations.

Validation: 410 existing TypeScript tests and 17 existing Java tests passed, and the full repository build and typechecking passed. Targeted regression witnesses fail because the actual exceptions are TypeError / NullPointerException instead of the expected record-conflict exceptions. In both witnesses, the rejected attempt leaves the committed revision unchanged and the corrected successor succeeds.

This review covers the record contract, resource closure, ownership rules, replay, and matching English/Chinese designs. Runtime enablement and the explicitly deferred H4e-b work remain outside this PR's scope. Reproduction used the authority and H2 store; no live CLI or MySQL/MariaDB E2E result is claimed.

[wenshao]

[P2] Validate the successor's recipient before dereferencing it

After committing a planned message from leader to alice, submit the same messageId with to: "carol" (absent from the roster), targetSessionId: "session-run-1", and delivery accepting. Because previous != null skips the participant check and isSuccessor runs only after requireTeamRecord, memberWith(...) returns null and this dereference throws NullPointerException instead of the normal 409 managed_session_extension_record_rejected. The API's generic exception handler maps it to 500. The equivalent TypeScript path in managed-session-authority.ts:2480–2484 throws TypeError: Cannot read properties of undefined (reading 'childRunId').

Both failures were reproduced on this commit; corrected successors still commit successfully. Validate the immutable fields or recipient membership before this lookup in both implementations. Add authority/store regression cases that change an existing message's recipient to an unknown member and assert the normal conflict exception and an unchanged committed revision.

[wenshao]

Fixed in 4851c23.

The party check now runs on every revision in both implementations, not only when the message opens. The roster only grows and from/to are fixed, so a lawful successor always passes, while one that readdresses the message to a name outside the roster is refused with the normal record conflict ("Team message must travel between the leader and members of its team.") before anything looks its recipient up.

Regression witnesses, both confirmed red before the fix (TypeError in the authority, NullPointerException in the store) and green after:

• Authority: after committing message-1 planned, an accepting successor addressed to carol is refused with ManagedSessionConflictError and the rule's message, and the committed record stays at revision 1 with its original body; the corrected successor then commits.
• Store: the same successor is refused with 409 managed_session_extension_record_rejected and the rule's message, and the Session's committed revisions are unchanged.

I also rechecked the other lookups the team rules make ahead of the chain rules (the joining member's child run, new blockers and the cycle walk, the team itself); each either handles a missing record as a refusal or only follows ids that an earlier commit already verified.

中文说明

已在 4851c23 修复。

两种实现现在都在每个修订上检查消息的参与者,而不只是在消息开启时检查。名册只增不减,from/to 是固定字段,因此合法的后继总能通过;而把消息改投给名册外名字的后继,会在查找接收方之前以正常的记录冲突("Team message must travel between the leader and members of its team.")被拒绝。

回归见证在修复前均为红(authority 中为 TypeError,store 中为 NullPointerException),修复后为绿:

• Authority:提交 message-1 的 planned 后,发给 carol 的 accepting 后继被以 ManagedSessionConflictError 及该规则的消息拒绝,已提交记录仍停在修订 1、内容不变;随后正确的后继可以提交。
• Store:同一个后继以 409 managed_session_extension_record_rejected 及该规则的消息被拒绝,该 Session 已提交的修订数不变。

我也复查了团队规则在链规则之前做的其他查找(加入成员的 child run、新增的阻塞方与环检测遍历、团队本身):它们要么把记录缺失当作拒绝处理,要么只沿着之前的提交已经核验过的 id 查找。

[qwen-code-review-bot]

Thanks for the PR!

Template looks good ✓ — every required heading is present, the Evidence section correctly says N/A for a contract that ships disabled, and the design doc is linked in both languages.

Problem: Real, and I checked it against the base tree rather than taking the description's word. MANAGED_SESSION_DOMAINS already lists team_state / team_task / team_message / team_plan, but MANAGED_EXTENSION_RECORD_BODIES has no entry for any of them and they are absent from MANAGED_SESSION_ENABLED_DOMAINS. So the four names are genuinely body-less today: nothing about a team can be committed, chained, rebuilt or refused on the Managed path. This is an observed gap in the code, not theoretical hardening.

Direction: Aligned. Landing the record contract inert, ahead of the runtime that produces it, is the convention this codebase already documents for itself — the base managed-session-records.ts says the Java store "validates both bodies since H6a and deploys before any writer, keeping the server-first order". This PR follows that order rather than inventing one, and it is a tracked slice of #12827 Stage H under #13745. Keeping the Legacy team vocabulary (sanitized names, reserved leader, board statuses, the six mailbox types, plan approval) instead of designing a parallel model is the right call — I verified the constants rather than trusting the comments: MAX_TEAMMATES = 10 (packages/core/src/agents/team/types.ts:180) and MAX_METADATA_BYTES = 32_768 (packages/core/src/agents/team/tasks.ts:43) both match MANAGED_TEAM_LIMITS / ManagedTeamRecords.

Size: Core paths are touched (packages/core/src/**) and the change spans two packages (packages/core + packages/sdk-java), so here is the breakdown of the 6,898 changed lines:

Bucket	Lines
Production logic — TS (managed-team-record.ts 738, managed-session-authority.ts 163, managed-extension-projection.ts 50)	951
Production logic — Java (ManagedTeamRecords.java 487, ManagedExtensionRecordStore.java 182, ManagedExtensionProjection.java 22)	691
Production logic total	1,642
Tests (*.test.ts 1,141 + Java src/test/java 610)	1,751
Contract fixtures (managed-team-record-v1.fixtures.json 3,100 + projection fixtures 6)	3,106
Design docs (EN + zh-CN, and the pointer updates)	399

At 1,642 production lines this is over both the 500-line maintainer-awareness mark and the 1,000-line large-PR advisory, so I am recording it plainly. It does not change the outcome here: the two-tier core gate in AGENTS.md applies to external PRs and exempts maintainer-authored ones, and this PR is authored by a repo admin who is also a listed owner in .github/issue-owners.json. The advisory is informational in any case, and the size is mostly not logic — 47% of the diff is one machine-replayed fixture corpus and 26% is tests.

Approach: The scope feels right, and notably this PR is the split rather than something that needs splitting: H4e was cut into H4e-a (records, this PR) and H4e-b (runtime), the same way H4d was cut. Everything expensive and user-visible is deferred — the seven team tools, plan resolution, member shutdown, the mailbox relay, legacy import, enablement, detach, the close cascade. What remains is the minimum that can express the rules at all. I considered whether team_state alone could land first, but the other three domains all bind to a team and their commit-time rules are the point of the slice, so a team_state-only contract could not state them. Cutting further would ship a contract that cannot enforce itself.

Reuse is good: no parallel validator utility is introduced. The TS side builds on assertManagedSessionStableId, assertManagedSessionDurableRef, assertManagedSessionDigest, boundedString, ManagedSessionRecordError, parseExtensionRun and isExtensionRunSuccessor; the Java side on ManagedExtensionRecords.closed/id/count/durableRef/digest/boundedText/requireRun/isRunSuccessor/same. I found no unrelated changes, drive-by refactors or formatting churn — the six doc edits are all consequence of the H4e re-scope, and each is mirrored in the Chinese version.

Risk: No elevated risk signals. The Stage 1e revert-correlated path scan matched nothing (no content generator, streaming parser, shell execution, MCP, LSP, ACP, relaunch or sandbox paths). The change is also structurally inert: the four domains stay out of MANAGED_SESSION_ENABLED_DOMAINS, this PR does not touch that file, and assertManagedSessionDomainEnabled is called on the commit path (managed-session-authority.ts:1379), so no caller can submit a team record after this merges. No migration, no OpenAPI change, no user-visible surface.

Moving on to code review. 🔍

中文说明

感谢贡献！

模板完整 ✓ —— 所有必需标题都在，Evidence 一栏对一个"禁用提交"的契约正确地写了 N/A，设计文档双语链接齐全。

问题： 真实存在，而且我是对照 base 代码树核实的，没有只采信描述。MANAGED_SESSION_DOMAINS 里已经列了 team_state / team_task / team_message / team_plan，但 MANAGED_EXTENSION_RECORD_BODIES 里四个都没有记录体，MANAGED_SESSION_ENABLED_DOMAINS 里也没有它们。所以这四个名字目前确实只有名字没有内容：在 Managed 路径上，团队的任何事实都无法提交、链式追加、重建或拒绝。这是代码里可观测到的空缺，不是理论性加固。

方向： 对齐。让记录契约先以"禁用"状态落地、再由产生它的运行时跟上，正是这个代码库自己已经写明的约定 —— base 的 managed-session-records.ts 就写着 Java store "自 H6a 起校验两种记录体，并先于任何 writer 部署，保持 server 先行的顺序"。本 PR 遵循这个顺序，而不是另造一套，并且它是 #12827 Stage H 下由 #13745 跟踪的既定切片。沿用 Legacy 团队词汇（清洗过的名字、保留名 leader、任务板状态、六种 mailbox 类型、计划审批）而不是设计一套并列模型，这个判断是对的 —— 我核实了常量本身而不是只信注释：MAX_TEAMMATES = 10（packages/core/src/agents/team/types.ts:180）与 MAX_METADATA_BYTES = 32_768（packages/core/src/agents/team/tasks.ts:43）都与 MANAGED_TEAM_LIMITS / ManagedTeamRecords 一致。

规模： 本 PR 触及核心路径（packages/core/src/**），并跨两个包（packages/core + packages/sdk-java），因此把 6,898 行改动拆解如上表：生产逻辑合计 1,642 行（TS 951 + Java 691），测试 1,751 行，契约 fixture 3,106 行，设计文档 399 行。

1,642 行生产逻辑同时超过了 500 行的维护者关注线和 1,000 行的大 PR 提示线，所以我如实记录。但这不改变结论：AGENTS.md 的核心两级门禁针对的是外部 PR，维护者本人提交的 PR 属于豁免范围，而本 PR 的作者既是仓库 admin、也是 .github/issue-owners.json 中列名的 owner。何况该提示本身只是信息性的，而且这些行数大部分并不是逻辑代码 —— 47% 是一份由机器双语回放的 fixture 语料，26% 是测试。

方案： 范围合理，而且值得注意的是：这个 PR 本身就是拆分的结果，而不是一个需要再拆的 PR —— H4e 被切成 H4e-a（记录，即本 PR）与 H4e-b（运行时），与 H4d 的切法一致。所有昂贵且用户可见的部分都被推后了：七个团队工具、计划裁决、成员关停、mailbox 中继、旧团队导入、启用开关、detach、关闭级联。剩下的正是"能把规则表达出来"的最小集合。我也考虑过能否先只落地 team_state，但另外三个 domain 都要绑定到团队，而它们的提交时规则正是本切片的重点，所以只有 team_state 的契约无法表述这些规则。再砍就会交付一个无法自我约束的契约。

复用做得好：没有引入并列的校验工具。TS 侧建立在 assertManagedSessionStableId、assertManagedSessionDurableRef、assertManagedSessionDigest、boundedString、ManagedSessionRecordError、parseExtensionRun 与 isExtensionRunSuccessor 之上；Java 侧建立在 ManagedExtensionRecords.closed/id/count/durableRef/digest/boundedText/requireRun/isRunSuccessor/same 之上。没有发现无关改动、顺手重构或格式化噪声 —— 六处文档修改都是 H4e 重新划定范围的必然结果，且每一处都在中文版同步了。

风险： 无升级风险信号。Stage 1e 的 revert 相关路径扫描没有命中任何一项（不涉及内容生成器、流式解析器、shell 执行、MCP、LSP、ACP、relaunch 或 sandbox 路径）。改动在结构上也是惰性的：四个 domain 仍然不在 MANAGED_SESSION_ENABLED_DOMAINS 中，本 PR 没有修改该文件，而提交路径上会调用 assertManagedSessionDomainEnabled（managed-session-authority.ts:1379），因此合并后没有任何调用方能提交团队记录。无迁移、无 OpenAPI 变更、无用户可见面。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 12be226486ae50183be37c1e068167fcc389eff6 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Code review

I wrote down what I would do before opening the diff: follow the existing managed-*-record.ts + contracts/*-v1.fixtures.json sibling pattern that the base tree already has a dozen instances of, put the invariants in the one existing authority rather than a new validation layer, mirror them in the Java store, express cross-language agreement as one shared fixture corpus replayed by both, and ship it disabled. The PR does exactly that, and in two places it is more careful than my baseline — it matches the ordering of validation clauses across languages, not just their content, and it reuses the H4d-a outbox shape for the mailbox entry instead of inventing one.

The cross-language parity holds. That is the main thing that can silently rot in a two-validator contract, so I walked all four domains clause by clause rather than spot-checking. Every rule matches, including the rejection strings: lead binding, append-one-member-per-revision, the lifecycle stepping one state at a time, deleted frozen, task-number uniqueness scoped to the team, in_progress requiring an owner, blockedBy growing only and staying in-team, the cycle check (same DFS, same "only new edges can close a cycle" reasoning, same seen guard), message direction per kind, the target/input set-once rules, and plan approval requiring a plan-mode member. Validation order matches too — both sides check closed → run shape → party names → decision/feedback → identity/count/ref fields last — which is what makes "refused on the clause the fixture names" a meaningful assertion rather than a lucky substring. The resource-closure additions agree as well: TS lists refs per domain, Java iterates the five ref field names and skips absent ones, same net effect, and team_state correctly contributes none.

Non-blocking, one thing for H4e-b to inherit carefully. The message-target path assumes a recipient named when the message opened is still on the roster — team.members.find(...)! in the TS authority and memberWith(team, "name", to).get("childRunId") in the Java store. That is sound today, and I traced why: parties are in MESSAGE_FIXED_KEYS so to cannot change, the roster is append-only, and takesPart is enforced at open. But it is sound because of the invariant the PR's own open questions list flags as unsettled — "how a continued member stays on the roster". If H4e-b ever makes the roster shrinkable, this stops being a clean rejection and becomes a TS TypeError / Java NPE on the commit path. Worth a guard or at least a comment when that slice lands. Not a blocker here, and unreachable today since the domains cannot be submitted.

I also checked the as { teamId: string } downcast in the new authority block, which looked risky out of context. It is safe: parsed is typed ReturnType<ManagedExtensionRecordBody['parse']>, so parsed.record is the already-validated, frozen body by the time this runs. The re-parse (parseTeamTask(parsed.record)) is redundant work but matches how the sibling session_message branch already reads its refs, so it is convention rather than noise.

No correctness bugs, no security concerns, no regressions found. No AGENTS.md violations: ESM, no any, kebab-case filenames, collocated tests, vi.hoisted() used for the mock the vi.mock() factory consumes (the documented CLI-test gotcha), and comments only where the why is non-obvious — which in this diff is mostly the Legacy-constant provenance and the "only new edges" reasoning, both genuinely worth having.

Design docs are complete in both languages. EN and zh-CN have identical 15-heading structure (Problem and scope → Current state → Decisions → Records → the four record subsections → Non-goals → Files affected → Validation → Acceptance criteria → Open questions → Follow-up work), and all six pointer updates into the H4, H4a and H4d-a docs are mirrored in the Chinese versions. No translation gap.

Files changed (20 of 20 shown)

File	What changed
packages/core/src/managed-runtime/managed-team-record.ts	The four record bodies: parse, isStart and isSuccessor for each, plus the shared limits, the leader name and the kind/direction tables.
packages/core/src/managed-runtime/managed-session-authority.ts	Commit-time rules binding every team record to its lead, and the three new resource-closure branches.
packages/core/src/managed-runtime/managed-extension-projection.ts	Registers the four bodies, each projecting no task.
packages/core/src/managed-runtime/contracts/managed-team-record-v1.fixtures.json	The shared corpus both languages replay: 5 templates, 125 cases, 57 successor pairs, limits and key sets.
packages/core/src/managed-runtime/contracts/managed-extension-projection-v1.fixtures.json	Records the four new domains and their null task kind.
packages/core/src/managed-runtime/managed-team-record.test.ts	Replays the corpus in TS; also asserts each domain stays out of the enabled list and that the gate throws.
packages/core/src/managed-runtime/managed-session-authority.team.test.ts	13 cases over the real commit and rebuild paths, with the gate lifted by a hoisted flag only to plant records.
packages/sdk-java/.../store/ManagedTeamRecords.java	The Java mirror of the four validators, matching clause order and messages.
packages/sdk-java/.../store/ManagedExtensionRecordStore.java	The Java mirror of the lead-binding rules, plus the ref-closure check and a domain-body read helper.
packages/sdk-java/.../store/ManagedExtensionProjection.java	Registers the four bodies on the Java side.
packages/sdk-java/.../ManagedTeamRecordContractTest.java	Replays the same core fixture file, walking up to find it, and pins the exact clause on every refusal.
packages/sdk-java/.../ManagedTeamStoreTest.java	6 cases committing the same chains over H2 in MySQL mode and asserting the store's rejection codes.
docs/design/2026-10-10-managed-agent-teams.md	New design doc: decisions, the four records, non-goals, validation, acceptance criteria, open questions.
docs/design/2026-10-10-managed-agent-teams.zh-CN.md	Chinese version, structurally identical.
docs/design/2026-10-04-managed-child-agents.md	Redirects the stale detach-owner pointer from H4c to the Detach follow-up.
docs/design/2026-10-04-managed-child-agents.zh-CN.md	Same pointer fix, Chinese.
docs/design/2026-10-06-managed-child-agent-runtime.md	Splits the H4e delivery-map row into record contract (H4e-a) and runtime (H4e-b).
docs/design/2026-10-06-managed-child-agent-runtime.zh-CN.md	Same split, Chinese.
docs/design/2026-10-09-managed-session-messages.md	Points its H4e row at the new design.
docs/design/2026-10-09-managed-session-messages.zh-CN.md	Same pointer, Chinese.

Testing evidence

This is an unattended CI run, so per the triage rules I did not build or execute anything from this PR — the evidence below is the PR's own CI, read through the API for the reviewed commit. No check has failed.

Final CI results for 12be226 (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Hosted process fault gates / MySQL 8.4 / Java 21	🚫 cancelled
Runtime Broker and Managed Agent MariaDB / Java 21	🚫 cancelled
Test (ubuntu-latest, Node 22.x)	🚫 cancelled
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	🚫 cancelled
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Flyway migration version uniqueness	✅ success
Integration Tests (no-AK, No Sandbox)	✅ success
Lint & Static (ubuntu-latest, Node 22.x)	✅ success
macos-latest / Java 21	✅ success
Real daemon E2E / Java 11	✅ success
ubuntu-latest / Java 11	✅ success
ubuntu-latest / Java 17	✅ success
ubuntu-latest / Java 21	✅ success
windows-latest / Java 21	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

Two workflow runs with event == pull_request were still unfinished at review time, and 58 further checks are skipped — those are the conditional bot-orchestration and path-filtered jobs (review-pr, verify, tmux-testing, publish-*, precheck-pr and friends), which is the normal shape for this repo, not a gap. The triage check in flight is this job. The still-pending items that actually matter for this diff are the Node unit suite and the Java 21 / MySQL 8.4 / MariaDB lanes, since those are what run the two contract suites and the H2 store tests. I did not poll or wait on them; the finalize pass rewrites the table above once CI settles.

What CI does substantiate is the PR's central claim. The cross-language agreement is not an assertion in the description — it is two suites, managed-team-record.test.ts under vitest and ManagedTeamRecordContractTest under Maven surefire, both reading the same file at packages/core/src/managed-runtime/contracts/managed-team-record-v1.fixtures.json (the Java test walks up parent directories to find it). When those two go green in the lanes above, the agreement claim is pinned by CI, not by the author. I verified the suites are not vacuous by reading them: all 89 invalid cases assert the specific clause substring via expect(...).toThrow(fixture.error) / assertTrue(refused.getMessage().contains(...)), isStart is asserted on every case valid or invalid, the TS side additionally asserts deep-freeze and the returned recordId, and the disabled-domain test flips the hoisted enablement.teams flag to false and asserts both the exact gate message and publishedBodies(...) === 0 for all four domains. I also confirmed the corpus matches the description: 125 cases and 57 successor pairs, with limits equal to MANAGED_TEAM_LIMITS.

Sandboxed verification would settle the one claim CI cannot: @qwen-code /verify — that the new commit-time guards actually fail closed. The description reports 22 of 22 authority mutants and 22 of 22 Java store/validator mutants killed, plus 6 TS validator spot checks; that is the author's own mutation run, not something CI reproduces, and it is precisely the load-bearing question for a contract whose entire value is its refusals. A green suite proves the fixtures pass; an A/B run against the base build would prove that deleting a guard turns a fixture red. Worth naming since the author has write access and can trigger it directly.

Not verified, with reasons: the mutation-testing numbers (author's claim, no CI lane reproduces them); the Java clean verify checkstyle:check totals of 1,625 surefire tests / 0 Checkstyle violations / 0 SpotBugs findings (author's local run — CI's Java lanes are still in flight at review time, so I am not treating them as confirmed); and the core managed-runtime figure of 58 files / 3,160 tests (same reason). Real-scenario tmux testing is N/A on two counts: this is an unattended CI run, which never drives the TUI, and there is nothing user-visible to drive — the four domains remain disabled for submission, so no caller can produce a team record through the product.

中文说明

代码审查

我在打开 diff 之前先写下了自己会怎么做：沿用 base 树里已有十几个实例的 managed-*-record.ts + contracts/*-v1.fixtures.json 同级模式，把不变量放进唯一的那个 authority 而不是新开一层校验，在 Java store 里镜像同样的规则，用一份被双语回放的共享 fixture 语料来表达跨语言一致性，并以禁用状态交付。这个 PR 正是这么做的，而且有两处比我的基线更细致 —— 它跨语言对齐了校验子句的顺序，不只是内容；mailbox 条目复用了 H4d-a 的 outbox 形状，而不是另造一个。

跨语言一致性成立。 这是双校验器契约里最容易悄悄腐坏的部分，所以我逐个 domain 逐条对照，没有只抽查。所有规则都一致，包括拒绝信息字符串：lead 绑定、每个修订只追加一名成员、生命周期每次只走一步、deleted 冻结、任务编号在团队内唯一、in_progress 必须有 owner、blockedBy 只增且留在团队内、环检测（同样的 DFS、同样的"只有新边能成环"推理、同样的 seen 保护）、每种消息类型的方向规则、target/input 只设置一次的规则，以及计划审批要求成员处于 plan mode。校验顺序也一致 —— 两侧都是 closed → run 形状 → 参与方名字 → decision/feedback → 最后才是 identity/count/ref 字段 —— 这正是"按 fixture 指名的子句被拒绝"成为有意义断言、而不是碰巧子串命中的原因。资源闭包的新增也一致：TS 按 domain 列出 ref，Java 遍历五个 ref 字段名并跳过不存在的，净效果相同，而 team_state 正确地一个都不贡献。

非阻塞，有一处需要 H4e-b 小心继承。 消息目标解析路径假设"消息开启时被指名的接收方仍在名册上" —— TS authority 里的 team.members.find(...)! 与 Java store 里的 memberWith(team, "name", to).get("childRunId")。这在今天是成立的，我追了原因：参与方在 MESSAGE_FIXED_KEYS 中所以 to 不会变，名册只追加，且开启时强制校验了 takesPart。但它成立恰恰依赖于本 PR 自己在开放问题里列为未定的那条不变量 ——"续任成员如何留在名册上"。如果 H4e-b 让名册变得可缩减，这里就不再是干净的拒绝，而会在提交路径上变成 TS 的 TypeError 或 Java 的 NPE。等那个切片落地时值得加一道保护或至少一条注释。在本 PR 里不是阻塞项，而且今天不可达 —— 这些 domain 无法被提交。

我也检查了新增 authority 代码块里的 as { teamId: string } 向下转型，脱离上下文看它像是有风险的。它是安全的：parsed 的类型是 ReturnType<ManagedExtensionRecordBody['parse']>，所以执行到这里时 parsed.record 已经是校验过并冻结的记录体。重新解析（parseTeamTask(parsed.record)）确实是冗余工作，但这与同级 session_message 分支读取 ref 的既有写法一致，属于约定而非噪声。

未发现正确性缺陷、安全问题或回归。未发现违反 AGENTS.md 之处：ESM、无 any、kebab-case 文件名、测试与源码同目录、vi.mock() 工厂消费的 mock 用了 vi.hoisted()（正是文档里点明的 CLI 测试陷阱），注释只出现在 why 不明显的位置 —— 在这个 diff 里主要是 Legacy 常量的出处和"只有新边"的推理，这两处确实值得写。

设计文档双语完整。 英文与中文版有完全相同的 15 个标题结构（问题与范围 → 现状 → 决策 → 记录 → 四个记录小节 → 非目标 → 受影响的文件 → 验证 → 验收标准 → 开放问题 → 后续工作），并且对 H4、H4a、H4d-a 文档的全部六处指向更新都在中文版同步了。无翻译缺口。

测试证据

这是一次无人值守的 CI 运行，因此按照 triage 规则我没有构建或执行本 PR 的任何代码 —— 下面的证据是通过 API 读到的、该 PR 自身在被审查 commit 上的 CI 结果。没有任何检查失败。

审查时还有两个 event == pull_request 的 workflow run 未完成，另有 58 个检查为 skipped —— 那些是条件触发的 bot 编排与路径过滤任务（review-pr、verify、tmux-testing、publish-*、precheck-pr 等），这是本仓库的正常形态，不是缺口。正在运行的 triage 检查就是本任务本身。对这个 diff 真正重要的待完成项是 Node 单测套件与 Java 21 / MySQL 8.4 / MariaDB 通道，因为正是它们运行两个契约套件和 H2 store 测试。我没有轮询或等待它们；CI 落定后 finalize 环节会就地重写上面的表格。

CI 能够证实的正是本 PR 的核心主张。跨语言一致不是描述里的一句断言 —— 它是两个套件，vitest 下的 managed-team-record.test.ts 与 Maven surefire 下的 ManagedTeamRecordContractTest，两者读取的是同一个文件 packages/core/src/managed-runtime/contracts/managed-team-record-v1.fixtures.json（Java 测试通过向上遍历父目录找到它）。当上面那些通道变绿时，一致性主张就是由 CI 钉住的，而不是由作者钉住的。我通过阅读确认了这些套件不是空转：全部 89 个无效用例都通过 expect(...).toThrow(fixture.error) / assertTrue(refused.getMessage().contains(...)) 断言了具体的子句字符串，isStart 在每个用例上都被断言（无论有效无效），TS 侧还额外断言了深度冻结与返回的 recordId，而禁用 domain 的测试把 hoisted 的 enablement.teams 标志置为 false，并对四个 domain 同时断言了精确的门禁信息与 publishedBodies(...) === 0。我也核实了语料与描述相符：125 个用例、57 个后继对，且 limits 等于 MANAGED_TEAM_LIMITS。

沙箱化验证能够解决 CI 解决不了的那一条主张：@qwen-code /verify —— 即新增的提交时守卫是否真的 fail closed。描述中报告了 22/22 个 authority 变异体与 22/22 个 Java store/validator 变异体被杀死，外加 6 个 TS validator 抽查；那是作者自己的变异测试运行，CI 没有对应通道复现它，而这恰恰是一个"全部价值就在于它的拒绝"的契约最吃重的问题。绿色的套件证明 fixture 通过；针对 base 构建的 A/B 运行才能证明删掉某个守卫会让某个 fixture 变红。作者有写权限、可以直接触发，所以值得点名。

未验证项及原因：变异测试数字（作者主张，无 CI 通道复现）；Java clean verify checkstyle:check 的 1,625 个 surefire 测试 / 0 Checkstyle 违规 / 0 SpotBugs 发现的总计（作者本地运行 —— 审查时 CI 的 Java 通道仍在进行，因此我不将其视为已确认）；以及 core managed-runtime 的 58 个文件 / 3,160 个测试（同样原因）。真实场景 tmux 测试为 N/A，理由有两条：这是无人值守的 CI 运行，从不驱动 TUI；而且没有用户可见的东西可驱动 —— 四个 domain 仍然禁用提交，因此没有任何调用方能通过产品产生团队记录。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 12be226486ae50183be37c1e068167fcc389eff6 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Confidence: 4/5 — the parity work is genuinely careful and the change is structurally inert; the one point I am holding back is a fragility this PR hands to H4e-b, not a defect in it.

Stepping back: my independent proposal was to follow the existing sibling record pattern, put the invariants in the one authority, mirror them in Java, replay one shared corpus in both languages, and ship disabled. The PR matches that and beats it in one respect I did not think of — it aligns the order of validation clauses across the two languages, which is what turns "refused on the clause the fixture names" from a lucky substring match into a real assertion. I did not find a simpler path it missed.

On the questions that usually decide these: the problem is verified in the base tree, not asserted (four registered domains with no body and no enablement). The direction follows a server-first ordering this codebase already documents for itself. The scope is already the reduced one — H4e was split into records and runtime, and everything user-visible is on the other half. Nothing in the diff is unrelated: six doc edits, each a consequence of the re-scope, each mirrored in Chinese. If I were maintaining this in six months I would thank the author for the fixture corpus and the clause-ordered validators rather than curse them; the thing that usually rots in a two-language contract is silent divergence, and 125 cases plus 57 successor pairs replayed from a single file is the right defence against it.

What keeps this at 4 rather than 5 is the roster-shrink fragility I named in Stage 2. It is not a bug today — I traced the invariant that makes it safe (parties are fixed keys, the roster is append-only, takesPart is enforced at open) and the domains cannot be submitted at all. But the PR's own open-questions list flags "how a continued member stays on the roster" as unsettled for H4e-b, and that is exactly the invariant the non-null lookups in the message-target path rest on. If the roster ever becomes shrinkable, a clean rejection turns into a TypeError / NPE on the commit path. Worth carrying into H4e-b as a known obligation.

I am not treating the size as a reservation. At 1,642 production lines this is over the advisory mark, but the two-tier core gate in AGENTS.md governs external PRs and exempts maintainer-authored ones, and this author is a repo admin and a listed owner in .github/issue-owners.json. Size aside, the shape is favourable: 47% of the diff is one machine-replayed fixture corpus, 26% is tests, and the 1,642 logic lines land behind a gate that refuses to let anyone submit them.

Verdict: approve, with the approval deferred until CI lands green on 12be226486ae50183be37c1e068167fcc389eff6. Two pull_request workflow runs were still unfinished at review time — the Node unit suite and the Java 21 / MySQL 8.4 / MariaDB lanes, which are precisely the ones that run the two contract suites and the H2 store tests. Approving now would attest to a result that does not exist yet, so I am leaving the deferred-approval marker below for the finalize pass to act on once those settle; it will withhold the approval and flag the status comment if anything lands red or the head moves.

The one thing I would suggest, if you want it before merge rather than after: an @qwen-code /verify run to pin that the new guards fail closed. The 22-of-22 mutation kills in the description are your own run and no CI lane reproduces them, and for a contract whose entire value is its refusals, that is the load-bearing evidence. Everything else I would merge as-is.

中文说明

信心度：4/5 —— 一致性工作做得确实细致，改动在结构上是惰性的；我保留的那一分是本 PR 交给 H4e-b 的一处脆弱性，而不是它自身的缺陷。

退一步看整体：我独立提出的方案是沿用既有的同级记录模式、把不变量放进唯一的 authority、在 Java 侧镜像、用一份共享语料在两种语言中回放，并以禁用状态交付。这个 PR 与之一致，并且在一个我没想到的方面做得更好 —— 它对齐了两种语言中校验子句的顺序，而这正是把"按 fixture 指名的子句被拒绝"从碰巧的子串命中变成真正断言的关键。我没有找到它遗漏的更简路径。

关于通常决定这类判断的几个问题：问题是在 base 代码树里核实过的，不是断言出来的（四个已登记的 domain，既无记录体也未启用）。方向遵循的是这个代码库自己已经写明的 server 先行顺序。范围已经是裁剪后的那一半 —— H4e 被切成记录与运行时，所有用户可见的部分都在另一半。diff 里没有无关内容：六处文档修改都是重新划定范围的必然结果，且都在中文版同步了。如果六个月后由我来维护，我会感谢作者留下这份 fixture 语料和按子句排序的校验器，而不是埋怨他；双语言契约里通常腐坏的东西是悄无声息的分歧，而"125 个用例加 57 个后继对、从单一文件回放"正是对此的正确防御。

让它停在 4 分而不是 5 分的，是我在 Stage 2 点名的名册可缩减脆弱性。这在今天不是 bug —— 我追查了使它安全的不变量（参与方属于固定键、名册只追加、开启时强制校验 takesPart），而且这些 domain 根本无法被提交。但本 PR 自己的开放问题列表就把"续任成员如何留在名册上"标为 H4e-b 待决，而那恰好正是消息目标路径上那些非空查找所依赖的不变量。如果名册有朝一日变得可缩减，一次干净的拒绝就会变成提交路径上的 TypeError / NPE。值得作为一项已知义务带进 H4e-b。

我没有把规模当作保留意见。以 1,642 行生产逻辑计，它超过了提示线，但 AGENTS.md 的核心两级门禁针对的是外部 PR、豁免维护者本人提交的 PR，而本作者既是仓库 admin、也是 .github/issue-owners.json 中列名的 owner。抛开规模不谈，这个改动的形态是有利的：47% 的 diff 是一份由机器双语回放的 fixture 语料，26% 是测试，而那 1,642 行逻辑代码落在一道拒绝任何人提交的门禁之后。

结论：批准，但把批准延迟到 CI 在 12be226486ae50183be37c1e068167fcc389eff6 上变绿之后。审查时还有两个 pull_request workflow run 未完成 —— Node 单测套件与 Java 21 / MySQL 8.4 / MariaDB 通道，而它们恰恰是运行两个契约套件和 H2 store 测试的那些。现在批准就等于为一个尚不存在的结果背书，所以我把延迟批准的标记留给 finalize 环节，等这些通道落定后由它执行；如果有任何一项变红或 head 发生移动，它会保留不批准并在状态评论中标出。

如果想在合并前而不是合并后补一件事，我的建议是：跑一次 @qwen-code /verify，把"新增守卫确实 fail closed"钉住。描述里 22/22 的变异体击杀是你自己的运行结果，CI 没有通道复现它，而对一个全部价值就在于它的拒绝的契约来说，这正是最吃重的证据。其余部分我会按现状合并。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 12be226486ae50183be37c1e068167fcc389eff6 · re-run with @qwen-code /triage}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[wenshao]

Re-reviewed at 4851c2364eddb5ab55a15611c2b01e7dc55fad22, including the delta from 12be226486ae50183be37c1e068167fcc389eff6 and the previous unresolved finding.

No new actionable findings. The previous P2 recipient-lookup issue is fixed in both implementations. Participant validation now precedes the recipient lookup on every revision. I checked the append-only roster and immutable message parties against the current code, including the authority's journal-rebuild path; valid successors remain admissible.

Independent reruns of the original recipient-change witness now produce ManagedSessionConflictError in TypeScript and ApiException / HTTP 409 / managed_session_extension_record_rejected in Java. Both preserve the committed revision after rejection and accept the corrected successor.

Validation on this exact head:

• npm run build and npm run typecheck: passed.
• Four affected TypeScript suites: 410 tests passed.
• Three affected Java suites: 17 tests passed.
• Independent reproduction checks: 2 TypeScript and 2 Java tests passed.

These are record-level checks (Java Spring/H2 and the existing TypeScript team-domain test enablement), not full HTTP/CLI E2E. Some hosted CI jobs were still pending when checked.

[wenshao]

Local maintainer verification — PR #13811 feat(managed-agent): H4e-a team record contract

Verdict: merge-ready — 17,916 scripted assertions executed across two rounds, 0 failures attributable to this PR.
Verified head: 4851c2364eddb5ab55a15611c2b01e7dc55fad22 · base: ad91df56f94f6080d32b340521e7f0095054b12c (both fetched from QwenLM/qwen-code and exercised as isolated worktrees).

Round note. Verification started at head 12be2264; the head moved to 4851c236 (fix(managed-agent): check a team message's parties on every revision) before posting, so every load-bearing measurement was re-run at the new head. Round 1 produced no findings against the PR, so the status table is:

#	Round-1 measurement	Status at 4851c236
1	Corpus replay + cross-language identity (199 lines)	Re-measured — re-executed at the new head, identical again (the input closure — managed-team-record.ts, managed-extension-projection.ts, ManagedTeamRecords.java, ManagedExtensionProjection.java, the fixtures — is byte-unchanged between heads, confirmed by git diff --stat over the closure AND by re-execution)
2	Domain gate	Re-measured — identical
3	TS mutation matrix	Re-measured — 14/14 killed (13 + the reverted-fix mutant)
4	Java mutation matrix	Re-measured — 7/7 killed (6 + the reverted-fix mutant)
5	Full suites	Re-measured — TS 3160/3160 green, Java 1625 tests as before

The delta commit itself was verified as load-bearing: reverting its every-revision parties check to the round-1 open-only form (mutants TS-M14 / JV-M7) turns its own new regression tests red on both sides.

中文摘要

结论:可以合并(当前 head 4851c236)。 两轮共 17,916 条脚本断言,没有任何失败可归因于本 PR。

• 验证期间 head 移动过一次(12be2264 → 4851c236,新增一个 fix 提交:把团队消息的收发方检查从"仅开链修订"改为"每个修订")。所有承重测量已在新 head 重跑;该 fix 本身也通过变异验证为承重——把它回退成旧形式(TS-M14 / JV-M7),其新增回归测试在两侧立即变红。
• 核心声明成立:四个团队记录体在 TS 与 Java 中回放同一份语言中立语料(125 用例 + 57 后继对),199/199 行判决逐字节一致;每个无效用例都按 fixture 指名条款被拒绝(100 clause 全命中);另有我独立构造的 17 个边界探针(2^53 边界的 number/planRevision、超限成员、astral 名字、cancelled 携带 input 等),两语言判决完全一致。基线对照:base 树 199/199 全部 NO-BODY。
• 变异矩阵:TS 14/14、Java 7/7 全部被杀,每个变异都死在以其命名的守卫测试上;两侧各含活性对照变异,均立即变红;矩阵结束后两棵树 git status 干净。
• 回归:新 head 全量 TS 套件 3160/3160(58 文件,与 PR 声明一致);Java clean verify:1625 测试、0 失败、2 个 error 为 ToolPublicationStoreTest 租约超时——在 base 上以相同签名重现,与本 PR 无关;Checkstyle 0 违规、SpotBugs 0 发现。
• 门禁:四个 domain 均 registered=1 enabled=0 REFUSED-EXACT,taskKindOf 全为 null(不投影 task),schedule 正对照通过。
• 未覆盖:H4e-b 运行时(本 PR 明确禁用);真实 MySQL/MariaDB 集成(store 以 H2 MySQL 模式驱动);作者自报的 22+22 全量变异数未逐一复跑(本报告以独立 14+7 矩阵覆盖全部承重守卫);其他 OS 的 CI flake 频率。
• 预先存在的红测试(TS flake 与 Java 租约超时)详见正文 "Pre-existing observations"。

Central claim and A/B proof

Claim: the four team domains (team_state, team_task, team_message, team_plan) land as schema-v1 record bodies whose validators and commit-time rules behave identically in TypeScript and Java, replaying one language-neutral corpus (125 cases, 57 successor pairs) — all four domains registered but disabled for submission, projecting no task.

Cell	Base (ad91df5)	Head (4851c236)	Oracle
Corpus replay (TS validators)	199/199 NO-BODY (no team bodies exist)	199/199 lines: expected verdict reproduced	per-line exp/got/rid/start/clause
Corpus replay (Java store)	199/199 NO-BODY	199/199 lines	same canonical format
Cross-language identity	—	diff of the two 199-line verdict files: empty — at both heads	byte-identical lines
Invalid-case clause attribution	—	100/100 clause=HIT on both sides, 0 MISS/WRONGTHROW	fixture's named clause must appear in the refusal
Domain gate	all 4 REFUSED-EXACT, body ABSENT	all 4 REFUSED-EXACT, body PRESENT	exact error string domain <d> is registered but not enabled for submission.
Task projection	—	taskKindOf → null for all 5 templates	no team record projects a task
Full src/managed-runtime/ vitest	2963 tests (3 pre-existing flakes under load)	3160/3160 green at both heads (58 files — matches the PR's claim exactly)	vitest
Java managed-agent-server verify	same 2 errors (see below)	1625 tests, 0 failures, 2 pre-existing errors, 1 skipped (macOS-disabled) — identical at both heads	surefire
checkstyle:check / spotbugs:check	—	0 violations / 0 findings (BUILD SUCCESS)	maven

Witness: 01-cross-language-fixture-identity.png, 04-domain-gate-ab.png, 03-suite-ab-and-gates.png below.

Independent drift probes (beyond the PR's own corpus)

17 extra probes I authored (harness/drift-probes.json) — the PR's fixtures are the author's, so these provide the independent input: number/planRevision at exactly 9_007_199_254_740_990 (accepted) and ...991 (refused) in both languages, an 11-member roster refused identically, astral-plane name refused, from == to == "leader" refused, a cancelled delivery carrying inputId refused, case-sensitivity of decision/status, string-typed planModeRequired, and an eleventh-member join successor refused. TS and Java agree on every probe, including the design-confirming positives that a team may be named leader (the reserved name binds participants only) and that a task can be in_progress owned by leader.

The follow-up fix (4851c236) is load-bearing

The delta commit widens the team-message parties check from the opening revision to every revision (both languages), closing the window where a successor readdressed to a non-member raced the fixed-key chain rule and hit the recipient lookup first. Reverting just that hunk (TS-M14 / JV-M7) turns the commit's own new regression tests red on both sides (routes a message only within the team… / routesMessagesAndPlansWithinTheTeam), so the fix is pinned by its tests, not decorative.

Mutation matrix (vacuity check on the guards)

Every guard was disabled one at a time and the PR's team tests re-run; each mutant died on the fixture case or authority/store test named for that guard, and both worktrees were git status-clean afterwards. A liveness-control mutant per language (perturbing an asserted error string) died immediately, proving both the suites and the harness can fail. Counts at 4851c236:

Mutant	Result	Killing witness
TS: membershipRevision = members+1	KILLED	state-revision-behind/state-revision-ahead
TS: member named leader refused	KILLED	state-member-leader
TS: message digest == content digest	KILLED	message-digest-mismatch
TS: message kind direction rules	KILLED	message-plan-request-from-leader et al. (4 tests)
TS: plan feedback only with decision	KILLED	plan-feedback-without-decision
TS: team led by this Session	KILLED	refuses a team that another Session leads
TS: one team per child run	KILLED	keeps each child run in one team…
TS: records open only in active team	KILLED	opens team records only in an active team…
TS: task number unique per team	KILLED	keeps task numbers unique…
TS: dependency cycle refused	KILLED	refuses a dependency outside the team or one that closes a cycle
TS: message targets recipient's Session	KILLED	routes a message only within the team…
TS: plan from plan-mode member	KILLED	takes a plan request only from a member that must plan
TS: liveness control (error string)	KILLED	state-members-null + state-members-not-array
TS: revert the follow-up fix to open-only parties check	KILLED	routes a message only within the team… (new regression assertions)
Java: team led by this Session	KILLED	bindsATeamToItsLeadAndItsMembersToLiveChildRuns
Java: one team per child run	KILLED	same
Java: task number unique	KILLED	keepsTheBoardInsideItsTeam
Java: dependency cycle	KILLED	same
Java: MAX_MEMBERS 10→11	KILLED	limits pinned by contract test (2 tests)
Java: liveness control (error string)	KILLED	validatesTheSharedRecordsAndStarts
Java: revert the follow-up fix	KILLED	routesMessagesAndPlansWithinTheTeam (new regression assertion)

Witness: 02-mutation-matrix.png. The PR's own larger claim (22 authority + 22 Java mutants) was not re-run exhaustively; this independent matrix covers every guard the PR introduces — see Not covered.

Static gates (liveness-proven)

ESLint and Prettier were first proven live (a planted unused variable and a planted format break were both caught), then run clean over the five changed TS files plus the two fixtures files; tsc --noEmit for @qwen-code/qwen-code-core is clean. Design docs exist in both languages with reciprocal links and equal length (190 + 190 lines).

Findings

None blocking. One design-level confirmation worth recording: the validators deliberately allow a team to be named leader (only participants reserve the name); both languages agree, and the design doc's wording ("the reserved leader", in the participant sense) matches the code. No action needed.

Pre-existing observations (not attributable to this PR)

• TS load-correlated flakes. Under a heavily loaded first pass (two installs + two suites + Maven running concurrently), the round-1 head showed 4 red tests and base 3, with byte-identical signatures for the shared three (managed-session-authority.hook-scale.test.ts ×2, managed-session-record-sink.test.ts ENOTEMPTY temp-dir race ×1). The three affected files re-run in isolation: 54/54 green on both arms; quiet full-suite reruns at both heads: 3160/3160 green. The single head-only extra (managed-child-run-supervisor.test.ts › settles a terminated process only after the unit is empty, a file this PR does not touch) also passes in isolation on both arms.
• Java ToolPublicationStoreTest × 2 errors (renewsTheOriginalClaimWhileScanningSlowObjectBytes, streamsLargeOutputAndReadsItsTailAfterStoreReplacement — lease/expiry timing): fail with the byte-identical signature at base and at both heads, in isolation, on this machine, in a file this PR does not touch. Pre-existing environmental failure (macOS; the PR's own evidence was gathered on Linux).
• Skipped-count delta: PR reports 2 skipped on Linux; 1 skipped here (RuntimeBrokerDefaultOnTest is Disabled on operating system: Mac OS X). Environmental, not a discrepancy in the change.

These 13 red executions are disclosed here rather than counted as failures of this verification: each was either re-driven to green in isolation on both arms or shown byte-identical at base, which is the A/B expectation for pre-existing failures.

Not covered

• H4e-b runtime (team tools, teammate routing, mailbox relay, plan resolution, member shutdown, legacy import, enablement) — explicitly out of scope for this PR; the four domains stay disabled, which the gate harness proves.
• Real MySQL/MariaDB integration lanes — the store was exercised on H2 in MySQL mode (the module's own test setup), as the PR's test plan specifies; no migration ships here.
• The author's full 22+22+6 mutation run was not reproduced exhaustively; the independent 14+7 matrix above covers every guard the PR introduces.
• Per-commit attribution of 12be2264's internals: it is a single commit; the aggregate diff was verified. The follow-up 4851c236 was verified separately (above).
• Other OS/CI lanes (Windows, Linux CI flake rates); npm run bundle beyond the per-workspace build the suites consume.

Methodology

Two isolated worktrees (tmp/pr13811-head at the current head, tmp/pr13811-base @ ad91df5), each corepack pnpm install --frozen-lockfile (prepare-built); internal-link integrity asserted via readlink -f node_modules/@qwen-code/qwen-code-core resolving inside each tree. Harnesses are mock-free against the real modules: TS replay via tsx importing managed-extension-projection.ts directly; Java replay via a scratch FixtureReplay.java compiled against the module's target/classes and its Maven dependency classpath, driving ManagedExtensionProjection.RECORD_BODIES. The corpus and my probe file were treated as pure input (base trees read them from the head tree). Mutation drivers apply anchored single replacements, assert exactly one occurrence, run the new team test files/classes, and restore byte-identically (verified by git status). Java env: Homebrew JDK 21 + Maven 3.9, -Dgpg.skip=true. Round-1 measurements whose input closures are byte-unchanged between heads were carried forward only after re-execution confirmed identical output (replay, gate); everything else was re-measured at the new head. All harnesses and raw logs are under tmp/pr13811-verify-20261010-112810/ (harness/, logs-*, evidence/).

Evidence captures

01 — Cross-language fixture identity (the central claim): 199/199 verdict lines byte-identical between TS and Java; base trees show 199/199 NO-BODY. (Captured at 12be2264; re-executed byte-identically at 4851c236.)

02 — Mutation matrix at 4851c236: 14/14 TS guards and 7/7 Java guards killed by their named witnesses, including the reverted follow-up fix; liveness controls killed; worktrees clean afterwards.

03 — Suites and gates at 4851c236: head suite 3160/3160 green on a quiet machine; loaded-pass flakes identical on base; Java 1625 with the 2 pre-existing errors attributed; checkstyle/spotbugs clean.

04 — Domain gate A/B: all four team domains registered but refused for submission on both arms; bodies present only at head; schedule positive control passes.

---

Local maintainer verification by @wenshao's request. Artifacts: tmp/pr13811-verify-20261010-112810/ (report.md, verdict.txt, assertions.json, harnesses, raw logs, evidence).

[qqqys]

Reviewed at head 4851c2364eddb5ab55a15611c2b01e7dc55fad22 (Critical-only scan).

Prior blocking issue — confirmed fixed. The P2 (a successor that readdressed a committed team message to a name outside the roster reached the recipient lookup before any participant check, so TypeScript threw TypeError and the Java store threw NullPointerException, which the generic handler maps to 500 instead of the normal 409) no longer holds on either side:

• managed-session-authority.ts — the takesPart(message.from) && takesPart(message.to) refusal now sits in the team_message branch unconditionally, not under previous === undefined, so it runs on every revision and precedes the team.members.find(...)! / extensionRecord('child_run', ...)! dereferences in the targetSessionId block.
• ManagedExtensionRecordStore.requireTeamRecord — require(takesPart(team, from) && takesPart(team, to), ...) likewise runs on every revision, and applyRevision calls it for any team_ domain regardless of previous, so it precedes memberWith(team, "name", to).get("childRunId").

The non-null dereferences that remain are backed by the record validator, which refuses leader as a member name and requires distinct member names and distinct child run ids, so a participant check that passes on a non-leader name matches exactly one member in both languages.

Current scan — no Critical. Checked against the head code:

• The cycle walk can only dereference tasks that exist: every newly added blocker is verified present and in the same team before the walk starts, and a committed task's own blockedBy entries were verified when it committed, with records append-only — so this.extensionRecord('team_task', next)! and Java's recordBody(...).get("blockedBy") cannot miss.
• The team-task owner rule, the task-number uniqueness rule, the blocker-scoping rule and the plan-mode member rule agree across the two implementations, including the "unchanged from the previous revision" allowance on the owner.
• Team membership rules match: a member joins as a non-terminal child Session run of the lead, and no child run may appear in a second team; the roster is append-only (prefix on the member list) with membershipRevision == members.length + 1.
• All four domains are registered identically in MANAGED_EXTENSION_RECORD_BODIES and ManagedExtensionProjection, each projecting no task, and the resource-closure list covers descriptionRef, metadataRef, contentRef, planRef and feedbackRef on both sides — the closed key sets make the Java superset scan equivalent to the per-domain TypeScript lists.
• Nothing here enables submission for the team domains, so the contract stays inert at merge.

CI: Qwen Autofix and the label/self-report jobs succeeded; Qwen Code CI was queued and SDK Java still running at review time. Nothing fails attributable to this diff, and no failure evidence contradicts the record-level checks above.

[yiliang114]

LGTM. Reviewed at 4851c2364e, including the delta from 12be226486.

The record contract holds up. The four team domains are registered bodies (all taskKindOf: () => null, so none of them projects a task), stay out of MANAGED_SESSION_ENABLED_DOMAINS, and the generic path refuses them at the extension funnel before the enablement check — no writer mints a team_state: / team_task: / team_message: / team_plan: event id. The commit-time rules match decision 8 rule-for-rule in both languages: lifecycle one step at a time (terminal deleted freezes the run), member join (a live child Session run of this Session, in no other team, active only), task (number is a fixed key, so uniqueness only needs to be checked at the open), owner (leader/member, or unchanged), blockedBy grows-only + in-team + acyclic, message parties checked on every revision with the target binding (leader→lead Session, member→its run's attached Session, otherwise it stays planned), plan from a plan-mode member keyed by the D6 requestId. The journal-rebuild path reuses the same assertExtensionRevision, so rebuild and live commit agree.

Your P2 from the earlier review is fixed: the parties predicate is evaluated unconditionally, before the recipient lookup, in both managed-session-authority.ts and ManagedExtensionRecordStore.java, and a rejected successor leaves the committed revision untouched. Shared fixtures are real (125 cases / 57 successor pairs, both suites load the same JSON), and the projection + ref-closure additions are equivalent across the two languages. The EN/ZH designs line up.

One non-blocking observation: managed-session-authority.extension.test.ts:1131 still describes team_state as "neither in the plain enabled list nor in the extension-record body index". After this PR it is in the body index, so in the real module that event takes the extension-funnel refusal ("records commit only through commitExtensionRecord") rather than "not enabled for submission". The test still passes only because that suite mocks the index down to {monitor_run}, so the probe's rationale is now stale — worth refreshing the comment (or dropping the mock later) so it stays honest. Not a behavior issue.

CI on this head: the lanes that have run are green (Test ubuntu Node 22.x, Lint & Static, Java matrix incl. Windows/macOS/11/17/21, Real daemon, Integration, Flyway uniqueness); Hosted process fault gates / MySQL 8.4, Runtime Broker and Managed Agent MariaDB, web-shell E2E and Desktop Shell are still pending, none failing. mergeStateStatus stays BLOCKED until the required approvals land.

Scope note: this is a source-level review of the frozen head plus fixture/doc checks; I did not rerun the MySQL/MariaDB lanes locally.

[qwen-code-review-bot]

Released in v0.25.1.