## ━━━ THE ORCHESTRATOR MODEL ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

The Varaverk scheduler contains exactly these entries:

```bash
# Array start event (Varaverk disks_mounted hook → cron: "array_start"):
array_started.sh

# Cron — managed via Varaverk Scheduler:
*/7   * * * *    transcode_management.sh
*/15  * * * *    watchdog_orchestrator.sh          ← resource → docker → system → stability
*/30  * * * *    critical_sync_maintenance.sh      ← auth + Emby dirty sync + partnership
0  */4 * * *     intermediate_sync_maintenance.sh  ← arr sync + failed recovery + optional rsync
0   1 * * *      daily_sync_maintenance.sh
0   7 * * 0      sunday_morning_coffee_report.sh
30  2 * * 0      weekly_sync_maintenance.sh
0   0 15 * *     monthly_maintenance.sh            ← uptime-gated: ZFS scrub, SMART tests

# Manual only (not scheduled):
fallback_test.sh, emby_database_repair.sh, repair tools
```

Every job list is configured in the `ORCHESTRATORS` section of `master.conf`.
No orchestrator script ever changes when jobs are added or removed — only `master.conf` changes.

---

## ━━━ THE ORCHESTRATOR PATTERN ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

All orchestrators follow the same structure:

```
1. Setup          → validate config, detect_hosts(), acquire_lock
2. Pre-flight     → fail fast checks before any work begins
3. Job loop       → run each job, track pass/fail, continue on failure
4. Summary        → one clean report of all job results
5. Notification   → one notify per run on failure (never per job)
```

Properties that apply to every orchestrator:

```
Consistent output    → every orchestrator looks the same in logs
No silent failures   → pass/fail tracked per job, all in summary
Resilient            → one job failing does not stop the rest
Single notification  → one bell per run, not one per job
--dry-run cascade    → passes --dry-run through to every child script
--status support     → show configured jobs and exit
```

---


Perfect! I see the issue now. The README-Orchestrators.md says:

```
0  */4 * * *     intermediate_sync_maintenance.sh  ← arr sync + failed recovery + optional rsync
```

So it claims that `intermediate_sync_maintenance` includes "failed recovery", but let me confirm what intermediate_sync_maintenance actually contains. Let me look at what it says it runs:


1	#!/bin/bash
2	# ==============================================================================================
3	# =========================== Intermediate Sync Maintenance ====================================
4	# ==============================================================================================
5	# 4-hour orchestrator — arr library reconciliation, artwork fetching, and optional rsync.
6	# Schedule: 0 */4 * * * (every 4 hours)
7	#
8	# ── EXECUTION ORDER ───────────────────────────────────────────────────────────────────────────
9	#   1. conf_sync.sh --pull-only    — refresh partner conf cache in RAM (/tmp/.vv/)
10	#   2. arr_sync.sh                 — sync Lidarr/Sonarr/Radarr libraries across all nodes
11	#   3. Rsync window (optional)     — INTERMEDIATE_SYNC_SHARES, if any configured
12	#   4. INTERMEDIATE_MAINTENANCE_SCRIPTS — artwork fetch and any future 4-hour jobs
13	#
14	# ── WHY A SEPARATE ORCHESTRATOR ───────────────────────────────────────────────────────────────
15	# arr libraries need to converge more frequently than once a day. If a remote node adds


So the intermediate_sync_maintenance.sh script header lists:
1. conf_sync
2. arr_sync
3. rsync
4. INTERMEDIATE_MAINTENANCE_SCRIPTS

It does NOT list `arrs_failed_stalled_recovery`. The README-Orchestrators.md comment is misleading/wrong!

Now let me generate my final report of discrepancies:

## REPORT: Documentation vs. Implementation Discrepancies

**DISCREPANCY 1: README-User_Script_Plug-in.md lists `intermediate_sync_maintenance` but it's NOT documented**
- FILE: README-User_Script_Plug-in.md
- **What the doc says:** The file contains extensive documentation for `arrs_failed_stalled_recovery` as a scheduled orchestrator (Schedule: 0 */6 * * *) at line 210, claiming it runs every 6 hours separately from other orchestrators.
- **What is actually true:** `arrs_failed_stalled_recovery.sh` exists in `Media/` folder but is NOT called by any orchestrator. The script exists but has no scheduled entry. Additionally, `intermediate_sync_maintenance.sh` is completely omitted from README-User_Script_Plug-in.md despite being a core orchestrator that runs every 4 hours (0 */4 * * *) per Manual.md line 321.

**DISCREPANCY 2: README-Orchestrators.md claims intermediate_sync includes "failed recovery"**
- FILE: README-Orchestrators.md (line 105)
- **What the doc says:** "0 */4 * * * intermediate_sync_maintenance.sh ← arr sync + failed recovery + optional rsync"
- **What is actually true:** The intermediate_sync_maintenance.sh script header (lines 8-12) documents execution order as: conf_sync → arr_sync → rsync → INTERMEDIATE_MAINTENANCE_SCRIPTS. It does NOT call arrs_failed_stalled_recovery.sh. Failed recovery is not included in this orchestrator.

**DISCREPANCY 3: Manual.md Schedule Table describes intermediate_sync incorrectly**
- FILE: Manual.md (line 321)
- **What the doc says:** "intermediate_sync_maintenance | 0 */4 * * * | arr sync + failed recovery"
- **What is actually true:** Same as Discrepancy 2 above—the script does not include failed recovery step. It calls arr_sync + optional rsync + maintenance scripts.

**Summary:** The relationship between `intermediate_sync_maintenance` (4-hour orchestrator) and `arrs_failed_stalled_recovery` (unused Media script) is documented inconsistently across three files. Two docs incorrectly claim failed recovery runs as part of the 4-hour cycle, and one doc completely omits the intermediate_sync_maintenance orchestrator while attempting to schedule the standalone Media script separately.