Activity
Activity notifications and troubleshooting
Notifications reduce the event stream to likely decision points. They accelerate triage but never replace the complete log or the detailed state in the feature that performed the work.
Evidence first
Separate saved measurements from setup states, estimates, and orientation summaries.
Clear ownership
Use the overview to navigate, then inspect evidence in the feature that owns it.
Verified next step
Turn a signal into an action only after checking scope, freshness, and outcome criteria.
Use notifications as a curated inbox
The inbox selects supported events that are likely to deserve attention. It is intentionally narrower than the timeline and should not be used as an exhaustive audit or billing report.
Choose relevant or all
| View | Use it for |
|---|---|
| Relevant | Failures, partial results, skipped duplicates, and explicitly visible events. |
| All | Every notification candidate available in the loaded data. |
Triage partial and failed outcomes
1
Read the event kind, status, scope, and counters.
2
Identify whether failure affects every item or only a subset.
3
Open the owning feature and inspect its current run or result.
4
Retry only when the operation is idempotent and the source permits it.
5
Verify the new event and the resulting data separately.
Preserve support codes
When an event shows a support code, copy it exactly with the time, workspace, event kind, and visible scope. The code supports diagnosis without exposing internal or sensitive error detail.
Escalate with complete evidence
- Workspace and approximate event time.
- Event kind, status, and visible counters.
- Support code when present.
- Expected result and what is actually missing or incorrect.
- Current state in the feature that owns the operation.