Issue Lifecycle

Issues follow a defined lifecycle with strict rules about who can transition status and when items can close. These rules ensure that all defects are properly resolved and verified. The four statuses are the same for every category. What unlocks Closed depends on where the issue came from, not on its category.

Enlarge

Status Flow

Status Transitions

Enlarge

Closure Rules in Detail

Rule 1: Closure Depends on Source, Not Role

There is no role check on closing — the transition is open to the issue's assignee, its creator, or the project owner. What decides the path is whether the issue was raised from an inspection. An inspection-raised issue closes through the reinspection workflow: the register's Close Issue row action is locked on any issue that has a source inspection, and clicking it routes you to the detail page instead. A manually raised issue closes as soon as one of those three presses Close Issue from Fixed.

Rule 2: All Siblings Must Be Fixed

Issues from the same inspection are treated as a group ("siblings"). No individual issue can close until ALL siblings are Fixed or already Closed. This prevents partial resolution.

Example:

• Inspection "Pre-Pour Check" generates 3 issues: I-001, I-002, I-003
• I-001 is Fixed, I-002 is Fixed, I-003 is still In Progress
• None can close yet — I-003 must also reach Fixed status

Rule 3: Auto-Close on Reinspection

When the Performer has:

1. Fixed all linked issues
2. Re-inspected and recorded new verdicts on the previously failed items
3. Submitted for review

The system transitions every issue linked to that inspection that is already in Fixed to Closed. Issues still Open or In Progress are not closed — the Performer cannot submit the reinspection until all of them are Fixed. Issues linked to a different inspection, or to none, are untouched.

How the Interface Guides You

The app makes these prerequisites visible rather than silently blocking you.

Issue Detail Page

When an issue is Fixed and linked to a source inspection, a "Before you can close this issue" checklist block appears above the form content. It shows two ordered steps:

Step 1 — Fix all related issues Shows live progress (e.g., "2 of 3 fixed"). If siblings are still open or in progress, each one is listed as a clickable row — tap any to navigate directly to that issue without losing your place.

Step 2 — Complete the reinspection This step is dimmed until Step 1 is fully complete. Once all siblings are Fixed, an inline Perform Reinspection button appears inside the step so you can start the reinspection immediately.

When both steps are done, the checklist header changes to "Ready to close" and the footer's Close Issue button unlocks.

Issues Table (row actions)

When "Close Issue" is blocked in the row actions menu, it displays a lock icon instead of being grayed out, and hovering shows a tooltip. Clicking the item navigates you to the detail page where you can see and act on the prerequisites — it's never a dead-end no-op.

Reinspection Gate

If the "Require Issue Resolution Before Reinspection" policy is enabled:

The Performer sees a message with the number of unresolved issues that must be resolved first.

Typical Lifecycle Example

Priority Impact

Priority doesn't affect the lifecycle mechanics but provides urgency signals:

Overdue items (past due date) show visual indicators in the table.

Next Steps

• Issues Overview — Table layout, categories, filtering, and management
• Reinspection — How the reinspection cycle works with issue resolution