New Chat Handoff

Last updated: 2026-06-22

Use this as the quick bootstrap note for a new Codex/AI chat. Detailed source

of truth remains in the linked project docs.

First Instructions

We are working in C:\Users\ravic\OneDrive\GitHub\VHNIC.

Read these first:
- README.md
- NEW_CHAT_HANDOFF.md
- FUTURE_CHANGES.md
- AUTOMATION_PLAN.md
- RETENTION_POLICY.md
- INCIDENT_REGISTER.md
- SECURITY_HYGIENE_REVIEW.md
- synology/HANDOFF.md
- synology/storage/VOLUME1_REBUILD_MIGRATION_PLAN.md
- synology/docker/projects/observability-compose/CURRENT_STATE.md
- pihole/CURRENT_STATE.md
- pihole/HANDOFF.md
- unifi/HANDOFF.md
- unifi/security/PORT_FORWARDS.md
- google-cloud-dns/README.md
- synology/docker/RECYCLARR_PLAN.md
- synology/docker/PLEX_PLAYLISTS.md
- diagrams/README.md

Important rules:
- Do not delete, prune, wipe, reformat, or repair unless the exact target is
  approved.
- Do not run btrfs check --repair.
- Do not modify /volume1/data/media/personal.
- Keep credentials/private keys out of chat and tracked docs.
- Prefer read-only diagnostics before changes.
- Summarize incidents before deleting raw logs. Use RETENTION_POLICY.md and
  INCIDENT_REGISTER.md; deletion still requires exact-path approval.

Current Highlights

• Synology NAS: 10.0.0.119, SSH user codex-maint, key path

C:\Users\ravic\.ssh\codex-synology\codex-maint-synology.

• Security/breach review on 2026-06-01:
• Report: security/breach-assessment-20260601.md.
• Privileged Synology audit:

synology/security/audits/20260601-190945/synology-security-audit.txt.

• No clear evidence of compromise was found across Synology, Docker, UniFi,

Pi-hole, or Google Cloud DNS evidence.

• The audit did show Synology PasswordAuthentication yes; treat disabling

SSH password auth as a future hardening item after confirming key-based and

emergency access.

• Direct qBittorrent and direct Seerr/Overseerr public forwards should stay

disabled. Plex and Caddy HTTP/HTTPS are the intentional remaining public

exposure paths. Plex Test removal and Minecraft public-forward

disablement were approved on 2026-06-13 and documented in

unifi/security/PORT_FORWARDS.md; verify live UniFi state before claiming

the helper was applied.

• Generic UniFi client names still need normal asset labeling, not emergency

incident response.

• Seerr replaced Overseerr on 2026-05-24.
• Active container: seerr
• Image: ghcr.io/seerr-team/seerr:latest
• Appdata: /volume1/docker/seerr
• Host port: 5055
• Public URL: https://overseerr.ravick5.com
• Public route: UniFi 80/443 -> Synology 8088/8443 -> Caddy -> seerr:5055
• Legacy overseerr container is stopped/replaced by Seerr, and old

Overseerr appdata/backups were removed on 2026-06-01 during stale Docker

cleanup.

• Seerr image caching remains disabled because it can consume large disk space.

Caddy instead sends:

Content-Security-Policy: upgrade-insecure-requests; block-all-mixed-content

to avoid browser mixed-content warnings where possible.

• Seerr Discord request notifications were configured on 2026-06-01 using the

protected Discord webhook already stored on the Synology. The helper backed

up Seerr settings first and did not print the webhook. Seerr still needs a

restart before the notification setting is active:

synology/docker/seerr/Enable-SeerrDiscordNotifications.ps1 -Apply -RestartSeerr.

• Caddy reverse proxy source:

synology/docker/projects/reverse-proxy-compose.

• 2026-05-30 post-reboot recovery note:
• DSM/SSH/Plex hung badly enough that the NAS required a front-panel forced

