@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/veterinary/surgical-schedule-utilization-check.yaml

@@ -0,0 +1,36 @@
+id: surgical-schedule-utilization-check
+version: 1
+name: Surgical Schedule/OR Utilization Check
+description: >
+  Calculates how much of tomorrow's surgical suite time is booked versus
+  open, so scheduling can fill gaps or flag overbooking. Use this if the
+  OR has ever sat half-empty on a weekday because nobody was watching
+  utilization, or double-booked because two procedures landed in the
+  same block — distinct from surgery-prep-check.yaml, which checks
+  individual case readiness (bloodwork/consent) rather than schedule
+  utilization.
+category: veterinary
+tags: [veterinary, surgery, scheduling, utilization, operations]
+schedule: "0 16 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  tomorrow=$(date -d "+1 day" +%Y-%m-%d 2>/dev/null || date -v+1d +%Y-%m-%d);
+  awk -F',' -v tomorrow="$tomorrow" -v capacity="{{available_or_minutes}}" '
+    NR==1 {next}
+    $2 == tomorrow { booked += $3; slots[$4]++ }
+    END {
+      pct = (capacity > 0) ? (booked / capacity * 100) : 0;
+      printf "OR UTILIZATION for %s: %d/%d minutes booked (%.1f%%)\n", tomorrow, booked, capacity, pct;
+      for (room in slots) if (slots[room] > 1) printf "POSSIBLE DOUBLE-BOOK: OR %s has %d procedures scheduled\n", room, slots[room];
+    }
+  ' "{{surgery_schedule_csv_path}}"
+variables:
+  surgery_schedule_csv_path:
+    default: "./surgery-schedule-detailed.csv"
+    description: "Path to a CSV with columns: pet_name,surgery_date (YYYY-MM-DD),duration_minutes,or_room."
+  available_or_minutes:
+    default: 480
+    description: Total surgical suite minutes available in a working day (e.g. 8 hours = 480).
+compatible_agents: [generic, claude, codex]
+notes: Zero-token. Flags overlapping bookings in the same OR room as a possible double-book — verify against the actual schedule before reassigning.

package/jobs/veterinary/vet-staff-ce-credit-tracking.yaml

@@ -0,0 +1,36 @@
+id: vet-staff-ce-credit-tracking
+version: 1
+name: Veterinary Staff CE Credit Tracking
+description: >
+  Reviews each veterinarian and licensed vet tech's continuing education
+  (CE) credit hours against what their state board requires by license
+  renewal, and flags anyone on track to fall short. Use this if a
+  provider has ever discovered close to renewal that they were short on
+  RACE-approved CE hours needed to keep their license active — distinct
+  from dvm-license-dea-registration-expiry-check.yaml, which tracks the
+  license's own expiry date rather than the ongoing education
+  requirement to renew it.
+category: veterinary
+tags: [veterinary, continuing-education, compliance, licensing, staff]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the CE tracking export from {{ce_tracking_system}} for all
+  veterinarians and licensed vet techs.
+  1. For each staff member, compare CE hours completed this cycle
+     against the hours required by their state board (note: this varies
+     by state and by whether they're a DVM or LVT/CVT — flag if you're
+     unsure of the requirement rather than guessing).
+  2. List anyone whose completed hours, at the current pace, won't reach
+     the requirement before their cycle end date.
+  3. Sort by soonest cycle end date first.
+  4. Suggest which upcoming CE opportunities (conferences, RACE-approved
+     online courses) would close the gap, if that information is
+     available.
+variables:
+  ce_tracking_system:
+    default: "your CE tracking spreadsheet or HR/credentialing system"
+    description: Where completed CE hours and cycle end dates are recorded.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Requires knowing each state board's specific CE hour requirement, which varies — verify against the actual state veterinary board rule before treating a flagged shortfall as final.

package/jobs/warehousing/conveyor-sortation-downtime-watch.yaml

