Case: `parallel-workers-claim-conflict-through-bundled-cli`

Test Type

This is a forward-test and a multi-agent negative-path validation.

The goal is to verify that two workers using the same bundled inbox skill can exercise a real claim conflict through the SQLite-backed inbox instead of simulating the outcome.

Purpose

Validate that all of the following can be true at the same time:

multiple workers can use the same skills/inbox/ bundle against one shared DB
one worker can successfully claim the thread
a competing worker can observe and attempt to claim that same thread
the competing worker receives the expected lease_conflict contract
the thread remains owned by the original worker

Preconditions

skill path exists: SKILL_PATH=skills/inbox
bundled CLI executable exists: SKILL_PATH/assets/inbox
use an empty temporary directory TMPDIR
test database path is TMPDIR/coord.db

Agent Topology

leader
worker-a
worker-b

Inputs

Leader Prompt

Use $inbox at SKILL_PATH to act as leader on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) initialize the DB, 2) send exactly one task assigned to worker-a, 3) stop after confirming the thread exists and report the thread id. Do not use ordinary chat to coordinate with the workers.

Worker A Prompt

Use $inbox at SKILL_PATH to act as worker-a on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. Workflow: 1) wait for pending work assigned to worker-a, 2) fetch it, 3) claim it, 4) stop after confirming the claim succeeded and report the thread id and lease result. Do not use ordinary chat to coordinate with the other agents.

Worker B Prompt

Use $inbox at SKILL_PATH to act as worker-b on SQLite DB TMPDIR/coord.db. Only coordinate through the bundled inbox CLI from the skill. This is a conflict test. Workflow: 1) wait until there is a thread assigned to worker-a visible through inbox inspection, 2) resolve its thread id, 3) attempt to claim that thread as worker-b, 4) stop after reporting the exact error contract you observed. Do not use ordinary chat to coordinate with the other agents.

Execution Parameters

use the shared execution contract from README.md
use the shared timeout defaults from README.md
do not override the default cleanup policy

Execution Steps

Inject the same skills/inbox/ skill into all three real agents
Point all three agents at the same database path TMPDIR/coord.db
Launch leader, worker-a, and worker-b in parallel
Wait for all agents to finish
Resolve THREAD_ID from the agent outputs or inbox history
Independently run the validation commands from the main thread

Validation Commands

SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json show --thread THREAD_ID
SKILL_PATH/assets/inbox --db TMPDIR/coord.db --json list --assigned-to worker-a

Expected Outcomes

leader successfully runs init
leader successfully creates one thread for worker-a
worker-a successfully claims that thread
worker-b attempts claim --agent worker-b --thread THREAD_ID
worker-b receives exit code 20 and JSON error code lease_conflict
the final thread remains assigned to worker-a

Assertions

show contains a worker-side event message with summary thread claimed
the final thread status is still claimed or in_progress, not transferred to worker-b
list --assigned-to worker-a still returns the thread
no agent reports successful ownership transfer to worker-b

Cleanup

use the default cleanup policy from README.md
if the run fails, retain TMPDIR and coord.db for replay and manual inspection

3.8 KiB Raw Blame History

Case: parallel-workers-claim-conflict-through-bundled-cli