---
type: client
name: scileppi-law
display_name: The Law Offices of Chris Scileppi
last_compiled: 2026-07-02
compiled_by: Howard-Home/claude-main
sources:
  - clients/scileppi-law/session-logs/2026-05-07-howard-sylvia-mac-mini-mail-memory.md
  - clients/scileppi-law/session-logs/2026-07/2026-07-01-howard-sylvia-server-mount-nosleep-screenconnect.md
  - clients/scileppi-law/session-logs/2026-07/2026-07-02-howard-scileppi-internet-outage-cox-wan-rca.md
  - clients/scileppi-law/docs/overview.md
  - clients/scileppi-law/docs/issues/log.md
  - clients/scileppi-law/PROJECT_STATE.md
  - session-logs/2026-06/2026-06-16-mike-scileppi-downloads-amt-harness.md
aliases: [scileppi]
---

# The Law Offices of Chris Scileppi

## Overview

- **Business type:** Law firm (small; Apple-leaning user environment).
- **Site:** 115 W Washington Street, Tucson, AZ 85701.
- **Email domain:** scileppilaw.com.
- **Syncro Customer ID:** 9601863.
- **Billing model:** Recurring monthly managed-services agreement (~$481.10/mo, billed ~12th of the month) **plus** break-fix time-and-materials labor on top. **No prepaid hour block** (`prepay_hours = 0.0`, verified live 2026-07-02).
- **Labor rates:** Remote $150/hr (product 1190473); Onsite $175/hr (product 26118).
- **Managed devices (Syncro assets):** 1.
- **Open tickets (Syncro, live):** 0 as of 2026-07-02 — see Active Work.

## Contacts

| Name | Role | Contact | Notes |
|---|---|---|---|
| Andrew Ross | Primary contact | andrew@scileppilaw.com · (520) 449-8446 · mobile (971) 218-6707 | Main point of contact for the firm |
| Chris Scileppi | Owner / attorney | — | Client namesake |
| Sylvia | Employee | — | Primary user of the Mac mini; single local account `sylvia` (uid 501) |

Invoice CC: info@scileppilaw.com.

> **Additional users seen on-site (verify):** the 2026-07-02 outage call found active NAS AFP sessions for **three** users — `sylvia`, `rose`, and `andrew` — meaning the firm has at least one more device/user (`rose`) than this article previously tracked. That device is not enrolled in GuruRMM and its owner's role/contact details are unconfirmed. Follow up to identify and, if warranted, enroll it (see Open Items).

## Infrastructure

### Workstations

| Asset | Hostname | Model | RAM | Storage | OS | Status |
|---|---|---|---|---|---|---|
| Sylvia's Mac mini | `Mac-mini-2` (formerly `Sylvias-Mini`) | Apple Mac14,3 (M2 base) | 8 GB LPDDR5 (soldered — no upgrade path) | 256 GB SSD (+ external "Sylvia External" drive) | macOS 14.x | In service; enrolled in GuruRMM |

**Current state of the Mac (`Mac-mini-2`, user `sylvia`, on Wi‑Fi `en1` = `192.168.242.154`):**
- **Enrolled in GuruRMM** (agent `1386d9fd-...`) and running the **ScreenConnect** access agent (as of 2026-07-01).
- Apple Mail disabled at System Settings → Internet Accounts (Mail toggle off); Sylvia uses outlook.office.com (webmail) for daily mail — see 2026-05-07 Mail event. Do NOT re-enable Mail (see Anti-Patterns).
- Downloads and large case files are steered **off** the local SSD onto the NAS share (`/Volumes/Data/StorageTemp`) via browser download-location settings + a catch-all LaunchAgent `com.acg.downloads-to-share` (deployed 2026-06-16). 7-day Trash auto-purge (`com.acg.trashcleanup`) also deployed.
- Mounts the NAS `Data` share at `/Volumes/Data` via LaunchAgent `com.acg.mount-server` (RunAtLoad + every 300 s).
- `pmset` set to `sleep 0 / displaysleep 0` (2026-07-01) so idle display-sleep no longer drops the Wi‑Fi link.

> **Machine identity (verify):** the May 2026 record named this unit `Sylvias-Mini` (M2, 8 GB, 256 GB, macOS 14.4.1); by June 2026 it appears in GuruRMM as `Mac-mini-2` (same user `sylvia`, agent `1386d9fd-...`). Treated here as the **same unit renamed + enrolled**, with the 8 GB replacement still pending. Confirm on next onsite whether the 8 GB M2 was ever replaced.

### File server (NAS)

| Asset | Hostname | Address | Type | Storage | Shares |
|---|---|---|---|---|---|
| Office file server | `SL-SERVER` | `192.168.242.5` | Synology NAS (netatalk cedarview build; no systemd) | btrfs `/volume1` (`/dev/mapper/cachedev_0`), 25 TB pool | `Data` at `/volume1/Data` (AFP 548 + SMB 445/139) |

- Enrolled in GuruRMM (agent `0186e9d5-...`, reported os_type linux).
- Resolves reliably as **`SL-SERVER.local`**. The AFP-service Bonjour name `SL-SERVER._afpovertcp._tcp.local` is **unreliable after NAS reboots** (Synology stops advertising it) — always mount by `SL-SERVER.local`.
- As of 2026-07-02, active AFP sessions were observed for three users (`sylvia`, `rose`, `andrew`) — more concurrent users than this article's Workstations table currently documents (see Contacts note above).

### Network gear (UniFi — full cloud-managed stack)

Scileppi is an **all-UniFi site, cloud-managed under ACG's Ubiquiti account** (owner `mike@azcomputerguru.com`). It is **NOT** on the self-hosted [[uos-server]] controller (`172.16.3.29`) — do not look for it there; reach it via the **UniFi Site Manager cloud API** (`https://api.ui.com`) or `unifi.ui.com`.

| Device | Role | Model | Address | FW | Notes |
|---|---|---|---|---|---|
| `UCG-Scileppi` | Gateway / router | UniFi **Cloud Gateway Ultra** (UDRULT) | LAN `192.168.242.1` · WAN `184.183.92.165` | 5.1.19 (UniFi OS 5.1.117 / Network 10.4.57) | WAN on `eth4` port 5, 2.5 GbE. MAC `1c:6a:1b:4b:14:xx` (LAN bridge shows locally-administered `1e:6a:1b:…` in ARP — normal for UniFi OS). Adopted 2025-10-20. |
| `USW Pro Max 16 PoE` | Core switch | USW-Pro-Max-16-PoE | `192.168.242.199` | 7.4.1 | |
| `File Room` | Access point | UniFi AP | `192.168.242.121` | 6.8.2 | |
| `Sylvia Desk` | Access point | UniFi AP | `192.168.242.10` | 6.8.2 | |

- **Cloud host id (Site Manager):** `1C6A1B4B14DD0000000008CE3561000000000946A4750000000067C563E4:1543906151` · **siteId** `68f6f0d89dda23444538a492`.
- **Access / creds:** use vault **`services/unifi-site-manager`** (`X-API-KEY` header vs `https://api.ui.com`). [WARNING] The other entry **`infrastructure/unifi-site-manager-api` is stale (returns 401)** — do not use it. Owner account: `mike@azcomputerguru.com`.
- **Useful cloud endpoints:** `/v1/hosts/<id>` (device detail incl. `reportedState.wans` + `internetIssues5min`), `/v1/devices?hostIds[]=<id>` (per-device `startupTime`/`status`/`firmwareStatus`), `/ea/isp-metrics/5m?beginTimestamp=&endTimestamp=` (per-5-min WAN latency / packet-loss / downtime; range must be within the last 24h and 5-min aligned).

### Replacement Mac (planned — status verify)

- **Target spec:** M4 Mac mini, 16 GB minimum, 24 GB preferred; 256 GB SSD sufficient (512 GB optional). Quote pending as of last update.
- **Migration plan:** Migration Assistant over wired Ethernet/Thunderbolt, then reconfigure Mail with Download Attachments = None.

## Network

