From 6de51b7be49932d7fd74164e941e035125c05e6b Mon Sep 17 00:00:00 2001 From: atlas Date: Mon, 7 Sep 2026 22:02:33 +0200 Subject: [PATCH] setup: drop two vale errors my own callout introduced `Microsoft.Contractions` fires on "is not" and "it is", and both were in the sentence I added about the role having no consumer yet. Reworded so neither appears, and the passive construction goes with them. The vale job is red on every PR by design -- ci.yml says so, the docs tree has a standing backlog against these rules -- which is exactly why "vale is red" was not a safe thing to wave through. Checking per line rather than per job is what found these. Verified with the invocation ci.yml uses: `XDG_DATA_HOME=$PWD/.vale-data vale sync && vale docs/getting-started/setup.md` -> synced 3 packages, 0 errors, 14 warnings. The 2 errors CI reported at 103:39 and 104:7 are the presence control: same rule, same file, prior commit. --- docs/getting-started/setup.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/getting-started/setup.md b/docs/getting-started/setup.md index 4b136d3f..42248604 100644 --- a/docs/getting-started/setup.md +++ b/docs/getting-started/setup.md @@ -99,9 +99,9 @@ ever authenticated to OpenBao, so treat the block above as derived rather than exercised — the grants come from `-output-policy`, not from a swarm that came up on them. -⚠️ **The role it creates has nothing to present a certificate for yet.** Minting -a leaf whose CN is `swarm-controller` is not wired up in any deployment shape; -until it is, the role is provisioning waiting for a consumer. +⚠️ **The role it creates has nothing to present a certificate for yet.** No +deployment shape mints a leaf whose CN reads `swarm-controller`, so until one +does, the role stays provisioning that waits for a consumer. **Delete the file once that has run.** The unit skips when it's absent, so a host that has finished bootstrapping stops carrying the credential — and the