actionstate.ai · this page as Markdown

Install Action State Receipts

Action State Receipts works beside your AI agent. The install sets up Action State Receipts and its Everyday Rules pack, asg/everyday/0.3.8, with the Muse integration. Before the agent pays, books, signs, cancels or shares your details, it checks the step against your rules, and every step is sealed on your machine as a receipt you can check. Nothing of the receipts' content leaves your machine.

This page is for you: what the install puts on your machine, the exact versions, every checksum, the sites the install reaches, and what you will be asked along the way. The install itself is a skill your agent follows; the one thing you do is give it that skill, as Add the install skill describes.

What gets installed

Installed means these pieces are on your machine: the schedule, the skills and the earlier copies the install moved to _backups, capsulectl, the plugin, the profiles in ~/.config/capsule, ~/.config/actionstate, the receipts store ~/.local/share/capsule-deal, the rules record ~/.local/share/actionstate, the log ~/checkpoint-cadence.log, your rules table and report, and capsulectl's cache. Uninstall removes the software and keeps your data; deleting the data too is a separate step.

Action State rules run on Linux x86_64 only. On any other device the install stops at its first step, and nothing is installed.

What's new: A pickup area now holds only what a public area does: letters, spaces and a few marks, with a number only as a ZIP, an ordinal such as 5th, a road or exit number such as Exit 12, or a short count such as 2 blocks, so a street address can't hide in one. A pickup area saved earlier with any other number is now refused, so write it again in those words. Your report pages open with their rows closed, list every record they carry, each with its own link, and open a conversation in place inside its card; a page opened without scripts links to the record instead. A page whose check failed says so at the top. Your 7-day spending limit is now decided even when a past purchase was charged a different amount than it stated; before, that left the limit not checked. When your spending limit can't be checked against your history, your agent asks you first; if no one can approve that kind of action, it is refused, and the refusal now says why.

Limits in this version: A History shows that its copies were picked and signed with the key on this computer; it does not show who made the deals. Sharing a History means sending its file; there is no other way to share one yet. An order that is not a payment is asked about, because the record does not say who is being paid. Recurring charges and a change to a payee's account are not yet checked on purchases. A merchant you paid in a receipt made by an older version is recognised only within that deal. A listing that was taken down still counts toward what your listings state, so a check can ask when it needn't. A refund or cancel of an earlier purchase may not yet free room in your 7-day spending limit, so a check can ask when it needn't. Action State rules run on Linux x86_64 only.

Your rules are what you permit; when the install ends, your agent sends you a short summary of them, and the full table on a page or when you ask. Your receipts are what happened: for each purchase or other commitment, what you asked, what was proposed, what you approved, what was done, and any difference.

The checksums

Every file is checked against these SHA-256 values before anything is installed, and the install stops if one differs. Any checksum your agent reports to you must match this list, character for character.

The rules pack asg/everyday/0.3.8 has the definition digest ac7697061fd1c50177000648e2458f6236068679fc67ae924870ee8fb1cd8488, and the seller's rules asg/seller/0.1.5 have 81013aedbc3d930dcb9a4871d932373eca9de6968e5cff9fb450158d1fcc576a; the rules checker is pinned to both. The public witness's key is 39bb654c9dc0afe1c0edef0deffaa69099b8518836c9ba26e0491535840f96b5.

What you are trusting: GitHub to deliver the capsulectl files from github.com/action-state-group/capsule-cli, GitHub's build attestation for that repository (checked when the agent has a recent gh), and the SHA-256 values on this page. The install skill, the install script, the plugin and the actionstate-rules skill have no build attestation yet: they are checked by their SHA-256 only, and those values are published on this site, the same place the files come from. A matching checksum shows a download arrived intact; it does not show that this site was not tampered with.

When the install ends

Your agent sends you a short message the plugin wrote: your spending limits, what your agent can do, and what it asks you about first. When your agent can attach a file, your rules page comes in a message of its own: the full rules table, your limits, and your report; otherwise your agent shows the full table when you ask. When you open the report, with no internet connection, it checks that nothing in it was changed or left out. The full signature check is a separate command. Then a short Install details note: what was installed, whether the build attestation was verified or only the checksum, and where the full record is, with every checksum and exit code. If you ask for the checksums, they come from that record, and they match the list above. Last comes your first Checkup, in a message of its own, after the summary and the rules page. If it could not be made, you get one line saying so, and the install still stands.

The sites it reaches

The install reaches these sites. Whether to allow each one is your answer, as What you will be asked explains.

Your rules record is labelled actionstate-rules, the same way your receipts are labelled deal; you are asked for no name. If an earlier install's rules record is on this computer, the install keeps that record as it is. The label is not a name; the record's key is what identifies it.

What you will be asked, and why

Two answers during an install are yours, and the install skill gives neither of them for you.

Add the install skill

The install skill holds every step, the commands and the checks, and it is the one thing you give your agent. There are two ways; with either, you then say in the chat that you want Action State Receipts installed.

  1. Add it as a skill. If your agent's host lets you add skills, download the install skill and add it there, in a folder named actionstate-install.
  2. Paste it. Open the install skill, copy all of it, and paste it into the chat as your own message.

The file you add or paste has the SHA-256 f83e3154812709a41f31a7b10ec180289bba4a53eddafec443134761832452f6, the first value under The checksums.

The skill's numbered steps are the ones the install script runs; an install that stops names the step it stopped at. The install skill linked here is the one for the versions on this page.

Already installed an earlier version? Upgrading is the same install. Near the end it asks before connecting your rules to the new version, as What you will be asked says.

Uninstall

