Skip to content

Restore atomic multi-edit admission to the v19 public API #871

Description

@flyingrobots

Classification

Public API regression in v19. The underlying patch engine still supports atomic multi-edit commits, but the supported application boundary no longer exposes that capability.

Problem

v18.2.1 exposed WarpWorldline.commit(build). One callback could add multiple nodes, edges, and properties to one PatchBuilder, then publish the resulting graph transformation as one patch.

v19.1.0 deliberately removed patch builders and graph-first runtime values from the supported package surface. That removal is sound, but no validated compound-intent replacement was provided:

  • Lane.write() accepts exactly one Intent;
  • the public Intent algebra contains single node, edge, and property edits plus the specialized entity.add birth shape;
  • entity.add can create one subject with multiple initial properties, but it cannot express several subjects or relationships among them;
  • arbitrary retained patches with multiple operations are rejected by public-intent hydration;
  • internal PatchBuilder and commitPatch() machinery still support multiple operations in one patch.

The substrate did not lose atomic graph patches. The public application port lost the ability to request one.

Evidence:

Consequence

A supported v19 consumer cannot atomically express transformations such as:

add node A
add node B
add edge A -> B
set initial properties on both

The consumer must currently issue several lane.write() calls. That produces several patches and receipts, creates crash-visible partial states, and changes one logical domain operation into several independently admitted causal operations.

This also prevents a generated domain intent from lawfully lowering to a composite graph transformation. For Think specifically, it blocks representation alternatives that need a capture occurrence and its discoverability relationship to become visible together. Consumers must not deep-import internal patch builders to recover the missing capability.

Required contract

Restore this invariant on the supported v19 application surface:

One validated application intent may lower to one or more ordered graph edits. A successful admission publishes all of those edits as exactly one patch and returns one receipt; refusal or failure publishes none of them.

The public noun and lowering mechanism require design. A compound intent, generated intent-lowering profile, or another validated application-owned abstraction may satisfy the contract. The solution must preserve the v19 boundary rather than reviving the graph-first facade.

Acceptance

  • A packed public consumer can express one application intent that lowers to at least two node births and one edge birth without a deep import.
  • Successful admission produces exactly one patch, one writer-ref advancement, one admission outcome, and one WriteReceipt.
  • Full close/reopen recovery reproduces the complete transformation and its receipt-bound evidence.
  • A validation or lowering failure in any constituent edit publishes no patch and advances no writer ref.
  • Worldline and Strand lanes preserve the same atomicity contract.
  • Descriptor encoding, canonical ordering, retry identity, and retained hydration are deterministic.
  • Cardinality and encoded-size limits are explicit and fail before publication.
  • Generated SDK intents can use the same lowering boundary without exposing Git or PatchBuilder nouns.
  • Receipt semantics explicitly account for zero, one, or multiple entity births without conflating graph subjects and causal occurrences.
  • Tests prove that sequential lane.write() calls and a multi-patch convenience API are not accepted substitutes for one atomic admission.

Non-goals

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:apiPrimary work area: api.priority:asapImmediate release pressure.status:activeSomeone is actively working this issue.type:bugDefect or incorrect behavior.

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions