claudetools/wiki/clients/scileppi-law.md

type, name, display_name, last_compiled, compiled_by, sources, aliases

type	name	display_name	last_compiled	compiled_by	sources	aliases
client	scileppi-law	The Law Offices of Chris Scileppi	2026-07-02	Howard-Home/claude-main	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	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.