[robbeverhelst]

The docs follow sluiceway v0.47.0. Step 0 saw pin=v0.46.0 latest=v0.47.0 open_prs=0. The release has one change (#287): a new command, sluiceway preview <repo> <stack id>, prints every change of a stack's preview, read from its preview page on GitHub through the app. The app reads that page with GitHub's Checks permission, which each org accepts. The action's copy of the app's OpenAPI document moves to version 1.1.0. No page moves, no heading moves, and no picture, input, mode or schema key changes.

What it does

• The pin moves from v0.46.0 to v0.47.0: the submodule and the branch line of .gitmodules together (bun run pin: "vendor/sluiceway is at v0.47.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.
• Command line page, a sluiceway preview example group (src/lib/command-line.ts), between stack and tick, with what it prints and its --json answer. Both were captured the same way as in docs: a Command line page for sluiceway v0.45.0, its commands, their --json answers and exit codes #23 and Follow sluiceway v0.46.0: the command line talks to console.sluiceway.dev #26: I extracted the action at v0.47.0 and ran runCli against fakeApp() from test/cli/fake-app.ts. The --json answer is checked against the Preview schema of the action's OpenAPI copy by test/command-line.test.ts. That test also requires an example for every command the action's table lists, so it failed until this group was added.
• The same capture reran all 18 older examples: all of them print the same at v0.47.0, words, --json and exit codes.
• Command line page description (pages.ts) now names previews: "Install the sluiceway command, sign in with an app token, then read status and previews, tick, rescan and change settings, with --json and exit codes." (150 characters, under the 160 the built-site test allows.)
• Install the app, the permissions table gains a row: Checks, Read, "Reading a stack's preview page when sluiceway preview asks for it, to hand it on. Until an org accepts it, preview fails there and says so." This is from the action's record 0116 (amended 2026-09-27) and docs/command-line.md.
• What the app keeps, under "No resource name, property path, diff or value", gains one sentence: when sluiceway preview asks, the app reads the preview page from GitHub at that moment, hands it on, and keeps none of it. The bullet stays true, but without this sentence it reads as if the app never touches resource names.

These arrive by themselves: the new preview row in the commands table, the new section "Reading a stack's preview", the exit table's new wording for 1 and 4, "version 1 (1.1.0 or later for preview)", the glossary's Command line entry, and record 0116's new section "Amended, 2026-09-27: sluiceway preview".

Now wrong on the live site (fixed here)

The live site pins v0.46.0.

Where	Before (live)	After
Start page, JSON-LD, footer	"Sluiceway v0.46.0", softwareVersion 0.46.0	v0.47.0 (all read the pin)
Command line	no preview in the commands table, no "Reading a stack's preview", no example	the action's row and section, and a captured example with --json
Command line, description	"…then check status, tick, rescan and change settings…"	"…then read status and previews, tick, rescan and change settings…"
Install the app, permissions	seven permissions, no Checks	Checks, Read, and what it is for
What the app keeps	says the app never has a resource name, with no word about preview	the same, plus: the app reads the page when preview asks, hands it on and keeps none of it

Checked and still right at v0.47.0: every other description and title in pages.ts, the JSON-LD, Using the app and The app and the action (neither lists the command line's commands), the example dashboard (only its picture URLs and footer moved to the new tag, and the site serves pictures from the submodule), the header page and gallery, RECORD_PICTURES (0116 is not about Penny), and the anchor redirects (no heading moved).

Different at the real tag from the plan

#26 planned: "when the action takes in [the app's 1.1.0 document], test/command-line.test.ts fails on sluiceway status infra --json, whose org has no unshared".

• That did not happen. unshared is required on the Org schema, the answer of sluiceway status without a repo, and on Audit. The org inside a Repo answer is its own small object (login, kind, page) without it. The page has no --json example of Org or Audit, so nothing broke, and the test found no problem.
• no-write-access is in the fixture's error codes, as planned. I added no example for it, because the action's own page does not list it (see below).
• Not in the plan: the fixture also gained no-preview and preview-unreadable, and the new Preview schema that the new example is held to.

When the open action PRs are released

sluiceway/sluiceway has no open pull request now, and nothing I can see is on its way.

Ambiguous or wrong

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

• 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 for the same fake data, minus its "Policies" block (warning tags · the queue has no team tag). The prose above the commands table says preview shows "the policies' failures and warnings", but the example shows none. 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: 617 pass, 0 fail, 0 errors, 0 warnings, 0 hints. The build's only warning is the one main has too (the empty i18n collection). The first run failed the built-site test on the Command line description (176 characters), and I shortened it. bun run release: "vendor/sluiceway pins v0.47.0, the action's latest release."

• Under both addresses, / and the default /docs: build, bun test (617 pass) and bun run links ("Checked 33030 links on 150 pages. All of them land.").

• The CLI capture: all 18 older examples, plus preview with and without --json, run through runCli at v0.47.0 against fakeApp(). Everything on the page matches byte for byte.

• 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/workflow/	99	100	100	100
  /guides/configuration/	98	100	100	100
  /guides/notifications/	99	100	100	100
  /guides/policies/	99	100	100	100
  /reference/sluiceway-yaml/	99	100	100	100
  /reference/what-sluiceway-writes/	99	100	100	100
  /using-the-dashboard/	99	100	100	100
  /what-it-looks-like/	99	96	100	100
  /the-header/	99	100	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. Each of the three changed pages was scrolled to the end first so lazy pictures load, then checked: no sideways scroll and no broken picture in any of the 12 views.

  • Command line, sluiceway preview, dark, 1280: the new h3 in the page's contents between stack and tick. The capital REPLACE line, and long lines scroll inside their block.
  • Command line, light, 390
  • Install, permissions with Checks, light, 1280 and dark, 390: the new row sits between Contents and Pull requests. At 390 the table scrolls inside its own box, as it already did.
  • What the app keeps, light, 1280 and dark, 390: the new sentence, with sluiceway preview as a code link to the Command line page.

Decisions no record covers

• No no-preview failure example. The fake app answers no-preview only for network:prod, which the page's own examples show as pending with 1 update. An example saying it "has nothing waiting to deploy" would contradict the page. The action's paragraph and the exit table already cover the case.
• The permissions row says what Checks is for in the site's words. The action names the permission ("Checks: Read-only", "the app's Checks permission, which each org accepts on GitHub"), not the table's "What for" wording.

Follow-ups

• 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