Follow sluiceway v0.48.0: a busy stack, a second try, and the failing header's alt text

[robbeverhelst]

The docs follow sluiceway v0.48.0. Step 0 saw pin=v0.47.0 latest=v0.48.0 open_prs=0. The release has one change (#289, records 0117 and 0118): a preview that fails for a reason a second run can change is tried once more in the same scan, after one pause of 10 seconds, and only a preview that failed twice is a preview failure. A stack whose lock another update holds is busy, not failed: its row says so under a section of its own, ## Busy, the counts line gains N busy with the white dot only when there is one, the header does not turn failing, and strict does not count it. The failing header's alt text names what failed and how many (Sluiceway: 1 preview failed), and the line above the preview failures says what comes next. The job log shows the tool's last lines under a preview that did not work. No page moves, no heading moves, and no picture, input, mode or schema key changes.

What it does

• The pin moves from v0.47.0 to v0.48.0: the submodule and the branch line of .gitmodules together (bun run pin: "vendor/sluiceway is at v0.48.0, and .gitmodules says so."). The build was green at the new pin with no mapping change. No check was weakened, and README_UNMAPPED is unchanged because the README has no new h2.
• The header page (the-header.mdx) gains a section, "The alt text says it in words": the header is its alt text where the picture does not load and in a screen reader, a failing header names what failed and how many (Sluiceway: 1 preview failed, Sluiceway: 2 previews and 1 deploy failed), the file's own label stays Sluiceway: something failed, and a busy stack is named last (, 1 stack is busy) since no picture shows it. Under "the first wins, in this order" it says that a busy stack makes no header failing, linked to the glossary's new Busy stack. The three failing pictures' alts in the gallery say "A preview or a deploy failed" in place of "Something failed", which is what the mascot README's "Shown when" row says and what record 0118 asks of the words.
• Record pictures (RECORD_PICTURES in pages.ts): record 0118 is about the failing header's alt text, so it shows failing-0 at the top with the alt "1 preview failed: the gate is stuck half open over a log, with a red lamp", the dashboard the record came from (one failed preview, nothing pending, everything else in sync). The alts of 0031 and 0066 follow the same words: 0066's "1 preview failed, 9 stacks are pending" is the dashboard its own story tells. Record 0117 keeps Penny's mark: no picture shows a busy stack.
• What it looks like, the walk-through: the counts line item adds "and, only when there is one, how many stacks are busy", and a new item "Preview failed and Busy" between the confirm box and In sync, in the order the renderer draws the sections: a stack whose preview failed twice after its second try sits under Preview failed with no box and a link to the run whose job log holds the tool's own words, a busy stack sits under Busy and its row says busy: another update holds the stack's lock and that the next scan previews it, and the example shows neither section. Second try and Busy stack link the glossary. test/walk-through.test.ts holds the row's words as code and both anchors.
• The counts line component (CountsLine.astro, on the hidden style-check page only) draws busy after in sync with the white dot, and only above zero, as the dashboard does.

These arrive by themselves: the pages and index rows of records 0117 and 0118, the "Amended by" lines on 0009, 0012, 0022, 0029, 0031, 0037, 0040, 0066 and 0114 (every amended record writes its own line this time, and the index reads both records from 0029's "Amended by 0117 and 0118" and from 0031's two sentences on one line), the glossary's Second try and Busy stack (anchors #second-try and #busy-stack) and its changed Counts line, Row state, Preview failure and Count dot entries, the two new bullets and two new job log rows in Using the dashboard, the busy marker key in What Sluiceway writes, strict's "A preview counts as failed after its second try, and a busy stack does not count" and the preview-failed output's "A busy stack is not counted" in the action reference, the three new rows of Later and the roadmap, hurdle 30 in the onboarding log, and the changelog.

Now wrong on the live site (fixed here)

The live site pins v0.47.0.

Where	Before (live)	After
Start page, JSON-LD, footer	"Sluiceway v0.47.0", softwareVersion 0.47.0	v0.48.0 (all read the pin)
The header	nothing on the alt text; "the first wins, in this order" with no word on busy stacks; the failing alts say "Something failed"	the alt text section; a busy stack makes no header failing; "A preview or a deploy failed"
What it looks like, counts line	five counts and the destroy count	plus the busy count, only when there is one
What it looks like	no word on the Preview failed section, and no Busy section existed	the "Preview failed and Busy" item with the busy row's words
Records 0031 and 0066	alt "Something failed"	"A preview or a deploy failed" and "1 preview failed, 9 stacks are pending"
Records index and pages	no 0117, no 0118	both, with their "Amended by" lines on nine records
Glossary, Using the dashboard, What Sluiceway writes, action reference	v0.47.0's text	the new terms, bullets, key and input text

Checked and still right at v0.48.0: every description and title in pages.ts (none names the failing alt, the preview failed line or the sections), the JSON-LD's operatingSystem and keywords, the start page's hero, steps and guide list, the example dashboard (only its picture URLs and footer moved to the new tag, and the site serves pictures from the submodule), the header gallery's "Shown when" rows (the mascot README did not change, and "a preview failed, or a row has a failure line" stays true because a busy row is neither), the Command line page (the fake app, the OpenAPI copy and every command are unchanged, so all 20 examples hold), the anchor redirects (no heading moved) and the water lines (WARM is unchanged; PREVIEW_FAILED_LINE became previewFailedLine(count), which the site never read).

Different at the real tag from the plan

#28 found no open PR in sluiceway/sluiceway and left no plan. Nothing to compare.

When the open action PRs are released

sluiceway/sluiceway has no open pull request now.

Ambiguous or wrong

In the action's own text at v0.48.0, for the coordinator to pass on. New this release first; the files behind the older items did not change, so each one still holds.

• Record 0031 writes two amendments in one blockquote line: "Amended by 0118: … Amended by 0117: a busy row does not make the header failing." Every other record gives each amendment its own paragraph. The site's index reads both, but on GitHub the second reads as part of 0118's sentence.
• docs/using-the-dashboard.md quotes the busy row short. "A row under Busy says busy: another update holds the stack's lock", while the row reads busy: another update holds the stack's lock, the next scan previews it (BUSY_ROW_WORDS in src/render/row.ts). Not wrong, and the site quotes it the same way, since the whole line is too long for a phone's inline code.
• The hosted app's console and the busy row. hosted-app/using-the-app.mdx says the org view counts five states and groups preview failed under Needs you. A busy row has the marker state preview-failed with busy="true", which record 0117 says a reader that does not know the key draws as a preview failure. Whether the console knows the key is the app's side to say; the page is left as it is.
• docs/command-line.md's preview example leaves out a block the command prints. Under "Reading a stack's preview", the example is the action's own test output minus its "Policies" block (warning tags · the queue has no team tag), while the prose says preview shows "the policies' failures and warnings". The site's captured example has the block.
• no-write-access has no line in the exit table. It is an app error code in test/fixtures/app/openapi.json at 1.1.0, but docs/command-line.md does not say what exit code it ends with or what to do.
• The README still does not link the Command line page, as record 0116 says it will once the site has it (https://docs.sluiceway.dev/hosted-app/command-line/, since docs: a Command line page for sluiceway v0.45.0, its commands, their --json answers and exit codes #23).
• Records 0102, 0104, 0106, 0107 and 0109 still write no "Amended by" line on the records they amend. The index here derives them.
• Record 0095's seven amended records still do not say so.
• Record 0113's lead lacks a full stop before "Promise 4 of 0014 holds".
• Record 0047's lead has a date and no record: "Amended, 2026-09-22: …".
• Top-level cost in schema/sluiceway.schema.json has no description.
• recordWriters' description ends "Empty hands none on."
• action.yml's env-file wraps "relative to the" onto its own line.
• Record 0094 is "Amended by slice 5.32", which is a slice, not a record.
• docs/init.md still does not mention Terraform.
• workflow.md#the-workflow still points at the page title from 11 links.
• docs/roadmap.md still lists "a docs site" under the launch.
• Link text that is a file path in docs/using-the-dashboard.md: three [docs/…md] links.

How I verified

• DOCS_SITE=https://docs.sluiceway.dev DOCS_BASE=/ bun run check (lint, tokens, pin, release, astro check, build, tests) passes: 675 pass, 0 fail (674 at the new pin before this change, 617 at Follow sluiceway v0.47.0: sluiceway preview on the Command line page #28: the records and glossary terms add their own), 0 errors, 0 warnings, 0 hints. The build's only warning is the one main has too (the empty i18n collection). bun run release: "vendor/sluiceway pins v0.48.0, the action's latest release."

• Under both addresses, / and the default /docs: build, bun test (675 pass) and bun run links ("Checked 33801 links on 152 pages. All of them land." under /, the same 33801 under /docs; 150 pages at Follow sluiceway v0.47.0: sluiceway preview on the Command line page #28 plus two records).

• Lighthouse, locally with bun run lighthouse (the repo's lighthouserc.json, a production build under /, phone, median of three). All four scores are 90 or more on every audited URL:

  URL	Perf	A11y	Best practices	SEO
  /	99	100	100	100
  /get-started/	99	100	100	100
  /guides/configuration/	98	100	100	100
  /guides/notifications/	99	100	100	100
  /guides/policies/	99	100	100	100
  /guides/workflow/	99	100	100	100
  /reference/sluiceway-yaml/	99	100	100	100
  /reference/what-sluiceway-writes/	99	100	100	100
  /the-header/	99	100	100	100
  /using-the-dashboard/	99	100	100	100
  /what-it-looks-like/	99	96	100	100

  What it looks like still scores 96 on accessibility, for the same two <summary> folds under 44 pixels as since docs: follow sluiceway v0.42.1, a policies page and redirects for two renumbered records #20.

• Screenshots: Playwright (global install), Chromium, 1280 and 390 wide, light and dark via prefers-color-scheme. Ten URLs (What it looks like, The header, records 0117 and 0118, the records index, the glossary, Using the dashboard, the action reference, the style check and the start page), each scrolled to the end first so lazy pictures load, then checked: no sideways scroll and no broken picture in any of the 40 views. The first pass found one sideways scroll: the walk-through quoted the whole busy row, 70 characters of inline code, which cannot wrap at 390. The quote is now the row's start, as the action's own page quotes it, and the rest is prose.

  • The header, the alt text section, light, 1280 and dark, 390: the new h2 and its paragraph, with the alt texts as code. At 390 every code span fits.
  • The header, "the first wins" with the busy stack sentence, dark, 1280, "busy stack" underlined as a glossary link. The whole page, dark, 1280: the failing pictures' captions unchanged, the new section between the signs and the water steps.
  • What it looks like, the Preview failed and Busy item, dark, 1280 and light, 390: "second try" and "busy stack" as links, busy: and the reason as code. The counts line item, light, 1280 with the busy count sentence. The whole page, light, 390: no sideways scroll.
  • Record 0118, the top, light, 1280 and dark, 390: the jam with no crate behind it above the title, and the lead. The whole page, light, 1280.
  • Style check, the counts line, dark, 1280: 1 busy after 8 in sync, with the white dot.

Decisions no record covers

• The gallery's failing alts say "A preview or a deploy failed", not a count. The gallery shows one file for any number of failures, and the mascot README's "Shown when" row is "a preview failed, or a row has a failure line". A count belongs to a dashboard, so only the record pages whose story has one (0066, 0118) use the counted form.
• Record 0118 shows failing-0, the same file as 0031. The two are not sidebar neighbours, and the record's own dashboard had nothing pending. The alt text differs, and is the point of the record.
• Record 0117 keeps Penny's mark. It changes the alt text too (, 1 stack is busy), but no picture shows a busy stack, and the rule is that records about Penny's pictures get one.
• The walk-through names both sections in one item, in the renderer's order (Busy right under Preview failed), because the example draws neither and a reader meets them where the drifted rows end.

Follow-ups

• The hosted app's org view and the busy row (above): a word from the app's side on whether the console counts a busy="true" row as busy or as preview failed, then one sentence on Using the app.
• The two <summary> folds of the example dashboard on What it looks like are under 44 pixels tall (Lighthouse, 96). A min-height on summary inside .sw-issue would fix it. Carried from docs: follow sluiceway v0.42.1, a policies page and redirects for two renumbered records #20.
• The action reference leaves a camelCase key without a dot as prose, such as "envFile" in the env-file description. Carried from docs: follow sluiceway v0.42.1, a policies page and redirects for two renumbered records #20.
• docs: a Command line page for sluiceway v0.45.0, its commands, their --json answers and exit codes #23's owner note still stands: What the app keeps says "The app keeps no token of yours, so it cannot act as you", while personal tokens let the command line act as the person. It needs a word from the app's side.
• A no-write-access example, once the action's page says what it means and how it exits.

🤖 Generated with Claude Code