Cycle Detail Page

Click any cycle on the timeline to open its detail page. A breadcrumb bar shows Cycles and the current cycle name; the cycle actions live on the ··· menu attached to the cycle-name crumb. Below it, the header shows the cycle name (editable inline), status, type, parent link, date range, execution progress, and the status-dependent primary action. Five tabs organise the cycle’s data: Overview, Runs, Explorations, Activity, and Issues.

Press Esc or click Cycles in the breadcrumb to return to the timeline.

Header meta chips

Below the title row, meta chips summarise the cycle at a glance:

• Status — Upcoming, Active, Completed, or Past due.
• Type — the cycle’s category (e.g. Release, Sprint) with its admin-configured icon and colour, when a type is assigned.
• Parent — a link to the parent cycle when this cycle is nested.
• Date range — start and end dates when set.
• Owner — shown when the cycle has at least one contributor. Despite the label this is not an assigned owner: see what Owner means below.
• Executed — for active cycles, the execution percentage with a progress ring.
• Blocked — when any run or exploration result uses the Blocked system status, an amber chip shows the total blocked count across the cycle subtree.

The tab strip carries live counts: the Runs and Explorations tabs show their item counts, and the Issues tab shows a badge with the open-issue count when it is greater than zero.

Overview tab

The default tab. Shows progress, linked work, and cycle metadata in a two-column layout.

Burn-up chart

A burn-up chart at the top plots executed scope over the cycle’s date range. An ideal-pace line shows whether execution is on track relative to the schedule.

Results card

Summarises overall progress:

• Pass rate — a large percentage with executed-vs-scoped count.
• Status breakdown — a segmented bar and legend showing counts per result status.

Test runs preview

Lists the runs directly attached to this cycle with progress indicators. Click View all to switch to the Runs tab, or click a run to open it.

Right rail

The right column holds contextual cards:

What “Owner” means

A cycle has no owner field. Nobody is assigned one, and there is nowhere to set one — the row is a summary, not an assignment.

What it shows is the first contributor in alphabetical order. A cycle’s contributors are everyone who has touched it: the people who recorded run or exploration results, and the people who created, updated, or were assigned the runs and explorations — counted across the cycle and every sub-cycle beneath it. Sort those by name and the Owner row shows the first.

It can change on its own. Because the value is derived alphabetically, someone whose name sorts earlier recording a single result anywhere in the cycle subtree changes who is shown as Owner. Do not read it as accountability, and do not use it to decide who is responsible for a release — it is a shorthand for “who is working on this”, nothing more. Before anyone has touched the cycle, the About card reads Unassigned and the header chip is hidden altogether.

Runs tab

Lists all test runs attached to this cycle with their progress and results — run id, title, failed-case count, a status distribution bar, completion percentage, and contributors.

When you have Manage cycles permission you can:

• Add a run — attach an existing run from the project (runs not in a cycle, or runs in another cycle).
• Move a run — reassign a run to a different cycle or detach it from any cycle.
• Plan a run — open the test runs page with the create modal pre-filled for this cycle; after you create, you land directly on the new run’s detail page.

Click a run row to open the run detail page.

Explorations tab

Lists the exploration sessions that feed into this cycle’s scope (including sessions on child cycles). The toolbar shows the session count and, when you have the Create explorations permission, a New session action that opens the project’s explorations page with the create composer ready.

Rows are sorted planned first, then debriefed. Each row shows:

• State glyph — a dashed circle for planned sessions, a pulsing live indicator while the session is in progress, or a green check for debriefed sessions.
• Reference — an EX- id derived from the exploration.
• Title — the exploration charter name.
• Findings chip — a count when the session raised findings during the charter.
• Time box — the planned duration when an estimate is set (for example, 90m box).
• Live elapsed — while a session is live, a progress ring and Nm in elapsed label; debriefed sessions show debriefed … ago instead.
• Inline actions — when you have Edit explorations permission, Start on planned rows and Debrief on live rows (without leaving the cycle). An Open link opens the full exploration runner.
• Assignee — the assigned tester’s avatar.

Click a row to expand an inline drawer with the charter summary and findings list. Click Open (or the row’s title when you need the full runner) to navigate to the exploration detail page. Explorations are time-boxed charters — their findings feed the cycle’s release gate. If no explorations are linked, the tab explains how to charter one.

Activity tab

A day-grouped feed of events across the cycle subtree:

• Run created — who created a run, with a deep-link to TR-….
• Result changed — who set a case in a run to a new status, with a deep-link to the run.
• Finding logged — who raised a finding during an exploration session, with the finding key and session title.
• Session live — who started an exploration charter.
• Session debriefed — who completed an exploration debrief.

Filter the feed to All, Runs, or Explorations. Live sessions show a pulsing indicator on their row, and each day header summarises how many events occurred that day. Older events load on demand with Load more.

Issues tab

Two link semantics in one view: defects (tracker issues linked from failed cases and exploration findings, deduped by key) and requirements (tickets linked with a Covers relation on scoped repository cases, each with a derived coverage verdict). Defects surface when linked to Jira, Linear, GitHub, Azure DevOps, or another configured source.

• Relation facet — All, Defects, or Requirements. The All view groups defects first, then requirements.
• Defect lifecycle sub-facet — All, Open, or Resolved (on the Defects facet).
• Requirement verdict sub-facet — All, At risk, In progress, Not covered, or Verified (on the Requirements facet). See Relations for how Covers links are created.
• Search — filter by key, title, assignee, or covering case.
• Paging — 50 rows per section with Show more.

The Issues tab badge on the header shows the open-defect count when it is greater than zero. Click a defect row to jump to the linked run when applicable; requirement rows expand to show which cases cover the ticket and their execution verdict.

Header actions

The detail page header provides the primary lifecycle controls:

The breadcrumb ··· menu (on the cycle-name crumb) also offers Edit cycle…, Plan a run in this cycle, Add sub-cycle… (hidden on Completed cycles, since new sub-cycles are always Upcoming and cannot nest under a Completed parent), Reopen cycle (on Completed cycles), and Delete cycle… when you have permission. See Lifecycle for start, close, and reopen details.