| Filename | Latest commit message | Latest commit date |
|---|---|---|
d14f583d92
The repository tracks the latest stable Rust, pinned at the root. A
`rust-version` key states a *floor* -- the oldest toolchain a crate supports --
which is a different promise, and one this repository does not make. It also
said 1.97 while the pin was 1.98.0 and nothing verified it, so it was a claim in
the wrong direction and unchecked in both.
So it goes, everywhere:
59 rust-version = "1.97" (workspace and package declarations)
417 rust-version.workspace = true (members inheriting them)
476 files, 476 deletions, 0 insertions
The 417 are why this is not the sixty-file change it looks like from a grep for
the value. A member inheriting a key that no longer exists does not fall back to
a default -- its manifest stops resolving. Removing the declarations without the
inherits would have broken every workspace that has members.
Deliberately untouched: `joule-code-rs/vendor/wtransport/Cargo.toml`. That is a
vendored third-party crate declaring a floor about itself, not about us, and our
pin is above it. Editing vendored source to satisfy our own policy would make
the copy diverge from upstream for no benefit.
Verified rather than assumed:
- all 493 `Cargo.toml` files in the tree parse (`tomllib`)
- `cargo metadata --no-deps --locked` resolves on `joule-code-rs`, `wai-rs`,
`openpay`, `mesh-rs`, `sandbox-rs` and `jcp-rs` -- the check that actually
exercises workspace inheritance, which a TOML parse does not
- no `Cargo.lock` changed; `rust-version` is not lockfile state
`wai/wai-verify/Cargo.toml` already carried a comment saying it omits
`rust-version` on purpose, so this makes the rest of the tree agree with the one
crate that had already decided.
What this gives up, stated plainly: cargo can no longer greet an older
toolchain with "requires rustc 1.97" and will instead fail wherever the code
first needs something newer. That is the cost of not maintaining a floor, and
it is the right cost when the floor was fiction.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
| .. | ||
| conformance | ||
| docs | ||
| joule-ui-rs | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
| SPEC.md | ||
joule-ui
A typed declarative protocol for agent-emitted user interfaces.
joule-ui is the sibling to JouleClaw for the moment when an
agent's resolution has to become something a human can see and interact
with. The agent emits a widget tree — (name, props, children),
recursively — against a widget registry the host has published. The
host renders. No React in the spec, no HTML over the wire, no agent
holding the renderer.
The shape the field has converged on for this is declarative components against a registry: agents are far more reliable emitting structured data than emitting code, and renderers are far easier to harden when they own their own widgets. joule-ui pins that shape as a protocol; the renderer is product surface, owned by the consumer.
What ships in v1
-
joule-ui-rs/crates/joule-ui-core/— the protocol types (Widget,PropValue,WidgetSchema,Registry) and the recursive validator. Pure Rust, no IO, JSON-serialisable. -
joule-ui-rs/crates/joule-ui-interaction/(v0.2) — the layer no other UI protocol carries: when a human or an agent fires anAction, the invocation is an accountable event. Every fire names the principal that made it — adid:key, the same whether a person or an agent (the protocol draws no distinction; both are traced).run_interactionauthorizes it against a capability before it runs (a denied action's handler never executes), meters it in joules, charges its cost (a reading or an estimate, and which), and anInteractionLogseals it as the next link of a hash-chained receipt. The actor is bound into the signed core, so an interaction cannot be re-attributed without breaking the chain. A joule-ui session becomes a tamper-evident ledger of who fired it, what it computed, and what it cost — verifiable by anyone holding the host's key. The metering (SandboxPowerMeter) and the capability (JCP grant) are recognized edges; the receipt, the chain, and the lifecycle are joule-ui's. SeeSPEC.md§5–§7 andexamples/metered_surface.rsfor the full loop. -
joule-ui-rs/crates/joule-ui-lang/(v0.3) — the line language: a model writes a surface as a short program, one widget a line (OpenUI Lang 1.0; seeNOTICE), and joule-ui takes it in as it streams. After every chunk a snapshot holds the tree as far as it can be built, each widget validated against the registry, and every error with its line and reason; a canonical writer turns a tree back into the language. State, queries, expressions and sequences of actions are refusednot-declarative: joule-ui carries no behaviour on the wire. SeeSPEC.md§11, the pack inconformance/lang/with its independent verifier, anddocs/create.md, the design of Create, the page that builds a WAI app as a model describes it.
The surface layer makes joule-ui a peer of the declarative-UI protocols (A2UI, MCP Apps). The interaction layer makes it the only one you can hand to an auditor: a UI whose every interaction is energy-accounted and sealed, by construction.
What is not here:
- A renderer. The renderer is owned by the host (browser app, native shell, terminal UI). joule-ui validates the surface and seals the interaction; it does not paint pixels.
- A transport. The validated spec and the interaction stream ride MCP, REST, SSE, gRPC, Web MoQ — any bytes-out protocol. Transport-agnostic.
- A "model emits React" path. The agent emits a declarative tree against the registry; arbitrary code emission is out of scope.
Why a sibling, not inside JouleClaw
The spec layer is protocol — small, stable, conformant. The renderer registry is product surface — many of them, evolving fast. Splitting them protects the tools for use line: JouleClaw stays the runtime substrate; joule-ui is the UI protocol; consumers ship their own widgets.
Licence
Specification text and protocol document: CC-BY-4.0 (see LICENSE).
Reference implementation in joule-ui-rs/: Apache-2.0 (see joule-ui-rs/LICENSE).