[happyren]

Every other test proves a part. This proves what the README actually claims: a team of sessions collaborating through this plugin avoids specific, nameable failures — and the accounting reports them honestly.

The storyline

A three-session team ships a breaking contract change, exercising each targeted failure mode in order:

Step	Failure mode	Outcome
Cards declare ownership	FM-1.2 / FM-2.3	routing is possible
Checkout claims api/	FM-1.3, 15.7%	refused — payments holds api/charges.ts beneath it
Payments steers checkout	—	delivered
Currency claim verified	FC3, 24.5%	refuted before it was acted on
Same verdict re-sent	—	dropped by loop control
Decision recorded, then superseded	FM-1.4 / FM-2.1	current set returns only the reversal
Docs ⇄ checkout both block	FM-1.5 / FM-3.1	deadlock detected

Then it pins the exact report:

3 receiver turns spent, 3 problems caught
  collisions avoided   1
  false claims caught  1
  deadlocks detected   1

If a change makes collaboration quieter or noisier, those numbers move and this test says so. That's the point — it's a regression bound on behaviour, not just on code.

What is and isn't mocked

Only the two edges the plugin doesn't own: the agent inbox (no live agent in a unit test) and the session corpus. The stores, sockets, loop control, admission path and metrics are real, writing to a real temp directory.

Two cases a single-process test can't reach

• Across a real Unix socket between hosts — the same storyline, the same admission path.
• The guarantee the admission design rests on: a refuse policy holds whether the message arrives in-process or over a socket. Sharing a process with a receiver is not a way around it.

3 new tests, 308 total.