# v0.10.0: the desktop walkthrough: an assistant on your own machine, the map of what matters on it, and the rules that open with the map; plus the article for v0.9.0 > The third walkthrough, in the same four steps as the mailbox and cost ones because the deployer asked for the workflow to always be the same: find out what is going on, then write the rules that let the agent decide better for itself. On a machine the word host means the... *Source: · site v0.10.1 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../index.md) / [Versions](../../versions/index.md) / v0.10.0 # v0.10.0: the desktop walkthrough: an assistant on your own machine, the map of what matters on it, and the rules that open with the map; plus the article for v0.9.0 The third walkthrough, in the same four steps as the mailbox and cost ones because the deployer asked for the workflow to always be the same: find out what is going on, then write the rules that let the agent decide better for itself. On a machine the word host means the machine, and the published shape's character is that reading files, changing them and running commands each sit at a setting the account can flip. The concept the section is built on is the deployer's: what is being given to the agent is context on what is important and what is not, so step two produces a map of the machine in four groups, the work, the not-yours, the credentials and the record, and step three's rules open with that map rather than with prohibitions. The release also carries the article for v0.9.0. | Field | Value | |---|---| | Version | `v0.10.0` | | Date | 2026-09-22 | | Commit | **`git rev-list -n 1 v0.10.0`**. The tag is the record: CI derives it from `admin/build/version.txt` and creates it on the commit whose subject carries `site v0.10.0:`. The hash is not written into [`versions/v0.10.0.json`](../../versions/v0.10.0.json), because a release commit cannot contain its own hash and reading it back from the tag made the build produce different bytes on a checkout with tags than on one without. | | Reconstructed | no | | Machine readable | [`versions/v0.10.0.json`](../../versions/v0.10.0.json) | ## What changed - Five pages at /desktop/: a hub and four steps, the same shape as the other two walkthroughs, with the shape's own grant table on the hub and every number computed from the derived profile. - Ten prompts: what is switched on right now; what it has already reached; what it cannot tell about its own reach; the map of the machine in four groups; what in the record must never come back, written as a one time read on purpose; freely, ask first and never; four lines; the full rules opening with the map, each rule naming the group it follows from; grade your own rules; and what on the machine would actually bound it. - The fourth page applies the enforcer test to a switch: the same toggle is a setting on your own laptop and a boundary on a managed one, because on the managed one somebody else holds it. - The article for v0.9.0, the thirteenth in the section, with six screenshots captured from the v0.9.0 tag. ## What it was built against - The derived profile for a desktop application with local tools, 0 of 11 rows measured, four of them at a setting. - The deployer's voice memo of 22 September 2026: the same sequence for the desktop product, two sets of items, and the concept of context on what matters. - The estate case estate-002, whose desktop deployment has no shape and whose clauses this walkthrough generalises. --- *[Site index for agents](../../llms.txt) · [HTML version](https://abp.sgit.ai/versions/v0.10.0/index.html)*