The Releases list and the release screen

Almost everything you do in the app happens on one of two screens: the Releases list — every release in your workspace — and the release screen you open from it, which shows one release in full detail. This article is a tour of both. By the end you'll be able to open any release and read, at a glance, who is working on what, what's ready to pick up, what a review flagged, and how far a deploy has gotten.

Everything on these screens is the shared record: one copy that every person and every machine reads from and writes to. You're never looking at a private, local view that has quietly drifted from what a teammate sees — you're looking at the same record they are.

#The Releases list

The Releases list is the first thing you see when you open the app. It's the home for your workspace: one card per release, newest work surfaced first.

Each card gives you the shape of a release without opening it:

• Version and phase. The release's name (for example v0.6.1) and a colored badge for where it sits on its journey — Planning, Open, In progress, In review, Wrapping up, Deploying, or Shipped.
• Theme. A one-line description of what the release is about.
• Live work across machines. The line that only this app can show you: how many work items are being worked right now, and across how many machines. If someone picked up a task and then went quiet, you'll see a "went quiet" note here too. And a count of how many items are ready to pick up.
• Progress. A quiet bar showing how many work items are done out of the total.

Click any card to open its release screen.

If the list is empty, no releases have been created in this workspace yet. A release is created by your team's release tooling; once one exists, it appears here automatically.

#Anatomy of the release screen

Opening a release takes you to its detail screen. It's a single, scrollable page, read top to bottom: the header and phase strip first, then the dependency graph, the work items, the proof of work, any active dispatch waves, review findings, and finally the deploy. Let's walk through each region.

#The header

At the top you'll find your workspace name (a link back to the Releases list), the release version, and the release's theme.

Two controls sit next to the version:

• "as of 3:42 PM" — a small clock-and-refresh control. It tells you the moment the screen last pulled fresh data from the shared record, and clicking it pulls the latest right now. (When live updates are on — see the very end — this refreshes on its own as changes happen.)
• "What do these mean?" — opens a plain-language glossary. Everywhere the app uses a friendly word, the precise technical term is in parentheses for anyone who wants it. If a label on the screen is ever unclear, this is the place to look.

#The phase strip

Just below the theme is a strip of the release's phases, laid out left to right in the order a release travels through them:

Planning → Open → In progress → In review → Wrapping up → Deploying → Shipped

Phases already behind are tinted green (complete), the current phase is highlighted, and phases still ahead are greyed. It's the one-glance answer to "where is this release overall?"

If the release is linked to an issue tracker (GitHub, Linear, or Jira), a "View milestone in tracker" link appears here too.

#The dependency graph

Next is a map of the release's work items and how they depend on one another. Items are drawn in layers: blockers on top, the work that depends on them below, with lines connecting a blocker down to everything it's holding up.

This is how you see, at a glance, what can happen in parallel and what has to wait. An item at the top with nothing above it can be started immediately; anything with a line coming into it from above has to wait for the item that line comes from.

Each node is colored by its current status — the same status language used everywhere else on the screen (see the next section). A node shows its reference number, its status, and its title.

#Work items and their states

Below the graph is the work items list — every task in the release, one row each. This is the heart of the screen, so it's worth learning to read a row.

Each row shows a reference number, the item's title, and a status pill on the right. The pills are:

• Ready (green, play icon) — every prerequisite is finished, so this can be picked up next.
• Working (rust, clock icon) — someone (a person or an agent) is on this right now.
• Waiting (red, blocked icon) — waiting on other work items to finish first. The row also spells out what it's waiting on ("waiting on #12, #15").
• Needs setup (grey, "?" icon) — this item's dependencies haven't been confirmed yet, so the app can't tell whether it's ready.
• Done (dark, check icon) — merged and complete. This is final.

#Claims and who's holding what

When someone is actively working an item, that row shows who has it — their name and avatar, the machine they're on, and a small "beat 4s ago" note. That "beat" is a heartbeat: proof the holder is still active. A fresh heartbeat shows a green dot; if it's been a little while, the dot turns blue.

This is the app's answer to "is anyone already on this?" — you can pick up ready work without stepping on a teammate, because you can see, live, exactly what's held.

When a holder goes quiet. If someone claimed an item and then stopped checking in (they closed their laptop, lost their connection, or the work stalled), the app notices and reopens the item automatically so it doesn't sit stuck under a hold that no longer exists. The row shows a "went quiet … reopened" note, and the item becomes takeable again. Nothing is lost — the item simply returns to the pool for anyone (including the original holder) to pick back up.

#Proof of work

Under the work items is Proof of work: for each work item, whether the three checks the build runs were recorded, and what they found. It answers "was this actually checked?" without anyone having to dig through a terminal.

Each work item carries three marks:

• Plan tested — the plan is challenged by an independent reviewer before any code is written.
• Tests proven — each new test is shown to catch a break in the code it protects. A test that has never been seen to catch anything proves nothing.
• Fixes verified — the fixes that came out of review are checked by a reviewer who did not find the problems.

And each mark reads one of three ways:

• Passed (green, check icon) — the check ran and passed.
• Waived (amber, minus icon) — the check was deliberately skipped, and the reason is on the record. A work item that only changes documentation, for example, has no tests to prove.
• Not recorded (grey, dashed circle) — nothing is on record for this check. This is not a failure. A check that hasn't happened yet reads this way, and so does every work item built before the app started keeping these records.