power-off after graceful shutdown did not complete.

• After reboot, Plex had to be started manually.
• Reverse proxy failed because

/volume3/docker/reverse-proxy/Caddyfile was missing.

• Monitoring failed because

/volume3/docker/observability/secrets/discord-alerts.env and

/volume3/docker/observability/secrets/unifi.local.env were missing.

• The files were restored from the local project/protected secrets and the

user reported all monitoring items green.

• Incident summary:

incidents/2026-05-30-synology-service-hang-volume3-restore/SUMMARY.md.

• Deep-dive findings:

incidents/2026-05-30-synology-service-hang-volume3-restore/DEEP_DIVE_FINDINGS.md.

• Current interpretation: the visible failure was DSM's backend/API stack

becoming unresponsive behind nginx. The unresolved risk is persistent

Volume 1 Btrfs metadata corruption at logical block 56885910093824; the

deep-dive did not show a clean md RAID failure, OOM kill, or SATA reset

storm immediately before the timeout window.

• Root cause is not proven. The existing logs explain the failure mode but

not the first domino. The main evidence gap is missing pre-reboot live

state plus no prior Prometheus ingestion of Synology nginx/Btrfs/core-dump

log patterns.

• A read-only synology-log-exporter is live in the monitoring project. It

alerts on recent synoscgi timeouts, Btrfs errors outside the known block,

core dumps, and storage timeout/reset language. Initial verification after

repair showed Prometheus 39/39 targets up, 0 active alerts, and 22

alert rules loaded.

• Do not reassure the user that this cannot recur. Treat recurrence risk as

moderate until Synology support or a Volume 1 rebuild/migration plan

resolves the Btrfs metadata issue.

• 2026-06-14 Plex buffering / Volume 1 storage incident:
• Multiple Plex users saw buffering while Plex API/timeline requests were

responsive and CPU/GPU were not saturated.

• Analysis points to intermittent Volume 1 storage stalls: recurring Btrfs

metadata errors for logical block 56885910093824 and md2 self-heal

retries/give-ups while DSM still reports the array active.

• Support-case bundle:

synology/support-cases/20260614-volume1-btrfs-md2/.

• Keep destructive storage repair off the table. Do not run

btrfs check --repair.

• Until Synology support or a Volume 1 rebuild/migration plan resolves it,

reduce write-heavy Volume 1 activity during Plex viewing and treat

direct-play buffering as likely storage-related before tuning Plex.

• 2026-06-16/17 Volume 1 evacuation and rebuild planning:
• Synology Support reviewed the NAS debug logs and reported thousands of bit

flip errors dating back to March 2026. They identified unsupported Crucial

CT16G4SFRA266.C8FF RAM as a likely contributor.

• The user removed the unsupported RAM after an accidental shutdown while

checking the rear of the NAS. Synology's recommended direction is still:

back up accessible data, remove/recreate the affected Volume 1, and restore.

• A DX1222 was added and Volume 4 temp_media was created as a temporary

RAID 6/Btrfs landing zone for Volume 1 evacuation.

• Temporary landing root:

/volume4/migration-from-volume1.

• The copy is running locally on the Synology with rsync, not through the

Windows desktop.

• Critical was copied first:

/volume1/data/media/personal, /volume1/data/media/photos, and

/volume1/data/work.

• An unattended queue was launched:

Start-Volume1ToVolume4MigrationQueue.ps1 -Profile InitialRemainder.

Queue log:

/volume4/migration-from-volume1/_runs/20260616-224332-queue-InitialRemainder.out.

• The latest pasted status around 2026-06-17 00:34 EDT showed the active

item as /volume1/docker, with rsync reporting about 16.32G processed at

3.44MB/s. This is slow but expected for live appdata with many small

files.

• Use this status helper:

tools/synology/Get-Volume1ToVolume4MigrationStatus.ps1.

Its default includes a capped destination size scan; a trailing

