[Runtime adapter] Request for adapter checklist feedback

[wcqxgjy6d8-pixel]

Goal

VALP needs runtime authors and agent-workflow builders to criticize the adapter checklist before any runtime claims Full Mode compatibility.

Checklist:
https://github.com/wcqxgjy6d8-pixel/Visible-Agent-Loop-Protocol/blob/main/docs/adapter-checklist.md

Runtime adapter contract:
https://github.com/wcqxgjy6d8-pixel/Visible-Agent-Loop-Protocol/blob/main/docs/runtime-adapters.md

What feedback is useful

Pick one runtime, queue, hosted agent platform, terminal controller, or manual workflow and answer:

1. Can it export dispatch submission proof, or only insert text / enqueue work?
2. Can it map runtime states to VALP receipt states?
3. Can it write expected evidence refs and verify they exist before completion?
4. Can it expose provider matrix, preflight, context policy, failure reasons, and approval state?
5. Should it start as Full Mode, Remote Mode, Manual Mode, or not compatible yet?

Important boundary

A runtime saying completed is not enough. VALP compatibility depends on receipts plus expected evidence plus review/approval/final synthesis gates.

A useful reply can be short: runtime name, likely mode, strongest exported proof, biggest missing proof.

[wcqxgjy6d8-pixel]

Adapter feedback entry points are now wired into the repo and Pages:

• Checklist: https://github.com/wcqxgjy6d8-pixel/Visible-Agent-Loop-Protocol/blob/main/docs/adapter-checklist.md
• Runtime adapter contract: https://github.com/wcqxgjy6d8-pixel/Visible-Agent-Loop-Protocol/blob/main/docs/runtime-adapters.md
• Short explainer: https://wcqxgjy6d8-pixel.github.io/Visible-Agent-Loop-Protocol/when-agent-done-is-not-done

A concrete first issue is open for anyone who wants to test one runtime against the checklist:
#10

The useful reply format is still short: runtime name, likely mode, strongest exported proof, biggest missing proof.

[ofekron]

Maintainer disclosure: I build Better Agent, a local web workspace supervising native Claude, Codex, and Gemini sessions.

Adapter class: hosted/local platform
Likely mode today: not compatible yet; Full Mode candidate after an explicit receipt/evidence adapter
Strongest exported proof: backend-persisted parent/worker session IDs, provider-native session identity, normalized event history, approval decisions, tool/file events, terminal outcome, and restart recovery state
Biggest missing proof: a task-local chain from dispatch submission → expected evidence refs → verified completion

Against the checklist:

1. Submission proof: Better Agent persists the user message and run/session creation, but that currently proves the platform accepted the turn—not a VALP-shaped dispatch-submitted receipt bound to expected evidence.
2. State mapping: pending/streaming/completed/stopped/failed plus worker states can map to VALP states. A native provider’s complete event must remain only runtime completion until evidence gates pass.
3. Expected evidence: files and events are inspectable, but expected refs are not yet declared as an authoritative task contract and checked before completion.
4. Provider/preflight/approval: provider/model/session and approval state exist. A VALP adapter would still need a versioned capability snapshot, context-policy reference, explicit preflight result, and failure reason projection.
5. Recovery: live execution, frontend-disconnected execution, and backend restart recovery converge through the same persisted render/event state. That is useful replay evidence, but it does not by itself prove the requested artifact exists or is valid.

A minimal receipt ledger entry could bind:

• VALP task and dispatch IDs;
• Better Agent app-session, turn, worker, and provider-session IDs;
• dispatch payload digest and persisted-user-message acknowledgement;
• provider/model/capability snapshot;
• approval refs;
• ordered event-log range;
• expected evidence refs with owner and validation status;
• terminal runtime state;
• final gate result and failure reason.

Known failure modes to expose rather than flatten: provider accepted but no first event, worker completed without the requested artifact, restart recovered a run whose outcome is still uncertain, approval denied/expired, and evidence superseded by a later worker.

So I would start with a read-only adapter that exports one completed Better Agent run into VALP receipts, then run the smoke test. Claim Full Mode only after dispatch-submitted is identity-bound and dispatch-completed is emitted exclusively after the expected-evidence gate.

License note: Better Agent is source-available and free for non-commercial use; commercial use requires separate permission.