test(vectors): wire waived async pipeline contracts through real async pipelines

[sethjuarez]

Context

Typra 0.13.0's @vector harness is async-capable: it awaits awaitable adapter
results and enforces the sync/async contract (a sync-declared vector that
returns a future is a violation). Several pipeline-stage contracts
(render / parse / toRequest / process / replay) are currently wired through
sync stand-ins in some runtimes rather than the runtime's real async
pipeline, so the async path isn't exercised end-to-end everywhere.

This is a Prompty-side wiring task (not upstream-blocked): the harness already
supports async; we need to route the waived/sync-standin stages through the
actual async pipeline in each runtime that has one.

Scope

• For each runtime with a real async pipeline, wire render/parse/toRequest/
  process/replay adapters to the async implementation instead of a sync
  stand-in.
• Keep honest waivers only where a stage genuinely does not exist in that
  runtime.
• Confirm the harness exercises the async path (await + sync-violation
  enforcement) for those stages.

Done when

• Async pipeline stages are driven by the real async implementations across
  runtimes that have them, with waivers only for genuinely-absent layers.
• Conformance green; no sync stand-ins masking async behavior.

Not blocked

Async support is present in the pinned emitter (0.13.0).

[sethjuarez]

Note — the emitter side is available: @typra/emitter made @vector conformance harnesses async-capable across targets (typra#257, shipped in 0.13.0; we are on 1.0.1). This is a Prompty-side wiring task, not upstream-blocked.

Current state on main: Python (runtime/python/prompty/tests/model/vector_adapters.py) and TypeScript (runtime/typescript/packages/core/tests/model/vector-adapters.ts) adapters are genuinely async (await render/parse, for await). Swift still registers sync: stand-ins in VectorAdapters.swift. Remaining work: replace the sync stand-ins with real async adapters so no stand-in masks async behavior.

[sethjuarez]

Re-verification against main — the Swift sync: adapters are honest, not stand-ins; #488(Swift) is entangled with #487

Checked the current model harness VectorAdapters (runtime/swift/prompty-model/Tests/PromptyModelTests/VectorAdapters.swift) against the premise here.

What the code actually does today

Stage registration:

• sync: — renderSegments, render, parse, process, toRequest (wire), load, replay, processStream, plus discovery.enrich/mapModel
• asynchronous: — run, runTurn
• waivers() == [:]

The sync: adapters wrap genuinely-synchronous model reference engines — JinjaSubset.renderSegments, the model render/parseMessages, processResponse, buildWireRequest, loadPromptyFile, and reconcileStream/classifyStreamEvents. These are honest sync operations, not async stand-ins presented as sync. So the premise "Swift still uses sync: stand-ins" does not hold against current code — there is nothing to "unwrap" into async in the model package.

Why #488(Swift) can't land independently

Making these stages genuinely async for Swift requires driving the SDK's async pipeline (Pipeline.render/parse, provider process/processStream, ReferenceTurnRunner). That means relocating the @vector harness into the SDK package — which is exactly #487, and shares #487's run/runTurn blocker (the run/runTurn vectors assert a rich projection produced only by the model-level AgentLoopEngine, which the SDK production turn() loop does not expose — see #487 for the full evidence).

Rewriting the model reference engines themselves to be async would be pointless — they are synchronous reference implementations by design, and the async harness form accepts sync adapters without failure.

Python / TS

Python and TS are already real-async because their SDK pipelines are async and their harnesses already run against those SDK entry points. The async harness capability (typra #257) is present and those two runtimes already satisfy this issue.

Net

• test(vectors): wire waived async pipeline contracts through real async pipelines #488(Python) and test(vectors): wire waived async pipeline contracts through real async pipelines #488(TS): satisfied.
• test(vectors): wire waived async pipeline contracts through real async pipelines #488(Swift): entangled with test(swift): reach provider-stage @vector coverage once typra#261 supports split-package harness #487 and blocked on the same maintainer design decision. No independent Swift change lands it without either test(swift): reach provider-stage @vector coverage once typra#261 supports split-package harness #487's harness relocation (blocked on run/runTurn observability) or a no-op rewrite of the reference engines.

Recommend tracking the Swift portion under the #487 decision. No code change made here.

[sethjuarez]

Follow-up: same typra-vs-Prompty split applies here

Refining the earlier comment: the Swift portion of this issue is gated on #487's harness relocation, and #487 in turn is not cleanly unblocked by typra.

Key point (full detail on #487): typra#261 shipped the harness-test-dir option as whole-harness relocation, not a split-package harness — so provider stages can't be moved to the SDK independently of the engine stages (run/runTurn/replay). And the load-bearing blocker — the run/runTurn vectors asserting a rich projection that only the model-level AgentLoopEngine produces, while the SDK production turn() exposes only result — is a Prompty design decision, not a typra capability gap.

So for #488(Swift): no typra change completes it. It resolves only via the Prompty-side decision on #487 (extend the SDK loop's observability, or accept the model-package harness as canonical). #488(Python) and #488(TS) remain satisfied.

[sethjuarez]

typra tracking issue for the emitter capability: sethjuarez/typra#271 (per-stage / partial Vector Media Group (@vector) harness placement). Swift portion is gated on this plus the Prompty-side decision on #487.

[sethjuarez]

Closed by #501 (merged), which implements Option A for this issue: the Swift SDK's runTurn (turn) vectors are now driven through the SDK's async harness with zero waivers, asserting the full snapshot/portability projection against the shared PromptyModel.TurnEngine (the same engine Python's core.turn_engine and TS's core/turn-engine drive). Turn semantics untouched. All Swift + cross-runtime conformance green; shared vectors byte-unchanged.