The host inventory still calls oracle a spare, five days after ADR-0011 put the wiki on it

[Gerrrt]

Area

Documentation

What should happen

docs/network.md and docs/architecture.md should agree with docs/adr/0011-keep-the-wiki-internal.md about what oracle is for.

What happens instead

They contradict it, and the ADR is the newer document.

docs/adr/0011-keep-the-wiki-internal.md:7 opens its Context by stating where the wiki runs, and the whole decision rests on it:

The Lemmiwinks wiki documents this estate, and it runs inside it — a container on Oracle at 10.0.99.30, on VLAN 99, behind the same firewall, switch and power as everything it describes.

It leans on that again eight lines later — "pfSense down: no docs. Oracle down: no docs. Power cut: no docs." The ADR is Accepted, and "the docs die with the host" is the premise the paper break-glass tier was justified with.

Meanwhile:

File	Line	Says
docs/network.md	89	Role column for oracle: Spare / undecided
docs/network.md	101	"oracle has no assigned role yet — see roadmap."
docs/architecture.md	167	Stack (none yet), Contents Undecided
docs/architecture.md	20	Diagram node: oracle · spare

So the repository simultaneously documents oracle as hosting the service that an accepted ADR is built around, and as having no assigned role at all.

Why it is the inventory that is stale, not the ADR

9a79626  2026-08-26  ADR-0011: keep the wiki internal, put the emergency tier on paper
b2dd6db  2026-08-21  docs: colour every VLAN reference to match the rack   <- last touch of
                                                                              network.md and
                                                                              architecture.md

The ADR is five days newer than the last edit to either inventory page. Neither was revisited when it landed. docs/hardware.md is not affected — it records specs, not roles, and its oracle row is correct.

Knock-on

• Decide what oracle is for #94 "Decide what oracle is for" is premised on the machine being unassigned. If the wiki has been running on it all along, that issue is at least partly already answered, and its framing should probably change rather than stay open as written.
• Deploy Alloy to Saruman and oracle #88 "Deploy Alloy to Saruman and oracle" is unaffected, but worth noting that oracle is a host with a live service on it rather than a spare — which changes how casually it can be rebooted.
• Should network documentation be discovered rather than hand-maintained? #153 "Should network documentation be discovered rather than hand-maintained?" — this is a clean worked example for that discussion. Nothing was wrong when written; two hand-maintained tables simply were not revisited when a third document changed the facts. That is precisely the failure mode Should network documentation be discovered rather than hand-maintained? #153 is asking about, and it went unnoticed for five days in a repo that is otherwise careful.

Suggested fix

Set the Role column and the Stack/Contents row for oracle to reflect Wiki.js, update the diagram node, drop the "no assigned role yet" note, and re-word #94.

---

Found while reconciling machine specs in the wiki against docs/hardware.md. The wiki's own pages were right about this and the discrepancy was in here, which is worth saying plainly since the reverse is usually true.

[Gerrrt]

#162 is fixed and merged (#163). While in scripts/check_docs.py for that, I found why this one could never have been caught — and it is not an oversight, which is what makes it worth writing down.

Two independent reasons it was invisible

1. ADRs are out of scope by design. The module docstring is explicit:

Only present-tense documents are checked. docs/roadmap.md and docs/adr/ record what was true when the work landed

That reasoning is sound and I would not change it — the comment goes on to explain that failing on those would need an ignore list, and cites the .gitleaksignore lesson for why that is worse. But it means ADR-0011 saying "a container on Oracle at 10.0.99.30" can never be compared against network.md saying "Spare / undecided". The two documents are on opposite sides of the checked boundary.

2. Even in scope, the Role column is checked by nothing. Assertion 5 compares docs/hardware.md's Compute table against docs/network.md, and what it compares is host presence and the OS string — os_key(row[4]) against os_key(row[5]). Roles are never read, by that assertion or any other.

So oracle could be simultaneously "hosts the wiki" and "no assigned role yet" while every one of the six assertions passed, twice over.

The shape of it

An accepted ADR changed a present-tense fact, and nothing connected the decision to the tables that record that fact. The gap is not between documents and configs — which is what check_docs.py covers well — it is between a decision and the documents it invalidates.

Worth noting the asymmetry: #162 was two hand-maintained rows that disagreed with physical reality, catchable only by looking at the rack. This one is two hand-maintained rows that disagree with another file in the same repository, and it still needed a human reading both. That is the more troubling of the two.

Both belong in #153. For that discussion, the useful distinction may be that discoverable facts (what is on the network, at what address, running what) and decided facts (what a machine is for) fail differently and probably need different mechanisms — the first can be polled, the second cannot.