@@ -0,0 +1,48 @@
+id: conveyor-sortation-downtime-watch
+version: 1
+name: Conveyor & Sortation System Downtime Watch
+description: >
+  Checks the material handling system's downtime log for conveyor and
+  sortation equipment and flags outages exceeding a target duration, or
+  a segment with repeat outages in the period. Use this if a conveyor
+  jam has ever backed up the whole outbound line for an hour while
+  everyone treated it as a one-off instead of the third time that
+  segment failed this week.
+category: warehousing
+tags: [warehousing, conveyor, sortation, downtime, equipment]
+schedule: "0 21 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v max_min="{{max_outage_minutes}}" -v repeat="{{repeat_outage_threshold}}" '
+    NR==1 {next}
+    {
+      segment=$1; minutes=$3; count[segment]++; total[segment]+=minutes;
+      if (minutes >= max_min) {
+        printf "LONG OUTAGE: segment %s — %d min outage (%s), reason: %s\n", segment, minutes, $2, $4;
+      }
+    }
+    END {
+      for (s in count) {
+        if (count[s] >= repeat) {
+          printf "REPEAT OUTAGES: segment %s — %d outage(s) totaling %d min today\n", s, count[s], total[s];
+        }
+      }
+    }
+  ' "{{conveyor_downtime_csv_path}}"
+variables:
+  conveyor_downtime_csv_path:
+    default: "./conveyor-downtime-log.csv"
+    description: "Path to a CSV with columns: segment_id,started_at,duration_minutes,reason — one row per conveyor/sortation outage."
+  max_outage_minutes:
+    default: 20
+    description: Minutes a single outage can run before it's flagged individually.
+  repeat_outage_threshold:
+    default: 3
+    description: Number of outages on the same segment in one day that triggers a repeat-outage flag.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Covers material handling automation (conveyors, sorters) inside the
+  warehouse, distinct from manufacturing's production-line-downtime-watch,
+  which tracks stoppages on production/assembly lines rather than
+  outbound material handling systems.

package/jobs/warehousing/labor-productivity-rate-check.yaml

@@ -0,0 +1,33 @@
+id: labor-productivity-rate-check
+version: 1
+name: Warehouse Labor Productivity Rate Check
+description: >
+  Compares units processed per labor hour against a target rate, by
+  shift or work area. Use this if a shift's productivity has ever
+  quietly drifted below what staffing was planned around, without
+  anyone noticing until the labor budget was already blown for the
+  month.
+category: warehousing
+tags: [warehousing, labor, productivity, staffing]
+schedule: "0 22 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{target_units_per_hour}}" '
+    NR==1 {next}
+    {
+      area=$1; units=$2; hours=$3;
+      rate = (hours > 0) ? units / hours : 0;
+      status = (rate < target) ? "BELOW TARGET" : "OK";
+      printf "%s: %s — %.1f units/hour (%d units / %.1f hours), target %.1f\n", status, area, rate, units, hours, target;
+    }
+  ' "{{shift_productivity_csv_path}}"
+variables:
+  shift_productivity_csv_path:
+    default: "./shift-productivity-log.csv"
+    description: "Path to a CSV with columns: work_area,units_processed,labor_hours — one row per work area per shift."
+  target_units_per_hour:
+    default: 40
+    description: Target minimum units processed per labor hour.
+compatible_agents: [generic, claude, codex]
+notes: Aggregate throughput rate only — pair with pick-pack-error-rate-watch so a "fast" shift isn't just a sloppy one.

package/jobs/warehousing/mhe-preventive-maintenance-check.yaml