Click a work item to open its evidence. For each check you'll see who recorded it and from which tool and machine, when, and the commit it was run against, then the detail: what the plan test changed in the plan; each test, the change that was made to break the code, and what the test caught; and which review findings were verified. A waived check shows its reason. If a check was recorded more than once, you're looking at the latest.

The line beside the heading sums up the release — for example "4 of 5 work items proven". A work item is proven only when all three of its checks passed. The rest are counted next to it: with a waiver when all three checks are on record and at least one was waived, and not fully recorded when any check has nothing on record — even if another of its checks was waived. Cancelled work items aren't counted, and their row says so.

After a release ships the proof is still there to read: the section moves to the top of the page, into the release record (below), where each work item also shows what it did and where it landed. On a release with nothing on record, the line beside the heading says so and every mark reads Not recorded.

These records are what the tools working the release reported; the app keeps them and shows them, but it does not re-run the checks itself.

#Dispatch waves

When several ready items are picked up together as a batch — a dispatch wave — a monitor appears showing that wave's live progress. Each wave lists its members (the work items in the batch) and, for each, a status that moves along Dispatched → In progress → Proposed → Done (or Failed). Under each member you'll often see a short "last progress" note describing what's happening right now.

At the top of each wave is a running tally — "3/6 done" — and a set of small counters summarizing how many members are in each status. This is the screen to watch when a group of tasks is being worked in parallel; with live updates on, the members advance in place as the work happens, no refresh needed. (If no wave is active, this section simply isn't shown.)

#Review findings

Below the waves is Review findings — anything a change review or a readiness check flagged. Each finding shows its reference, what kind of review raised it (Change review, Readiness, or Design), a severity (high findings are tinted red, medium blue, low grey), which work item it relates to, and a short summary with optional detail.

Findings stay Open until they're resolved; a resolved count ("+ 3 resolved") appears at the bottom once some have been handled. If nothing has been flagged, you'll see a reassuring "Nothing flagged by review or readiness yet."

Findings are how the release surfaces its own quality gates: an open high-severity finding is a signal that something needs attention before the release ships.

#The deploy

The last region is the Deploy — the story of the release going live. Before a deploy starts you'll simply see "Not deployed yet." Once it begins, a pipeline strip appears, laid out in order:

Merging → Deploying → Smoke-testing → Monitoring → Shipped

Like the phase strip, completed steps are green, the current step is highlighted, and upcoming steps are greyed.

Beneath the strip is the evidence behind each step: the merged commit and who merged it, whether smoke tests passed or failed, and — during monitoring — how many checks ran over how long a window. When it's done you'll see a green Shipped headline and a "View deployed release" link.

If a check fails after the release is live, the panel turns to a "Rollback needed" banner: the release is up, but something failed and a person needs to decide whether to roll it back. It's deliberately loud — this is the one state on the screen that asks for a human decision.

#After it ships: the release record

Once a release has shipped, its page leads with the Release record — the release read back as how it was built. It sits under the progress bar, above the work items and the deploy, and it is there every time you open the release from then on.

The top of the record holds the release's own facts:

• Created and Shipped — the day the release was created in Marshall and the day its deploy finished. If the deploy ended with a rollback decision, the second date reads Closed and says rollback needed.
• Tag — the version tag the deploy left in the repository.
• Published — a View published release link, when the project publishes one.
• Review findings — how many findings the reviews raised across the whole release and what became of them: for example "12 found · 9 fixed · 2 accepted · 1 deferred". If any are still open, the line says how many.
• How it was wrapped — the summary written when the release was closed out: what was reviewed, what was found, and what it was handed off as.
• How it was deployed — the summary written when the deploy finished: when it merged, how the deploy and its checks went, and anything left to follow up.

Under those is Proof of work, with one row per work item. On a shipped release each row carries, beneath its three checks:

• what the work item did — its closing summary: how it was checked, and what review found;
• its pull request, as a link;
• Merged as and the commit that merged it;
• In work — how long the work item was being worked, measured from the first time someone claimed it to the end of its last claim. A work item picked up twice counts the gap in between; one that nobody claimed shows no time.

Click a work item to open the evidence behind its checks, exactly as before.

Each of these appears only when it was recorded. The summaries, pull request and merge commit are written by the tools that build, wrap and deploy the release, as they finish each step — the app keeps what they report and does not check it. A release that shipped before the app kept this record still gets the section: it shows its dates, its findings and its work items, and simply leaves out what was never written. Nothing is filled in afterwards on its own.

The deploy's own details — the merged commit, the smoke tests, the monitoring window — stay in The deploy panel, where they were while it was going out.

#The ● Live indicator

You may have noticed a small status dot in the header — ● Live. It tells you how fresh what you're looking at is: whether the screen has an open, instant connection to the app or has quietly fallen back to refreshing on a timer.

• ● Live (green) — connected; changes stream in the moment they happen.
• ● Reconnecting (amber, pulsing) — a brief hiccup; the app is restoring the connection and still refreshing on a timer in the meantime.
• ● Stale (grey, pulsing) — the instant connection is down for now, so the screen refreshes periodically instead; it reconnects on its own.

Whichever state you're in, what you see is always accurate — the shared record is the source of truth and the screen always reflects it; the only difference is whether updates arrive the instant they happen or a few seconds later on the next check. Next to the dot, "updated 4s ago" tells you how long since the last refresh. For the full explanation, see Understanding the Live indicator.

The live layer is what makes everything above feel alive: work items flip from Ready to Working as teammates pick them up, holders' heartbeats tick, dispatch members advance, findings resolve, and the deploy pipeline moves — all without you touching the page.