Terminated ( du ... ) line is expected when the optional 20-second size

scan times out.

• Next recovery steps are tracked in:

synology/storage/VOLUME1_REBUILD_MIGRATION_PLAN.md.

• Do not delete/recreate Volume 1 until the queue, true-up, final stopped

true-up, and validation steps are complete.

• 2026-06-21/22 container/appdata placement update:
• Current project docs show most non-Plex container appdata/projects/secrets

staged or moved to the Volume5 SSD role under /volume2/docker-v5.

• Plex and Tautulli appdata now run from Volume3 under /volume3/docker.
• The old /volume2/VM Storage Plex/Tdarr data is rollback evidence unless a

current doc says otherwise.

• qBittorrent/Gluetun are staged on Volume5 but should remain stopped until

torrent payload handling is resolved.

• Follow-up item: verify DSM's displayed Volume5 name/number versus the

/volume2/docker-v5 path before removing old Volume2/VM Storage references.

• Synology storage warning:
• Active Insight reported `[Critical] Btrfs checksum inconsistency was

detected - Vick-NAS at 2026-05-29 02:28 EDT`.

• Fresh read-only snapshot:

synology/system/privileged-health/20260529-081538.

• /volume1 still shows the known scrub baseline: 48.21TiB scrubbed,

35,311 checksum errors, 0 corrected, 35,311 uncorrectable.

• md2 RAID6 is active/non-degraded with all eight members present.
• Kernel logs still reference the known Btrfs metadata block

56885910093824 in root/subvolume 262; do not run btrfs check --repair

on the live filesystem.

• Seerr now runs as service seerr inside the media-project project:

/volume1/docker/projects/arrs-compose/compose.yaml.

The old standalone seerr-compose folder is retained only as migration

documentation.

• NZBHydra2 is part of the media-project Compose project as service

nzbhydra2; its appdata remains /volume1/docker/nzbhydra2 and host port

remains 5076.

• Grafana/Prometheus observability runs on Volume 3 at

http://10.0.0.119:3000. On 2026-05-25, storage-integrity and

observability-stack-health dashboards were added using existing Prometheus

metrics; no new agent was required.

• Homepage is the primary internal portal at http://10.0.0.119:7576.
• It replaced the Homarr pilot on 2026-06-03.
• Synology Container Manager project: homepage.
• Tracked source: synology/docker/projects/homepage-compose.
• Synology project path: /volume1/docker/projects/homepage-compose.
• Runtime config/secrets: /volume3/docker/homepage/config and

/volume3/docker/homepage/secrets/homepage.env.

• It includes service launchers, live widgets, Grafana dashboard shortcuts,

runbook/safety cards, and diagram references.

• Homarr container/appdata were removed; do not recreate Homarr unless the

user explicitly decides to revisit that tool.

• Bazarr subtitle pilot was retired on 2026-06-14.
• It had been added to media-project on 2026-06-03 and hardened on

2026-06-05, but continued to create logging noise and had no proven value

in the current workflow.

• The tracked media-project compose no longer includes Bazarr.
• Homepage and Prometheus should no longer expect a Bazarr card/probe.
• Keep Bazarr scripts/runbooks as historical reference; do not recreate it

unless the user explicitly reopens subtitle automation.

• Lidarr naming was reviewed on 2026-06-04. Lidarr is active inside

media-project, appdata is /volume1/docker/lidarr, root folder is

/data/media/music, and its database integrity check passed. Track renaming

was enabled with the preferred format:

{Album Title} ({Release Year})/{Artist Name} - {Album Title} - {track:00} - {Track Title};

multi-disc uses {medium:00}-{track:00} in the filename. A full-library

rename was launched as artist-scoped RenameFiles commands. Ignore the

first failed all-files command with artistId=0; follow-up checks should

look at Lidarr command history/logs for RenameTrackFileService.

• Lidarr had repeated transient SQLite database is locked log entries on

