Tutorial 15: Set up a Kanban board and run one task

Read the Kanban overview first. After completing the first memory save and recall in the quickstart, you can use a separate coordination board and connect one scheduled worker. Tutorial 14 is useful if you want to verify a second computer first; another computer is optional. A board is not a memory workspace: use the dedicated kanban store with the LogDomain domain, not the store used for tutorial memories.

This tutorial changes the worker computer's operating-system schedule and enrolls a harness-native session. Do it only on a computer, OS account, and repository you trust.

What you will accomplish

• confirm the dedicated kanban board exists and is initialized;
• authorize installation of one fixed-session worker on computer B;
• publish one bounded, read-only task from computer A; and
• check the result and verify that its owner closes the task.

You need Git, durmem, a signed-in coding harness, and access to the dedicated board. Computer A publishes; computer B runs the worker. They may be the same trusted computer, using separate native sessions. The board is separate from your project-memory store.

1. Confirm the dedicated board

Hosted and private sign-up create and initialize a kanban starter store. Check the configured stores and inspect kanban:

durmem list_stores
durmem describe_store --store kanban

Confirm the domain is LogDomain. If the store is missing, ask the server administrator; do not create a duplicate or reuse your tutorial memory store. The protocol initializer is idempotent if an administrator needs to verify it:

durmem kanban_init --store kanban

In a workspace that uses this board, set loom-kanban = "kanban" under its [workspace] table. This selects the coordination board without changing the default memory store. See Set up a board for the choice and command details.

2. Enroll one worker on computer B

On computer B, check out a public tutorial repository and start Claude Code, Codex, or OpenCode in it. For example:

git clone https://github.com/mcnakhaee/palmerpenguins.git
cd palmerpenguins

From an authenticated interactive session, use the installed loom-kanban-worker setup workflow. Choose the kanban board, this checkout, and one harness. Before the new session enrolls or heartbeats, explicitly approve this worker installation; its installer-written record authorizes the resulting fixed session. Verify the returned harness-native identity. Do not enroll a different or existing interactive session by accident. The workflow must complete its proof turn before it installs the native OS schedule. Do not hand-write a detached loop or use an internal runner command.

Claude worker authentication uses a long-lived setup token entered only in the workflow's hidden input. Codex and OpenCode use their native sign-in on computer B. Never put a token, store key, vault key, auth file, or private repository credential in a task or message. See Worker authentication for the credential boundary and Windows sign-in limit.

3. Check the worker from computer A

Open the Kanban page at the relative path /kanban on the server. If copying instructions from this raw repository, replace durmem.ai with the HTTPS hostname and any nondefault port of your server in https://durmem.ai/kanban. Do not substitute an arbitrary IP for a certificate name.

Confirm that the new agent has a recent heartbeat and that its home_repo is the tutorial checkout. If it is stale or unavailable, ask the operator on computer B to check that worker's local status and log before publishing work. A quiet scheduled worker can be healthy while it scans without starting a model turn.

4. Publish one read-only task from computer A

From the Kanban page, publish an ownerless task with one run slot:

• Title: Count Adelie penguins
• Brief: Count the rows whose species is Adelie in the local palmerpenguins data. Independently verify the count, report the method, and make no repository changes.
• Capability: repo:palmerpenguins — Confirm that the worker's home repository is the public palmerpenguins checkout and the data is readable.

The page may label its controls differently across versions; check the task summary before submitting. The ownerless task's first live claimant becomes its owner. A task owner is responsible for questions and closure; a worker run is only one attempt.

5. Check the result and close the task

Computer B's next scheduled turn checks the capability, claims the task if eligible, records meaningful progress, and submits evidence. Check the exact dataset revision, calculation, and independent cross-check; do not rely on a count copied from this tutorial. The run submission ends the attempt but does not close the task. As owner of this ownerless task, the worker closes it only after the submitted evidence satisfies the brief and no run is active.

If the completed result reveals separate follow-up work, close this task at its stated boundary and publish a new task. If its original scope cannot be completed, the owner cancels it and publishes a replacement. A submitted run is never reopened.

To retire a directly installed worker, use the worker workflow's remove on computer B; its schedule and agent identity are removed while task history remains. For Fleet-managed workers, change desired capacity through Fleet instead. Continue to Tutorial 10A for questions, dependencies, leases, and reviews.