A Merry-Compiled Room Reaction Executes Within the Sandbox Surface

Claim

In the eOS-Harness MVA running against DGD 1.7.9 plus the eOSContinuum/eOS-kernellib feature/cohesive-lift branch carrying the kernel-layer cohesive lift (Vault + Schema + XML + Index + Merry + property-change dispatcher), a Merry reaction script -- LPC-dialect source compiled at runtime into a sandbox object, bound on a chat-room object as a property, and invoked via run_merry -- executes within the Merry sandbox surface and mutates the binding object's property storage. The dispatch shape is: the boot-time test driver compiles Set($this, "chat-room.message-count", $count); via new_object("/usr/Merry/data/merry", source), binds the resulting script object on room_a under the reaction-property key merry:on:chat-room.message:main, posts a message through the chat daemon, and fires the reaction with run_merry(room_a, "chat-room.message:main", "on", ([ "count": count ])). Inside the script, $this resolves to the binding host (room_a), $count resolves to the passed argument, and the Set merryfun forwards to room_a->set_property("chat-room.message-count", count). The driver reads the marker property back and writes a SANDBOX-ACCEPT OK sentinel. The loaded code was authored as a string, compiled into the running runtime, bound on a live object, and executed against that object's storage -- with no container, no external policy engine, and no redeploy.

Grounds

This is an Empirical Observation. The grounds are a captured cold-boot smoke run 2026-05-30 against the live MVA demonstration instance with examples/chat-app/ (deployed from the eOSContinuum/eOS-kernellib examples/chat-app/) overlaid at the isolated runtime staging tree's src/usr/Chat/.

Setup (verifiable from repo state):

Load-bearing source (phase 3 of examples/chat-app/sys/test.c):

object accept_script;
int count;

accept_script = new_object(MERRY_DATA,
        "Set($this, \"chat-room.message-count\", $count);");
room_a->set_property("merry:on:chat-room.message:main", accept_script);

CHAT_DAEMON->post_message(bob, room_a, "first post");
count = sizeof(room_a->query_messages());

run_merry(room_a, "chat-room.message:main", "on", ([ "count": count ]));

if (room_a->query_raw_property("chat-room.message-count") != count) {
    log_line("ChatApp:test: FAIL: SANDBOX-ACCEPT marker property did not land");
    return;
}

MERRY_DATA is /usr/Merry/data/merry; new_object(MERRY_DATA, source) invokes the Merry compiler on the source string and returns a compiled script object. The test driver inherits /usr/Merry/lib/merryapi for the run_merry static surface. The cross-domain clone of ~Merry/data/merry and the cross-domain merryapi inherit ride the global-access grants set in src/usr/System/initd.c.

Smoke transcript (the load-bearing portion of the sentinel result log after the cold boot):

ChatApp:test: starting
ChatApp:test: CAP-REJECT OK
ChatApp:test: CAP-ACCEPT OK
ChatApp:test: SANDBOX-ACCEPT OK

SANDBOX-ACCEPT OK writes to the sentinel file only when:

  1. new_object(MERRY_DATA, source) returns a non-nil compiled script (the in-sandbox source parsed and compiled).
  2. run_merry(...) returns without throwing (the reaction fired; no sandbox shadow masked any kfun the source named).
  3. room_a->query_raw_property("chat-room.message-count") equals the passed count (the reaction's Set actually mutated the room's property storage).

All three are inside a catch{}; a throw at any point writes a distinct FAIL sentinel instead.

Process identity check: a single DGD process served the assertion in one boot. The boot log records no ** System halted. entry before phase 3 (the halt is from the later persistence phase). The runtime instance carrying the reaction execution is the same one initialized at ** Initialization complete..

What the evidence establishes:

What the evidence does not establish:

What Would Revise It

Sources

Relations