Composability, proven elsewhere
Part III — The Paradigm · Chapter 8 of 9
The last two chapters described machinery I arrived at the hard way — evidence taxonomies forced by a calendar bug, frozen snapshots forced by mid-turn edits, capability contracts forced by not trusting prose. Then, in August 2026, a preprint derived the same laws from a completely different direction — plugin ecosystems and type theory — and gave them names.
This chapter states the paper's laws, maps them one-to-one onto Bonnie, and marks the exact place an ambient system has to go further than the paper does.
The paper
A Programming Paradigm for Spatiotemporal Composability (Yifan Shi, Wei Zhang, Tianyi Cui — Peking University and DeepSeek-AI; a preprint dated August 13, 2026, under active revision; repo) starts from the observation that modern software — "from plugin systems to self-evolving agent harnesses" — needs dynamic composition, and that its formal foundations are underdeveloped. It identifies two orthogonal dimensions:
- Temporal composability — "the ability to completely revert a component's side effects upon removal." Mechanism: revertible effects. Every tracked change carries an explicit inverse; unloading replays the inverses in reverse order. Track, and recover.
- Spatial composability — the ability of components to "declare, discover, and resolve their dependencies… in a structured and verifiable manner." Mechanism: reactive coeffects. A component declares what it requires; every change of context notifies it as activating, deactivating, or neutral; a component whose dependency is missing "stays inactive until it appears, without erroring."
The critiques are concrete. Of VSCode's top hundred extensions, the authors count eighty-seven that need a full host restart to remove, because deactivate is a shutdown callback, not an inverse. Self-evolving agent harnesses compose tools, sandboxes, session state, and subagents — where "a faulty self-modification can disable the very process needed to recover." And the diagnosis is a single granularity argument: operating systems revert at the granularity of a process, orchestrators declare-and-discover at the granularity of a service, and everything composed finer than that is handled by restarts that discard accumulated state.
The paper's answer is to lift effect and coeffect systems — classically compile-time analyses — into runtime mechanisms, validated on Cordis, the framework under the Koishi ecosystem and its four-thousand-plus community plugins.
The mapping
The claim of this chapter, stated flat: every law in the paper already had a working implementation in Bonnie — and in every case, Bonnie's version exists to protect the person at the desk. The paper derived these laws from plugins. Bonnie derived them from human-computer interaction.
| The paper's law | Bonnie's mechanism | What the person gets |
|---|---|---|
| Reactive coeffects — unmet dependency means inactive, "without erroring" | Signals revalidate at every turn freeze; effectful Skills exist only while a compatible adapter is installed and ready | Unplug the calendar and nothing errors — the Ability sleeps and wakes when it returns. Eyes are an upgrade, never a precondition. |
| Epochs — execution never straddles two configurations | The frozen per-turn AbilityRuntimeSnapshot; a Studio edit activates a new registry for the next turn | You can edit the system while it runs and never race it — changes land next turn, never mid-flight. |
| Revertible effects — every tracked change carries its inverse | "access": "reversible" in Capability contracts; revert_last_edit; receipts and edit reports | Every edit leaves a receipt and a way back — and a touch of the mouse cancels the run, with focus never reclaimed. |
| The system boundary — where reversibility ends; a coeffect moves it by reifying an external location | Confirmation gates on destructive and external-communication effects; verified activation; the staged writing surface | Nothing irreversible happens without asking you first — and Bonnie proves what is actually on your screen before acting on it. |
| The granularity mismatch — per-process temporal, per-service spatial, nothing between | Ability-grain composition across Bonnie, Seer, and Totem on one wire contract | The composition doesn't stop at a process or a service. It reaches your desk: the frontmost app, the live selection, you. |
Three rows earn a sentence more.
Coeffects is the row that made me sit up. Bonnie's prompt-assembly rule — signals "disappear when their schema or Value version is gone or their publishing adapter is unavailable" — is reactive coeffect semantics, discovered under deadline instead of derived formally. The calendar bug of chapter 6 was a coeffect failure: a requirement with no declared shape, so its evidence deactivated silently instead of visibly.
Epochs: the paper aborts and rolls back when a dependency changes mid-flight. Bonnie freezes the world per turn so the race cannot arise. Different mechanism, same invariant — and in Bonnie the invariant is an HCI promise: the person may touch anything at any moment, so the machine must never be caught straddling two configurations when they do.
The boundary is where the paper is most honest and Bonnie is most opinionated. A sent email is not revertible, and pretending otherwise is worse than admitting it. The paper's escape hatch — reify an external location to move the boundary — is what Bonnie does by hand: prove the activation, stage the surface, hold the proof as typed evidence, and only then let an effect depend on it. Undo is not free. It is earned, one reified location at a time.
The harness
The paper is not hypothetical about agents. DeepSeek Harness (dsh) is built on Cordis — the paper's own runtime — and takes the ideology to its end: everything is a plugin. The model adapter, the tool registry, the session log, the agent loop itself. A running instance is a dynamic tree of services assembled from ordered configuration layers; the same codebase becomes a CLI, a web app, or a headless runner by swapping profiles.
Two of its ideas rhyme with Bonnie directly. Its capability seams — a swappable capability split into definition, provider, and consumer, so a sandbox swaps as one unit — are Bonnie's adapter bindings behind schema-declared operations. Its invariant that anything model-visible must be reconstructible from the session log is Bonnie's receipts and route traces: the record of what the model saw and did is the source of truth, not a debugging afterthought.
So the positioning, precisely: dsh is the paper's ideology applied to a harness — the machinery around a model.
Where Bonnie leaves the page
The paper composes inside a process; dsh composes a harness around an agent. Both keep the system on one side of a line and the world on the other.
Bonnie's line can't sit in one place, because Bonnie doesn't. Cordis is infrastructure — the in-process laws, validated on a single host. Bonnie is Cordis plus the application layer that carries those same laws where the infrastructure alone doesn't reach: across three processes with separate lifecycles, and past any process, into the frontmost application, the live selection, the sentence just spoken, the mouse movement that cancels a run.
That's the inversion this book has been circling: the human is a participant in the composition, not a client of it. A harness serves requests for a user; an ambient system composes with one — the person is the component that's always activating, whose signals always win, whose state can never be clobbered or fully reverted.
The previous chapter's comparison is now one line: SKILL.md has track and no recover, and no coeffects at all. It fails both axes. A .bonnie Ability — per-turn epochs, typed requirements, dormant-not-broken degradation — spoke the paper's language before I'd read a word of it.
That convergence, found independently by the plugin people, the harness people, and an ambient assistant on a Mac, is the strongest evidence these are laws, not preferences. What differs is how far each extends the boundary — and what holds it once extended.
Bonnie extends the boundary into the room, but only because the process discipline underneath — epochs, snapshots, abilities, contracts, receipts — is what taught the model to behave inside it. The room doesn't replace the process. It's what the process was for.