I’m giving Potbot a signed trail of its tool work. Each run records the input it received, its source and policy revisions, the child work it started and the result it retained. That gives me something concrete to inspect when a workflow stops halfway through.
This follows the checked tool contracts. Those define what can pass between operations. This step follows a particular operation and its history.
The new core uses SYN Cogs for seventeen kinds of work, with separate Cogs to seal and inspect a receipt. Every admitted operation has a distinct run identity and records its start, actual progress and completion in Potbot’s existing work ledger. Child runs point to their direct cause. Private input and output files are checked against the hashes attached to the record.
The test creates 18 linked runs. A Python command and an MCP tool really execute in separate subprocesses. Agent, model, browser and other work kinds use scripted host handlers in this fixture, so their registration is exercised without implying a live provider or device connection.
A signing step binds the complete retained trace to a small immutable manifest. Later inspection checks its signature, original input and policy, then returns bounded pages of recorded events. The test’s counter for the original handlers stayed at 16 before and after that inspection: reading the history did not repeat them. Outcome verification is kept separately and remains “not assessed”.
The fixture also compares a small Python workload with cProfile off and on. Both produce the same result hash, and the record keeps their measured durations. That is one sample with unestimated timing noise, rather than a stable performance benchmark. Target memory, GPU use and cost stay marked unavailable where no measurement exists.
Windows temporary files needed a permanent fix along the way. This Python build gives directories created with mode 0700 a protected access list. In the restricted process, that dropped the inherited access needed to use the directory. A direct comparison reproduced the failure; preserving the selected parent’s existing permissions allowed the file to be created, read and deleted.
Tests, workers, benchmarks, build scripts and native startup launchers now use a shared scratch-storage policy. It checks access before writing a payload, handles bounded transient locks and reports a retained path if cleanup is genuinely blocked. Child processes receive a usable temp root, compact names leave room for nested Windows paths, and atomic-file allocation fails immediately on an access denial. The Windows regression covers Unicode and binary files, nested output, a child process reopening a closed file and read-only-file cleanup. Native vault custody keeps its own private access rules.
The code checks changed inputs, revoked admission, foreign workspaces, incomplete traces and expired page cursors. A write with an uncertain result is recorded as indeterminate and fences further dispatch through that runtime. The recorded history remains available for reconciliation.
This is the shared core of the next implementation stage. Adopting it in every existing producer, general artifact range transport and independently testing remote hardware still have their own gates. The 0.5.0.dev6 source preview, provenance guide and Windows scratch-storage notes include the implementation and its limits.
Leave a Reply