2026-06-04 despite a clean DB integrity check. If those continue when the NAS

is otherwise calm, investigate Lidarr load/storage behavior.

• Audiobook stack was added on 2026-06-04 and promoted as an internal

production service after the initial POC proved the shape.

• Compose source: synology/docker/projects/audiobook-compose.
• Synology project path: /volume1/docker/projects/audiobook-compose.
• Active service: audiobookshelf.
• Retired services: readairr, readairr-postgres, removed from active

runtime/monitoring on 2026-06-14 after repeated expensive rescans and bad

imports.

• Audiobookshelf URL: http://10.0.0.119:13378; library path inside the

container is /audiobooks/books.

• Current media folder: /volume1/data/media/audiobooks/books, physically

reorganized into author/title and author/series folders on 2026-06-04.

• Separate ebook folder: /volume1/data/media/books.
• Treat audiobook ingestion as manual/staged through the reviewed

Need_Processing workflow unless the user explicitly reopens automation.

• Audiobookshelf is intended to be reachable externally at

https://audiobooks.ravick5.com for ShelfPlayer after DNS/proxy deployment

and hardening review.

• Reading stack was prepared on 2026-06-05 as a production-style internal

project rather than a temporary POC.

• Compose source: synology/docker/projects/reading-compose.
• Synology project path: /volume1/docker/projects/reading-compose.
• Planned Container Manager project name: reading.
• Planned services:
• Kavita: http://10.0.0.119:7578, appdata

/volume3/docker/kavita/config, media mount /books is read-only.

• Mylar3: http://10.0.0.119:8091, appdata

/volume3/docker/mylar3/config, comic/manhwa mounts are writable for

future management.

• Media roots:
• /volume1/data/media/books
• /volume1/data/media/books/comics
• /volume1/data/media/books/manhwa
• Mylar3 must stay disconnected from Prowlarr, NZBGet, and qBittorrent until

the user explicitly approves an acquisition workflow. Kavita/Mylar3 are

internal-only and should not be exposed through Caddy yet.

• Container footprint direction as of 2026-06-07:
• Avoid adding more containers unless there is a clear operational, security,

or maintainability reason.

• Do not combine reader-facing apps with admin/automation apps just to reduce

the visible container count.

• Audiobookshelf and Kavita are the likely durable reader/player apps.
• ReadAIrr was retired on 2026-06-14; Mylar3 is the remaining future

retirement candidate if it does not prove useful after the trial/metadata

workflow settles.

• Architecture note:

synology/docker/CONTAINER_FOOTPRINT_REVIEW.md.

• 2026-06-11 book/audiobook audits:
• Audiobookshelf fresh audit:

manual-missing-reports/audiobookshelf-fresh-audit-20260611-150336.md.

Current baseline is 588 books, 106 series, 12 collections, 0

missing/invalid items, 0 duplicate paths/authors, and 0 missing book

covers.

• Acquisition gap report:

manual-missing-reports/missing-acquire-report-20260611-150336.md.

Strongest audiobook acquisition targets include current Discworld, Drizzt,

James Patterson, Maximum Ride, Daniel X, Witch & Wizard, Secret Projects,

and selected Orson Scott Card/Star Wars/Oz/DemonWars gaps.

• Kid-safe audiobook review:

manual-missing-reports/kid-safe-audiobook-list-20260611.md.

Suggested child account model is allowlist tags, not a denylist.

• Kavita fresh audit:

synology/docker/projects/reading-compose/inventory/snapshots/kavita-audit-20260611-150919/kavita-audit.md.

Current baseline is 512 series / 954 files across four libraries, with

_Needs Metadata Review still excluded from Books.

• On 2026-06-01, backup freshness metrics, VHNICBackupStale, optional

non-paging probes for 10.0.0.126 RDP/SMB, and the `VHNIC Backup and

Optional Node Health` dashboard were deployed. The correct Pi-hole backup

