JOURNAL / WORKFLOW
A status you can check
A useful status explains what is known now, how fresh the evidence is and what action is needed. Busy activity and accepted work answer different questions.
Start with an observed fact
A running process establishes that a process exists. Naming its current task needs a connection to the assignment or observed phase. A past successful check does not establish that tests are running now, and the role “reviewer” does not describe the current operation by itself.
When the phase is unknown, say so: the agent is running, but its current step is unavailable. Preserve the source and time of the observation. After a connection is lost, the last state becomes the last known state, rather than a confident description of the present.
Separate work from its evidence
| State | Meaning | Evidence to inspect |
|---|---|---|
| Working | An assigned task is being performed | The current assignment and run |
| Waiting | The next step is unavailable | The reason and condition for resuming |
| Checked | A specific check passed | The check and revision it covered |
| Published | A change reached a named environment | The deployment confirmation and address |
| Accepted | The owner reviewed the result against its criteria | The acceptance decision and remaining limitations |
A single green indicator can blur these states. Keep the distinction in the task card, report and handoff. “Tests passed” becomes more useful when it names the scenario and revision actually checked.
Explain waiting without guessing
An empty queue, an owner question, an unavailable resource and a provider limit need different responses. Use confirmed provider evidence for a limit. Show a resume time when the source provides one; an unknown remaining allowance should not become an attractive percentage.
An owner question should identify the decision that would unblock the task. Keep that answer distinct from a technical failure. Repeating attempts without new information cannot replace either fixing the cause or obtaining a decision.
Notify on change and preserve context
A screen refresh is not a new event. Tie a brief cue to a stable task or question identity. Polling the same state must not extend the notification, and reopening a panel must not celebrate old work as a new success.
After an icon disappears, the important error or question remains accessible until handled. Sound and motion follow the chosen preferences. Animation gives the companion character; claims about work need confirmed state.
Close the handoff with evidence
A short handoff names the change, where to inspect it, checks performed, limitations and the next step. The queue entry, current run and result should refer to the same task. Iteration counts help investigate a run; they do not replace acceptance of a useful result.
Keep owner decisions understandable →Build the first clear loop →