@@ -0,0 +1,38 @@
+id: mhe-preventive-maintenance-check
+version: 1
+name: Material Handling Equipment Preventive Maintenance Check
+description: >
+  Checks scheduled preventive maintenance due dates for material
+  handling equipment other than forklifts — pallet jacks, order pickers,
+  conveyor drive units — and flags anything overdue. Use this if a
+  piece of MHE has ever broken down mid-shift for a service item that
+  was actually due weeks earlier and nobody was tracking anything but
+  the forklifts.
+category: warehousing
+tags: [warehousing, mhe, maintenance, equipment]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      if (due_epoch < today) {
+        days_over = int((today - due_epoch) / 86400);
+        printf "OVERDUE: %s (%s) — PM was due %s, %d day(s) overdue\n", $1, $2, $3, days_over;
+      }
+    }
+  ' "{{mhe_pm_schedule_csv_path}}"
+variables:
+  mhe_pm_schedule_csv_path:
+    default: "./mhe-pm-schedule.csv"
+    description: "Path to a CSV with columns: equipment_id,equipment_type,next_pm_due_date (YYYY-MM-DD) — one row per unit of MHE, excluding forklifts."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Covers non-forklift MHE preventive maintenance schedules. Forklifts
+  have their own daily pre-use inspection check
+  (forklift-inspection-check); this job tracks scheduled service
+  intervals for the rest of the equipment fleet, not daily inspections.

package/jobs/warehousing/order-fulfillment-sla-watch.yaml

@@ -0,0 +1,42 @@
+id: order-fulfillment-sla-watch
+version: 1
+name: Order Fulfillment On-Time-Ship SLA Watch
+description: >
+  Checks yesterday's order log for orders that missed their promised
+  ship-by date/time and flags the on-time-ship rate against target. Use
+  this if an on-time-ship rate has ever slipped for a week before anyone
+  outside the warehouse noticed, because nobody was tallying misses
+  against the SLA daily.
+category: warehousing
+tags: [warehousing, fulfillment, sla, on-time-ship]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{on_time_target_pct}}" '
+    NR==1 {next}
+    {
+      total++;
+      if ($3 == "late") { late++; print "LATE: order " $1 " — shipped " $2 ", missed ship-by date" }
+    }
+    END {
+      pct = (total > 0) ? ((total - late) / total) * 100 : 0;
+      if (pct < target) {
+        printf "BELOW TARGET: %.2f%% on-time-ship (%d of %d orders), target %.2f%%\n", pct, total-late, total, target;
+      } else {
+        printf "OK: %.2f%% on-time-ship (%d of %d orders)\n", pct, total-late, total;
+      }
+    }
+  ' "{{orders_csv_path}}"
+variables:
+  orders_csv_path:
+    default: "./fulfillment-sla-log.csv"
+    description: "Path to a CSV with columns: order_id,shipped_at,sla_status (on_time/late) — one row per order shipped in the period."
+  on_time_target_pct:
+    default: 97.0
+    description: Target minimum on-time-ship rate as a percentage.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Tracks whether orders shipped by their promised date, distinct from
+  pick-pack-error-rate-watch (which tracks fulfillment accuracy — right
+  item/quantity — not shipping timeliness).

package/jobs/warehousing/shift-headcount-coverage-check.yaml

@@ -0,0 +1,33 @@
+id: shift-headcount-coverage-check
+version: 1
+name: Warehouse Shift Headcount Coverage Check
+description: >
+  Compares scheduled headcount against required headcount per shift and
+  flags gaps before the shift starts. Use this if a shift has ever
+  started three people short with no time left to call in coverage,
+  because the staffing gap wasn't checked until people were already
+  clocking in.
+category: warehousing
+tags: [warehousing, labor, staffing, scheduling]
+schedule: "0 5,13 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      shift=$1; required=$2; scheduled=$3;
+      gap = required - scheduled;
+      if (gap > 0) {
+        printf "SHORT: %s shift — scheduled %d of %d required (%d short)\n", shift, scheduled, required, gap;
+      } else {
+        printf "OK: %s shift — scheduled %d of %d required\n", shift, scheduled, required;
+      }
+    }
+  ' "{{shift_staffing_csv_path}}"
+variables:
+  shift_staffing_csv_path:
+    default: "./shift-staffing-plan.csv"
+    description: "Path to a CSV with columns: shift_name,required_headcount,scheduled_headcount — one row per upcoming shift."
+compatible_agents: [generic, claude, codex]
+notes: Checks planned coverage before a shift starts — pair with labor-productivity-rate-check for whether the headcount that did show up actually kept pace.