Uninstalling removes the Action State software and keeps your data: your receipts and their keys, your rules record and its key, and the settings that point capsulectl at them stay on this computer. A later install uses them as they are, with the same keys, so the receipts you already have still check. Deleting the data as well is a separate step, Also delete my data, only if you want it.

Remove Action State (keeps your data)

These steps run in this order, in a terminal on the machine it was installed on. The schedule goes first, so no checkpoint run is left behind with nothing to publish from.

  1. The schedule. If your agent's host keeps scheduled tasks, delete the one named Action State checkpoint cadence there. If it is in your crontab, the first line below takes it out. The second deletes the file that holds the schedule's line.

    crontab -l 2>/dev/null | grep -v 'cll checkpoint cadence' | crontab -
rm -f ~/.config/actionstate/cadence-schedule

  2. The skills, and the earlier copies the install moved to _backups. SKILLS_DIR is the folder your agent loads skills from, the one the install was given.

    SKILLS_DIR=/path/to/your/agents/skills
rm -rf "$SKILLS_DIR/deal" "$SKILLS_DIR/actionstate-rules" "$SKILLS_DIR/actionstate-install"
rm -rf "$SKILLS_DIR/../_backups/deal-"* "$SKILLS_DIR/../_backups/actionstate-rules-"*
rmdir "$SKILLS_DIR/../_backups" 2>/dev/null

  3. The rules checker. Your receipts' settings stop naming the Action State checker, which the next step removes, and stop using the Action State wording for your approval cards, which goes with it. The second line clears that wording only when it is Action State's (its file name starts actionstate.capsulectl-en-); a wording pack of your own stays, and the line prints kept: with its path. Your receipts and their keys are not touched. If the install replaced a capsulectl that was already first on your PATH, that is the one to use here and to delete next, instead of ~/.local/bin/capsulectl.

    ~/.local/bin/capsulectl profile update --profile deal --rules-checker ''
S=$(~/.local/bin/capsulectl profile show deal) && P=$(printf '%s' "$S" | sed -n 's/.*"Wording":{"Path":"\([^"]*\)".*/\1/p') && case ${P##*/} in actionstate.capsulectl-en-*) ~/.local/bin/capsulectl profile update --profile deal --wording '' ;; '') ;; *) echo "kept: the deal profile pins another wording pack, $P" ;; esac

  4. capsulectl, the plugin, their caches and the install's summary. The first line keeps a copy of the plugin for the check at the end.

    cp ~/.local/lib/capsulectl/plugins/capsulectl-actionstate ~/capsulectl-actionstate-copy
rm -f ~/.local/bin/capsulectl
rm -rf ~/.local/lib/capsulectl
rm -rf ~/.cache/capsulectl ~/.cache/actionstate-plugin
rm -f ~/.local/share/actionstate/install-summary.json

  5. The check. Each removed path prints as absent, each piece of your data as kept, and the crontab has no cadence line. Your host's scheduled tasks should list no Action State checkpoint cadence. The last line runs the plugin's own list of what the install put on this machine from the copy, which shows each piece of software absent and your data present, each with its path, then deletes the copy. Its first line counts your kept data too, so it still says installed=true. Its schedule line reads the age of ~/checkpoint-cadence.log, which is kept: within 15 minutes of the last checkpoint it can still say running. Later, running means a task left in your host still writes the log.

    for p in ~/.config/actionstate/cadence-schedule "$SKILLS_DIR/deal" "$SKILLS_DIR/actionstate-rules" "$SKILLS_DIR/actionstate-install" "$SKILLS_DIR/../_backups" ~/.local/bin/capsulectl ~/.local/lib/capsulectl ~/.cache/capsulectl ~/.cache/actionstate-plugin ~/.local/share/actionstate/install-summary.json; do ls -d "$p" 2>/dev/null || echo "absent  $p"; done
for p in ~/.local/share/capsule-deal ~/.local/share/actionstate/rules.db ~/.local/share/actionstate/rules-*.db ~/.config/actionstate/seed ~/.config/capsule/profiles/deal.yaml ~/.config/capsule/profiles/actionstate-rules.yaml ~/checkpoint-cadence.log ~/actionstate ~/workspace/actionstate; do ls -d "$p" >/dev/null 2>&1 && echo "kept    $p" || echo "not here  $p"; done
crontab -l 2>/dev/null | grep 'cll checkpoint cadence' || echo "absent  crontab line"
~/capsulectl-actionstate-copy doctor --install-state --skills-dir "$SKILLS_DIR" --workspace ~/actionstate --text; rm -f ~/capsulectl-actionstate-copy

The standing rule is in your agent's memory, not in a file: remove it where your agent's host lets you edit what it remembers.

Data left on this computer

Also delete my data

Only if you want your data gone as well, after the steps above. This permanently deletes your receipts, their keys and your rules record from this computer, and a later install starts over with new keys: keep a copy of anything you want first. ~/.config/capsule holds every capsulectl profile on this machine, including any you made yourself.

rm -rf ~/.local/share/capsule-deal ~/.local/share/actionstate ~/.config/actionstate ~/.config/capsule
rm -f ~/checkpoint-cadence.log
rm -rf ~/actionstate ~/workspace/actionstate
for p in ~/.local/share/capsule-deal ~/.local/share/actionstate ~/.config/actionstate ~/.config/capsule ~/checkpoint-cadence.log ~/actionstate ~/workspace/actionstate; do ls -d "$p" 2>/dev/null || echo "absent  $p"; done

What a receipt is, and is not

A receipt shows which steps the agent sealed, and that they were not changed afterwards: it is tamper-evident against the agent and against Action State. It is the agent's own record of what it did, not a statement from the merchant; calling the check is advisory, and a step never sealed is not in it. Anyone can check a receipt file independently at verify.agentactioncapsule.org: open it and drop the file in.

actionstate.ai · install.md