Desktop application environments
This roadmap records the planned implementation sequence. It does not establish current completion, review approval or verification status. For current workflows, see desktop capture, build computers, tasks and export. Individual verification records retain their original scope and limitations.
Goal: REA turns an application installed and used on a Linux desktop into an agent environment's computer application. The real application installs into a computer image, launches to ready, exposes reset, load and get over its own state, and ships with tasks graded through that state.
The planned sequence was one PR per step:
- Pin the real agent environment lane to the framework release that carries the computer application contract.
- Capture: launch the application on the user's desktop and record its inventory, windows and home-directory state at checkpoints.
- State view: decide which paths are the application's state and read their formats into a typed JSON view.
- Export: write the computer application class, environment card, skill and seed.
- Verification inside an agent environment computer: put, boot, ready, reset equals the seed, grader checks.
- Tasks: an agent writes a prompt and declarative checks from the observed change, REA keeps the task when the checks fail on the seed and pass on the captured end state, and a run of the bundle measures an agent's solve rate.
- Three applications end to end: Mousepad (plain files), GnuCash saving to SQLite, and Joplin (Electron, SQLite).
- Vendor packages: closed-source applications from a vendor apt repository, with its verified signing key and the packages of the libraries they load, starting with Typora.
- Vendor .deb files: closed-source applications
installed from a downloaded
.debfile, which the computer downloads from an operator's URL and checks by its captured SHA-256, starting with VariCAD. - Document views: documents saved as zip archives (FreeCAD, OpenDocument, Office Open XML, EPUB) read as their entries, checked by name rather than position, namespaced XML included, and numbers compared within a tolerance, starting with FreeCAD.
- Capture for building: one capture makes
the seed and then the change, at checkpoints the export and the task
draft are told; apt lists from a user-space
apt-get updateare found; the application does not inherit the computer's control token; and the bundle holds neither the capture host's name nor its user's. - Build computer: an agentenv computer REA keeps up from a request or a bundle, with REA installed inside for building, driven through REA's MCP tools while an agent builds the environment.
- Build and witness: REA's capture, task draft and export run inside the build computer with acknowledged checkpoints, the bundle comes back to the host, and the task is witnessed live in a fresh computer of it: seed, edit, near miss and reset, recorded.
- XML text checks: XML whose DOCTYPE only names its DTD read as XML, starting with AbiWord, and checks of an element's whole text across the runs an app splits a paragraph into.
- Download installs: applications no package
offers, from their project's AppImage or tarball pinned by URL and
SHA-256, unpacked under
/opt/rea-appsby the build computer and the export alike, starting with FreeCAD. - Readers: checks of a file REA reads as binary,
such as GIMP's
.xcfor Blender's.blend, through the app's own headless command, run in the computer on a private copy of the file. - Screen judges: checks of state no file shows, such as a calculator's result, by a model judging a screenshot against the build's labelled seed and end screenshots.
- Secrets typed unseen: a password or key the person keeps in a file on the build host, typed by its handle, which no result, log, record or exported bundle holds; sign-in and licence state withheld from the seed and supplied at run time, seeded only with the person's recorded consent; known handle values are checked explicitly.
- Several tasks: one capture yields several tasks, each checked at its own end checkpoint and, when one was taken, failing at its near miss; the eval lists them all and each is witnessed on its own fresh computer.
- Task difficulty: a build tool solves a bundle's task in fresh computers for a model, 3 times and 2 more unless they passed none or all, within a budget, and records its band, cost, turns and failures per check in the bundle.
Version 1 covers Linux with X11, applications whose state lives in files or SQLite under the home directory, and real applications from public packages. It uses the user's real state and keeps everything local.