path is /volume1/data/media/backups/pihole. Post-repair verification showed

Prometheus 41/41 targets up and 0 firing alerts.

• Discord alert notification plumbing was installed and test-posted on

2026-05-25:

Prometheus -> Alertmanager -> discord-alert-bridge -> Discord webhook.

Only warning alerts are intended for Discord; info alerts remain dashboard

only. Webhook secrets belong in ignored/protected .env files, not tracked

docs.

• Prometheus alert rules were tuned on 2026-05-27:
• VHNICDiskBusySustained is now info-only, >95% for 1 hour.
• VHNICStoragePressureHigh is the Discord warning, requiring disk busy

>95% plus CPU I/O wait >20% for 30 minutes.

• VHNICExpectedContainerMissing warns if any expected always-on container

disappears from cAdvisor for 5 minutes; Recyclarr is intentionally excluded.

• VHNICContainerRestartingOften warns if an expected container restarts

more than twice in 30 minutes.

• Exporter/service probe warnings wait 5 minutes.
• Volume usage warning waits 30 minutes.
• Reload verification on 2026-05-29 after Dispatcharr retirement showed

17 rules loaded, 0 active alerts, and 0 down Prometheus targets.

• Docker images were refreshed on 2026-05-27. Container wrappers were replaced

from Compose projects while preserving bind-mounted appdata. qBittorrent

5.2.1_v2.0.12-ls459 was tested but failed to bring up the qBittorrent

WebUI/app cleanly, so it was rolled back to

linuxserver/qbittorrent:5.1.4-r3-ls453. Details:

synology/docker/IMAGE_UPDATE_LOG.md.

• qBittorrent is protected from Watchtower updates with

com.centurylinklabs.watchtower.monitor-only=true while still declaring

com.centurylinklabs.watchtower.depends-on=gluetun. Compose also has

depends_on.restart: true for explicit Gluetun Compose restarts.

• Container Manager project alignment as of 2026-05-29:
• media-project: Sonarr, Radarr, Prowlarr, Lidarr, NZBHydra2, Seerr, and

NZBGet.

• monitoring: Grafana, Prometheus, Alertmanager, cAdvisor, Blackbox,

Node exporter, Tdarr/Tautulli/UniFi exporters, Discord alert bridge.

• vpn-project: Gluetun and qBittorrent.
• plex: Plex and Tautulli.
• tdarr: Tdarr remains separate. Source folder is still

/volume2/VM Storage/projects/tdarr-compose, but Compose project name is

explicitly tdarr.

• watchtower: intentionally separate and running, with qBittorrent protected

by Watchtower monitor-only labels.

• On 2026-05-27, the user imported/registered the missing monitoring,

tdarr, and reverse-proxy-compose rows through Synology Container

Manager, so DSM Project view and Docker Compose labels now agree.

• Recyclarr was removed from media-project on 2026-05-27 because its normal

stopped state made DSM mark the project as needing attention. Appdata

remains at /volume1/docker/recyclarr; run Recyclarr manually/controlled

when needed.

• Dispatcharr was removed from media-project on 2026-05-29 because the IPTV

provider will not be renewed. The container was removed with Compose

--remove-orphans, monitoring expected-container rules were updated, and

stale appdata at /volume1/docker/dispatcharr was removed on 2026-06-01

after exact approval.

• Homebridge review and migration were completed on 2026-05-28:
• It used to be Synology Package Center package homebridge version 4.1.2.
• Live appdata/config is /volume1/homebridge.
• UI port is 8581; bridge port is 51537.
• Plugins observed: Ring, TP-Link/Kasa, Rain Bird.
• Current runtime is Docker Compose project homebridge, container

homebridge, image homebridge/homebridge:latest, host networking,

appdata /volume1/homebridge.

• Compose file:

synology/docker/projects/homebridge-compose/compose.yaml.

• Rollback archive:

