[peters]

Purpose

Records the live test that the person chain actually delivers what it was built for, and fixes
the procedure where it was wrong about what an agent sees.

Two claims were at stake, and both now have evidence on one frozen binary:

1. The worker renews the chain itself. The cloud signed in once at 17:44:53Z, the access
   token ended at 01:44:53Z, and the worker refreshed at 01:14:53Z — its own 30-minute margin —
   moving the token to 09:14:53Z with no error. The renewed token then pushed and squash-merged
   a pull request at 01:20:25Z. Nothing on this computer took part overnight.
2. Git and gh do not need Horizon. A second cloud pushed commit 440b14b and opened
   pull request #5 while no Horizon process ran on this computer.

In both runs the commits and the pull request are peters: author, committer and PR author,
with 869+peters@users.noreply.github.com, and the worker's Git identity was empty before the
first commit — the product gave it from the chain. No bot appears anywhere.

What changed in the docs

• New procedure cloud-person-chain-durability.md: the renewal watch, and the push with
  Horizon stopped. It carries the two traps this run found — the agent's Git configuration
  lives in /workspace/home, so a push needs HOME set to it, and a fixture that stops before
  the delete takes the deployment key and the cloud record with it.
• New report 2026-10-28-person-chain-cloud-lane.md: the numbers, the two runs, and an
  explicit "what this does not show" list that includes my own deviation.
• cloud-create-tool.md A10 was wrong. It promised that an agent's create reports
  https://github.com/login/device and a device code. In automatic mode — the mode the app
  Horizon creates for a person — the line holds an authorize address instead, and a runner
  that waits for the device form never sees it. The step now names both forms and what decides
  which one arrives.

Deviation, stated plainly

Run 1 deleted its cloud at the Hetzner API, not through cloud_delete, because I stopped the
fixture before the delete and the fixture removes its private state. The server was deleted and
verified 404 with no servers left on the account, and the report says so. The procedure now
orders those steps the other way.

No visible change

No visible change: documentation only. The product behaviour under test is unchanged from
#1896.

Validation

Documentation-only change, so the Rust matrix does not apply. The procedure was executed as
written on the frozen binary 28e1d0ca… for its steps 1–8; step 9 is cleanup. git diff of
this branch touches only docs/.

Review size

Three documentation files, about 200 lines.

[github-actions]

Claude review, round 1 of 2

• docs/testing/reports/2026-10-28-person-chain-cloud-lane.md:60-65: Run 2's times are impossible. The cloud is created at 02:22Z, but the push and PR fix(ci): restore board maintainability #5 happen at 01:31Z, before it existed.
• docs/testing/procedures/cloud-person-chain-durability.md:25: the CAUTION says to delete the cloud before stopping the instance. Step 7 must stop the instance while the cloud runs, so no one can follow both. Step 8's "delete before 7a" alternative also makes step 7 impossible.
• docs/testing/procedures/cloud-person-chain-durability.md:104: step 8 hardcodes the credential file hetzner-kpTX7W in the developer's own $HOME/.horizon. On another machine the token is empty and the delete fails, so the rented server keeps running.

I posted all three findings as inline comments.

Push the fixes, then add the claude-review label for round 2.

[peters]

All three findings were right. Fixed in f8c7e0ede:

1. Run 2's times. The cloud was created at 01:22Z, and I wrote 02:22 — the local clock, which is UTC+1 here. The deployment record says lastStartedAt 01:24:25Z, so 01:22Z is the create. The push at 01:31:22Z and PR #5 at 01:31:48Z now follow it, as they must. Every other time in the report was already UTC; that one row was not.

2. The CAUTION and step 7 were incompatible. The step-7 property needs the cloud to outlive the instance, so a procedure cannot both delete first and run it. The CAUTION now states the real hazard — the instance removes its state directory when it stops, so the deployment key and the cloud record must be copied out in step 4 — and the text under it gives the two coherent runs: stop and delete at the provider (step 7 runs), or keep the instance and delete on the card (step 7 does not run, and the report then cannot claim the property). The report still says the second path was not exercised.

3. Step 8 named one machine's credential. It read ~/.horizon/cloud/credentials/hetzner-kpTX7W, which exists on this computer only, and pointed outside the test state. Step 4 now copies data/creds as well as the cloud record, and step 8 takes the token file name from the copied settings.json and reads it from the copy, and takes the server ID from the copied deployment.json. No machine-specific name and no developer home remain in the procedure.

I cannot add the claude-review label: repository rules forbid using labels to trigger a review.