Follow sluiceway v0.50.0: a tick written back, runs that failed, and ticks with dependencies from the command line

[robbeverhelst]

The docs follow sluiceway v0.50.0. Step 0 saw pin=v0.49.0 latest=v0.50.0 open_prs=0. The release has four changes:

• #298: a tick made while a writer writes the body is written back. Record 0119, which amends 0004, 0017 and 0025, plus the glossary's Stretch.
• #300: the open pull requests are read with pull-requests: read alone, and a list that fails is a warning. Also record 0119.
• #301: the dashboard says when runs failed (records 0120 and 0121, a new input job-status, if: ${{ !cancelled() }} on the step of the one-step workflow, a new section "A run that failed" in the workflow guide), and a row says drift not checked when its drift check failed.
• #302: the command line ticks stacks with dependencies, and --yes sends the stack's confirm. Record 0116 gains an amendment, and the app's OpenAPI copy and fake app change.

What it does

• The pin moves from v0.49.0 to v0.50.0: the submodule and the branch line of .gitmodules together (bun run pin: "vendor/sluiceway is at v0.50.0, and .gitmodules says so."). The build was green at the new pin with no mapping change, and no check was weakened. README_UNMAPPED is unchanged, because the README has no new h2.

• Two records share the number 0119. The site keyed record links by number, so every "0119" went to whichever file sorted last (the open pull requests one). Records 0004, 0017 and 0025 ("Amended by 0119"), record 0120, and the index rows of 0004, 0017 and 0025 all linked the wrong record. SHARED_NUMBERS in src/lib/pages.ts now says, for each file that cites a shared number, which record it means:

  • the write that went over an edit: build-plan.md, records 0004, 0017, 0025 and 0120;
  • the open pull requests: workflow.md, split-workflow.md and later.md.

  The loader resolves record links per part by the part's file. The records index resolves the "Amended by" it derives from a later record's lead by that record's file, so 0054 and 0081 link the open pull requests one. A record citing its own number means itself, and a number that is already a link is not cited again. The build fails, naming the file, when a file cites a shared number without an entry, or when an entry names a record the tag does not have. test/shared-numbers.test.ts holds this, including the built pages.

• The Command line page's examples are captured again from the action's fake app at v0.50.0, as docs: a Command line page for sluiceway v0.45.0, its commands, their --json answers and exit codes #23 did. sluiceway stack … --json and the tick's answer gain confirm (null for network:prod). The tick group gains the queued tick of a chain, sluiceway tick infra apps/api:prod --yes after network:prod, with one sentence in its intro saying why it is queued. Every other example still matches the fake app word for word, JSON and exit code.

• Using the app: a tick in the app now handles stacks with a dependency, a phase, a deploy window or deploy on merge (the app's record 0330, app PR #56, merged 2026-10-07; the record says this holds for the page's own tick and for the command line). The list of boxes that stay on GitHub drops them, and one paragraph says a record may open queued, and that a tick whose dependency has a change nobody ticked starts nothing.

• What it looks like: the counts line item names the lines about runs that failed, with a link to the workflow guide's new section, and says this example does not show them. The drifted rows item says a stack whose drift check failed keeps its row and says drift not checked.