/volume1/docker/backups/homebridge/homebridge-before-docker-.tar.gz

• Do not run package and container at the same time. Preserve persist/ and

accessories/ to avoid resetting HomeKit pairing.

• Monitoring now probes Homebridge UI and expects the homebridge

container through cAdvisor.

• Rain Bird follow-up was performed on 2026-05-28:
• showRequestResponse was disabled to remove noisy request/response logs.
• Device 10.0.0.24 was given firmware: "2.10" and

configDeviceName: "RainBird Controller".

• A small local plugin compatibility patch was applied for

seasonalAdjust.length on undefined responses.

• Reapply helper if a Rain Bird plugin update overwrites it:

synology/docker/homebridge/Patch-HomebridgeRainBirdPlugin.ps1.

• Monitoring now includes a RainBird Controller ICMP probe on

10.0.0.24; this is ping-style reachability only, not a HomeKit control

test. It replaced the old TCP 10.0.0.24:80 probe on 2026-06-05 because

the controller can refuse HTTP while still being fine.

• Detailed review: synology/docker/HOMEBRIDGE_REVIEW.md.
• Pi-holes:
• PiHolePi4 at 10.0.0.195
• PiHole4B at 10.0.0.132
• PiHoleEx replacement:
• The Raspberry Pi 2-based PiHoleEx was replaced by the Raspberry Pi 4

PiHole4B on 2026-06-13 while preserving the secondary DNS IP

10.0.0.132.

• Post-cutover inventory:

pihole/inventory/snapshots/20260613-153931.

• Manual post-cutover backup verification created

PiHolePi4-20260613-154353.zip and PiHole4B-20260613-154353.zip.

• Keep old PiHoleEx references only as historical backup/rollback context.
• Google Cloud DNS manages ravick5.com; wildcard DNS was removed and explicit

records are preferred.

• DNSSEC was reviewed on 2026-06-13. The Cloud DNS zone is currently unsigned

(dnssecConfig.state: off); enabling DNSSEC requires both Cloud DNS signing

and registrar DS-record publication. See google-cloud-dns/DNSSEC_PLAN.md.

• Latest Google Cloud DNS snapshot:

google-cloud-dns/inventory/snapshots/20260621-113009.

• Mermaid diagrams were refreshed again on 2026-06-13 under diagrams/. They cover

network topology, app communication, public exposure, storage/backups,

observability/alerts, and project-maintenance flow. Homepage now has a

Diagrams / Maps section linking operators back to those durable diagram

documents.

• Personal media path /volume1/data/media/personal is off-limits for

modification.

• Recyclarr current state is documented in synology/docker/RECYCLARR_PLAN.md.

As of 2026-06-03, Recyclarr is reference-only and should not be scheduled or

synced unless the user explicitly reopens that project. Active Sonarr/Radarr

preference authority is direct API helpers:

• Set-SonarrPreferX265NonAnime.ps1
• Set-RadarrPreferX265.ps1
• Set-ArrWeb1080CutoffNoBluray.ps1
• tools/synology/arr-vhnic-storage-conscious-quality-caps.sh

Latest audit:

synology/docker/arr-preference-audit/20260603-221118/SUMMARY.md

showed 31 pass, 0 warn, 0 fail. Anime remains intentionally untouched.

The main Radarr movie profile now allows only 1080p WEB/HDTV qualities and

disables SD/DVD/480p/720p/Bluray/remux/2160p fallback qualities.

• Plex Dimension 20 playlists were created on 2026-05-25. Details and helper

scripts are documented in synology/docker/PLEX_PLAYLISTS.md.

• Tdarr TV Shows was added on 2026-05-26:
• Library: VHNIC TV Shows
• Library ID: tvShows01
• Folder: /media/media/tv shows
• Settings cloned from VHNIC Movies
• DB backup:

