Repository navigation
0.1.8 Beta2: Define tool-type compatibility rules for custom Responses endpoints #65
Description
Parent
Outcome
Define one model-agnostic compatibility table for runtime-provided Codex tool declarations sent to custom Responses endpoints.
The table is keyed by declaration type, wire lifecycle, selected upstream protocol, and whether the request requires the tool. It is never keyed by model display name or a GLM/K2.7 allowlist.
Required table
For each structural family observed by #62, record:
- runtime declaration kind and whether Codex or the selected Provider executes it;
- selected-protocol native representation, if any;
- model-visible exposure decision;
- request encoding and inverse call/result/history mapping;
- streaming assembly and identity requirements;
- loss/ambiguity boundary;
- final disposition:
native,adapt,omit, orrequired-but-unavailable.
Rules
native: preserve the declaration and wire items unchanged.adapt: use an Adapter only when the selected protocol cannot carry the native shape and the mapping is injective, request-scoped, and reversible.omit: do not expose an optional capability that the selected Provider cannot execute or that cannot be represented safely; emit only a bounded sanitized diagnostic.required-but-unavailable: fail visibly before upstream sampling whentool_choiceor the request contract requires an unavailable tool.- Hosted tools are available only from the already-selected Provider. Unsupported hosted search, compaction, or other hosted semantics are never delegated to another Provider.
- Execution follows the tool type; the Gateway does not add an independent executor/scheduler decision.
- Unknown custom endpoints use the same conservative type/protocol rules. Maintained-Provider tests are evidence, not runtime eligibility.
Acceptance criteria
- Every 0.1.8 Beta2: Inventory Codex CLI 0.146 tool types and representative Responses lifecycles #62 structural family has exactly one deterministic rule for each relevant selected-protocol condition.
- Native-compatible tools are not unnecessarily wrapped.
- Namespace and custom/freeform mappings define collision-free aliases/envelopes and complete inverse history behavior.
- Client-executed tool discovery and Collaboration namespace shapes have a generic representability rule without claiming full workflow qualification.
- Unsupported hosted tools resolve to
omitorrequired-but-unavailable; no cross-Provider path exists. - Unknown or unqualified models are not denied merely because they lack a model-specific matrix row.
- The table contains no model-name production dispatch rule and no runtime QualificationRecord/allowlist.
- The accepted table is precise enough to implement 0.1.8 Beta2: Implement runtime-derived tool compatibility for custom Responses endpoints #58 without additional product decisions.
Activity
NOirBRight commentedon Jul 15, 2026
2026-07-16 native Responses strict_apply_patch qualification
Source: dev a0cb8c9; Codex CLI 0.144.1. The harness used an isolated Codex CLI and isolated Gateway, native /v1/responses only, with strict_apply_patch selected in temporary provider/model configuration. No Responses-to-Chat conversion or protocol fallback was allowed. Each strict pass required shell_command -> apply_patch -> shell_command, one exact one-line target mutation, zero request errors, zero upstream retries, and zero protocol fallbacks.
Results:
Additional native Responses provider rows were prepared for volc/glm-5.2, xunfei/xopglm52, and minimax-cn/MiniMax-M3. Their configured credential environment variables were not available to the isolated task process, so no live upstream call was made and no protocol verdict is claimed.
Decision evidence: do not infer that all Ollama Cloud models, or all external providers, are safe for a provider-wide/global strict_apply_patch default from this matrix. Keep explicit model selection while #65 gathers more evidence; #58 remains the capability-driven production-default owner after #57's decision gate.
NOirBRight commentedon Jul 15, 2026
Correction and additional provider results
Correction to the prior matrix comment: CodexHub had saved credentials for all four providers in the active runtime configuration. The initial harness inspected the bundled template rather than the active runtime layer. The rerun read each stored credential only in memory and passed it to its isolated Gateway child; no credential was copied into evidence or printed.
All probes below used native Responses only; no Chat conversion or protocol fallback was used.
Updated decision evidence: provider-wide or global strict_apply_patch default activation remains unsafe. Volc exposes a concrete Responses event-shape incompatibility; Xunfei and MiniMax.cn require account-side authorization/quota recovery before their protocol rows can be qualified.
NOirBRight commentedon Jul 29, 2026
Corrected 2026-07-29 qualification result
The configured and user-visible path is Chat Completions. Native Responses was exercised only as a control and must not be used to mark Sol's Chat path green.
Environment: CodexHub
fad95c869bf3726461d9f9a764020863a5ba0317, Codex CLI0.145.0, and a private CLIProxyAPI-compatible endpoint. No endpoint address, credential, request ID, prompt, or generated text is included here.The exact model-test request defined in
src-tauri/src/models.rswas replayed against Chat Completions with its non-streaming payload and eight-second timeout, alternating models to control for time-window effects:auth_unavailableresults, and—after the cooldown window—a further 502.A separate native Responses control completed once for Sol, and one earlier synthetic Gateway Chat request also completed in a different bounded run. Neither is equivalent to this model-test path or a real Codex-over-Chat turn, so neither is a green qualification for Sol/Chat.
Current matrix disposition: Sol + Chat Completions = red/unqualified; Luna + Chat Completions = probe-green only. Catalog exposure, protocol reachability, current auth/capacity availability, and real Codex text/tool compatibility must remain separate fields. Real Codex-over-Chat is additionally blocked by #66's deterministic request-field translation gap.
20 remaining items
NOirBRight commentedon Aug 4, 2026
Orchestrator dispatch status (2026-08-04)
Campaign:
campaign:0.1.8-beta2.Dispatch is held by
#62and#350. A single Luna Max worker will start only after the 0.146 inventory and ADR are accepted. The worker owns the generic tool-type/protocol compatibility decision artifact and tests; it must not change production routing or select/fallback a model. #249 remains the maintainer approval gate after this work.feat: harden Issue #62 runtime inventory evidence contract
NOirBRight commentedon Aug 5, 2026
Beta2 dispatch update
#62 and #350 are closed, so the tool-type compatibility table is now unblocked. The worker scope is the model-agnostic structural contract only: deterministic native/adapt/omit/required-but-unavailable rules for every #62 family, execution ownership, native passthrough, reversible namespace/custom mappings, hosted-tool omission/failure, and generic representability boundaries for tool_search and Collaboration V2 without claiming their full Beta3/Beta4 workflows.
No production implementation (#58), named-model branch, cross-Provider proxy, Gateway tool execution, alternate-codec retry, model-output repair, or release action is authorized in this ticket.
NOirBRight commentedon Aug 5, 2026
Worker dispatched
n- Workspace: wks_27fcc0f94b6c1becn- Branch: codex/issue-65-tool-compatibility-tablen- Exact base: dcd2f79986186cdb047388c5fb5c3f07c2bd09a9nThe worker owns only Issue 0.1.8 Beta2: Define tool-type compatibility rules for custom Responses endpoints #65's repository contract/table and Draft PR. Exact-SHA review, acceptance, merge, 0.1.8 Beta2: Approve the custom-endpoint tool compatibility contract #249, 0.1.8 Beta2: Implement runtime-derived tool compatibility for custom Responses endpoints #58, and release actions remain with the coordinator/maintainer.
NOirBRight commentedon Aug 5, 2026
{ "contract": { "acceptance": [ "Every Issue #62 structural family has one deterministic rule for each relevant selected-protocol condition.", "Native-compatible tools are not unnecessarily wrapped.", "Namespace and custom/freeform mappings define collision-free aliases or envelopes and complete inverse history behavior.", "Client-executed tool discovery and Collaboration V2 namespace shapes have a generic representability rule without claiming full workflow qualification.", "Unsupported hosted tools resolve to omit or required-but-unavailable and no cross-Provider path exists.", "Unknown or unqualified models are not denied merely because they lack a model-specific matrix row.", "The table has no model-name production dispatch rule or runtime QualificationRecord/allowlist and is precise enough to implement Issue #58 without more product decisions." ], "change_claims": { "paths": [ "docs/evidence/issue-65/README.md" ], "resources": [ "contract:runtime-tool-compatibility" ] }, "dependencies": { "dispatch_after": [ 62, 350 ], "merge_after": [ 62, 350 ] }, "design": [ "Add one durable model-agnostic compatibility table at docs/evidence/issue-65/README.md from the accepted Issue #62 inventory, ADR-0002, and Issue #64 V1/V2 boundary; do not modify production routing.", "For plain function, namespace, custom/freeform, client tool_search, Provider-hosted tools, Collaboration V2 representability, and unknown kinds, define execution owner, selected-protocol native shape, exposure, request encoding, inverse call/result/history mapping, streaming and identity requirements, ambiguity boundary, and exactly one disposition.", "Preserve native shapes unchanged; adapt only through a request-scoped injective collision-free reversible mapping; omit optional unavailable capabilities with bounded sanitized diagnostics and fail required unavailable capabilities before upstream sampling.", "Keep the exact selected Provider/model and never add cross-Provider hosted-tool proxying, Gateway execution or scheduling, named-model dispatch, retries, output repair, Issue #58 implementation, or Beta3/Beta4 workflow qualification." ], "difficulty": "light", "done_when": [ "Inspect docs/evidence/issue-65/README.md against Issue #65, ADR-0002, and the Issue #62/#64 evidence; every acceptance item is explicit and every referenced repository path resolves.", "git show --check --oneline --stat HEAD exits zero.", "git status --porcelain is empty after the candidate commit is pushed." ], "priority": "P1", "risk": "low", "sha256": "b329854aea029e3ec8bcd9691dc208fe645a9f4f61db4017c89ec6b978f8a8c7", "unresolved_decisions": [] }, "dispatch": { "accepted_at": "2026-08-05T08:06:56Z", "attempt": 1, "base_sha": "dcd2f79986186cdb047388c5fb5c3f07c2bd09a9", "branch": "work/issue-65", "candidate_sha": "c92441e770cebaa06019d2cf56ef3cddc926f69b", "claimed_at": "2026-08-05T07:41:24.561156Z", "contract_sha256": "b329854aea029e3ec8bcd9691dc208fe645a9f4f61db4017c89ec6b978f8a8c7", "creator_agent_id": "470f6d8f-78e6-4afb-b625-257f00f09983", "generation": 1, "id": "dispatch-issue-65-a1", "integrating_at": "2026-08-05T08:08:48.461610Z", "merged_at": "2026-08-05T08:09:06Z", "pr_number": 362, "recovery_prompt_sent": true, "status": "merged", "worker_agent_id": "321f26a7-6925-4e7f-b546-c8002df3cf05", "workspace_id": "wks_27fcc0f94b6c1bec" } }NOirBRight commentedon Aug 5, 2026
Delivered by merged PR #362.