Checkpoint Lab — Issues, Statuses, Assignments, False Positives, and Resolution Workflow

1. Checkpoint scenario and success criteria

Operate one disposable project from baseline through verified remediation. A reviewer must be able to determine which issue was fixed in code, which issue was temporarily Accepted, which revisions/tasks were analyzed, how Activity changed, and whether the gate changed because of source, metadata, both, or neither.

2. Record exact assumptions

3. Write predictions before acting

1. Assignment: assignment/comment changes workflow history but not Git SHA or detection.
2. Code fix: source edit creates a new SHA; after successful reanalysis the chosen issue should become Fixed.
3. Accepted: status/history and possibly gate-relevant metrics change while Git SHA stays unchanged.
4. Reopen: current status returns Open while previous Activity remains auditable.

Do not rewrite predictions after seeing the result.

4. Execute the bounded runbook

1. Create a synthetic Git fixture and baseline revision A.
2. Create academy_issue_checkpoint_lab and a project analysis token stored only in SONAR_TOKEN.
3. Run Scanner CLI with debug evidence; preserve report-task.txt; wait for the baseline CE task.
4. Record several Open issues with key / rule / location / author / assignee / status / history.
5. Assign one issue and comment the ownership rationale. Verify the assignment prediction.
6. Fix one observed issue in source, commit revision B, analyze, and verify the original issue becomes Fixed only after CE success.
7. Temporarily mark another valid issue Accepted with lab-only rationale and review condition. Do not use False positive unless the analyzer is demonstrably wrong.
8. Record gate/measures before/after and attribute the cause correctly.
9. Reopen the Accepted issue and verify Activity history remains.
10. Revoke the project token when the checkpoint is complete.

5. Required evidence packet

• assumptions.md with edition / version / scanner / runtime / plugin / integration assumptions and limitations.
• baseline and fixed revision SHAs.
• baseline/fixed scanner logs with secrets redacted.
• baseline/fixed report-task.txt and final CE task statuses.
• baseline issue inventory with keys/rules/locations/status/author/assignee.
• Activity evidence for assignment/comment, Accepted, reopen, and reanalysis.
• source diff for the real code fix.
• gate/measures before and after meaningful changes.
• token record containing only metadata and revocation proof.
• a limitations note describing what the checkpoint does not prove.

6. Interpret outcomes causally

7. Verification checklist

• Every project/revision is disposable and recorded.
• No token value appears in source, properties, logs, screenshots, or evidence.
• Every workflow action links to an exact issue identity.
• Code-fix claims have a diff plus later successful analysis.
• The temporary Accepted action has rationale, owner, and rollback proof.
• No false-positive action exists without technical evidence the analyzer is mistaken.
• Gate changes are attributed to actual causes.
• Scanner success, upload, CE success, issue state, and gate state are recorded separately.

8. Guarded cleanup

1. Reopen temporary lab dispositions that should not persist.
2. Revoke lab-only project/User tokens and verify failure.
3. Preserve evidence outside the project.
4. If deleting the project, verify the exact key academy_issue_checkpoint_lab.
5. Delete only owned fixture directories; do not clear server logs, database/search state, or unrelated caches.

9. Production handoff to Chapter 11

Chapter 10 adds governed human decisions to the SonarQube lifecycle: explicit owners, current statuses, justified exceptions, source-linked fixes, rollback, and audit evidence. Chapter 11 can now build Quality Gates, Conditions, Policies, and Pipeline Enforcement on top of signals whose changes can be explained.

Knowledge check

Official references and version notes

• Issues introduction — current issue concepts and lifecycle entry points.
• Issue management solution — identification, SCM-assisted assignment and lifecycle.
• Editing issues — Accepted/False positive, reopening, assignment, tags, comments and bulk changes.
• Retrieving issues — current issue filtering and review UI.
• Web API — bearer authentication and Web API V2 migration guidance.
• Managing tokens — token types, API use and revocation.
• SonarQube releases — dated release identities.
• SonarScanner CLI 8.1.0.6389 — scanner baseline.