[Gerrrt]

prometheus and oracle were both recorded as Ubuntu 24.04.3 while both were
running 24.04.4 — lsb_release -ds on each, 2026-09-03. check_docs.py
could not see it: assertion 5 compares hardware.md's compute table against
network.md's segment tables, and the two copies were stale together. Found
while checking oracle for #94.

Which of the two fixes

Correcting the four cells buys about as long as the next point release, so this
takes the other option: stop recording a fact that changes without anyone
touching this repository.

	Before	After
prometheus, oracle	Ubuntu Server 24.04.3	Ubuntu Server 24.04 LTS
Saruman	Proxmox VE 9.2.11	Proxmox VE 9

The release line changes only on a decision to rebuild, which is an edit to
this repository. The running version is already collected on every Linux host
as node_os_info{pretty_name="Ubuntu 24.04.4 LTS"}, from the same Alloy agents
that produce everything else here, so nothing is lost by not duplicating it.

Saruman gets the same treatment for the same reason. VLAN 30 is not reachable
from the monitoring host, so that row is truncated rather than re-verified —
but node_os_info reports it as Debian 13 (trixie) on a 7.0.14-12-pve
kernel, which is PVE 9, so the shorter claim is the one the telemetry actually
supports and the longer one never was.

The recurrence guard

A third version component in either table is now a check failure rather than a
house rule nobody can see, and the message names node_os_info as the place to
look for a patch level. os_key() needed no change — it already compares
family and version rather than the string, and 24.04 compares equal across
the two documents' different phrasings.

Verified the way a new rule should be: reintroducing 24.04.4 in each document
in turn, and watching it fail on that document.

docs/network.md gives prometheus the OS 'Ubuntu 24.04.4 LTS' — that column
records the release line, not the point release, which goes stale the next time
the host takes an update. node_os_info carries the running one

make lint and make validate both pass.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The new point-release detection in check_docs.py can miss point releases when a host appears multiple times in docs/network.md because it only inspects the first occurrence per host.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR updates the documentation to record OS release lines (e.g., “Ubuntu 24.04 LTS”, “Proxmox VE 9”) instead of point releases, and extends the docs consistency check to fail if a point release is recorded in either docs table.

Changes:

• Update OS entries in docs/network.md, docs/hardware.md, and docs/architecture.md to remove point-release pinning.
• Extend scripts/check_docs.py compute-table check to reject OS cells containing a 3+ component version (point release), with a clearer assertion message.

File summaries

File	Description
scripts/check_docs.py	Adds a guard to reject point-release OS values in compute/network docs tables.
docs/network.md	Replaces Ubuntu/Proxmox point releases with release-line values in segment tables.
docs/hardware.md	Replaces point releases with release-line values and documents the rationale in prose.
docs/architecture.md	Updates the Saruman OS mention to “Proxmox VE 9” to match the new rule.

Review details

• Files reviewed: 4/4 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Gerrrt]

Overlaps with #252, which edits the same two rows for a different reason — the oracle line in network.md's VLAN 99 table (Role cell there, OS cell here) and the Saruman/oracle rows in architecture.md's host table. Whichever merges second needs a rebase; the conflicts are cell-level and adjacent, not contradictory. I'll do it as soon as the first one lands.