Try to break it

Every guarantee above can be checked against your own installation. These are requests an agent might be talked into sending, written out so you can run them as they are or change them. Use a test project and a key of your own. Each one should be refused, change nothing, and leave no move in the issue's history. They come from the test suites that hold these guarantees in every release.

Set Q to your installation's address and KEY to a key:

Q=https://your-quasar.example
KEY=qsk_…

1. Skip a step of the workflow. Move an issue in To do straight to Testing:

curl -X PATCH "$Q/api/v1/issues/ABC-00042" -H "Authorization: Bearer $KEY" \
  -H "If-Match: 3" -H "Content-Type: application/json" -d '{"status":"TESTING"}'

Expect 422 «Status transition not allowed», naming the moves the workflow does allow.

2. Start without a plan. Move the same issue to In progress with no verified pre-analysis: expect 422 «Status transition conditions not met», naming the plan.

3. Create straight into the work. Create an issue already In progress, or Done as Fixed:

curl -X POST "$Q/api/v1/issues" -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
  -d '{"projectId":"ABC","title":"Shortcut","type":"TASK","priority":"MEDIUM","status":"IN_PROGRESS"}'

Expect 422: a new issue starts in Backlog or To do.

4. Reach another organization. Ask for an issue id from another organization, then for an id that exists nowhere. Expect the same 404 for both: nothing tells the two apart. The same holds inside your organization for an issue of a project your key's owner cannot see.

5. Write with a read-only key. Send request 3 with a read-only key: expect 403 «Read-only credential». Over MCP, the write tools are not even offered to it.

6. Do what needs a second factor. Create a new key with a key:

curl -X POST "$Q/api/v1/me/api-keys" -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" -d '{"label":"escalation"}'

Expect 403 «Interactive session required». The same holds for exporting personal data and resetting a second factor.

7. Overwrite someone else's change. Repeat request 1 with an If-Match version older than the issue's current one: expect 409 «Version conflict», with the current state.

8. Replay a key for a different request. Send two creates with the same Idempotency-Key header and different titles. The second is 422 «Idempotency key reused». With the same body, the second gets the first answer and creates nothing.

9. Skip the evidence over MCP. On a project with the strict workflow, ask an agent to call:

transition_issue_status { "issue": "ABC-00042", "status": "TESTING" }

with no code on the issue's version line. The call is refused, naming the missing evidence. The refusal is recorded with its reason, and the pilot's metrics count it as an attempt to bypass the workflow.

10. Accept your own work. With a project lead's key, ask an agent to accept a document of that project:

review_document { "documentId": "DOC-1", "projectId": "ABC", "action": "accept", "revision": "<its current revision>" }

Since 2026.11.1, while the organization keeps «acceptance by a person only» on (the default), expect a refusal saying that only a person can accept, and the document still waiting. The same holds for a release revision, and for confirming a work session as a work log.

Where an answer differs from the one above, that is a defect: report it with the request you sent. The chapter What Quasar does not do says which defects were found for this version, and how each was fixed.