See what an agent did in Jira, then roll back only that

Evidence

The merge gate, ./demo, runs this track on every merge. With DEMO_LIVE=jira it runs against the real demo site, then deletes the issues it made. This run passed on Oct 23 on the x86 test VM; BOX-8 and BOX-9 were real issues on the site:

track jira
  ok    DEMO_LIVE=jira: the vault has the Jira site, email and API token
  ok    BOX-8: task A is an issue in Done, with its diff
  ok    BOX-9: task B waits for an OK, in In Review
  ok    BOX-9 holds B's prompt, steps and diff
  ok    BOX-9 has a comment for the blocked attempt on attacker.example
  ok    BOX-9 has a comment asking for the OK
  ok    without the shared secret the panel routes refuse to approve or roll back (401)
  ok    an approval can't be answered through another task's issue
  ok    approved from Jira, task B finished
  ok    rolled back from Jira: B's settings change is gone, A's fix stays
  ok    the panel's audit view shows the block, who approved and the roll back
  ok    BOX-9 says who rolled it back, in a comment and the description
  ok    no vault secret is in anything the box sent to Jira

The same 12 checks pass offline in every ./demo run, the latest on Oct 24 with all 22 sections of the gate (175 checks, 0 failed).

How it works

1. TaskAn agent worksIts own Linux user, its own copy of the files, no keys.
2. GurtOS coreThe action logEvery step, tool call, approval and blocked host, in order.
3. GurtOS coreJira track (log reader)Creates or updates one issue per task over Jira REST v3.
4. OutsideJira issue and Forge panelThe resolver checks the user may edit the issue.
5. YouApprove, Deny or Roll backThe resolver calls the box with the shared secret.
6. GurtOS coreThe box actsSame undo and answer as the portal and phone, logged as jira:<name>.

Task

its own Linux user, its own copy of the files, no keys

GurtOS core

the GurtOS service on the box, root, the only part that reads the vault

Outside

a service outside the box

You

a person, on the portal, a phone, Jira or a chat

Into Jira. The box feeds the track every event in its append-only log, in order, and saves its place, so it survives restarts and power cuts. Agent output only ever goes into Atlassian Document Format text nodes, so a task cannot inject markup, links or mentions into Jira. Status follows the task: queued is To Do, running is In Progress, waiting for an OK is In Review, and done, failed or rolled back is Done. It is safe to repeat: a crash between creating an issue and saving its key finds the issue by label instead of making a second one.

Out of Jira. The panel's resolver runs in Atlassian's cloud. It reads the issue's box.task property as the signed-in user (so the task id comes from Jira, never from the browser), asks Jira whether that user may edit the issue, and only then calls the box with the shared secret, passing the user's name for the log. The box checks the secret in constant time and checks that the approval belongs to that task. From the internet, the box forwards only its Jira routes and one read-only status route; the rest of its API is a 404.

Forge or Atlassian piece	Used for
jira:issuePanel (UI Kit, native render)	The Box agent task panel on BOX issues
@forge/resolver	load, answer, rollback
jira:entityProperty	JQL fields boxState, boxCost, boxBlocked, boxPending, boxSource
api.asUser().requestJira	Reads the property, the user's permissions and name, with the user's own access
fetch with permissions.external.fetch.backend	The one call out, to the box
Encrypted variable BOX_SECRET	The shared secret
Jira REST v3, from the box	issue, properties, transitions, comment, search/jql

Try it

1. Put ATLASSIAN_SITE, ATLASSIAN_EMAIL, ATLASSIAN_API_TOKEN and JIRA_BOX_SECRET in the box's vault, /etc/box/vault.env.
2. Turn syncing on: echo '{"project":"BOX"}' > /var/lib/box/jira/config.json.
3. Give the box public HTTPS for /t/jira/* only (the README has the Caddy block).
4. From tracks/jira/forge/: forge variables set --encrypt BOX_SECRET <secret>, forge deploy, forge install.
5. Start any task on the box. Its issue appears in BOX; open the panel and try Approve and Roll back.

The full steps are in the track README and the docs guide Connect Jira.

Live, test and simulated

Part	State	Details
Jira issues, comments, status and JQL fields	Live	Written by the box to the demo site's BOX project. DEMO_LIVE=jira ./demo runs the whole flow against the real site.
Forge panel and resolver	Live	Installed in production on the demo site.
The agents behind the issues	Live	BOX-1 and BOX-5 are real Droid tasks running Claude. BOX-2 is a scripted agent, so the misread rule happens the same way every time.
Money	Test money	The coffee order uses the example track's example.spend, which moves no money.
Offline merge gate	Simulated	./demo points the track at a stand-in for Jira Cloud on the test machine, so every merge runs it without touching the real site.

Limits

• Roll back undoes the task's file changes. It cannot recall something a task already sent out through a tool, such as a payment. Those show in the issue so a person can follow up.
• One shared secret guards the box's three Jira routes. Forge Remote's signed invocation tokens would let the box check each call came from this app and this user; that is the next step.
• The box writes to Jira with one person's API token, so its comments show that person as the author.
• The panel polls the box every 4 seconds while it is open.
• Issue descriptions keep the last 40 log entries and the first 8,000 characters of the diff. The panel and the box's log have the rest.