[Product Gap] Publish a stable BAP/MCP runtime API with resumable task lifecycle

[seonghobae]

Buyer-visible gap

OriginWeave has protected-main authority kernels and active pull-request evidence for bounded WebDriver BiDi, MCP routing, semantic observation, task execution, and post-condition proofs. A buyer still cannot integrate an external Agent platform through one stable, authenticated, versioned runtime contract.

Current active work such as #168 and #170 is intentionally narrower than a complete MCP server: it validates typed tool routing and discovery metadata but does not yet provide the full transport, identity, task, browser-state, cancellation, retry, persistence, or interoperability boundary.

This issue owns the first supported external runtime surface:

Browser Agent Protocol (BAP) 1.0 as the internal product contract, with MCP 2026-07-28, WebDriver BiDi, CDP, and future WebMCP implemented only as versioned adapters.

Product boundary

No external protocol identifier becomes durable OriginWeave authority.

External orchestrator
→ authenticated BAP/MCP request
→ OriginWeave task/session/context handle
→ typed observe/query/action/extract operation
→ deterministic policy and approval
→ trusted browser adapter
→ verified result/evidence

• BAP owns stable task, browser-session, browsing-context, document-epoch, node, artifact, approval, and evidence identifiers.
• WebDriver BiDi and CDP remain browser adapters; raw protocol IDs must be translated through a session-scoped registry.
• MCP remains a high-level Agent adapter. A model or MCP client must never connect directly to Chromium, CDP, WebDriver, the secret broker, or persistence authority.
• WebMCP remains optional and untrusted when present. It may provide structured site tools but cannot mint capabilities, alter the trusted goal, approve actions, or disclose secrets.
• A returned command receipt is not task success; success requires the exact declared post-condition and evidence contract.

Required BAP 1.0 operations

Provide a versioned OpenAPI/JSON Schema/AsyncAPI contract and Rust, TypeScript, and Python SDKs for at least:

create_task
get_task
cancel_task
resume_task
close_task

create_browser_session
checkpoint_browser_session
close_browser_session

navigate
observe
query_nodes
act
extract
capture_evidence

request_approval
resolve_approval

get_artifact
verify_artifact

The first public action vocabulary remains bounded and typed. Unrestricted JavaScript, arbitrary CDP commands, raw selector execution, shell commands, and ambient filesystem/network access are not normal BAP operations.

Task lifecycle

Implement a durable state machine with explicit terminal and recoverable outcomes.

created
→ admitted
→ running
→ waiting_for_approval | waiting_for_external_input | checkpointed
→ running
→ succeeded | failed | cancelled | expired

• Every mutating command requires an idempotency key and returns a durable receipt.
• Retries may repeat a command receipt but must not repeat an externally visible side effect.
• Cancellation must propagate through browser I/O, model/orchestrator work, queues, storage, and pending approvals under bounded deadlines.
• Resume must require a compatible checkpoint, exact software/protocol policy, task identity, and freshness. Stale node handles or expired grants are never revived.
• Crash recovery must distinguish unknown outcome, confirmed no side effect, confirmed side effect, and reconciliation required.
• Dead-letter and manual-reconciliation states must preserve complete evidence without silently reporting success.
• Task history is append-only; corrections and supersession create new records.

MCP 2026-07-28 adapter

The MCP adapter must follow the current stateless protocol core while keeping durable task/browser state inside OriginWeave handles.

• Validate the exact supported MCP protocol generation on every request.
• Validate routing metadata and body method/name agreement before dispatch.
• Expose tools/list from the reviewed OriginWeave tool catalog; do not generate tools from arbitrary browser/CDP capabilities.
• Expose tools/call only for reviewed typed BAP operations.
• Use modern Tasks only as a transport-level projection of OriginWeave task state; OriginWeave remains the lifecycle authority.
• Keep cache disposition, freshness, visibility, pagination, and cursor issuance explicit.
• Fail closed on unsupported generations, missing required metadata, route/body mismatch, unissued cursors, replay, malformed JSON-RPC, excessive batch/field/document size, or unknown tool names.
• Apply the MCP deprecation policy through adapter-version negotiation without silently changing BAP semantics.

Authentication and authorization

• Support local Unix-domain/loopback deployment and remote authenticated deployment as separate profiles.
• Remote deployments require Keyverse-compatible OIDC/OAuth, issuer and audience validation, PKCE where applicable, explicit resource binding, short-lived tokens, and workload identity for service-to-service use.
• Prohibit token pass-through to downstream systems.
• Bind actor, workload, tenant, device/session, task, purpose, requested operation, origin scope, data classification, and approval state to each decision.
• Use narrow service credentials and authenticated transport; do not use one shared static token across tenants or services.
• A valid MCP/BAP credential grants access only to explicitly assigned OriginWeave capabilities, never ambient browser authority.

Contextual Orchestrator integration

Provide an adapter for ContextualWisdomLab/contextual-orchestrator that:

