codex-a2a 0.7.1__tar.gz → 0.7.3__tar.gz

{codex_a2a-0.7.1/src/codex_a2a.egg-info → codex_a2a-0.7.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: codex-a2a
-Version: 0.7.1
+Version: 0.7.3
 Summary: Codex A2A runtime adapter
 Author: liujuanjuan1984@Intelligent-Internet
 License-Expression: Apache-2.0
@@ -157,11 +157,7 @@ Use this project when:
 - you want a thin service boundary instead of building your own adapter
 - you want inbound serving and outbound peer access in one deployable unit
 
-Prefer [a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub) when:
-
-- you need a broader application-facing client integration layer
-- you want higher-level A2A consumption and upstream adapter normalization
-- you want client-side integration concerns separated from the Codex runtime boundary
+Prefer **[a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub)** when you need a broader application-facing integration layer or higher-level A2A consumption (see [Ecosystem](#ecosystem) for details).
 
 Look elsewhere if:
 
@@ -201,6 +197,25 @@ The normative compatibility split and deployment model live in [Compatibility Gu
 - [External Conformance Experiments](docs/conformance.md) Manual A2A TCK experiment entrypoint and triage workflow.
 - [Security Policy](SECURITY.md) Threat model, deployment caveats, and vulnerability disclosure guidance.
 
+## Ecosystem
+
+`codex-a2a` is part of a growing landscape of A2A-compliant projects. Depending on your architecture, you may find these related projects useful:
+
+### Foundations (Upstream)
+
+- **[Intelligent-Internet/a2a-python](https://github.com/Intelligent-Internet/a2a-python)**: The core protocol implementation and SDK used by this adapter.
+- **Codex**: The underlying local agent runtime (Proprietary).
+
+### Gateways & Hubs (Vertical Integration)
+
+- **[liujuanjuan1984/a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub)**: An application-facing integration layer that consumes A2A-compliant instances (like `codex-a2a`) and provides higher-level normalization.
+- **[jinyitao123/a2a-gateway](https://github.com/jinyitao123/a2a-gateway)**: Operates at the protocol-bridging layer, sitting between agent platforms and the A2A/MCP ecosystem to handle discovery and routing.
+
+### Alternative Implementations & Runtimes (Horizontal Differences)
+
+- **[Intelligent-Internet/opencode-a2a](https://github.com/Intelligent-Internet/opencode-a2a)**: A complementary Python runtime implementation that shares similar protocol patterns and output negotiation practices.
+- **[MyPrototypeWhat/codex-a2a](https://github.com/MyPrototypeWhat/codex-a2a)**: A lightweight **TypeScript** Express middleware implementation. Ideal for developers looking for in-process SDK integration within a Node.js environment.
+
 ## Development
 
 For contributor workflow, validation, release handling, and helper scripts, see [Contributing Guide](CONTRIBUTING.md) and [Scripts Reference](scripts/README.md). Use that workflow to create a PR from the working branch and merge into `main` after human review.

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/README.md

@@ -110,11 +110,7 @@ Use this project when:
 - you want a thin service boundary instead of building your own adapter
 - you want inbound serving and outbound peer access in one deployable unit
 
-Prefer [a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub) when:
-
-- you need a broader application-facing client integration layer
-- you want higher-level A2A consumption and upstream adapter normalization
-- you want client-side integration concerns separated from the Codex runtime boundary
+Prefer **[a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub)** when you need a broader application-facing integration layer or higher-level A2A consumption (see [Ecosystem](#ecosystem) for details).
 
 Look elsewhere if:
 
@@ -154,6 +150,25 @@ The normative compatibility split and deployment model live in [Compatibility Gu
 - [External Conformance Experiments](docs/conformance.md) Manual A2A TCK experiment entrypoint and triage workflow.
 - [Security Policy](SECURITY.md) Threat model, deployment caveats, and vulnerability disclosure guidance.
 
+## Ecosystem
+
+`codex-a2a` is part of a growing landscape of A2A-compliant projects. Depending on your architecture, you may find these related projects useful:
+
+### Foundations (Upstream)
+
+- **[Intelligent-Internet/a2a-python](https://github.com/Intelligent-Internet/a2a-python)**: The core protocol implementation and SDK used by this adapter.
+- **Codex**: The underlying local agent runtime (Proprietary).
+
+### Gateways & Hubs (Vertical Integration)
+
+- **[liujuanjuan1984/a2a-client-hub](https://github.com/liujuanjuan1984/a2a-client-hub)**: An application-facing integration layer that consumes A2A-compliant instances (like `codex-a2a`) and provides higher-level normalization.
+- **[jinyitao123/a2a-gateway](https://github.com/jinyitao123/a2a-gateway)**: Operates at the protocol-bridging layer, sitting between agent platforms and the A2A/MCP ecosystem to handle discovery and routing.
+
+### Alternative Implementations & Runtimes (Horizontal Differences)
+
+- **[Intelligent-Internet/opencode-a2a](https://github.com/Intelligent-Internet/opencode-a2a)**: A complementary Python runtime implementation that shares similar protocol patterns and output negotiation practices.
+- **[MyPrototypeWhat/codex-a2a](https://github.com/MyPrototypeWhat/codex-a2a)**: A lightweight **TypeScript** Express middleware implementation. Ideal for developers looking for in-process SDK integration within a Node.js environment.
+
 ## Development
 
 For contributor workflow, validation, release handling, and helper scripts, see [Contributing Guide](CONTRIBUTING.md) and [Scripts Reference](scripts/README.md). Use that workflow to create a PR from the working branch and merge into `main` after human review.

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/docs/guide.md

@@ -191,7 +191,7 @@ Use the grouped sections below as the deployment-first reading order:
 - `A2A_DATABASE_URL` also owns the adapter-managed runtime-state schema lifecycle. On startup, `codex-a2a` auto-creates the runtime-state tables, records a schema version for the `runtime_state` scope, and applies in-place migrations for those tables only.
 - The adapter-managed runtime-state schema is limited to `a2a_session_bindings`, `a2a_session_owners`, `a2a_pending_session_claims`, `a2a_pending_interrupt_requests`, and `a2a_schema_version`. It does not own the A2A SDK task-store tables or any upstream Codex/provider-local state.
 - For deployment-specific durability constraints and migration-scope boundaries, see [compatibility.md](./compatibility.md).
-- `A2A_LOG_LEVEL`: `DEBUG/INFO/WARNING/ERROR`, default `INFO`
+- `A2A_LOG_LEVEL`: `DEBUG/INFO/WARNING/ERROR`, default `WARNING`
 - `A2A_LOG_PAYLOADS`: log A2A/Codex payload bodies, default `false`
 - `A2A_LOG_BODY_LIMIT`: payload log body size limit, default `0` (no truncation)
 - `A2A_TITLE`: agent name, default `Codex A2A`
@@ -438,7 +438,7 @@ This path is for contributors. End users should prefer the released CLI path des
 - `mention.path` and `skill.path` are forwarded verbatim. The service does not guess app or plugin identifiers from display names.
 - `local_image` is not part of the current declared stable rich-input contract.
 - Session query projections currently use the upstream Codex `session_id` as the A2A `contextId`. This is intentional for the current deployment model: `contextId` and `metadata.shared.session.id` refer to the same upstream session identity, and the contract declares that equality explicitly.
-- Task state defaults to `input-required` to support multi-turn interactions.
+- Completed chat turns are persisted as `completed`; `input-required` is reserved for active interrupt asks that still need a reply.
 - Non-streaming requests return a `Task` directly.
 - Non-streaming `message:send` responses may include normalized token usage at `Task.metadata.shared.usage` with the same field schema.
 - `tasks/resubscribe` remains part of the core A2A method baseline, but this deployment's terminal-task replay-once policy is a declared service-level behavior rather than a generic A2A guarantee.

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/src/codex_a2a/client/agent_card.py

@@ -64,10 +64,3 @@ def build_agent_card_request_kwargs(config: A2AClientConfig) -> dict[str, Any]:
             key: str(value) for key, value in config.default_headers.items() if value is not None
         }
     return http_kwargs
-
-
-__all__ = [
-    "AgentCardEndpoint",
-    "build_agent_card_request_kwargs",
-    "resolve_agent_card_endpoint",
-]

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/src/codex_a2a/client/payload_text.py

@@ -186,6 +186,3 @@ def extract_text_from_payload(payload: Any) -> str | None:
             return mapped_text
 
     return None
-
-
-__all__ = ["extract_text_from_payload"]

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/src/codex_a2a/client/request_context.py

@@ -39,6 +39,3 @@ def build_call_context(
     if not extra_headers:
         return None
     return ClientCallContext(state={"headers": dict(extra_headers)})
-
-
-__all__ = ["build_call_context", "build_default_headers", "split_request_metadata"]

{codex_a2a-0.7.1 → codex_a2a-0.7.3}/src/codex_a2a/config.py

@@ -330,7 +330,7 @@ class Settings(BaseSettings):
     a2a_enable_turn_control: bool = Field(default=True, alias="A2A_ENABLE_TURN_CONTROL")
     a2a_enable_review_control: bool = Field(default=False, alias="A2A_ENABLE_REVIEW_CONTROL")
     a2a_enable_exec_control: bool = Field(default=False, alias="A2A_ENABLE_EXEC_CONTROL")
-    a2a_log_level: str = Field(default="INFO", alias="A2A_LOG_LEVEL")
+    a2a_log_level: str = Field(default="WARNING", alias="A2A_LOG_LEVEL")
     a2a_log_payloads: bool = Field(default=False, alias="A2A_LOG_PAYLOADS")
     a2a_log_body_limit: int = Field(default=0, alias="A2A_LOG_BODY_LIMIT")
     a2a_documentation_url: str | None = Field(default=None, alias="A2A_DOCUMENTATION_URL")