Core documentation

24. Supersede server-initiated applyEdit with host-authorized applyProposal

Specification metadata
adr: 24
title: Supersede server-initiated applyEdit with host-authorized applyProposal
status: accepted
date: 2026-06-22

§Context

ADR 0013 accepted serialized apply with idempotency and included a server-initiated applyEdit path. Later host-boundary decisions made that branch unsafe: providers must not decide whether a gate passes, claim apply authority, or trigger workspace writes outside a host-owned apply transaction.

ADR 0012 requires explicit user or agent initiation, ADR 0019 treats authorized host/applyProposal intent as sufficient for host writes, and ADR 0022 requires the conforming host to coordinate providers without Lattice-specific or provider-specific fast paths.

§Decision

ASP removes server-initiated applyEdit from the conforming write path. The only conforming write-attempt surface is an authorized harness, user, or agent request to the host-owned host/applyProposal operation.

Servers can still produce edit plans and upload proposal blobs through host-scoped callbacks. They cannot initiate apply, schedule background writes, or convert an edit plan into gate authority. The host validates the hypothetical changeset, serializes the workspace transaction, reports assurance mode and transaction guarantee, and applies or stages only if the host decision permits it.

This ADR supersedes only the server-initiated applyEdit branch of ADR 0013. ADR 0013’s per-workspace serialization, deterministic conflict handling, and (server, proposalId) idempotency semantics remain accepted for provider-originated edit plans. The host issues proposalId values and derives server from the authenticated provider session.

§Consequences