These arrive by themselves: records 0119 (both), 0120 and 0121 with pages and index rows; the amendment lines on 0004, 0009, 0012, 0017, 0025, 0055, 0077, 0086 and 0108; the job-status entry in the action reference; "A run that failed" in the workflow guide (anchor #a-run-that-failed) and the step's if: in every workflow shown; the permissions note on the split workflow; Stretch and One-step workflow in the glossary; the drift not checked sentence in Configuration; the Command line page's new tick paragraphs and exit table row; three rows in Not in v1 and the roadmap; and the changelog.

Now wrong on the live site (fixed here)

The live site pins v0.49.0.

Where	Before (live)	After
Start page, JSON-LD, footer	"Sluiceway v0.49.0", softwareVersion 0.49.0	v0.50.0 (all read the pin)
Using the app, Tick from the app	"a stack with a dependency, a phase, a deploy window or deploy on merge" stays on GitHub	ticked in the app, queued or waiting by the action's rules; only a drift repair and an ignored stack stay
Command line, sluiceway stack --json and tick --json	no confirm	"confirm": null, as the app answers
Command line, tick	no stack with dependencies	the queued tick of a chain
What it looks like	no word on runs that failed or a failed drift check	one sentence each
The workflow guide and every workflow shown	no if: ${{ !cancelled() }}, no "A run that failed"	both (imported)
Action reference	no job-status	its entry
Decision records	end at 0118	0119 (two), 0120, 0121, each "0119" linking the record it means

Checked and still right at v0.50.0: every description and title in pages.ts, 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; the site serves pictures from the submodule), the header page and gallery (no picture changed; record 0120 says a failed run is "a line, never a state", so the header does not change for it), RECORD_PICTURES (none of the new records is about Penny's pictures), Install's "a stack that deletes or replaces resources still waits for a person's tick" (still true with the confirmation of the app's record 0320), the anchor redirects (no heading moved), and the water lines (src/render/voice.ts is unchanged).

Different at the real tag from the plan

• #298 was planned as record 0119 alone. At the tag, #300 took 0119 as well, and the plan's "0119 keeps the mark" holds for both. The plan did not foresee the clash, which needed SHARED_NUMBERS (above).
• The plan said the records index would read all three amendments. It does: 0004, 0017 and 0025 write "Amended by 0119" themselves, and each now links the write-back record.
• #296 went in with v0.50.0 as planned. docs/acceptance.md has no page, so nothing changed on the site.
• Not in the plan: #300, #301 and #302 were opened and merged after Follow sluiceway v0.49.0: a Telegram message can go to one topic of a forum group #33.

When the open action PRs are released

No pull request is open in sluiceway/sluiceway (checked 2026-10-09), and main is at v0.50.0. Nothing to plan for.

Ambiguous or wrong

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

• Two records are numbered 0119: 0119-a-write-that-went-over-an-edit-… and 0119-the-open-pull-requests-are-read-…. A bare "record 0119" in workflow.md, split-workflow.md, later.md, build-plan.md, 0004, 0017, 0025 and 0120 cannot say which on GitHub. If the action renumbers one, the build here fails on the stale SHARED_NUMBERS entry until it is removed.
• action.yml's job-status writes if: !cancelled() without backticks, so the action reference shows it as prose. It also drops the ${{ }} that docs/reference.md and the workflows use.
• Records 0054 and 0081 do not say "Amended by 0119", though the open pull requests record amends them. Record 0029 does not say "Amended by 0120". The index adds all three from the leads.
• action.yml gives the notification inputs three modes, the other pages four.
• telegram-thread-id cites record 0078 in What v1 is, but 0078 says nothing of topics.
• docs/roadmap.md still lists "a listing on the GitHub Marketplace, a docs site" under the launch, and docs/later.md still has "Docs site and Marketplace launch".
• Record 0031 writes two amendments in one blockquote line.
• docs/using-the-dashboard.md quotes the busy row short.
• docs/command-line.md's preview example leaves out the Policies block the command prints.
• no-write-access has no line in the exit table.
• The README still does not link the Command line page.
• Records 0102, 0104, 0106, 0107 and 0109 still write no "Amended by" line on the records they amend, and record 0095's seven amended records still do not say so.
• Record 0113's lead lacks a full stop; record 0047's lead has a date and no record; record 0094 is "Amended by slice 5.32".
• Top-level cost in the schema has no description; recordWriters' description ends "Empty hands none on."; action.yml's env-file wraps "relative to the" onto its own line.
• docs/init.md still does not mention Terraform; workflow.md#the-workflow still points at the page title from 11 links; link text that is a file path in docs/using-the-dashboard.md.

How I verified

• bun run check (lint, tokens, pin, release, astro check, build, tests) passes under both addresses, the default /docs and DOCS_SITE=https://docs.sluiceway.dev DOCS_BASE=/: 757 pass, 0 fail, 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.50.0, the action's latest release."

• bun run links under each address: "Checked 35332 links on 156 pages. All of them land."

• The command line examples: every example on the page was run again through the action's runCli against its fake app at v0.50.0 and compared on words, JSON and exit code. Only the two confirm answers differed, plus the signed-out status --json example, which differs by design.

• Lighthouse, locally with bun run lighthouse (the repo's lighthouserc.json, a production build under /, phone, median of three). No assertion failed, and 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.

• This is the third run on this bump. The 06:00 and 09:00 runs of 2026-10-08 did the work and stopped at signing (the 1Password agent was down). This run applied the 09:00 run's staged diff onto main at Follow sluiceway v0.49.0: a Telegram message can go to one topic of a forum group #33, checked that nothing moved since (no new action release or open action PR; the app's only merge since record 0330 is app #57, which moves the app's own pin to v0.50.0), and ran every check above again today: the same 757 pass, 35332 links, Lighthouse scores and 40 clean views.

• Screenshots: Playwright (global install), Chromium, 1280 and 390 wide, light and dark via prefers-color-scheme. Ten URLs: What it looks like, Using the app, Command line, the records index, both 0119 records, record 0017, the action reference, the workflow guide and the start page. Each was scrolled to the end first so lazy pictures load. All 40 views: no sideways scroll and no broken picture, and the theme matches the scheme. I looked at the walk-through's new sentences (dark, 390), the tick paragraph on Using the app (light, 1280), the queued tick example (dark, 390; the code block scrolls inside itself, as the others do), the index's 0004 row linking the write-back 0119 (dark, 1280), job-status in the action reference (light, 390), "A run that failed" (dark, 1280) and the write-back 0119 record (dark, 390). The screenshots are not attached: the 1Password agent went down again between the signed commit here and the commit for the screenshots branch, and that branch would have been unsigned. They are described here instead.

Decisions no record covers

• A shared record number resolves by the citing file, from a table, and an unlisted citation stops the build. Guessing from context (the nearest date, the lead) would be silent when wrong. The table is eight lines, and the next shared number or new citation fails loudly with the file to add.
• Using the app was corrected from the app's record 0330, not from the action, because the page describes the console. Only behaviour is written. I did not see the live console: the record and app PR #56 say the page's tick does this from 2026-10-07.
• One CLI example for the dependency change, the queued one. The waits answer's sentence names a dependency (site:prod) that the page's other examples do not set up, and the action's page already says what waits means.

Follow-ups

• Using the app's "One banner" (line 30) uses a word the voice rules rule out. It may be the console's own name for it; check with the app before changing.
• Using the app and the delete confirmation: the app's record 0320 has a tick that deletes ask first on the page. The page says nothing of the question yet. Check the console, then add one sentence.
• The hosted app's org view and the busy row: 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. Carried from Follow sluiceway v0.48.0: a busy stack, a second try, and the failing header's alt text #31.
• 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.
• A no-write-access example, once the action's page says what it means and how it exits.

🤖 Generated with Claude Code