package/jobs/warehousing/slotting-velocity-review-check.yaml

@@ -0,0 +1,44 @@
+id: slotting-velocity-review-check
+version: 1
+name: Slotting Velocity Review Check
+description: >
+  Reviews SKU pick-frequency data against current storage locations and
+  flags fast-movers stuck in slow-to-reach slots (or slow-movers hogging
+  prime golden-zone real estate). Use this if pickers have ever walked
+  past empty golden-zone slots to reach a high-velocity SKU stashed in
+  the back corner because the slotting plan was never revisited after
+  demand shifted.
+category: warehousing
+tags: [warehousing, slotting, velocity, layout-optimization]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the last {{lookback_days}} days of pick-frequency data per SKU
+  along with each SKU's current storage location from {{data_source}}.
+  1. Rank SKUs by pick frequency and identify the top
+     {{top_mover_pct}}% by volume.
+  2. Flag any top mover currently stored outside a golden-zone/easy-reach
+     location (e.g. upper reserve racking, far aisle) — these are prime
+     re-slotting candidates.
+  3. Flag any slow-mover (bottom {{top_mover_pct}}%) currently occupying
+     a golden-zone slot that a fast-mover could use instead.
+  4. Summarize the highest-impact re-slotting swaps (biggest expected
+     travel-time savings), not every mismatch found.
+variables:
+  data_source:
+    default: "your WMS pick history and slotting/location report"
+    description: System of record for pick frequency per SKU and current slot assignment.
+  lookback_days:
+    default: 90
+    description: Days of pick history to analyze for velocity ranking.
+  top_mover_pct:
+    default: 20
+    description: Percentage cutoff (by pick volume) used to define "top movers" and "slow movers."
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  This is a periodic optimization review, not a daily operational check —
+  re-slotting recommendations still need a supervisor to schedule the
+  physical moves. Distinct from pallet-putaway-delay-check, which tracks
+  how fast pallets get put away, not whether the slot they're put away
+  into is the right one.

package/jobs/warehousing/warehouse-damage-writeoff-review.yaml

@@ -0,0 +1,41 @@
+id: warehouse-damage-writeoff-review
+version: 1
+name: Warehouse Damage Write-Off Review
+description: >
+  Reviews inventory damaged inside the facility during handling
+  (dropped in putaway, forklift contact, racking collapse) and flags
+  cases pending a write-off decision, along with any recurring cause
+  worth fixing. Use this if damaged inventory has ever sat on a "to be
+  reviewed" pallet for weeks because nobody owned the write-off
+  decision.
+category: warehousing
+tags: [warehousing, damage, write-off, loss-prevention]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the in-facility damage log for the last {{lookback_days}} days
+  from {{data_source}}.
+  1. List damage incidents still pending a write-off/disposition
+     decision, with the SKU, estimated value, and days pending.
+  2. Group incidents by likely cause (handling, equipment contact,
+     racking, storage stacking) and flag any cause responsible for more
+     than {{recurring_cause_threshold}} incidents in the period as a
+     recurring problem worth a process or equipment fix, not just a
+     write-off.
+  3. Total the estimated dollar value of pending write-offs.
+variables:
+  data_source:
+    default: "your damage/loss-prevention log"
+    description: System of record for in-facility inventory damage incidents.
+  lookback_days:
+    default: 30
+    description: Days of damage log history to review.
+  recurring_cause_threshold:
+    default: 3
+    description: Number of incidents sharing a cause in the period before it's flagged as recurring.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Covers damage caused inside the facility during handling/storage, not
+  customer returns — distinct from returns-processing-backlog-check,
+  which tracks turnaround time on inbound customer RMAs.

