vh
b9988a7bef
The OEM SFP-H10GB-CU3M between ESH-Media SFP+1 and UDM SFP+2 linked cleanly at 1000 with zero errors on both ends, which rules out a damaged cable — a marginal one links at 10G and throws CRCs rather than dropping a rate. The switch reported sfp_compliance "Unknown": it reads the EEPROM but cannot parse the compliance codes on a third-party cable wearing Cisco coding, so autoneg falls back to the safe rate. A TP-Link TL-SM5220 DAC on the adjacent UDM port runs at 10000 with the same speed_caps and autoneg on, which exonerated the port, the firmware and autoneg before anything was changed. Forced autoneg off / 10000 / full duplex on the UDM end only. ESH-Media's end followed to 10000 on its own, which is the proof the cable was always capable and only the negotiation was wrong. Both ends now 10000. The UDM end was chosen because it is the recoverable one: ESH-Media reaches the controller through this link, so a failed force there would strand the switch. The path to the UDM was traceroute-verified not to cross the link, and the revert payload was written before the forward one was sent. Cost ~60 s of link renegotiation. ESH-Media, the E7-ESH-Media AP and the USW Flex XG ESH-Office-Vuong all returned at uplink_speed 10000 with uptimes unbroken; the Zigbee coordinator and HA's path to it were re-verified. ⚠ The port is now pinned: a non-10G module will not link there. Documented, along with the ~200 link-up errors that then went flat and the fact that steadily climbing errors would mean the cable genuinely cannot do 10G.
docs/
Navigation map for the documentation tree. New session? Read
orientation.md first — it's the narrative overview
of the fleet, backup architecture, governing principles, and gotchas,
and it points at everything else.
Tree
docs/
├── orientation.md # start here — fleet overview + where-to-look guide
├── runbooks/ # ops runbooks (recovery, deployment phases)
│ ├── disaster-recovery.md
│ ├── nh3-prune-ritual.md
│ └── pbs-deployment.md
└── pfi/ # PFI-specific reference (services, models, VMs)
├── docker-stack.md
├── model-list.md
├── proxmox-vms.md
├── recommended-model-settings.md
├── vm-102-matrix-appservice.md
└── vm-102-matrix-synapse.md
What goes where
runbooks/— step-by-step ops procedures. Anything you'd reach for during an incident or while standing up new infrastructure. Examples: disaster recovery (blast-radius tiers + restoration steps), PBS deployment (9-phase rollout). New runbook → new file here.pfi/— PFI-specific reference material that's too narrow for the top-level CLAUDE.md but doesn't change incident response. AI model inventory, recommended inference settings, Matrix bridge config, Proxmox VM map. New stable reference → new file here.- Top-level (
docs/orientation.md,docs/README.md) — narrative guides about the workspace itself, not about specific infra.
Cross-references
- Fleet topology + servers table: top-level
CLAUDE.md. - Open work + recent milestones: top-level
STATUS.md. - Durable cross-session facts:
~/.claude/projects/-home-lkraven-development-eshpfi-management/memory/.
Conventions
- Markdown, GitHub-flavored. CommonMark renders fine in most viewers.
- File names are lowercase-kebab-case, descriptive. No dates in filenames — git history covers that.
- One topic per file. If a file grows past ~500 lines, look for a natural split before adding more.
- No checked-in binaries or checksums. Build/release artifacts belong
in a build pipeline or
tools/, notdocs/.