The body puts pending first and folds away only rows that need nothing

Decision record 0029

Amended by 0117 and 0118: busy stacks have a section of their own, ## Busy, right under Preview failed, and the line above the preview failures counts its rows and says what comes next.

Amended by 0114: the order of the sections is dashboard.sections, In sync may be a list or off, the counts line may leave out a count of 0, and the rescan box and the footer may be off. A section that is off keeps its rows in one closed fold at the end of the sections.

Amended by 0108: a scan that is running gets one line right under the scan line, from the root marker, above the line of 0086.

Amended by 0089: every time on the dashboard is in the repo’s zone, dashboard.timeZone, UTC by default. A time that stands alone ends in its offset from UTC, the line under Recently deployed names the zone, and the markers keep UTC.

Amended by 0086: a run of the workflow that has waited ten minutes or more for a runner gets one line right under the scan line, from the root marker.

Amended by 0076: a failure line stays only while no deploy of its stack, from the dashboard or outside it, ended after the failure. An in sync row whose stack was deployed outside the dashboard after the failure, and whose tool keeps a history, has no failure line and sits in the fold.

Amended by 0073: Recently deployed also lists deploys made outside the dashboard, from the tool’s own history. Those lines carry a marker, so the section is no longer drawn from the deployment records alone.

Amended by 0040: the header, the counts line and the scan line are centered, and every count has a dot. The wording of both lines stays as it is here.

Amended by 0051: the In sync section ends with a fold of the stacks that an ignore entry with a reason leaves out, and is shown when that fold has a line even with no in sync rows.

Amended by 0055: a Drifted section sits right under Pending, and the counts line says N drifted when it is not 0.

Amended by 0062: Recently deployed lists failed deploys too, with their failure reason, its length is dashboard.recentlyDeployed (default 10), a superseded deploy shows the time it went out, and the destroy alert sits above the pending list.

Superseded by 0063 on the order of the sections: Deploying comes first while it has rows, then the updates waiting to merge, Pending, Drifted, Preview failed, In sync and Recently deployed. What each section holds and when it is left out stay as they are here.

Record 0009 made everything outside the row blocks a pure function of the root marker, the row blocks and the deployment records, regenerated by every writer. This record fixes what that function renders. It was judged on rendered issues with 58 made-up stacks: 11 pending, 2 deploying, 2 preview failures, 43 in sync.

<!-- sluiceway:dashboard v="1" scan-sha="..." scan-run="..." scan-at="..." full-scan-at="..." full-scan-run="..." -->

<picture> mascot for the dashboard's state, light and dark </picture>

**11 pending** · 2 deploying · 2 preview failed · 43 in sync · :warning: **4 pending stacks destroy resources** · 2 failed deploys

Scanned [`8c41f0e`](commit-url) on 2026-09-21 10:02 UTC · [run](run-url) · <sub>last full scan 2026-09-21 06:00 UTC</sub>

## Pending
## Deploying
## Preview failed
## In sync
## Recently deployed

---

- [ ] Rescan all stacks <!-- sluiceway:rescan -->

<sub>Sluiceway version · docs</sub>

Pending comes first because ticking is what a person opens the dashboard for. Putting the short sections (deploying, preview failed) above the long pending list was considered and rejected. The counts line already says how many there are, and the brief’s order holds.

Consequences

• The counts line always carries the four state counts, also when a count is 0, so the line keeps its shape. Two more facts appear only when they are not 0: how many pending stacks destroy resources, with the warning sign and in bold, and how many rows carry a failure line. Both come from the destroys and failed marker keys (0027), so every writer can produce them for carried rows.
• The Pending section is always shown. When it is empty it keeps its heading and gets the good-news line, whose wording belongs to the voice work. Deploying, Preview failed and Recently deployed are left out entirely when empty, heading included.
• The In sync section is a fold, because 43 one line rows need nothing, so nobody needs them open. One thing in it does need a person: an in sync row with a failure line. The stack is in sync now, often through an outside deploy (0016), but its last deploy from the dashboard failed and nobody may have looked. Those rows are listed open under the In sync heading, above the fold, and the fold’s summary then reads 42 more in sync. Their state stays in-sync. This is placement only, which 0009 leaves free, and the failed marker key makes it work for carried rows.
• Opening the whole fold whenever one row in it has a failure line was rejected: it shows 43 rows to surface one. Leaving the row inside the fold was rejected: the header would say 1 failed deploy with nothing on the page to match it.
• Recently deployed is a plain list of the newest 10 successful deployment records from the page that 0003 already reads: stack id · ticked by alice · 2026-09-21 09:41 UTC · [run](url). Failed deploys are not listed there. A failure already has its failure line on the stack’s own row, and the list stays a log of what went out. Ten is fixed in v1.
• Every time on the dashboard is absolute, in UTC, to the minute. A relative time (“2 hours ago”) would make the body differ on every render, which breaks the byte-identical rule (0004) and the skipped write that depends on it.
• Inside a section rows are sorted by stack id (0009). A row with a delete or replace is not moved to the top of Pending. Its first line and its open lines carry the signal (0027), and a stable order means a row is where it was the last time someone looked.
• The mascot block is a top level <picture> with a light and a dark source, followed by a blank line (rendering research). Its state is derived from the same counts. Which states exist and what they look like belongs to the brand work. A dashboard with any pending delete or replace uses a state without personality.
• The footer is a rule, the rescan box, and one small line with the version and a link to the docs.
• The note about shortened rows (0028), when there is one, sits directly under the scan line.

Settled while building (slice 1.7)

• The In sync section is left out when it has no rows, like the other three. An empty heading says nothing that 0 in sync on the counts line does not. When every in sync row has a failure line there is no fold.
• The fold’s summary reads 43 stacks in sync, or 1 stack in sync, when no row sits above it.
• The Preview failed section opens with one plain line, as the prototype did: These stacks could not be previewed, so they cannot be deployed from here until a scan succeeds.
• Rows of a state the writer does not know (0009) come after the footer line, which keeps them apart from the rescan box. Two lists with only a blank line between them would render as one loose list.
• The body does not end in a line break.
• The scan line leaves out last full scan when the root marker does not hold it, and leaves out a time that does not parse. Writers other than the scan take these facts from the live body, which a person can edit.

Prototype: the variant B issue in the private lab repo, generated from the prototype/dashboard branch.

Settled while building (slice 4.5)

• Under a header, each line of Recently deployed starts with the dot of its result and a non-breaking space: 🟢 went out, ⚪ nothing to deploy, 🟣 rehearsed, and since record 0062 🔴 for a failed deploy. The rest of the line does not change, and without a header the list is as above. Record 0040 holds the colours and why.

Settled while building (slice 5.10)

• A line of Recently deployed fits on one line at GitHub’s issue width for a stack id of about 40 characters (owner, 2026-09-22, on a real dashboard where every line took two). The stack id stays whole. The line is stack id · result word · login · time · [run](url): a result word only when the deploy was not a plain one (drift fixed, no changes, rehearsed, failed), the ticker’s login without ticked by, and the time without UTC and without the year when it is the year of the scan, which the scan line shows in full. A time of another year keeps it: 2025-12-31 23:59. The heading has one line under it, Times are in UTC. The rule that every time is absolute, in UTC, to the minute, holds. Every other time on the dashboard keeps UTC and its year.