The row marker carries its counts and what a queued row waits behind, and the example dashboard is data

Decision record 0110

Amends 0009 (the row marker gains six optional keys), 0022 (each fixed list gains a reason word for a reason the reader does not hold), 0088 (the example dashboard is exported as data, and drawn under any setting) and 0096 (the page documents the keys and the words, with generated examples). Built as slice 5.46, from issue 263.

A reader that redraws the dashboard from the published shape (0096) with the action’s own renderer, holding stack-level facts only and never a diff, was tried on 2026-09-25 and found five small gaps. Each is an addition to what a marker or the example carries. None changes a rule: the row state is still a cache, nothing is decided from any of the new keys, and the marker version stays 1 under 0009’s rule for new keys.

Decision

A pending row’s marker carries the counts of its first line: creates, updates, replaces and tracking, after every older key and in the order of the first line, each left out at 0. tracking is the changes that only touch the tool’s record of a resource, the N tracking only of the first line (0007). deletes keeps its meaning from 0075, how many of the destroys are deletes, and is written as it was: whenever destroys is, 0 included. replaces is the same number as destroys less deletes, and is written anyway, so a reader draws the line without arithmetic. A deploying row copies destroys and deletes from the row it replaced and nothing else, as before.
A drifted row’s marker carries changed, how many resources its drift check found changed outside the code, right after gone (0075), left out at 0. Without it a reader that holds gone="1" alone draws a drifted row with two findings as one resource gone, and a drifted row with nothing gone as nothing at all. A pending row that also shows drift keeps drift="true" and neither count, as before.
A queued row’s marker carries behind, the stack ids it waits behind, as a list like depends-on (0059), last. It is the display cache 0009 foresaw: the fact is behind on the deployment record (0056), resolve and settle read the record and never the row, and a row that waits for its deploy window alone (0104) has none.
The example dashboard is data first. scripts/example-dashboard.ts exports EXAMPLE: the root facts, the rows, the trail, the outside deploys, the ignored stacks, the updates waiting to merge and on their checks, and the confirm box, before any setting is applied. exampleBody draws the published body from it, and takes the settings of sluiceway.yaml a body is drawn under: redact, personality, timeZone and readOnly. A reader that wants the example under its own setting takes the data and the renderer, instead of the published file’s markers, which lose the made-up changes and the trail’s lines.
Each fixed list of 0022 gains a reason word for a reason the reader does not hold. For a deploy, the reason is on the deployment record, because the reason of a failed deploy is the description of its status, which 0096 leaves out of the published shape. For a preview, the reason is in the summary of the run, because a preview failure has no record and its reason is in the summary and the result file. Both are constants with nothing filled in. Sluiceway never writes either: a scan and an apply always hold the reason. A reader writes them so a failure line or a preview failure row drawn from the facts alone keeps the action’s sentence, escaped and placed as the renderer places every reason, instead of words of its own.
The page documents all of it. docs/what-sluiceway-writes.md names the six keys in the row table, in the order the writer writes them, and a generated example of the row markers shows each: the queued row behind the deploying one, a pending row with a create and an update, one with a replace, one with deletes and a tracking change, and a drifted row with a resource changed next to the one with a resource gone. A section under the row table says which two things a drawn row cannot take from a marker and gives the two reason words, with an example the renderer draws. The page also says that the example is data.

Considered

One count, changes, as the issue first put it. A reader with one number cannot draw 2 updates, 1 create, which is what the row says and what the issue wanted. The five numbers of the first line are the counts.
Leaving replaces out, since it follows from destroys and deletes. Rejected: a documented key costs nothing to read and the four counts then have the same shape.
The counts on a deploying row, copied from the row it replaced like destroys. Left out: a deploying row shows no counts, so a reader has nothing to draw from them. It is on docs/later.md with the drift counts on a pending row’s marker, in case a reader asks.
One reason word for both lists, the reason is on the record, the issue’s own phrasing. Rejected: a preview failure has no record, and a word that points somewhere should point at the right place.
Documenting the description of a deployment status instead of a reason word. Rejected: 0096 left it out so the fixed lists can be reworded, and the reason word keeps that freedom.

Consequences

Every pending row’s marker grows by up to four keys and every queued row’s by one. On the 58 stack fixture that is well under one percent of the body, inside the size budget’s room (0028).
Every writer already carries keys it does not know, so a body one version wrote reads in the next and back (0009).
A test holds the published example to the renderer over the exported data, and holds a redraw under another setting to every stack of the example.
The written surface tests hold the page’s row table to the keys the writer writes, in order, and the two drawn rows to the renderer and the fixed lists.