Skip to content

docs(adr): two ADRs claimed 0041 — renumber the second to 0042 - #503

Merged
Gerrrt merged 1 commit into
mainfrom
gerrrt/adr-0041-duplicate-number
Sep 18, 2026
Merged

Gerrrt merged 1 commit into
mainfrom
gerrrt/adr-0041-duplicate-number

Conversation

@Gerrrt

@Gerrrt Gerrrt commented Sep 17, 2026

Copy link
Copy Markdown
Owner

What changed

The remote-path ADR is renumbered 0041 to 0042, and every reference to it
follows. The CRS326 ADR keeps 0041. Two stale counted claims in README.md
are corrected in the same commit.

No ADR prose is edited. ADR-0001 makes these immutable once accepted, and a
number is not an argument — inside the renamed file the only change is the
number in its H1.

Why

#491 and
#495 merged 56 seconds apart
on 2026-09-17 and both numbered their ADR 0041. check_docs.py catches
exactly this and says to renumber the one that landed second; the first-parent
history settles which without ambiguity:

ADR-0041 Merged via At
…run-the-crs326-on-routeros… #491 16:27:56
…terminate-the-remote-path… #495 16:28:52

main has been failing check_docs.py by itself since then, so every open
pull request inherits a red Validate configs on a fault that is not its own.
Four were open when this was written (#493, #497, #500, #501). Confirmed by
checking out origin/main alone, with no feature branch present.

The references were the actual work

The rename is mechanical. The references are not, because a bare ADR-0041 in
prose does not say which ADR it means, and both are referenced widely. The
link-carrying references were retargeted mechanically; each remaining bare
mention was read in context and moved on what it is about, not on where it
sits:

  • open-the-remote-path.md, eight mentions — that runbook is the remote path
    end to end, and names neither the CRS326 nor RouterOS anywhere.
  • restore-the-firewall.md, two — both read "ADR-0041's tunnel" / "ADR-0041's
    rules", about the WireGuard peers.
  • ADR-0011 — "from ADR-0041 onward, on a tunnel that terminates on VLAN 30".
  • ADR-0014 — "what ADR-0041 adds to this segment is a second source subnet —
    172.31.0.0/24, the WireGuard peers".
  • roadmap.md — the Guacamole decline, whose closing sentence contrasts itself
    against the remote-access answer named in the preceding clause.

Everything still reading ADR-0041 afterwards was re-checked and is the
switch: swap-the-switch.md throughout, ADR-0018, and the hardware.md and
roadmap.md rows that link the CRS326 file.

This is the part worth reviewing — a reference moved the wrong way would point
a reader at a decision about a switch when they wanted one about a tunnel, and
no check can catch that.

Blast radius

  • No change to network segmentation or firewall rules
  • No new port published to a VLAN that could not already reach the service
  • No credential added outside secrets/*.sops.yaml

Documentation only. No rule, test, compose file or script is touched, so
nothing deploys.

Verification

  • make validate passes
  • Deployed to the lab and confirmed working — n/a, documentation
  • Docs updated

python3 scripts/check_docs.py prints docs OK — 82 Prometheus + 18 Loki rules, 7 dashboards, 141 panels, 10 assertions and exits 0. The same command
on main at 3406525 reports the duplicate 0041 and both stale counts
(41 vs 42 ADRs, 26 vs 27 runbooks), which is the before-and-after this PR is
for. ./scripts/lint.sh passes all five linters, which is what covers the
relative links the rename touches.

🤖 Generated with Claude Code

#491 and #495 merged 56 seconds apart on 2026-09-17 and both numbered their
ADR 0041. check_docs.py catches exactly this and says to renumber the one that
landed second, which the first-parent history settles without ambiguity: #491
at 16:27:56, #495 at 16:28:52. So the remote-path ADR becomes 0042 and the
CRS326 one keeps 0041.

main has been failing check_docs.py by itself since then, so every open pull
request inherits a red Validate job on a fault that is not its own. That is
what this fixes; there are four open at the time of writing.

The rename is the easy half. The references are not, because a bare "ADR-0041"
in prose does not say which ADR it means, and both are referenced widely. The
link-carrying ones were retargeted mechanically, and each remaining bare
mention was read in context and moved on what it is about rather than on where
it sits:

- open-the-remote-path.md, eight mentions — that runbook is the remote path
  from end to end and names neither the CRS326 nor RouterOS anywhere.
- restore-the-firewall.md, two — both say "ADR-0041's tunnel"/"ADR-0041's
  rules" about the WireGuard peers.
- ADR-0011 — "from ADR-0041 onward, on a tunnel that terminates on VLAN 30".
- ADR-0014 — "what ADR-0041 adds to this segment is a second source subnet,
  172.31.0.0/24, the WireGuard peers".
- roadmap.md — the Guacamole decline, whose closing sentence contrasts itself
  against the remote-access answer in the preceding clause.

Everything still reading ADR-0041 afterwards was re-checked and is the switch:
swap-the-switch.md throughout, ADR-0018, and the hardware and roadmap rows that
link the CRS326 file.

The two counted claims in README are corrected in the same commit because they
were already stale on main and would fail the same check: 41 ADRs to 42, and
26 runbooks to 27.

No ADR text is edited. ADR-0001 makes these immutable once accepted, and a
number is not an argument — the only changes inside the renamed file are its
filename and the number in its H1.

Verified: python3 scripts/check_docs.py prints "docs OK — 82 Prometheus + 18
Loki rules, 7 dashboards, 141 panels, 10 assertions" and exits 0, where the
same command on main at 3406525 reports the duplicate 0041 and both stale
counts. ./scripts/lint.sh passes all five linters, which covers the relative
links this rename touches.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@Gerrrt
Gerrrt merged commit 107256f into main Sep 18, 2026
3 checks passed
@Gerrrt
Gerrrt deleted the gerrrt/adr-0041-duplicate-number branch September 18, 2026 02:37
Gerrrt added a commit that referenced this pull request Sep 18, 2026
Brings in #503, which renumbered the duplicate ADR-0041 to 0042 and was the
only thing failing this branch's Validate job. main now carries 0041 for the
CRS326 and 0042 for the remote path, and check_docs.py passes on it again.

The conflict was README.md's counted-claims bullet once more, and for the same
reason as the last merge: main had corrected the runbook count to 27 for its
own additions while this branch held 28 for those plus this one. Resolved to 28
and then read off the repository rather than reasoned about — 42 ADR files and
28 runbook files, which is what check_docs.py now agrees with.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gerrrt added a commit that referenced this pull request Sep 18, 2026
#503 renumbered the remote-path ADR to 0042 on main, the same move this
branch made, so the two agree everywhere; the one conflict was README's
counts, and the merged tree has 43 ADRs and 28 runbooks.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Gerrrt added a commit that referenced this pull request Sep 18, 2026
…s gate it

nothing the documents say. This adds the document that makes the fit provable
when it happens, and records what has actually been decided.

The layout question the issue left open is answered: the SSDs become a second
RAID 1 logical drive on the P440ar, Smart Array managed, with the 7.2K mirror
keeping Proxmox, the ISOs and the backups. That is the smaller change, it keeps
a spindle for the things that do not need IOPS, and it leaves
IloDrivePredictiveFailure, IloDriveSmartUnreadable and the
replaceDriveSSDWearOut(4) state reading cpqida.mib exactly as they do today —
so #351's decision to skip smart-state on this host stays right rather than
needing re-checking.

The runbook's "before" column is read, not assumed: every cpqDa* value in it
came out of Prometheus on 2026-09-17. That reading also sharpens #76.
cpqDaAccelWriteCachePercent has been the one column anyone looked at; the
baseline shows cpqDaAccelMemory, cpqDaAccelReadMemory and both cache percents
all at 0 against a 2 GiB module, with cpqDaLogDrvHasAccel{1} reading other
rather than enabled. Four columns agreeing is much weaker support for "the iLO
does not populate the ratio" than one was. The runbook takes the ssacli reading
that settles it and hands the finding to #76 without acting on it: modify
cacheratio= is controller-wide and would land on the array holding every guest,
and it would move two variables at once underneath the measurement.

What is deliberately not here: ADR-0029's ninety random write IOPS is derived,
not measured — seek plus half a rotation at 7200 rpm — so replacing it with a
differently-shaped measured number would be worse than leaving it alone. The
runbook measures both arrays at the parameters that derivation implies, 4 KiB
at queue depth 1, three times. Until that reading exists ADR-0029, ADR-0007,
ADR-0017 and the roadmap's #414 paragraph stand as written, and then each gets
a dated note rather than a silent edit.

The fit is blocked, and the runbook says so at the top. #498 recorded two SFF
trays bought 2026-09-11 and still in transit; a Gen9 bay holds a drive only in
a carrier, so step 4 is a stop condition rather than something discovered at
the rack. Steps 0 to 3 can all be done first, and step 2 — getting ssacli onto
Debian 13, which nothing in this repository is evidence of — is the one most
worth failing early.

README's runbook count goes to 28 for the runbook this adds. The ADR counter
and the duplicate ADR-0041 that had check-docs failing on main are both fixed
there now, by #503, so nothing about them is carried here.

Refs #418, #76, #148

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant