Operation requests

The problem this solves. An agent working for you often reaches an operation it is not allowed to perform — removing a Space the repo owns, rewriting nodes across a partition, asking a NodeType to recompile — because on a system-synced Space no human or agent identity holds Delete, by design. Until 2026-09-04 the agent's only honest answer was a list of GUI links, one per node, one per instance. The maintainer's verdict on that: "I should get a screen with your request where I can approve and then it executes."

An Essentials/OperationRequest node is that screen.

How it works

  1. Propose. The agent (or you) creates a request node anywhere it may write — its own home is the natural place — with a title, the reason, and the operation as a C# script written against the fluent Plan DSL below. Filing needs no rights beyond writing the node.
  2. Preview. A global admin presses Preview. The platform prepends the DSL to the script and runs it on the mesh kernel in preview mode: every DSL call records a step, each target is probed (does it exist? what type? how many nodes below it?), and the plan comes back onto the request as a table. Nothing is executed.
  3. Read the script. The table shows what the DSL recorded. A script is general C#, so it may do more than the DSL lists — which is why the script itself is on the page, and why preview is admin-gated too (it runs the code).
  4. Approve. The same admin presses Approve & run as System. The platform refuses if the script changed since the preview (its hash is on the request), then runs the same script in execute mode as System — the identity that owns synced Spaces — strictly in order, fail-fast, one log line per step. The outcome lands on the request; the full kernel log is the activity under it.
  5. Reject at any time; a rejected request keeps its history.

Who pressed what is never a field anyone types: the control plane reads the framework-stamped author of the write that set the action (lastModifiedBy), and refuses a blank one outright.

The DSL

The script sees one object, Plan, and chains what it wants. Every call records; nothing runs until the plan completes at the end of the script (the platform appends that line).

Plan.Because("UWDeepfield and ClaimsDeepfield are retired legacy modules (#159)")
    .Space("UWDeepfield").Delete()
    .Space("ClaimsDeepfield").Delete();
Call Records
Plan.Because(reason) why — shown first on the page
Plan.Note(text) a line of explanation between steps; never executed
Plan.Space(id).Delete() two steps: the Space's _GitSync source first (so no later sync re-imports it), then the Space root, recursively — absent parts are no-ops, so a re-run heals a half-removed Space
Plan.Node(path).Read() reads the node; the safest first step in any plan
Plan.Node(path).Delete() deletes the node and its subtree
Plan.Node(path).Update(n => n with { … }) rewrites the node through a record with; content included (n.ContentAs<T>(…) to type it)
Plan.Node(path).Create(nodeType, content, name) creates the node; an existing one is left as is
Plan.Query(query).Read() / .Delete() / .Update(…) the same over every match of an anchored mesh query (namespace:X scope:descendants nodeType:Y) — the store refuses one that names no partition
Plan.NodeType(path).Recompile() flips the type's compilationStatus to Pending; the framework rebuilds it
Plan.Do(kind, target, effect, run, probe?) anything the verbs above do not cover — still recorded. run executes only in execute mode; probe is read-only and renders in preview. A step with no run is refused when it is written.

Because the script is C#, the fluent APIs of the records themselves compose with it: a .Update(n => n with { Content = (n.ContentAs<Workbench>(opts)) with { Partitions = ["Acme"] } }) is an ordinary record expression.

🚨 Everything that changes the mesh goes through the DSL — and since Do exists, everything can. A raw Mesh call in the script still runs in both modes, but it is INVISIBLE to preview: it does not probe, it does not appear in the plan table, and the approver approves a list that does not mention it. That was the one hole in the promise "you approve the steps that will run", and it was open only because an unforeseen operation had nowhere else to go. It now does:

Plan.Because("retire the anonymous grant on Edu")
    .Do("revoke", "Edu/_Access/Anonymous", "removes the anonymous viewer grant",
        run:   ct => Plan.DeleteAt("Edu/_Access/Anonymous", ct),
        probe: async ct => OperationPlan.Describe(await Plan.Find("Edu/_Access/Anonymous", ct)));

An unforeseen operation should cost a step in the table, never a step outside it.

Where the pieces live

When a request looks inert

A request that keeps its pending action and never previews is not a request the API could not file — filing one through the API and watching it preview and run takes under a second, measured. It is a request whose watcher stopped, and why that could happen, what the control plane now guarantees, and the one gap still open is written up beside this page.

Why both buttons need a global admin

A preview runs the script. The DSL records instead of executing in preview mode, but the script is not confined to the DSL — a line of raw Mesh code runs in both modes. So the gate is on running code at all, and it is the same gate Store/Publishing's SystemRemoval puts in front of System impersonation: SystemAuthorization.Authorize, fail-closed (a probe that answers nothing is a no). The request's own page tells the approver exactly that.

The first use

The Deepfield retirement of 2026-09-04 (MeshWeaver.Reinsurance#159): two Spaces on memex, then twenty-two reinsurance and education Spaces on systemorph — twenty-four removals that were twenty-four links before this existed, and are two requests now.

Reconnecting…
The server was updated. Reloading the page to pick up the latest version.