package/jobs/warehousing/warehouse-near-miss-incident-rate-watch.yaml

@@ -0,0 +1,47 @@
+id: warehouse-near-miss-incident-rate-watch
+version: 1
+name: Warehouse Near-Miss & Incident Rate Watch
+description: >
+  Reviews the safety incident log for a trend in near-misses and minor
+  injuries on the warehouse floor against a rolling benchmark, and
+  looks for a common thread (location, shift, equipment) before it
+  becomes a serious injury. Use this if near-misses have ever piled up
+  in the log unread until a lost-time injury made someone finally go
+  looking for a pattern that was there the whole time.
+category: warehousing
+tags: [warehousing, safety, incidents, near-miss]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the last {{lookback_weeks}} weeks of safety incident and
+  near-miss reports from {{data_source}}.
+  1. Calculate the incident rate for the period and compare it to the
+     trailing {{baseline_weeks}}-week average.
+  2. If the rate is trending up by more than {{trend_threshold_pct}}%,
+     flag it and look for a common thread across the reports — same
+     zone, same shift, same equipment type, same task.
+  3. List any near-miss that involved equipment already flagged in a
+     recent MHE maintenance or forklift inspection check, since that's
+     a compounding risk worth escalating immediately.
+  4. Summarize the trend and any pattern found in plain language for a
+     safety walk the next morning.
+variables:
+  data_source:
+    default: "your incident/near-miss reporting log"
+    description: System of record for warehouse floor incident and near-miss reports.
+  lookback_weeks:
+    default: 4
+    description: Weeks of incident data to analyze for the current period.
+  baseline_weeks:
+    default: 12
+    description: Weeks of trailing history used to compute the baseline incident rate.
+  trend_threshold_pct:
+    default: 20
+    description: Percentage increase over baseline that triggers a trend flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Tracks incident rate trend and pattern-finding across the floor,
+  distinct from manufacturing's osha-recordable-incident-audit (which
+  checks whether a single recordable incident got logged on the OSHA
+  300 form within a deadline, not the rate or pattern across incidents).

package/jobs/warehousing/warehouse-space-utilization-check.yaml

@@ -0,0 +1,39 @@
+id: warehouse-space-utilization-check
+version: 1
+name: Warehouse Space Utilization Check
+description: >
+  Reviews storage location occupancy against total capacity by zone and
+  flags zones running near overflow or sitting oddly empty. Use this if
+  a zone has ever hit effective capacity without warning, forcing
+  overflow pallets into aisles because nobody was watching utilization
+  trend toward full.
+category: warehousing
+tags: [warehousing, space-utilization, capacity, planning]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull current occupied-location counts and total location capacity per
+  zone from {{data_source}}.
+  1. Calculate utilization percentage per zone.
+  2. Flag any zone at or above {{high_utilization_pct}}% as at risk of
+     overflow — likely to force out-of-location or aisle storage soon.
+  3. Flag any zone at or below {{low_utilization_pct}}% as a candidate
+     for consolidation or reallocation to a busier zone.
+  4. Summarize the overall facility utilization rate and call out the
+     trend versus last week's report if history is available.
+variables:
+  data_source:
+    default: "your WMS location/capacity report"
+    description: System of record for storage location occupancy and capacity per zone.
+  high_utilization_pct:
+    default: 90
+    description: Utilization percentage at or above which a zone is flagged as overflow risk.
+  low_utilization_pct:
+    default: 30
+    description: Utilization percentage at or below which a zone is flagged as underused.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Facility-level capacity planning signal, distinct from
+  slotting-velocity-review-check (which is about whether the right SKU
+  is in the right slot, not how full the zone is overall).

package/jobs/warehousing/wave-pick-batch-efficiency-check.yaml

