stack/packages/tasks/live

S3 live run

run.mjs takes one task through every verb against a real Vikunja, with the real broker and adapter in one process. It's the row 38 acceptance run against the estate instance, and it was rehearsed against a scratch container first.

node packages/tasks/live/run.mjs setup.json out/ --base https://tasks.example.org

--base has to repeat baseUrl from the setup file, or the run exits 2 before it reads a token. A setup file copied from another install can't send the run to the wrong host without the operator typing that host.

Setup file

{
  "business": "demo",
  "baseUrl": "https://tasks.example.org",
  "project": 12,
  "sync": {"botId": 41, "file": "/home/op/.config/mosaic-dev/tokens/demo-sync", "expires": "2027-01-01"},
  "roles": {
    "pm": {"botId": 42, "env": "VK_PM", "expires": "2027-01-01"},
    "coder": {"botId": 43, "env": "VK_CODER", "expires": "2027-01-01"},
    "reviewer": {"botId": 44, "env": "VK_REVIEWER", "expires": "2027-01-01"}
  },
  "labels": {"slice-1": 7}
}

Each token is a file or an environment variable, never a value in this file. A token file follows the broker's rules: an absolute path, mode 0600, owned by the operator, not a symlink. expires is the day the token was minted to expire, as YYYY-MM-DD. The project, buckets, bots and labels come from runbook sections 2 and 3 (docs/guides/slice-1-identities.md). The first label in labels is added at create and removed at schedule. Leave labels empty to skip both.

What it does

The run builds a business with an operator human and the pm as arbiter for both domains, then starts the broker with the adapter in a fresh data directory under TMPDIR. The three roles claim their launches and the adapter runs its startup checks and one reconcile.

Then the steps, in order. Each one either succeeds or refuses with the code the step expects:

Step	Role	Verb	Expected
create-by-coder	coder	task.create	field-writer
create	pm	task.create	ok, with the label
assign	pm	task.assign to coder	ok
update-by-unassigned	reviewer	task.update.assigned	not-assigned
start	coder	task.update.assigned in-progress, 25%, comment	ok
conflict	pm	task.priority.change with a wrong expect	task-conflict
priority-undecided	pm	task.priority.change, no decision	decision-required
priority	pm	task.priority.change with a resolved decision	ok
priority-reused	pm	the same decision again	decision-consumed
schedule	pm	task.schedule due date, label removed	ok
scope	pm	task.scope.change with a resolved decision	ok
review	coder	task.update.assigned in-review, 100%	ok
reassign	pm	task.reassign to reviewer	ok
close	pm	task.close	ok
after-close	reviewer	task.update.assigned	task-done

Priority and scope are cross-role for the pm, so each needs a decision. The pm raises it, and the operator resolves it through the broker's human CLI binding. A tick after the start step and a tick and reconcile at the end must each record 0 snapshots, since the only writes were the run's own. The run then prints the event counts by kind and the snapshot counts by source and role, read from bus.sqlite.

It exits 0 when every step went as expected, 1 when one didn't or the run stopped, and 2 on a bad command line or setup file. The task stays in the project, done, with "Safe to delete" in its description.

Project trees

The run reads the setup's one project, with descendants off. It never reads a child. A tree is checked with read-only GETs instead, listed in agents/darkwing/work/queue-62/probes.md.

The log

out/live-run.txt, mode 0600, holds verbs, refusal codes, counts and task refs. It holds no token, title, description or comment. Before it writes, the run checks the log text for every token and for the word "bearer". A hit writes nothing and exits 3. The data directory is removed when the run ends.