Repository navigation
0.1.8 Beta4: Implement runtime-derived Collaboration V2 direct-tool and lifecycle adaptation #282
Description
Parent
Outcome
Implement generic Collaboration V2 direct-tool and lifecycle adaptation for custom Responses endpoints using the exact contract accepted in #392.
The work extends the Beta2 V1/V2 isolation boundary. It must not invent the historical collaboration namespace when the bound runtime exposes V2 as direct function tools.
Required behavior
- Preserve the six V2 direct function declarations and lifecycle natively when the selected Responses protocol carries them completely.
- Otherwise use only an injective, request-scoped, fully reversible representation for declarations, calls, results, task identity, message/
agent_message, streaming, and history. - Preserve exact call/item identity, ordering, canonical task identity, follow-up, wait/result, list/interrupt, parent delivery, replay, and same-Home restart semantics.
- Keep all V1 repair/state/scheduler code structurally unreachable from V2.
- Fail before upstream sampling when an essential lifecycle item is not natively representable and no complete inverse exists.
- Codex Client remains the agent owner and executor.
Acceptance criteria
- Protocol fixtures cover spawn, send message, follow-up, wait, interrupt, list, result delivery, streaming, history, and replay shapes.
- Direct
spawn_agent/wait_agentnames are classified from the authoritative runtime selection and complete schema, never by name alone. - V2 never receives V1
fork_context, agent-ID targeting, close/resume, scheduler, or wait-result repair. - Unknown aliases, conflicting state, ambiguous task identity, malformed
agent_message, and missing/duplicate IDs fail safely. - Gateway does not create agents, invent task identity, schedule V2 work, or fabricate completion.
- No Provider/model name selects the adapter.
- Exact route identity remains unchanged and no cross-Provider execution occurs.
Activity
[-]0.1.8 Beta3: Complete the GLM-5.2 Collaboration V2 lifecycle[/-][+]0.1.8 Beta4: Complete the GLM-5.2 Collaboration V2 lifecycle[/+][-]0.1.8 Beta4: Complete the GLM-5.2 Collaboration V2 lifecycle[/-][+]0.1.8 Beta5: Complete the GLM-5.2 Collaboration V2 lifecycle regression[/+][-]0.1.8 Beta5: Complete the GLM-5.2 Collaboration V2 lifecycle regression[/-][+]0.1.8 Beta4: Implement generic Collaboration V2 namespace and lifecycle adaptation[/+][-]0.1.8 Beta4: Implement generic Collaboration V2 namespace and lifecycle adaptation[/-][+]0.1.8 Beta4: Implement runtime-derived Collaboration V2 direct-tool and lifecycle adaptation[/+]NOirBRight commentedon Aug 10, 2026
#392 calibration supersedes #282's pre-capture direct-wire assumption for the frozen Beta4 runtimes.
Bound evidence (
CLI 0.146.1,Desktop 26.803.5235.0, candidated1308ce5bd0546993a68579b23102bafde24513a) shows both clients serialize V2 as one Responsesnamespacedeclaration namedcollaboration, containing the six function children. The client dispatch recipient group is also namedcollaboration, but it is a separate layer. Six top-level same-named function declarations are explicitly not a frozen-runtime V2 marker.Therefore #282 will implement the accepted #392 contract:
agent_message) is covered.This is a calibration correction, not a Provider/model-specific exception.
NOirBRight commentedon Aug 10, 2026
Implemented and merged in PR #406 at dev merge commit 5e057c6. Exact #392 runtime-derived Collaboration V2 classification, native/adapted lifecycle, fail-closed history/call/result/agent_message/SSE identity/order, V2-before-V1 isolation, and mixed ordinary function history regression are covered. Focused/full Python evidence is recorded in the Beta4 worktree report.