Issues & RunSessions
Issues and RunSessions are RunWhen’s two units of operational state. They answer different questions and have different lifecycles, but they reinforce each other and you cannot really understand one without the other.
- An Issue is a finding — something a task raised because a check failed or surfaced something worth attention.
- A RunSession is a recorded investigation — every interaction with the assistant (whether a chat, a slash command, or a scheduled run) creates one.
Issues persist until the underlying condition clears or someone ignores them. RunSessions are immutable history.
What an Issue is
When a CodeBundle task detects a problem, it does not just log a line — it raises a structured Issue with:
| Property | Meaning |
|---|---|
| Severity | 1 (Critical) → 4 (Informational). Drives ranking in the Issues list and in assistant responses. |
| Title | A short, human-readable description (“Segmentation Fault in checkoutservice”). |
| Details | The evidence — command output, log excerpts, or whatever the task gathered. |
| Reproduce hint | The command or action that surfaced the finding, so a human can re-check it. |
| Next steps | Suggested investigative or remediation actions. |
| Resource | The thing the Issue is about, expressed as a resource path. |
This structured shape is what lets the platform group Issues by SLX, dedupe recurrences, count occurrences, and let assistants cite them by reference instead of re-running the same diagnostic.
The Issue lifecycle
An Issue moves through a small number of states:
| State | What it means |
|---|---|
| Detected | A task run produced the finding. |
| Open | The Issue is visible in the Issues list and surfaced to assistants. |
| Investigated | A user or assistant has opened a RunSession that references the Issue. (Investigation does not close the Issue — the underlying condition has to clear.) |
| Resolved | The next task run no longer detects the condition. The platform clears the Issue automatically; users do not have to mark it resolved. |
| Ignored | A human has explicitly suppressed the Issue. Ignored Issues do not surface in the list and are not cited by assistants. They can be un-ignored. |
The “automatically resolves on next task run” property matters. RunWhen does not require teams to maintain Issue status by hand — the next scheduled execution of the same task is the source of truth.
What a RunSession is
A RunSession captures a single investigation end-to-end:
- The original prompt, slash command, or trigger.
- Every task the assistant chose to run and its output.
- The Issues, Knowledge notes, and prior RunSessions the assistant cited.
- The final response — analysis, citations, recommended actions.
RunSessions are how you re-read what happened: post-incident review, training new responders, demonstrating to auditors what the platform did and why. Because every interaction creates one, you also have a history of which questions your team asks repeatedly — useful signal for what should become a Command.
How Issues and RunSessions reinforce each other
The two are designed to feed back into each other:
- A task detects an Issue.
- A user (or a Workflow, or a scheduled command) opens a RunSession to investigate.
- The session cites the Issue — the assistant doesn’t re-derive what the task already found.
- The session may trigger more tasks, producing more findings (which may become more Issues).
- The session ends with analysis and recommendations; the original Issue stays Open until the underlying problem clears, at which point the next task run resolves it automatically.
This is why “what’s wrong in online-boutique-dev?” produces structured output instead of a from-scratch investigation: the assistant finds the relevant Issues first and uses them as the spine of the response.
Severity, in concept
The 1-to-4 severity scale is intentionally simple:
| Severity | Intent |
|---|---|
| 1 — Critical | Something is broken or actively degrading users; investigate now. |
| 2 — Major | Important and worth attention this shift. |
| 3 — Minor | Worth knowing about; investigate when convenient. |
| 4 — Informational | Background context; may be useful to an assistant but rarely demands action. |
CodeBundle authors assign severity at the task level. Workspace Rules can adjust how the assistant frames a given severity in your environment (for example, treating routine lab pressure as background rather than as a Major finding) without changing the underlying number.
Anti-patterns
- Treating an open Issue as something a human must close. Issues self-resolve; manual closure is not the workflow.
- Ignoring Issues to silence noise instead of writing a Rule or fixing the underlying check. Ignore is for one-offs and known temporary conditions.
- Using RunSessions as the only audit trail for write actions. RunSessions are part of the audit trail, but workspace-level audit logging is the system of record.
Where to use this in the UI
Issues and RunSessions are surfaced primarily through Workspace Chat — when you ask the assistant about a service or namespace, it cites the relevant open Issues, opens a RunSession to capture the investigation, and lets you drill into individual findings inline. There is no separate “Issues” page to browse; the chat surface is the entry point.