- **Subnet:** `192.168.242.0/24`; gateway/DNS `192.168.242.1` = `UCG-Scileppi` (see Network gear above).
- **NAS:** `SL-SERVER` = `192.168.242.5` (see File server above).
- **Sylvia's Mac mini is on Wi‑Fi (`en1`, `192.168.242.154`)**, not Ethernet. It has an unused wired port — moving to Ethernet is the durable fix for idle network drops (Wi‑Fi drops on display sleep).
- **WAN / ISP:** cable, WAN IP `184.183.92.165`. Carrier is **Cox** (`Cox Business`, **AS22773**, Phoenix) — confirmed by the WAN IP's ASN and by traceroute egress through Cox (`68.105.x`, `72.215.x`). Note: UniFi's ISP auto-detection is flaky here — it has labeled the same circuit both "Cox Business (AS22773)" and, transiently, "Comcast Cable (AS7922)". It's Cox either way; don't trust the UniFi ISP name in isolation.
- **WAN line quality is degraded (2026-07-02):** intermittent WAN packet loss — a minority of 5-min windows show loss, **spiking to ~13%** — on otherwise steady ~22–24 ms latency, plus brief (sub-minute) WAN drops. Worst event on 2026-07-02 was a **~20 s WAN downtime (2 s + 18 s samples) around 04:15–04:20 Phoenix**, with a second blip ~10:45–10:55 that recovered so fast it only left a `not_reported` telemetry gap. This produces intermittent "no internet" flags on the UCG that self-recover; the underlying fix is a **Cox circuit/signal service call**, not UniFi gear. (ISP-metrics counts vary between API pulls because UniFi backfills/recomputes the 5-min series — read the current `/ea/isp-metrics/5m` at diagnosis time rather than a cached number. A second, independent model pass — Fable 5, via subagent — re-pulled the same window and refined the first-pull figures of 90/276 lossy windows / max 6% down to the 21/283-window / max 13% / 2 s+18 s-downtime figures used above; the underlying verdict did not change.)

> **Diagnosing a Scileppi internet complaint:** `SL-SERVER` (wired, default route via the UCG) is a live in-site vantage point — its GuruRMM heartbeat is an internet up/down signal, and from it you can `traceroute`/ping to separate LAN vs WAN vs ISP (hop 1 = UCG, hop 2 = Cox CMTS). For the WAN event *timeline*, pull the UCG's `internetIssues5min` + `/ea/isp-metrics/5m` from the cloud API. Note the UCG logs a brief blip that kills its own cloud telemetry as a **`not_reported` gap**, so the console dashboard may **not** graph the most recent drop even though it happened.

## Cloud / M365

- **Mail platform:** Exchange Online / M365; domain **scileppilaw.com**. Sylvia's mailbox accessed via Outlook Web (outlook.office.com); Apple Mail deliberately disabled on the Mac.
- Tenant ID and admin details not yet documented (verify).

## GuruRMM