@@ -0,0 +1,33 @@
+id: wave-pick-batch-efficiency-check
+version: 1
+name: Wave/Batch Picking Efficiency Check
+description: >
+  Checks completed picking waves against a target completion time and
+  flags waves that ran long. Use this if a wave has ever spilled past
+  its window and pushed the whole outbound schedule back before anyone
+  noticed the wave itself, not the individual pickers, was the problem.
+category: warehousing
+tags: [warehousing, wave-picking, batch-picking, throughput]
+schedule: "0 20 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{target_wave_minutes}}" '
+    NR==1 {next}
+    {
+      wave=$1; lines=$2; minutes=$3;
+      rate = (minutes > 0) ? lines / minutes : 0;
+      if (minutes > target) {
+        printf "OVER TARGET: wave %s — %d line(s) in %d min (%.2f lines/min), target %d min\n", wave, lines, minutes, rate, target;
+      }
+    }
+  ' "{{wave_log_csv_path}}"
+variables:
+  wave_log_csv_path:
+    default: "./wave-pick-log.csv"
+    description: "Path to a CSV with columns: wave_id,order_lines,completion_minutes — one row per completed picking wave."
+  target_wave_minutes:
+    default: 90
+    description: Target maximum minutes to complete a picking wave/batch.
+compatible_agents: [generic, claude, codex]
+notes: Measures wave-level completion time, not individual picker accuracy — pair with pick-pack-error-rate-watch for the quality side.

package/jobs/warehousing/wms-integration-error-check.yaml

@@ -0,0 +1,36 @@
+id: wms-integration-error-check
+version: 1
+name: WMS Integration Error Queue Check
+description: >
+  Scans the warehouse management system's integration error queue
+  (failed order imports, ASN mismatches, inventory sync failures) and
+  flags anything sitting unresolved past a target age. Use this if a
+  failed inbound order sync has ever sat quietly in an error queue for
+  days while the warehouse floor had no idea the order even existed.
+category: warehousing
+tags: [warehousing, wms, integration, systems]
+schedule: "*/30 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  now=$(date +%s);
+  awk -F',' -v now="$now" -v max_minutes="{{max_unresolved_minutes}}" '
+    NR==1 {next}
+    $4 == "unresolved" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline occurred_epoch; close(cmd);
+      age_minutes = (now - occurred_epoch) / 60;
+      if (age_minutes >= max_minutes) {
+        printf "UNRESOLVED: error %s (%s) — occurred %s, %d minute(s) old\n", $1, $3, $2, age_minutes;
+      }
+    }
+  ' "{{wms_error_queue_csv_path}}"
+variables:
+  wms_error_queue_csv_path:
+    default: "./wms-error-queue.csv"
+    description: "Path to a CSV with columns: error_id,occurred_at (YYYY-MM-DD HH:MM),error_type (order_import/asn_mismatch/inventory_sync/etc),status (unresolved/resolved)."
+  max_unresolved_minutes:
+    default: 60
+    description: Minutes an integration error can sit unresolved before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Zero-token systems-health check on the integration layer itself — it doesn't diagnose the underlying data mismatch, just surfaces that one is sitting unresolved.

package/jobs/warehousing/yard-trailer-detention-watch.yaml

