CreateOrUpdateNodeRequest cannot express a counter increment, so the one verb with owner-side existence and the ghost-hydration repair is unavailable to the callers that need it (blocks #1174) #4928

The gap

CreateOrUpdateNodeRequest is the platform's single global upsert verb — the one write path that establishes existence from a persistence read rather than the eventually-consistent query index (MeshExtensions.cs:5851-5868, trail stages UPSERT_READ absent → create / UPSERT_READ existing → update), and the one that carries the durable-truth version floor repairing "a hub that could not hydrate the stored node and started from a blank MeshNode.FromPath" (~6270, the AdoptDurableTruth rebase, #902/#638).

It cannot express a counter increment, so the callers that most need those two properties cannot use it.

Why neither payload mode works

Full-instance mode merges through UpdateAccordingToSourceNode, which takes content wholesale:

Content = sourceNode.Content ?? state.Content,

The source's Content was computed by the caller from a read that is stale by construction. Any count + 1 in it is the old count plus one.

Patch mode is documented for exactly this use case — the record's own summary says:

"Used for incremental edits where multiple writers may race on the same node — log lines, view-count bumps, status-flip patterns."

But JSON Patch has no increment operation. replace /content/accessCount <value> still requires the caller to know the current value, which is the stale read again. The documented use case is not served by either mode.

There is no third route: MeshNodeStreamHandle has three Update overloads (MeshNodeStreamExtensions.cs:1246, 1268, 1355) and none takes a create-if-missing seed, so a caller cannot get owner-side folding and create-on-absent from the stream API either.

🚨 Why this is a design call and not a patch

The obvious fix — hand the upsert the same Func<MeshNode, MeshNode> merge lambda that stream.Update takes — is not available. CreateOrUpdateNodeRequest is an IRequest<CreateOrUpdateNodeResponse> routed to the owning hub; a delegate cannot cross the wire. That is why Patch is typed object? with "the patch type owned by the caller's package … handlers cast on receipt".

So the fold has to be expressed declaratively. Roughly the options:

1. An increment/numeric-delta operation in the patch payload (a JSON-Patch extension, or a small typed sibling of it) applied owner-side inside the existing .Update(live => …) lambda at MeshExtensions.cs:~6295.
2. A typed UpsertFold descriptor on the request naming field paths and a combine rule (sum, max, min, first-write-wins).
3. A registered server-side merge strategy keyed by NodeType, so UserActivity declares its own fold once.

All three are additive. I have not picked one — the choice is a wire-contract decision.

Who is blocked by it today

#1174 (A CreateNodeRequest addressed to the sending hub itself is never answered — 425 occurrences, MeshWeaver.Graph.ActivityTracking). Its failing branch is:

// MeshWeaver.Graph/MeshNodeExtensions.cs
286:  var stream = workspace.GetMeshNodeStream(activityPath);
320:  workspace.GetQuery($"UserActivity|{activityPath}", $"path:{activityPath} nodeType:UserActivity …")
379:  if (existing != null)
392:      return AsCaller(() => stream.Update(FoldOntoLive));   // ← 30 s BaseStateTimeoutException

It decides create-vs-update from the query index — precisely the shape MeshExtensions.cs:3315 (#4668) says the upsert verb exists to retire:

"A client-side existence check is precisely the shape CreateOrUpdateNodeRequest exists to retire on the create side … The operation is where the race is decidable, because the owning hub serialises it."

It cannot move onto the verb because FoldOntoLive (:356, guarding #3001) re-reads AccessCount off the live node inside the owner-serialised lambda, and that is the thing neither upsert mode can carry.

Full source-level analysis: #1174 (comment)

Acceptance

• A counter bump can be issued as one CreateOrUpdateNodeRequest that (a) creates the node when absent, (b) folds the increment against the node as the owner holds it when present, and (c) is safe under concurrent writers without the caller reading first.
• MeshWeaver.Graph/MeshNodeExtensions.cs:379-392 no longer chooses its write from a query result.
• The CreateOrUpdateNodeRequest summary's "view-count bumps" claim becomes true, or is removed.

_{Filed 2026-09-19 by Claude Opus 5 from a source reading of current main — no production evidence required or claimed.}