/volume2/VM Storage/docker/tdarr/server/Tdarr/DB2/SQL/database.db.codex-backup-add-tvshows-20260526-214500

• Authenticated scan was triggered; follow-up checks showed the library

actively indexing, rising from 677 to 3,295 files and continuing.

• Tdarr TV Shows repair follow-up on 2026-05-27:
• Current active health-failure bucket: 48 queued files
• Breakdown:
• 44 MPEG4/AVI files
• 4 H.264/MKV files
• Controlled FFmpeg tests supported a TV-Shows-only fallback change toward

HEVC MP4 with AAC audio for these legacy cases.

• Current failure detail snapshot:

synology/docker/tdarr/health/20260527-182550/tdarr-health-failures.txt

• Follow-up item: one Tdarr post-restart read error was documented for

Obi-Wan Kenobi - S01E02 - Part II.mkv; treat that as a file/path/storage

investigation item, not an automatic repair or replacement action.

• Latest weekly maintenance report:
• reports/weekly-maintenance/20260621-073001
• All scheduled capture steps succeeded.
• Pi-hole backup status, Pi-hole inventory, UniFi inventory/Wi-Fi health,

Google Cloud DNS inventory, Synology Docker no-sudo inventory, Synology

read-only health, and retention dry run all completed successfully.

• Pi-hole backup status verified PiHolePi4-20260621-031502.zip and

PiHole4B-20260621-031502.zip.

• The retention dry run now reports older May snapshot folders as review

candidates; no deletion is approved without exact-path approval.

• Latest Tdarr state:
• The original broad rollout targets are complete for Kids TV, Kids Movies,

Movies, TV Shows, and Reality.

• 2026-06-10 capture:

synology/docker/tdarr/progress/20260610-151023/tdarr-progress.txt

showed queue 0, errors 0, DB load Stable, total files 28,065, total

transcodes 19,945, and space saved 9,394.1 GB.

• 2026-06-11 capture:

synology/docker/tdarr/progress/20260611-143608/tdarr-progress.txt

showed queue 112, active jobs 98, errors 0, DB load Stable, total

files 28,154, total transcodes 20,075, and space saved 9,529.2 GB.

Treat the queue as the user's remaining evening work; recapture after it

finishes before adding Anime or making profile changes.

• Anime inventory was captured at

synology/docker/tdarr/anime-inventory/20260609-223132/; Anime is still a

prep-plan-only target and needs a custom profile plus tiny playback test

set before any library add.

• Incident retention is now formalized. Keep summaries in INCIDENT_REGISTER.md

and incidents/<date-topic>/SUMMARY.md; raw evidence should be reviewed and

removed later only after exact-path approval.

• Automation split is documented in AUTOMATION_PLAN.md: scheduled tasks create

read-only reports, while Codex handles interpretation and doc updates.

Implemented tasks:

• Windows scheduled task Codex VHNIC Weekly Maintenance Report, Sundays

07:30.

• Codex automation review-vhnic-weekly-maintenance-report, Sundays 09:30.
• Codex automation refresh-vhnic-project-docs-and-handoff, Mondays 09:00.

Useful Follow-Ups

• Test Seerr public login and one normal plus one anime request.
• If tests pass, revisit Seerr csrfProtection.
• Public Seerr aliases currently include overseerr.ravick5.com,

seerr.ravick5.com, and requests.ravick5.com. The typo

overserr.ravick5.com was removed.

• Monitor new non-Anime Sonarr/Radarr direct-helper behavior; do not touch Anime

unless explicitly planned and previewed.

• Recapture Tdarr after the 2026-06-11 finish-out queue drains before changing

profiles or adding Anime.

• If pursuing friendly internal app names, start from

synology/docker/projects/reverse-proxy-compose/INTERNAL_FRIENDLY_NAMES_PLAN.md;

DNS-only records will not remove ports because current Caddy is on host

8088/8443.

• Review UniFi public forwards and keep direct app-port exposure disabled.