@@ -0,0 +1,41 @@
+id: yard-trailer-detention-watch
+version: 1
+name: Yard Trailer Detention Watch
+description: >
+  Checks trailers currently parked in the facility's own yard against
+  their free-time window and flags any at risk of detention charges.
+  Use this if a trailer has ever sat in the yard so long that a
+  detention invoice showed up before anyone realized it was still
+  parked out there.
+category: warehousing
+tags: [warehousing, yard-management, detention, trailers]
+schedule: "0 */3 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  now=$(date +%s);
+  awk -F',' -v now="$now" -v free_hours="{{free_time_hours}}" '
+    NR==1 {next}
+    $4 != "departed" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline arrived_epoch; close(cmd);
+      yard_hours = (now - arrived_epoch) / 3600;
+      if (yard_hours >= free_hours) {
+        printf "DETENTION RISK: trailer %s (carrier %s) — %.1fh in yard (arrived %s), free time %dh\n", $1, $3, yard_hours, $2, free_hours;
+      }
+    }
+  ' "{{yard_log_csv_path}}"
+variables:
+  yard_log_csv_path:
+    default: "./yard-trailer-log.csv"
+    description: "Path to a CSV with columns: trailer_id,arrived_at (YYYY-MM-DD HH:MM),carrier,status (in_yard/spotted/departed)."
+  free_time_hours:
+    default: 48
+    description: Hours a trailer can sit in the yard before detention charges typically apply.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Tracks trailer-in-yard detention risk at this facility's own yard, at
+  the destination/origin end of a move. Distinct from logistics'
+  cross-dock-dwell-time-watch, which tracks freight dwell mid-transit
+  through a third-party cross-dock, and from container-demurrage-fee-watch,
+  which covers ocean containers at a port rather than trailers at a yard.

package/lib/category-descriptions.js

