[Gerrrt]

Plans the NAS, and builds nothing. Closes #95 by answering its four questions in
ADR-0016.

The starting point was the enforced ruleset on morpheus rather than the prose
about it — ADR-0013's method — and it changed two of the answers.

50→40 is not a rule to add

Hicks and Winterfell each carry an explicit Block access to CasaBonita above
their catch-all:

block drop in quick on igc0.50 inet from <OPT2__NETWORK> to <OPT3__NETWORK> \
  label "descr=Block access to CasaBonita" ridentifier 1760994115

So the pass has to be ordered in front of a deny, not appended. One added
where new rules naturally land — next to Allow internet — would match nothing,
which is exactly the fault ADR-0013 found in Allow Hicks access to
ImaginationLAN, a rule that has done nothing since it was written. The failure
mode is a firewall that looks configured and a NAS that is unreachable.

One rule is not enough

Every other host in the estate is monitored and backed up by pushing —
Saruman, oracle and prometheus all run Alloy agents that remote_write to
10.0.99.20:9090 and push to :3100. Build the NAS the way the others are
built and its agent initiates 40→99: the first upward path in the estate, and
the end of the property ADR-0008 claims to keep when it says "nothing untrusted
ever initiates upward".

The ADR reverses the direction instead. node_exporter scraped over
99→40:9100 rather than Alloy pushing; the metadata backup pulled by
prometheus over 99→40:22 rather than sent. Three rules, all inbound, all host-
and port-scoped — and deliberately not created, because a pass to an address
with nothing behind it is a rule nobody can test.

That costs the NAS its logs. Loki has no pull, and its ingest is unauthenticated
(ADR-0012), so a 40→99:3100 rule would not just move logs — it would let
anything reaching the NAS write to the log store the rest of the estate is
judged by. The NAS gets metrics and no logs, which makes it the one host whose
compromise is invisible. Named rather than absorbed.

The rest

• Capacity — a four-bay chassis with two bays filled. The bay count is the
  half that cannot be changed later; the library's size is a number nobody has,
  and an ADR that names a drive capacity is wrong within a year.
• Redundancy — a ZFS mirror, for availability rather than durability, and
  the ADR says out loud that a mirror is not a backup.
• Backups — the library is not backed up. It is terabytes and replaceable,
  and that is the whole reason ADR-0008 allowed it on the segment with the
  televisions; oracle has 67 GB behind a 100 Mb/s NIC and could not hold it if
  it were wanted. The Jellyfin database and configuration are, encrypted on the
  NAS with age -r so a VLAN 40 host holds ciphertext and no key.
• Terminal — it was never a property of the segment, it is a property of a
  direction. CasaBonita stops being terminal inbound and stays terminal
  outbound; TerminalSegmentReachedInternalNetwork cannot fire — the firewall logs blocks only #223's tripwire is untouched, and its counter staying at zero after
  the rules land is the test.
• Jellyfin alone, with Plex deferred against a test rather than rejected —
  it authenticates clients through plex.tv even on a LAN, in an estate that
  went to the trouble of keeping the wiki internal.
• Ubuntu and one compose stack, not TrueNAS — oracle's hand-made wiki
  containers are what an appliance OS costs, and they took until Put the wiki on oracle into the repository, and back up its database #251 to become
  visible.

One disagreement with the issue

#95 opens by calling the NAS "the first machine in the estate holding data whose
loss would actually matter". ADR-0008 already ruled the opposite way — this data
is replaceable, which is why it is allowed on 40 at all — and the machine whose
loss matters is the sensitive-tier box on Winterfell. Keeping that distinction
is what lets the backup answer be as small as it is.

Verification

make check-docs and ./scripts/lint.sh both pass. Nothing was changed on
morpheus, and no hardware was bought.

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

There are documentation clarity/correctness issues in the updated roadmap and network text that could mislead readers about directionality and intent.

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

Pull request overview

Adds a new ADR documenting the planned NAS placement on VLAN 40 (CasaBonita) and updates existing documentation to reflect that plan, without making any infrastructure/config changes.

Changes:

• Add ADR-0016 describing the NAS plan, directionality constraints, and proposed firewall rule intent.
• Update the roadmap entry for #95 to reference ADR-0016 and summarize the key conclusions.
• Update the CasaBonita section in docs/network.md to include the planned NAS host/IP and link to ADR-0016.

File summaries

File	Description
docs/roadmap.md	Expands the #95 roadmap item with ADR-0016 reference and a detailed summary of the revised plan.
docs/network.md	Adds planned NAS hostname/IP for VLAN 40 and explains intended impact relative to existing segmentation docs.
docs/adr/0016-open-casabonita-inward-and-keep-it-terminal-outward.md	New ADR capturing the NAS-on-VLAN-40 decision, constraints, and operational implications.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 2
• Review effort level: Lite

---

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