V3 — Dependencies, Toolchain Cost, and the SDK Proof

Why this exists. Sol's 03-decisions/sol-conflicts-and-corrections.md §5 lists three things neither author had verified. All three are now measured. This file is the evidence, written as a finding in docs/-equivalent territory — V3's dependency and cost posture is my lane (config/providers.json, fallback chain, cost policy per 05-operations/layer-ownership.md), so this is a report from my lane, not a patch to Sol's or Min's.

1. The SDK claim — CLOSED (positively)

From the installed environment:

a2a-sdk 1.2.2

TaskState.keys():
    TASK_STATE_UNSPECIFIED, TASK_STATE_SUBMITTED, TASK_STATE_WORKING,
    TASK_STATE_COMPLETED, TASK_STATE_FAILED, TASK_STATE_CANCELED,
    TASK_STATE_INPUT_REQUIRED, TASK_STATE_REJECTED, TASK_STATE_AUTH_REQUIRED

This confirms both V3 documents at once:

• canceled is the spec spelling — one L. Confirmed against the installed enum, value 5.
• input-required / auth-required are hyphenated, values 6 and 8.
• Min's states.yaml mapping in DESIGN-OF-RECORD.md §2.4 is correct against the reference implementation. The proposed mapping is not a guess.

Two facts about the SDK worth having before Phase 1

That second row is a genuine trap for Phase 4 and is not in either design document.

2. The dependency bill — what adopting the SDK actually costs

Measured in the provisioned venv, not estimated:

My assessment. Against the defect it prevents — a hand-rolled transport serving three non-spec state values — the dependency is cheap and the extras are correctly optional. Nothing here blocks adoption.

One caution, cost-adjacent. google-auth and cryptography are security-relevant transitive dependencies in a system that runs unattended. They should be pinned and auditable, not floating. Recommend uv.lock or a requirements.txt with hashes, committed into the V3 repo. V2's spec/ was untracked and one git clean from gone — see §3.

3. spec/ — the reference implementation is one command from deleted

Sy answering Sol's "copied or referenced?" question from the money side:

Recommendation — reference it, tracked, as a submodule. Sol's answer is correct and I agree with his reasoning; the size figures support it. An 18 MB commit inside a new repo is the wrong fix, and an untracked copy is the defect we already have. A submodule pins a revision, so "which SDK did we build against?" is answerable.

4. The Inspector — the high-value, not-yet-cheap piece

Sol's §5 is right that it has never run here. I went further and measured what standing it up actually requires:

Correction to my own earlier claim — recorded, not quietly edited

My first draft of this table asserted that the backend could run headless "without the UI." That was inference, not measurement, and it was wrong. I tried to import it:

cd /home/lab/solos2/spec/insp/backend && python -c "import app"
ModuleNotFoundError: No module named 'bleach'

So the Inspector's backend is not a drop-in CLI probe. Its own dependency list (bleach, jwcrypto, pyjwt, python-socketio, uvicorn, jinja2, sse-starlette, validators, plus a2a-sdk[all]) is unmet on this host, and the .venv that exists beside it is incomplete. There is no cheap path to "just the conformance check" — running the Inspector means satisfying its whole backend, and its frontend needs bun on top of that.

This is a real cost and it is not in either design document. The Inspector is described in both DESIGN-OF-RECORD.md §2.6 and A2A-ADOPTION-2026-10-10.md as "the gate" — and in Phase 1.3 as the proof. Before it can be a proof, it has to run once.

Recommendation. Budget an explicit setup task for the Inspector — install bun and a2a-sdk[all], or vendor the exact checks we want as our own pytest conformance tests and call those the gate. Do not carry an acceptance criterion that depends on a tool that has never executed here, and do not assume the backend is a usable shortcut — I assumed that and was wrong.

5. The A2A CLI — cannot be built here

So a2a-cli is not usable on this host without installing Go. It is named in the design as the "operate with it" tool — it is a nice-to-have, not a blocker. The Inspector is the load-bearing one.

6. Port placement — agreeing with Sol, with a cost reason

Sol recommends different port numbers for V3 so the "run both" proof in D4 is runnable. Agreed, plus a reason from my lane: same-ports migration means any cost sampling during the change is unattributable — you cannot tell V2's spend from V3's. A clean, different block also makes the cost baseline measurable, which is what I need in order to tell Young what V3 actually costs to run.

7. Summary — what this closes, and what it opens

Closed (measured, previously "not established"):

• a2a-sdk 1.2.2 installs and imports on this host.
• The spec state spellings are confirmed against the installed enum.
• The dependency bill is known and small.
• The CLI needs Go; the Inspector needs bun — both currently absent.
• Corrected: the Inspector's backend is not a headless shortcut — it fails to import (No module named 'bleach'). My first draft said it was; that was inference, and the correction is in §4.

Opened:

1. Phase 4 has a hidden trap — the SDK's JSON form and enum form of a task state are different strings. states.yaml must record both. (New; neither doc has it.)
2. The Inspector must be budgeted as a setup task, not assumed present.
3. Pinning policy needed — google-auth and cryptography should be locked and auditable, not floating.
4. Phase 1.3's acceptance criterion needs a substitute. "The Inspector passes" is currently un-runnable here. Either stand it up properly or write our own conformance tests and name them as the gate.