@@ -4,44 +4,44 @@
 // from scripts/build-catalog.js, not a hard failure).
 export const CATEGORY_DESCRIPTIONS = {
   agriculture: "Farm operations — weather risk, irrigation, equipment, market prices.",
-  automotive: "Repair shop workflow — repair orders, parts, loaners.",
+  automotive: "Dealership and repair shop ops — repair orders, parts, loaners, recalls, F&I, used inventory, CSI.",
   childcare: "Daycare compliance and ops — ratios, immunizations, tuition.",
-  construction: "Job site compliance — permits, inspections, change orders, rentals.",
+  construction: "Job site ops — permits, RFIs, submittals, safety, payments, budget vs. actual.",
   content: "Site/content health — SEO, broken links, freshness, repurposing.",
   creator: "Influencer/creator ops — content calendar, cross-posting, sponsorships.",
   crypto: "Wallets, gas prices, DeFi risk, and token unlock schedules.",
   devops: "Infra health — backups, deploys, dependencies, monitoring.",
   ecommerce: "Storefront ops — carts, stock, returns, reviews.",
-  education: "Classroom ops — grading, attendance, deadlines, permission slips.",
+  education: "School/district ops — grading, attendance, IEP compliance, staffing, facilities, budget.",
   events: "Event planning — budget, RSVPs, staffing, vendors, day-of check-in.",
   fieldservice: "Dispatch ops — tech ETAs, parts, warranty claims, maintenance contracts.",
   finance: "Personal/business finance — budgets, invoices, taxes, subscriptions.",
   fitness: "Gym/studio ops — memberships, class utilization, equipment.",
-  fleet: "Vehicle fleet compliance — maintenance, registration, licenses, fuel.",
+  fleet: "Company vehicle fleet ops — compliance, maintenance, safety, fuel, cost, scheduling.",
   gaming: "Streaming and community server ops — schedules, patches, tournaments.",
   government: "Public-sector ops — records requests, permits, constituent casework.",
-  growth: "Lifecycle marketing — churn, trials, onboarding, reviews.",
+  growth: "Lifecycle marketing — churn, trials, onboarding, activation, expansion, retention, NPS.",
   healthcare: "Clinic ops — appointments, recalls, licenses, lab results.",
   hiring: "Recruiting pipeline — candidates, offers, interviews, reqs.",
   home: "Household reminders — maintenance, warranties, plants, safety.",
-  hospitality: "Hotel ops — guest reviews, inspections, maintenance requests.",
+  hospitality: "Hotel ops — revenue management, reservations, housekeeping, guest experience, loyalty.",
   hr: "People ops — payroll, onboarding, benefits, reviews, offboarding.",
-  insurance: "Policy tracking — renewals, claims, coverage, certificates.",
+  insurance: "Policy & carrier ops — renewals, claims, underwriting, compliance.",
   inventory: "Stock accuracy — counts, shrinkage, expiry, overstock.",
   investing: "Portfolio tracking — prices, dividends, rebalancing, taxes.",
   learning: "Personal learning — certs, courses, flashcards, reading.",
   legal: "Contracts and deadlines — NDAs, trademarks, court, compliance filings.",
   logistics: "Shipping ops — customs, freight, delays, fees.",
   manufacturing: "Production ops — downtime, defects, maintenance, suppliers, materials.",
-  marketing: "Campaign ops — ad spend, SEO rank, deliverability, competitors.",
+  marketing: "Campaign ops — ad spend, ROAS, SEO rank, deliverability, attribution, competitors, MQLs, PR.",
   nonprofit: "Fundraising ops — grants, donors, volunteers, board follow-ups.",
   personal: "Daily life reminders — bills, habits, meals, screen time.",
   podcast: "Show ops — publish cadence, guests, sponsors, ratings.",
   productivity: "Work habits — inbox, standups, focus, meetings, reports.",
   publishing: "Book/print ops — manuscript deadlines, royalties, print runs, rights.",
   realestate: "Property management — leases, rent, vacancy, inspections, tax.",
-  restaurant: "Kitchen/FOH ops — food cost, labor cost, waste, inspections.",
-  retail: "Store ops — till reconciliation, opening checklist, scheduling.",
+  restaurant: "Kitchen/FOH ops — food cost, labor cost, waste, inspections, POS, menu margins.",
+  retail: "Physical store ops — till reconciliation, checklists, scheduling, merchandising, loss prevention, pricing.",
   sales: "Pipeline ops — leads, deals, quota, CRM sync.",
   security: "Security posture — keys, certs, access, scans, firewalls.",
   spa: "Salon/spa/wellness ops — no-shows, inventory, license renewals, membership churn.",
@@ -49,6 +49,6 @@ export const CATEGORY_DESCRIPTIONS = {
   team: "Team ops — 1:1s, on-call, PTO, anniversaries.",
   telecom: "ISP/telecom ops — outages, SLA uptime, circuit provisioning, churn.",
   travel: "Trip logistics — flights, passports, visas, insurance, miles.",
-  veterinary: "Clinic ops for animals — vaccines, controlled substances, boarding.",
-  warehousing: "Warehouse ops — dock scheduling, pick/pack errors, climate control.",
+  veterinary: "Clinic ops for animals — vaccines, controlled substances, boarding, surgery scheduling, records, billing, licensing.",
+  warehousing: "Warehouse facility ops — dock scheduling, pick/pack, slotting, labor, maintenance, safety.",
 };

package/lib/duplicates-allowlist.js

@@ -21,6 +21,16 @@ export const ALLOWED_DUPLICATE_PAIRS = [
     "landlord-insurance-claim-status-check",
     "Same stale-claim-followup goal, different mechanism and scale — generic insurance job is agent-prompt for a single policyholder's claims; realestate job is a zero-token shell scan over a property portfolio's claims CSV.",
   ],
+  [
+    "competitor-price-watch",
+    "competitor-price-monitoring-check",
+    "Same competitor-pricing goal, different mechanism — ecommerce job scrapes a competitor's live product page URL per SKU via regex; retail job is an agent-prompt reading a brick-and-mortar competitor's weekly flyer/in-store photos, since there's no comparable URL for a physical shelf price.",
+  ],
+  [
+    "prescription-refill-request-backlog-check",
+    "pet-medication-refill-backlog-check",
+    "Same stale-refill-request pattern, different domains — healthcare job tracks human patient prescription refills; veterinary job tracks pet medication/food refill requests from clinic clients. Intentionally parallel jobs, not a copy-paste duplicate.",
+  ],
 ];
 
 export function isAllowedPair(idA, idB) {