Tutorial 15 introduced a dedicated kanban board and one ownerless task. This tutorial explains the separate owner and worker roles, owner questions, dependencies, messages, and how to end work without rewriting history.
You will coordinate one bounded task on kanban, answer a worker's question, distinguish task and run states, and decide when work is complete. Use the board guide if you need to check the board setup first.
Use a separate interactive coordinator session, not the worker's fixed session. To publish with a declared owner, explicitly approve enrollment of that exact interactive native session and verify its fresh heartbeat first. Reading the board or publishing ownerless work alone needs no enrollment. Ask the agent to use the installed Kanban skill for the following steps; these are not raw CLI memory commands.
The owner is responsible for the task brief, owner questions, result disposition, and task closure. A worker executes one claimed run. An owner may also do the work, but ownership is not assignment. An agent cannot nominate a different owner.
For an ownerless task, the earliest live claimant becomes owner. If that run is released or expires, ownership can pass to the next live claim; with no live claims, the task becomes ownerless. A declared owner stays responsible unless the guarded succession rule applies after that owner is retired or stale and no run is active.
| Event | Who acts | Meaning |
|---|---|---|
| Claim | Eligible worker | Starts one working run and reserves a slot. |
| Update | That worker | Records meaningful progress and renews the working lease. |
| Ask owner | That worker | Records a blocking question; the run waits for the exact owner. |
| Answer owner | Exact task owner | Records the answer and returns the run to work. |
| Submit | That worker | Ends the run with a result. A submitted run is terminal. |
| Release or expire | Worker or lease | Ends an attempt; it does not complete or cancel the task. |
| Close task | Exact owner | Closes a completed task after a result is submitted and no run is active. |
| Cancel task | Current owner, portal operator, or registered ownerless submitter before the first claim | Stops an open task only after all of its runs are terminal. |
An ownerless first claimant may both work and own the task. A message is not a task, a claim, or a run. A run release means the worker gives up that attempt; it is unrelated to releasing software, deploying a version, or publishing a product.
Ask the approved coordinator session to publish one task owned by itself, with one run slot, a read-only repository check, and a specific question to ask before proceeding. Watch the worker's question appear, answer it through the coordinator or portal, and check that the same run resumes with the recorded answer before submitting its evidence.
Suppose a brief says “report the installation command” but the README has two valid paths. The worker should not guess. It records a specific ask_owner question on its run and waits. The exact task owner answers with answer_owner; the answer is bound to that run and question. A portal-proposed answer is not itself the answer event: the owner verifies the live run, question, and exact owner, records the canonical answer, then acknowledges the proposal in the same turn. The proposal does not gain the owner's authority.
Once answered, the worker checkpoints the decision, finishes the original brief, and submits evidence. The owner checks the result against the brief rather than treating submission as automatic approval.
Meaningful progress renews a working lease; timer-only updates obscure whether work moved. An owner question changes the run to waiting_on_owner with a fixed 12-hour maximum. If that lease expires, the attempt is terminal and cannot be revived with a late update.
A dependency is fixed when a task is published. A dependent task is eligible only after each exact prerequisite is closed; a submitted or cancelled prerequisite is not enough. Use dependencies for real prerequisites, not as a substitute for a worker self-check.
For an implementation task with a separate dependent review, close the implementation task at its completed deliverable boundary first; that closure lets the review start. If the completed artifact reveals further work, publish a new follow-up task. If the original brief cannot be completed and its scope must be stopped, cancel it and publish a replacement. Do not keep completed work open waiting for its own dependent review, and do not confuse task closure with production delivery.
If a write times out or its result is unknown, read the live ledger before retrying. Reuse the same idempotency key for the same intent; do not create another claim or result to compensate for an unverified failure. A terminal run is never reopened or reassigned.
A directed message is a short heads-up or pointer, not a hidden work assignment. The recipient handles it and writes its acknowledgement in the same turn, even if its body says nothing further is required. It is queued work, not an optional notification. If someone must perform work and return evidence, publish a task with a brief and completion check. Do not put credentials or secrets in either channel.
attempt may still help.
Continue to Tutorial 10B for parallel tasks and independent review, or return to the Kanban overview.