fix: restore the entry fixture's captain tool count after the amendment tool - #180
Merged
Merged
Conversation
…nt tool `progressive-entry` asserts the captain's fixed team-tool exposure, and that set grew from 13 to 14 when `agent_teams_amend_task` landed (e651d50, via #155). The fixture kept the old count, so every Real Harness job went red on main immediately after that merge: AssertionError: 14 !== 13 at scripts/fixtures/harness-runtime-entry.mjs:43 The tool itself is wired correctly: captain-only (src/tool-names.ts derives CAPTAIN_TOOL_NAMES), hidden from members through both capabilities.ts and memberToolFilter, registered under the exact name the set declares, and visible from the captain's first request, which is what the fixed-exposure contract requires. Only the fixture's mirror of the count was stale. Also update the prose that still stated the old count, and add the missing `agent_teams_amend_task` row to the usage tool table. Verified locally with the same harness CI runs, on all four supported hosts (0.1.5-rc.1, 0.1.2-rc.1, 0.1.2-alpha.5, 0.1.2-alpha.2): all ten scenarios pass, including the previously failing progressive-entry.
…n flush
`web-approval` on 0.1.5-rc.1 fails intermittently (2 of the last 3 CI runs) even
though every substantive assertion passes:
SessionHandleClosedError: session "<id>": flush on a closed handle
at JsonlSessionHandle.assertOpen (dsh-session-persistence-jsonl)
at fixtures/harness-runtime-web-approval.mjs:181
The four runtime fixtures that the CI gate drives share one teardown idiom: walk
`ctx.agents.list()`, await each agent's idle, then flush the sessions still
registered. The liveness check and the flush are separated by an await, so
another agent's handle can close in that window. Closing persists the session,
so the flush has nothing left to do — but the host refuses the call and the
whole scenario exits non-zero.
Guard each flush site against exactly that error; any other failure still
propagates. The same race is reachable in entry, idle and resume, which use the
identical idiom.
fixtures/harness-model-driver.mjs carries the same idiom but runs only in the
real-model benchmark lab, not in the CI gate, so it is left alone.
Tonited
added a commit
to Tonited/dsh-agent-teams
that referenced
this pull request
Sep 17, 2026
Brings in v0.1.18 plus NanmiCoder#155, NanmiCoder#167, NanmiCoder#180 and NanmiCoder#172. Conflict resolution: - package.json: both sides appended to the `verify` chain, so both steps are kept — `dispatch-visibility-tdd.mjs` (this branch) and `verify:member-spawn-recovery` (NanmiCoder#172). - src/tools.ts `dispatchMember`: NanmiCoder#172 and this branch record a rejected spawn on two different surfaces, and both are kept — the member carries `spawnError` (with the failing stack, rendered as `start failed:` under the member) and the team carries `lastDispatchError` (rendered above the roster as `Last dispatch rejection:`). The successful-spawn path now clears both (`delete member.spawnError` + `clearDispatchFailure`). Guard rejections (`halted`, `staged`, member stopping, stale attempt, …) remain unique to this branch: NanmiCoder#172 only covers the thrown-spawn path.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
main 从合并 #155（
fa5803d）起 CI 就是红的：4 个 Real Harness job 全部只挂同一个 scenario，报同一条错。progressive-entry断言队长固定暴露的团队工具数量。agent_teams_amend_task（e651d50，随 #155 进来）把TEAM_TOOL_NAMES从 13 个变成 14 个，但 fixture 里 4 处硬编码的 13 没跟着改。这不是工具本身的问题
agent_teams_amend_task的接线是对的，无需改源码：CAPTAIN_TOOL_NAMES由src/tool-names.ts:14派生；src/capabilities.ts:91和harness-compat.ts的memberToolFilter两条路径都挡住；src/tools.ts:1784）；所以只有 fixture 那份「数量的镜像」过期了。
顺带修掉的文档
#155 只更新了模型可见的 prompt（
src/index.ts:146），README 和 docs 里仍写着「13 个工具」，且docs/usage.md的工具表缺agent_teams_amend_task这一行。历史快照（
docs/releases/**、docs/*verification.json、release-notes/**）保持不动 —— 那些是版本化的存档，protocol-compatibility用的 13 项白名单也是有意为之的 legacy 允许列表。第二个 commit：修掉 gate 上的一条 flake
计数修好之后，
Real Harness (0.1.5-rc.1)仍然间歇性失败（3 次 run 挂 2 次），但所有实质断言都过：CI 驱动的 4 个 runtime fixture 共用同一个收尾 idiom：遍历
ctx.agents.list()，等每个 agent idle，再 flush 仍注册着的 session。存活检查与 flush 之间隔着一个await，别的 agent 的 handle 可能正好在这个窗口里关掉。关闭本身已经完成持久化，这次 flush 无事可做，但宿主会拒绝这个调用并让整个 scenario 非零退出。给每个 flush 点只针对这个错误加保护；其他失败照旧抛出。
entry/idle/resume用的是同一个 idiom，同样可命中，一并修掉。harness-model-driver.mjs有同样的写法，但只跑在真实模型 benchmark lab、不在 CI gate 里，未改动。验证
用 CI 同一个 harness 在本地跑了全部 4 个宿主（
0.1.5-rc.1/0.1.2-rc.1/0.1.2-alpha.5/0.1.2-alpha.2），每个都是 10/10，含此前失败的progressive-entry。pnpm verify通过（exit 0）。