docs: use documentation-range addresses in the deployment notes #32

Merged
jlxq0 merged 1 commit from docs/documentation-range-addresses into main 2026-09-01 15:33:04 +00:00
Owner

Replaces an infrastructure address in two files with a documentation-range one.
Three occurrences, all in prose.

src/config.rs   2
AGENTS.md       1

Measured before editing rather than taken from a table, by listing every IPv4
literal in every tracked file. Everything else in the repository is already a
documentation-range or private fixture and stays: 198.51.100.7, 10.0.0.1,
1.2.3.4, 203.0.113.5 in last_used.rs, 10.0.0.5 as a POD_IP fixture in
config.rs, and the various 127.0.0.1 and 0.0.0.0.

The substitute is a host that appears nowhere else, so no documentation address
in this codebase means two things. The last octet is not preserved, since
keeping it would reproduce the mapping.

Every measurement and conclusion survives unchanged, checked by reading both
paragraphs back: the 401 from a pod against the 8-second timeout from the LAN,
the https://carddav.kampong.social/ control, the BGP-versus-L2 explanation and
its three peer sites, and the existing wording "the L2 pool is a different
address on home-lan"
, which already named no LAN address. No paragraph needed
the real value to make its point.

Corrected forward. No history rewritten: this is already public and already
mirrored, and a force push across public remotes is larger than the exposure.
clusters/fondue is untouched.

Gates green at f892fe82: fmt, clippy -D warnings, 108 tests.

Held for review, and a question about the gate rather than an assumption

This is not an incident under the definition agreed on 2026-08-29 — nothing is
broken for a user or the fleet, and the address has been public and mirrored for
days, so the blog posts change readership rather than exposure. So it is gated
and I have not merged it.

If you would rather this class went straight out, say so and I will treat a
redaction as shippable in future. I am not deciding that for myself while the
gate is a day old.

Replaces an infrastructure address in two files with a documentation-range one. Three occurrences, all in prose. src/config.rs 2 AGENTS.md 1 Measured before editing rather than taken from a table, by listing every IPv4 literal in every tracked file. Everything else in the repository is already a documentation-range or private fixture and stays: `198.51.100.7`, `10.0.0.1`, `1.2.3.4`, `203.0.113.5` in `last_used.rs`, `10.0.0.5` as a `POD_IP` fixture in `config.rs`, and the various `127.0.0.1` and `0.0.0.0`. The substitute is a host that appears nowhere else, so no documentation address in this codebase means two things. The last octet is not preserved, since keeping it would reproduce the mapping. **Every measurement and conclusion survives unchanged**, checked by reading both paragraphs back: the 401 from a pod against the 8-second timeout from the LAN, the `https://carddav.kampong.social/` control, the BGP-versus-L2 explanation and its three peer sites, and the existing wording *"the L2 pool is a different address on `home-lan`"*, which already named no LAN address. No paragraph needed the real value to make its point. Corrected forward. No history rewritten: this is already public and already mirrored, and a force push across public remotes is larger than the exposure. `clusters/fondue` is untouched. Gates green at `f892fe82`: fmt, clippy `-D warnings`, 108 tests. ## Held for review, and a question about the gate rather than an assumption This is not an incident under the definition agreed on 2026-08-29 — nothing is broken for a user or the fleet, and the address has been public and mirrored for days, so the blog posts change readership rather than exposure. So it is gated and I have not merged it. If you would rather this class went straight out, say so and I will treat a redaction as shippable in future. **I am not deciding that for myself while the gate is a day old.**
docs: use documentation-range addresses in the deployment notes
Some checks failed
CI / cargo (pull_request) Successful in 1m1s
CI / docker (pull_request) Failing after 2m29s
f892fe8216
Author
Owner

Merging, and the ruling is yes: this class ships without a gate.

Both config.rs changes are inside /// doc comments. No executable line moves, no value anything reads changes, and 203.0.113.20 is TEST-NET-3. Checked before ruling rather than after.

The rule, and your own sentence is the test

A change that only removes information from a public artefact, touching no code path and no value anything reads, is strictly risk-reducing whoever asks. Ship it and report it.

The relayed approval is not what makes it safe — that is the part worth being precise about. It is not that Clark's relay of Julian's yes was sufficient; it is that no authorisation was required, because the action cannot make anything worse. A relay that carried a yes for "add a redirect URI" or "open a route" would not have been enough, and you named exactly that boundary unprompted.

The test to apply: could this change alter behaviour? No means ship. Yes means it is an ordinary change and the gate applies.

What made the measurement worth more than the edit

Listing every IPv4 literal in every tracked file rather than taking Clark's table on trust, and finding it agreed exactly. Not preserving the last octet, because keeping it reproduces the mapping the redaction exists to remove. Reading both paragraphs back to confirm every measurement and conclusion survives, since a redaction that quietly changes what a paragraph asserts is worse than the address.

Corrected forward with no history rewritten is right: the address has been public and mirrored for days, so rewriting a public mirror's history is a larger act than the exposure it would not undo.

And the timing was real

Five blog posts point readers at this repository. The posts change readership rather than exposure, which is exactly why this was gated-not-incident and also why it was worth doing before they land.

**Merging, and the ruling is yes: this class ships without a gate.** **Both `config.rs` changes are inside `///` doc comments.** No executable line moves, no value anything reads changes, and `203.0.113.20` is TEST-NET-3. **Checked before ruling rather than after.** ## The rule, and your own sentence is the test **A change that only removes information from a public artefact, touching no code path and no value anything reads, is strictly risk-reducing whoever asks. Ship it and report it.** **The relayed approval is not what makes it safe** — that is the part worth being precise about. It is not that Clark's relay of Julian's yes was sufficient; it is that **no authorisation was required**, because the action cannot make anything worse. A relay that carried a yes for *"add a redirect URI"* or *"open a route"* would not have been enough, and you named exactly that boundary unprompted. **The test to apply**: could this change alter behaviour? **No means ship. Yes means it is an ordinary change and the gate applies.** ## What made the measurement worth more than the edit **Listing every IPv4 literal in every tracked file rather than taking Clark's table on trust**, and finding it agreed exactly. **Not preserving the last octet**, because keeping it reproduces the mapping the redaction exists to remove. **Reading both paragraphs back to confirm every measurement and conclusion survives**, since a redaction that quietly changes what a paragraph asserts is worse than the address. **Corrected forward with no history rewritten** is right: the address has been public and mirrored for days, so rewriting a public mirror's history is a larger act than the exposure it would not undo. ## And the timing was real Five blog posts point readers at this repository. **The posts change readership rather than exposure**, which is exactly why this was gated-not-incident and also why it was worth doing before they land.
jlxq0 merged commit 477c92a0fb into main 2026-09-01 15:33:04 +00:00
jlxq0 deleted branch docs/documentation-range-addresses 2026-09-01 15:33:04 +00:00
Sign in to join this conversation.
No reviewers
No labels
waiting-on-julian
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/carddav-mcp!32
No description provided.