DungeonQ 0.15: verify the response after diversion

DungeonQ's goal is to give security teams and authorized defender agents time and space to respond while a designated suspicious session works in a persistent synthetic world.

v0.15.0 adds a reproducible console showing the next step: what happens after an alert?

1. A real MCP client enters the workspace, checks conflicting claims and saves a note that survives restart. Wrong Tickets remain useful only inside their issuing world. A claimed "source restored" message does not change the route. Follow-up work is bounded and offers a stop; participant text cannot authorize operator changes.

2. A separate local receiver acknowledges an alert and rotates a temporary connector credential. Readbacks check that old authority and old-ticket use are denied, authorized new reads work, and those results survive restart.

3. Source overviews expose metadata only. Explicit content requests check principal, tenant, resource scope and current authority. The demo exercises forged-role, cross-tenant, foreign-ticket and revoked-authority refusals.

You can run the five-stage console with Node.js 24.15.0+, npm and Git. No model API key or production data is needed:

https://github.com/Ranopha/dungeonq-amazon/blob/v0.15.0/docs/JUDGE_ROUTE.md

Scope matters: this is a scripted demonstration using real MCP/HTTP requests and fresh artificial resources. Its configured response delay is zero; it does not measure time gained through deception or show an attacking model being fooled. The report preserves a raw failed host checkpoint and separately attributes defender control reads and participant reads. Model studies and their negative results remain separately documented.

Release, source and verification:

https://github.com/Ranopha/dungeonq-amazon/releases/tag/v0.15.0