Verify fixes against the assessment's current head revision (free)

POST 
/api/v1/assessments/:assessment_id/fix-verify

Spawn fix-verify against the assessment's current head.

Free run — no credit spend. The verify workflow runs against whatever revision the head points at, so the supported flow is:

1. POST /assessments/{id}/revisions — attach a new fix_attempt revision (the "Update source code" action).
2. POST /assessments/{id}/fix-verify — kick off verification against that new head. Re-runnable against the same head.

A 400 "Update the source code before verifying fixes." fires when the head is still the genesis initial revision (or absent), because verifying fixes against unchanged source produces no signal.

revision-aware spawn inheritance propagates the head revision_id to every verify_fix leaf; each leaf re-fetches the source from object storage by revision_id so the runner doesn't need the bytes inline. The KB stays put — no knowledge base cloning — because fix-verify runs in the SAME project.

Concurrency guard: a 409 fires when another fix-verify is already pending/running/paused for this assessment.

• Scope required: assessments:update + assessment write access.
• Rate-limit tier: assessment_create (100/hour/user).
• Allowed only when the assessment is in completed state.

Request

Responses

200

Successful Response

400

Bad request — malformed input or failed validation.

401

Missing, expired, or invalid credentials.

403

Authenticated but not authorized for this resource. Note: cross-organization reads return 404, not 403.

404

Resource not found, or hidden for tenant-enumeration safety (the caller lacks permission to know whether the resource exists).

409

Conflict — the current resource state does not allow this operation (e.g. assessment already started, email already in use).

422

Semantic validation failure — request shape was valid but contents were not.

429

Too many requests — rate limited. Retry after the window resets.

500

Internal server error — unexpected failure.