• uses automatic model discovery and approved providers through the orchestrator rather than embedding provider credentials in OriginWeave;
• distinguishes low-cost observation/extraction, high-reasoning planning, verifier, and safety-policy roles;
• supports single-model and multi-agent execution without changing browser authority;
• records provider/model/prompt/reasoning/workflow metadata without logging protected values;
• propagates task cancellation, deadlines, token/cost budgets, and structured failures;
• fails closed when provider, model, region, retention, or sensitive-data policy is incompatible; and
• keeps deterministic browser policy outside model judgement.

Persistence and data model

Every database object must contain at least two words and use snake_case. Suggested objects:

agent_task
agent_task_event
task_checkpoint
task_command
task_receipt
task_reconciliation
browser_session
browsing_context
document_epoch
node_handle_record
approval_request
approval_decision
artifact_reference
protocol_adapter
protocol_session_binding
idempotency_record
outbox_event
inbox_event
dead_letter_record

Use 3NF for lifecycle, authority, idempotency, approval, and protocol mapping. Do not make opaque external protocol payloads the sole source of product state.

Realistic tests

Acceptance must include local and authenticated remote profiles.

1. Create a task, open an isolated Chromium session, navigate, observe, query, act, verify the post-condition, capture evidence, and close cleanly through BAP.
2. Execute the same workflow through MCP 2026-07-28 without exposing CDP/BiDi identifiers.
3. Repeat every mutating request at least 100 times with the same idempotency key and prove no duplicate action.
4. Cancel before dispatch, during navigation, during model work, while awaiting approval, and after an external side effect; preserve the exact outcome classification.
5. Crash and resume from a valid checkpoint; reject incompatible software/policy/protocol, expired approval, stale document epoch, and cross-task checkpoint reuse.
6. Reject wrong issuer, audience, tenant, task, device, origin, capability, tool, method, route/body pair, cursor, token binding, and replay.
7. Prove token pass-through never occurs and protected values never appear in logs, traces, errors, metrics, task history, or model-visible protocol metadata.
8. Prove backpressure, queue saturation, deadline expiry, dead-letter, and reconciliation behavior.
9. Run provider outage/fallback cases through contextual-orchestrator without weakening sensitive-data or browser policy.
10. Require exact 100% OriginWeave-owned production function, line, region, and branch coverage, complete public rustdoc, contract-test parity across Rust/TypeScript/Python SDKs, and no skipped required integration test.

Documentation and versioning

• Add an accepted ADR defining BAP authority, MCP projection, browser adapter mapping, task lifecycle, authentication, compatibility, migration, and reversal.
• Publish OpenAPI, AsyncAPI, JSON Schema, generated SDKs, conformance fixtures, compatibility tables, and protocol-version support/deprecation policy.
• Add sequence diagrams for synchronous tool call, durable task, approval wait/resume, cancellation, crash recovery, and contextual-orchestrator execution.
• Update PRD, TRD, ARCHITECTURE, API contract, THREAT_MODEL, TEST_STRATEGY, OPERABILITY, RELEASE_AND_ROLLBACK, ERD/UML, traceability, roadmap, README, AGENTS.md, CLAUDE.md, and CHANGELOG only as implementation becomes protected-main truth.

Dependencies and non-goals

Dependencies:

• [Product Gap] Complete the first real Chromium agent vertical slice #28 supplies the complete live Chromium execution chain;
• [Enterprise Gap] Preserve operational PII through policy-bound disclosure instead of blanket masking #10 supplies protected-data/model disclosure boundaries;
• [Product Gap] Deliver schema-bound extraction with durable WARC/PROV replay #199 supplies durable artifact and provenance references for replayable results.

Active pull requests #168 and #170 are valid implementation inputs but are not shipped truth until integrated normally.

Out of scope:

• exposing arbitrary Chromium/CDP or shell execution;
• allowing MCP/WebMCP content to grant authority;
• using protocol session metadata as browser state authority;
• embedding provider credentials in clients;
• claiming universal compatibility with every MCP client without conformance evidence.

Commercial proof

Two independent Agent/orchestration clients can execute and resume the same governed browser workflow through the stable BAP/MCP surface, with identical authorization and evidence semantics, no duplicate side effects, no ambient browser authority, and no dependency on raw Chromium protocol identifiers.

Standards and primary references — APA 7th

Model Context Protocol. (2026). Model Context Protocol specification (2026-07-28). https://modelcontextprotocol.io/specification/2026-07-28

Soria Parra, D., & Delimarsky, D. (2026, July 28). The 2026-07-28 specification. Model Context Protocol. https://blog.modelcontextprotocol.io/posts/2026-07-28/

World Wide Web Consortium. (2026, June 29). WebDriver BiDi (W3C Working Draft). https://www.w3.org/TR/webdriver-bidi/

Hardt, D. (2012). The OAuth 2.0 authorization framework (RFC 6749). Internet Engineering Task Force. https://doi.org/10.17487/RFC6749

Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2020). OAuth 2.0 security best current practice (RFC 9700). Internet Engineering Task Force. https://doi.org/10.17487/RFC9700

Campbell, B., Bradley, J., Sakimura, N., & Lodderstedt, T. (2018). OAuth 2.0 mutual-TLS client authentication and certificate-bound access tokens (RFC 8705). Internet Engineering Task Force. https://doi.org/10.17487/RFC8705