# 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

```text
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

```text
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

```text
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](./README.md)
- use the shared timeout defaults from [README.md](./README.md)
- do not override the default cleanup policy

## Execution Steps

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

## Validation Commands

```bash
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 `claim`s 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](./README.md)
- if the run fails, retain `TMPDIR` and `coord.db` for replay and manual inspection