- **GuruRMM site:** Main Office (`WEST-MEADOW-9025`).
- **Enrolled agents (as of 2026-07-01):**
  - `Mac-mini-2.localdomain` (macOS, Sylvia's Mac) — agent `1386d9fd-ac16-423c-ada0-5abad5b61838`.
  - `SL-SERVER` (Synology, file server) — agent `0186e9d5-e1cc-4603-a81a-adb1f2230702`.
- **Off-LAN access:** the internal RMM API (`172.16.3.30:3001`) and coord API (`:8001`) are LAN-only; from off-net, drive RMM via the public endpoint **`https://rmm.azcomputerguru.com`** (same vault creds; `rmm-auth.sh` hardcodes the internal URL, so authenticate manually against the public host off-LAN).
- **ScreenConnect:** installed on `Mac-mini-2` 2026-07-01 (session `Mac-mini-2`; Company "The Law Offices of Chris Scileppi" / Site "Main Office" / Tag "Mac"). `SL-SERVER` is a headless Synology — **not** a ScreenConnect target.

## Active Work

*As of 2026-07-02, Syncro shows **0 open tickets** for customer 9601863 — all recent tickets are Resolved/Invoiced.*

| Ticket | Date | Subject | Syncro status |
|---|---|---|---|
| #32493 | 2026-07-01 | Server mount drop + no-sleep + ScreenConnect deploy | Invoiced (0.5h remote, $75) |
| #32345 | (verify) | Not covered in an on-file session log | Resolved/Invoiced |
| #32333 | 2026-06-16 | Disk-full remediation + downloads-to-share redesign | Resolved, no-charge |
| #32282 | (verify) | Not covered in an on-file session log | Resolved/Invoiced |
| #32262 | 2026-05-07 | Apple Mail memory exhaustion (interim fix) | Resolved/Invoiced (session log noted the line item was initially held un-invoiced per Mike; Syncro now shows it invoiced) |

No Syncro ticket is currently open. The one active item is an **external vendor ticket**, not a Syncro ticket: Cox service ticket `HD0000032972890` (P1, submitted 2026-07-02, awaiting Cox signal/SNR check) — see Open Items below.

## Active Projects / Open Items

| Priority | Action | Owner |
|---|---|---|
| P1 | **Cox service ticket OPEN — `HD0000032972890`** (submitted by Winter 2026-07-02) for circuit `184.183.92.165` (Cox Business, AS22773): intermittent connectivity + packet loss, requested Cox check upstream/downstream signal + SNR at the modem/ONT. Awaiting Cox. **Track this ID.** | Winter / Mike |
| P2 | Move `Mac-mini-2` to **wired Ethernet** — durable fix for Wi‑Fi idle drops (`displaysleep 0` is the interim mitigation) | Howard (onsite) |
| P2 | **Identify the "other laptop"/user found on 2026-07-02** — NAS showed active AFP sessions for `rose` in addition to `sylvia` and `andrew`; `rose`'s device is not documented or enrolled in GuruRMM. Confirm identity and enroll if warranted. | Howard |
| P2 | Verify NAS-share auto-mount from a clean login/boot now that the agent uses `SL-SERVER.local` (not exercised from scratch on 2026-07-01) | Howard |
| P2 | Confirm replacement-Mac status (was the 8 GB M2 ever replaced?); if not, spec/quote/order M4 (16/24 GB) | Mike / Howard |
| P3 | On any replacement: Migration Assistant + Mail Download Attachments = None; re-enable Mail only on 16 GB+ hardware | Howard |
| P3 | Historical: Syncro #32262 line item 42350646 ($175 × 1.0) — session log flagged it as held un-invoiced per Mike; Syncro now shows the ticket Resolved/Invoiced (verify disposition matches) | Mike |

## Key Events / History

### 2026-07-02 — Site "no internet" reports → root-caused to the Cox WAN line (not a device)

Reported: USG "reports no internet"; intermittent drops + users unable to reach the server; "another laptop" also affected. **Root cause: WAN/ISP (Cox) line quality — no equipment fault.**

- **Gateway did NOT reboot/crash:** `UCG-Scileppi` `startupTime` = 2026-06-24 (up 8 days); all four UniFi devices (UCG, USW Pro Max 16, both APs) online. `SL-SERVER` uptime 1 day (its own Jul-01 reboot), no LAN link flaps.
- **In-site verification (from `SL-SERVER`, wired):** gateway, `8.8.8.8`, `1.1.1.1`, Cox resolver all 0% loss; 20-ping sustained 0% loss; traceroute clean end-to-end through Cox (hop 2 `10.68.48.1` → `68.105.x`/`72.215.x` → Google, ~30 ms); DNS fine. So no live outage at check time — the reported drops had already recovered.
- **NAS session check:** `SL-SERVER` showed active AFP sessions for three users (`sylvia`, `rose`, `andrew`) — evidence the firm has more active devices/users than previously documented; the "other laptop" report is most likely `rose` or `andrew`, neither enrolled in GuruRMM (open item).
- **WAN telemetry (UCG cloud API):** `internetIssues5min` shows a brief WAN-downtime + packet-loss cluster ~03:50–04:25 (Phoenix, `wan_downtime` flag ~04:15) and a `not_reported` telemetry gap ~10:45–10:55 (the "one it just had that didn't report" — a blip that briefly severed the UCG's own cloud link, so the dashboard didn't graph it). `/ea/isp-metrics/5m` over 24 h: a minority of 5-min windows had WAN packet loss (**spiking to ~13%**) on steady ~22–24 ms latency, and **two downtime samples of 2 s + 18 s at ~04:15–04:20** — i.e. one ~20 s WAN drop, no multi-minute hard outage. (Counts differ between pulls — UniFi backfills the series; the ~20 s downtime and 13% spike were confirmed on a second, independent pull.)
- **Independent verification:** an independent re-gather run on a second model (Fable 5, via subagent) confirmed the core verdict (Cox line quality, gateway 8-day uptime, all devices online, clean live test) and refined the ISP-metrics counts to the figures used above (21 lossy windows of 283, max 13%, two real downtime samples) versus the coarser first pull (90 of 276 windows, max 6%, no recorded downtime).
- **ISP:** carrier is **Cox** — `Cox Business`, **AS22773** (WAN `184.183.92.165`; traceroute via Cox). UniFi's ISP name flip-flops (seen as both "Cox Business/AS22773" and "Comcast Cable/AS7922") — it's Cox regardless.
- **Action:** recommended Cox service call for line/signal quality (see Open Items P1). UniFi gear needs no change. Findings DM'd to Winter. Sylvia's Mac Wi-Fi drops are a **separate** issue (display-sleep; fix = Ethernet).
- **Cox ticket submitted (Winter, 2026-07-02): `HD0000032972890`.** Type "Trouble with Service"; Account Alias **115 W WASHINGTON**; Services Affected: Internet & Data — Intermittent Connectivity, Slow Speed/Packet Loss; requested Cox check upstream/downstream signal + SNR at the modem/ONT. Preferred contact: **Guru Admin — Winter or Mike**, callback **520-304-8300**, `admin@azcomputerguru.com`, mornings. (Ticket text quoted the first-pull figures — 90/276 windows, up to 6% — not the later-refined ~13% / ~20 s downtime; verdict and the ask to Cox are unchanged.)
- **Customer-facing update:** a findings note was posted to Syncro **#32493** (comment id 421854153, `hidden:false`, `do_not_email:false` — emailed to the customer) summarizing: cause = Cox WAN line, not on-site gear; UniFi gateway/switch/2 APs and the Synology all healthy (8-day gateway uptime); two brief drops (~04:15 and ~10:45 Phoenix) with packet loss; steady ~22–24 ms latency; Cox ticket HD0000032972890 opened; no on-site changes needed. Posted on the existing #32493 rather than a new ticket (Howard's call).
- **Doc/tooling notes:** documented Scileppi's full UniFi layer here (was previously undocumented); flagged stale vault key `infrastructure/unifi-site-manager-api` (401) — use `services/unifi-site-manager`.

### 2026-07-01 — Sylvia "can't connect to server" (dropped drive) + no-sleep + ScreenConnect

**Syncro #32493** (Howard). Reported: mapped drive gone; handled remotely via GuruRMM (public endpoint). 0.5h remote labor logged ($75).

- **Root cause:** `SL-SERVER` (Synology) rebooted ~09:34 local and was slow to bring SMB/AFP back up; while down, the Mac's AFP mount failed (error `-5014`). `/volume1` (25 TB) stayed mounted and healthy — no data risk. Services recovered on their own.
- **Recurring bug found + fixed:** the mount LaunchAgent `com.acg.mount-server` targeted the Bonjour name `afp://SL-SERVER._afpovertcp._tcp.local/Data`, which the Synology stops advertising after a reboot (NORESOLVE), while `SL-SERVER.local` resolves fine. Repointed the agent to `afp://SL-SERVER.local/Data`; retired stale duplicate agent `com.azcomputerguru.mount-slserver`. Backup: `com.acg.mount-server.plist.bak-20260701`.
- **Meta-cause of instability + fixed:** the Mac (Wi‑Fi) had `displaysleep 10`; when the display slept the Wi‑Fi link dropped (system `sleep` was already 0). Set `pmset -a sleep 0 displaysleep 0 womp 1 powernap 1 tcpkeepalive 1`. Long-term: Ethernet.
- **ScreenConnect** installed on `Mac-mini-2` (self-tagged Company/Site/Tag).

### 2026-06-16 — Disk-full remediation + downloads-to-share redesign (Mike)

**Syncro #32333** — resolved no-charge. `Mac-mini-2` had recurring home-folder/disk-full problems. Cleared Trash (358 GB) and Apple Mail cache (~27 GB); deployed a 7-day Trash auto-purge. Redesigned how downloads stay off the local disk: restored local `~/Downloads` (fixed the broken Finder favorite — the earlier server symlink was breaking it on every reboot), pointed browsers' download location directly at the share (`/Volumes/Data/StorageTemp`, Firefox via `user.js`, Safari via `defaults`), and deployed a catch-all LaunchAgent `com.acg.downloads-to-share` that moves stray downloads onto the share every 10 min via cross-volume `mv` (never routes to Trash, skips in-progress/<2-min-old files). Apple Mail needed no change — its save-panel keys already pointed at the share's per-client folders and multi-GB case files arrive via browser, not mail.
- A first customer-facing resolution comment on this ticket was sent without the mandatory preview and incorrectly mixed in another client's (AMT) Windows-cleanup details; it was deleted and rewritten accurately, previewed, and approved before resend. Logged to `errorlog.md`.

### 2026-05-07 — Sylvia's Mac mini: Apple Mail memory exhaustion

**Syncro ticket #32262** (Howard). Status: Resolved (interim).

**Root cause:** Apple Mail's local cache (`~/Library/Mail/V10/`) grew beyond what 8 GB unified RAM can service; Mail's VM footprint exceeded 45 GB on the 8 GB machine, forcing constant swap (~4.4M swapouts in 9 min uptime).

**Diagnosis:** two Envelope Index rebuilds (footprint climbed to 12 GB then 28 GB) conclusively ruled out index corruption — the mailbox itself is too large for 8 GB.

**Interim fix:** force-quit Mail, disabled Mail toggle in System Settings → Internet Accounts, verified no auto-relaunch, moved Sylvia to outlook.office.com webmail.

**Billing artifacts:** ticket #32262; resolution comment 409686752; timer entry 39082403 (3600 s); line item 42350646 ($175.00 × 1.0, non-taxable); invoice — session log noted it was held un-invoiced per Mike; Syncro now shows the ticket Resolved/Invoiced (verify final disposition matches).

## Anti-Patterns / Warnings

- [WARNING] **Mount the NAS by `SL-SERVER.local`, never the AFP Bonjour name** `SL-SERVER._afpovertcp._tcp.local` — Synology stops advertising it after a reboot, which silently breaks auto-mount (AFP error `-5014`).
- [WARNING] **The Mac mini is on Wi‑Fi and drops its link when the display sleeps.** Keep `displaysleep 0`; the real fix is wired Ethernet. Idle drops also knock the RMM agent offline, which makes remote work flap.
- [WARNING] **Do NOT re-enable Apple Mail** on the 8 GB Mac. RAM is soldered (no upgrade path) — Mail will immediately reproduce the memory exhaustion. Stays on webmail until replaced with 16 GB+ hardware.
- [WARNING] After migration to a new Mac mini, set Mail → Settings → Accounts → Mail Behaviors → Download Attachments = None; skipping this on a large mailbox reproduces the issue even on 16/24 GB.
- [WARNING] Do not restore `~/Downloads` as a server symlink — it breaks the special Finder "Downloads" favorite on every reboot (favorite caches a dead bookmark when the share is briefly unmounted at login). Use a local folder + app-level download-location settings + the catch-all mover instead.
- 8 GB M2 Mac mini RAM is soldered and not upgradeable — do not quote a RAM upgrade.
- Keep local downloads/case files off the 256 GB SSD — they belong on the NAS share (`/Volumes/Data`); the `com.acg.downloads-to-share` mover enforces this.
- Never send a customer-facing resolution comment without the mandatory preview, and never carry details from another client's ticket into Scileppi's notes (both happened on #32333 — see 2026-06-16 event).

## Backlinks

- `session-logs/2026-05-07-howard-gururmm-macos-installer-and-cf-bot-block.md` — related GuruRMM macOS installer failure (enrollment has since succeeded).
- `session-logs/2026-06/2026-06-16-mike-scileppi-downloads-amt-harness.md` — downloads redesign session (paired with AMT onboarding work, unrelated client).
- Skills: `/rmm`, `screenconnect`, `/syncro`.