@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/logistics/carrier-otd-performance-scorecard.yaml

@@ -0,0 +1,41 @@
+id: carrier-otd-performance-scorecard
+version: 1
+name: Carrier On-Time Delivery Performance Scorecard
+description: >
+  Tracks each carrier's on-time delivery rate over recent shipments and
+  flags any carrier that's dropped below your target. Use this if a
+  carrier's reliability has ever quietly slipped for months before a
+  customer complaint made it obvious.
+category: logistics
+tags: [logistics, carrier, otd, performance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{otd_target_pct}}" '
+    NR==1 {next}
+    {
+      total[$1]++;
+      if ($2 == "on-time") ontime[$1]++;
+    }
+    END {
+      for (c in total) {
+        pct = (ontime[c] / total[c]) * 100;
+        if (pct < target) {
+          printf "BELOW TARGET: %s — %.1f%% on-time (%d of %d shipments), target %d%%\n", c, pct, ontime[c], total[c], target;
+        }
+      }
+    }
+  ' "{{shipments_csv_path}}"
+variables:
+  shipments_csv_path:
+    default: "./carrier-shipments.csv"
+    description: "Path to a CSV with columns: carrier_name,status (on-time or late) — one row per recent outbound shipment."
+  otd_target_pct:
+    default: 90
+    description: Minimum acceptable on-time delivery percentage per carrier.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Tracks outbound carrier delivery performance to customers, not inbound
+  supplier delivery of materials — pair with your TMS or carrier
+  scorecard export to keep the CSV current.

package/jobs/logistics/carrier-rate-contract-renewal-check.yaml

@@ -0,0 +1,35 @@
+id: carrier-rate-contract-renewal-check
+version: 1
+name: Carrier Rate Contract Renewal Check
+description: >
+  Checks tracked carrier rate agreements against their expiry date and
+  warns before they lapse. Use this if a freight contract has ever
+  quietly expired and shipments kept moving on it anyway, until a rate
+  dispute surfaced with no valid agreement backing it.
+category: logistics
+tags: [logistics, carrier, contract, renewal]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline expiry_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (expiry_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "RENEWAL DUE: carrier agreement %s — expires %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{carrier_contracts_csv_path}}"
+variables:
+  carrier_contracts_csv_path:
+    default: "./carrier-rate-contracts.csv"
+    description: "Path to a CSV with columns: carrier_name,contract_expiry_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 45
+    description: How many days before contract expiry to start warning, to leave time for renewal negotiation.
+compatible_agents: [generic, claude, codex]
+notes: Assumes carrier rate agreements and their term dates are exported or manually tracked from procurement/legal — this is the renewal-deadline backstop, not a contract management system.

package/jobs/logistics/cross-dock-dwell-time-watch.yaml

@@ -0,0 +1,43 @@
+id: cross-dock-dwell-time-watch
+version: 1
+name: Cross-Dock Dwell Time Watch
+description: >
+  Checks freight moving through a cross-dock facility against a target
+  dwell time and flags anything sitting too long between inbound and
+  outbound legs. Use this if freight has ever quietly stalled at a
+  cross-dock for days, turning a same-day transfer into a missed
+  delivery window.
+category: logistics
+tags: [logistics, cross-dock, dwell-time, freight]
+schedule: "0 */2 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{max_dwell_hours}}" '
+    NR==1 {next}
+    {
+      shipment=$1; arrived=$2; status=$3;
+      if (status != "departed") {
+        cmd = "date -d \"" arrived "\" +%s 2>/dev/null || date -j -f %Y-%m-%dT%H:%M:%S \"" arrived "\" +%s 2>/dev/null";
+        cmd | getline arrived_epoch; close(cmd);
+        "date +%s" | getline now_epoch; close("date +%s");
+        dwell_hours = (now_epoch - arrived_epoch) / 3600;
+        if (dwell_hours >= threshold) {
+          printf "DWELL EXCEEDED: shipment %s has been on the dock %.1fh (arrived %s), threshold %dh\n", shipment, dwell_hours, arrived, threshold;
+        }
+      }
+    }
+  ' "{{crossdock_status_csv}}"
+variables:
+  crossdock_status_csv:
+    default: "./crossdock-shipment-status.csv"
+    description: "Path to a CSV with columns: shipment_id,arrived_at (ISO timestamp),status (e.g. staged, departed) — export from your dock/yard management system."
+  max_dwell_hours:
+    default: 12
+    description: Hours a shipment can sit at the cross-dock before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Tracks freight-in-transit dwell between inbound and outbound legs at a
+  cross-dock, distinct from warehousing's dock-schedule-conflict-check
+  (which checks appointment scheduling conflicts, not how long freight
+  actually sits once it's on the dock).

package/jobs/logistics/freight-invoice-rate-audit.yaml

@@ -0,0 +1,38 @@
+id: freight-invoice-rate-audit
+version: 1
+name: Freight Invoice Rate Audit
+description: >
+  Compares billed freight invoice amounts against the contracted rate for
+  each shipment and flags overcharges. Use this if a carrier has ever
+  quietly billed above the agreed rate and it only got caught months
+  later during an annual freight spend review.
+category: logistics
+tags: [logistics, freight, invoice, audit, billing]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{overcharge_tolerance_pct}}" '
+    NR==1 {next}
+    {
+      invoice_id=$1; contracted=$2; billed=$3;
+      if (contracted <= 0) next;
+      pct_over = ((billed - contracted) / contracted) * 100;
+      if (pct_over > tolerance) {
+        printf "OVERCHARGE: invoice %s — billed $%.2f vs contracted $%.2f (%.1f%% over, tolerance %d%%)\n", invoice_id, billed, contracted, pct_over, tolerance;
+      }
+    }
+  ' "{{invoices_csv_path}}"
+variables:
+  invoices_csv_path:
+    default: "./freight-invoices.csv"
+    description: "Path to a CSV with columns: invoice_id,contracted_rate,billed_amount — export from your freight audit/AP system."
+  overcharge_tolerance_pct:
+    default: 3
+    description: Percent above the contracted rate allowed before flagging as an overcharge worth disputing.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Checks billing accuracy against the contracted rate, not market rate
+  movement — pair with freight-rate-spike-watch if you also want to
+  track whether the contracted rate itself is falling behind the
+  market.

package/jobs/logistics/fuel-surcharge-rate-monitor.yaml

@@ -0,0 +1,40 @@
+id: fuel-surcharge-rate-monitor
+version: 1
+name: Fuel Surcharge Rate Monitor
+description: >
+  Checks the current published fuel surcharge index against your
+  baseline and flags a jump. Use this if a carrier's fuel surcharge has
+  ever crept up for weeks before it showed up as a bigger-than-expected
+  line item on the freight invoice.
+category: logistics
+tags: [logistics, freight, fuel-surcharge, rates]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  surcharge_pct=$(curl -s -H "Authorization: Bearer {{fuel_index_api_token}}" "{{fuel_index_api_url}}" | grep -o '"surcharge_pct":[0-9.]*' | head -n1 | cut -d':' -f2);
+  if [ -z "$surcharge_pct" ]; then echo "ERROR: could not fetch fuel surcharge data from {{fuel_index_api_url}}"; exit 1; fi;
+  if awk "BEGIN{exit !($surcharge_pct - {{baseline_surcharge_pct}} >= {{jump_threshold_pct}})}"; then
+    echo "WARNING: fuel surcharge is ${surcharge_pct}% (baseline {{baseline_surcharge_pct}}%, jumped >= {{jump_threshold_pct}}pt)";
+    exit 1;
+  else echo "OK: fuel surcharge is ${surcharge_pct}%, within tolerance of baseline {{baseline_surcharge_pct}}%"; fi
+variables:
+  fuel_index_api_url:
+    default: "https://api.example-carrier.com/fuel-surcharge/current"
+    description: Carrier or DOE fuel surcharge index API endpoint returning surcharge_pct.
+  fuel_index_api_token:
+    default: "your-api-token"
+    description: Bearer token for the fuel surcharge index API, if required.
+  baseline_surcharge_pct:
+    default: 25
+    description: Baseline fuel surcharge percentage to compare against.
+  jump_threshold_pct:
+    default: 5
+    description: Percentage-point jump above baseline that counts as worth flagging.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Generic REST pattern — point fuel_index_api_url at your carrier's
+  published surcharge schedule or the DOE/EIA weekly diesel price feed
+  used to derive it; adjust field names to match its response shape.
+  Distinct from freight-rate-spike-watch, which tracks the all-in
+  quoted lane rate rather than the fuel surcharge component alone.

package/jobs/logistics/international-shipment-documentation-check.yaml

@@ -0,0 +1,36 @@
+id: international-shipment-documentation-check
+version: 1
+name: International Shipment Documentation Completeness Check
+description: >
+  Checks upcoming international shipments for missing export/import
+  paperwork before they're due to ship. Use this if a shipment has ever
+  reached the port only to get held up because the commercial invoice or
+  certificate of origin was never finalized.
+category: logistics
+tags: [logistics, international, documentation, export, compliance]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{shipment_system_hint}} for international shipments scheduled
+  to depart within the next {{lookahead_days}} days.
+  1. For each shipment, verify the required document set is present:
+     commercial invoice, packing list, certificate of origin, and any
+     destination-specific requirements (e.g. import license, phytosanitary
+     certificate) for {{destination_hint}}.
+  2. Flag any shipment missing one or more required documents.
+  3. For each flagged shipment, note which document is missing and who
+     typically owns producing it (shipper, freight forwarder, customs
+     broker).
+variables:
+  shipment_system_hint:
+    default: "your TMS or export documentation system"
+    description: Where upcoming international shipments and their document status are tracked.
+  lookahead_days:
+    default: 5
+    description: How many days ahead to check for shipments needing documentation.
+  destination_hint:
+    default: "your typical export destination(s)"
+    description: Destination country/countries, since required documents vary by destination.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — required document sets vary by destination country and commodity, and need judgment about which regulatory requirements apply.

package/jobs/logistics/linehaul-transit-time-variance-check.yaml

@@ -0,0 +1,43 @@
+id: linehaul-transit-time-variance-check
+version: 1
+name: Linehaul Transit Time Variance Check
+description: >
+  Compares actual transit times against the scheduled transit time per
+  lane and flags lanes running consistently slow. Use this if a lane's
+  transit times have ever crept up gradually until service levels
+  quietly missed the mark for a whole quarter.
+category: logistics
+tags: [logistics, transit, lanes, performance]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_hours_threshold}}" '
+    NR==1 {next}
+    {
+      lane=$1; scheduled=$2; actual=$3;
+      variance = actual - scheduled;
+      sum[lane] += variance; count[lane]++;
+    }
+    END {
+      for (l in sum) {
+        avg = sum[l] / count[l];
+        if (avg >= tolerance) {
+          printf "SLOW LANE: %s — averaging %.1fh over scheduled transit time across %d shipments\n", l, avg, count[l];
+        }
+      }
+    }
+  ' "{{transit_times_csv_path}}"
+variables:
+  transit_times_csv_path:
+    default: "./lane-transit-times.csv"
+    description: "Path to a CSV with columns: lane,scheduled_transit_hours,actual_transit_hours — one row per completed shipment."
+  variance_hours_threshold:
+    default: 6
+    description: Average hours over scheduled transit time before a lane is flagged as consistently slow.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Aggregates variance across a lane's shipment history, unlike
+  shipment-delay-watch which checks a single shipment's live tracking
+  status — this catches gradual lane-level drift a one-off delay check
+  won't.

package/jobs/logistics/proof-of-delivery-reconciliation-check.yaml

@@ -0,0 +1,38 @@
+id: proof-of-delivery-reconciliation-check
+version: 1
+name: Proof-of-Delivery Reconciliation Check
+description: >
+  Checks shipments marked delivered against whether a signed proof-of-
+  delivery has actually been received and filed. Use this if a delivery
+  dispute has ever dragged on for weeks because nobody could produce the
+  POD to settle it.
+category: logistics
+tags: [logistics, delivery, pod, reconciliation]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{missing_pod_warn_days}}" '
+    NR==1 {next}
+    {
+      shipment=$1; delivered_date=$2; pod_received=$3;
+      if (pod_received == "no" || pod_received == "") {
+        cmd = "date -d \"" delivered_date "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" delivered_date "\" +%s 2>/dev/null";
+        cmd | getline delivered_epoch; close(cmd);
+        "date +%s" | getline now_epoch; close("date +%s");
+        age_days = (now_epoch - delivered_epoch) / 86400;
+        if (age_days >= days) {
+          printf "MISSING POD: shipment %s delivered %s (%d days ago), no proof-of-delivery on file\n", shipment, delivered_date, age_days;
+        }
+      }
+    }
+  ' "{{delivered_shipments_csv}}"
+variables:
+  delivered_shipments_csv:
+    default: "./delivered-shipments.csv"
+    description: "Path to a CSV with columns: shipment_id,delivered_date,pod_received (yes/no) — export from your TMS or carrier POD feed."
+  missing_pod_warn_days:
+    default: 3
+    description: Days after delivery a POD can be missing before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Assumes delivered status and POD receipt are both tracked in your TMS/carrier feed — this is the reconciliation backstop, not a POD capture system itself.

package/jobs/logistics/route-load-optimization-check.yaml

@@ -0,0 +1,32 @@
+id: route-load-optimization-check
+version: 1
+name: Route Load Optimization Check
+description: >
+  Checks planned truckload trailer fill rates and flags loads shipping
+  significantly under capacity. Use this if a half-empty trailer has
+  ever gone out the door because nobody checked fill rate before
+  dispatch, paying full linehaul cost for a fraction of the freight.
+category: logistics
+tags: [logistics, routing, load-planning, optimization]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{min_fill_pct}}" '
+    NR==1 {next}
+    {
+      load=$1; fill_pct=$2;
+      if (fill_pct < threshold) {
+        printf "UNDERFILLED: load %s — %.1f%% trailer fill, below %d%% target\n", load, fill_pct, threshold;
+      }
+    }
+  ' "{{planned_loads_csv_path}}"
+variables:
+  planned_loads_csv_path:
+    default: "./planned-loads.csv"
+    description: "Path to a CSV with columns: load_id,fill_pct — one row per load planned for today's dispatch, exported from your routing/load planning system."
+  min_fill_pct:
+    default: 80
+    description: Minimum acceptable trailer fill percentage before a load is flagged as underfilled.
+compatible_agents: [generic, claude, codex]
+notes: Assumes your routing/load-building system can export planned fill rate per load before dispatch — this is the pre-dispatch check, not a route optimization engine itself.

package/jobs/manufacturing/changeover-time-tracker.yaml

@@ -0,0 +1,29 @@
+id: changeover-time-tracker
+version: 1
+name: Changeover Time Tracker
+description: >
+  Compares logged changeover/setup durations against a target and flags
+  the ones that ran long. Use this if a slow product changeover has ever
+  eaten into a shift's output without anyone tracing the lost hours back
+  to the setup itself.
+category: manufacturing
+tags: [manufacturing, changeover, setup, efficiency]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{changeover_target_minutes}} '
+    NR==1 {next}
+    {
+      if ($3 > target) printf "LONG CHANGEOVER: line %s, %s -> %s, took %d min (target %d min)\n", $1, $2, $4, $3, target;
+    }
+  ' "{{changeover_log_csv}}"
+variables:
+  changeover_log_csv:
+    default: "./changeover-log.csv"
+    description: "CSV with header row, columns: line_id,from_product,duration_minutes,to_product — one row per changeover event."
+  changeover_target_minutes:
+    default: 45
+    description: Maximum acceptable changeover duration in minutes before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Log each changeover's start/end from the line's MES event stream or a shift supervisor's log — this job only compares durations against target, it doesn't time the changeover itself.

package/jobs/manufacturing/critical-spare-parts-stock-check.yaml

@@ -0,0 +1,29 @@
+id: critical-spare-parts-stock-check
+version: 1
+name: Critical Spare Parts Stock Check
+description: >
+  Compares on-hand stock of critical maintenance spare parts against a
+  set minimum and flags anything running low. Use this if a machine has
+  ever sat down for days waiting on a spare part that a stock check
+  would have caught weeks earlier.
+category: manufacturing
+tags: [manufacturing, maintenance, spare-parts, inventory]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    { if ($2 < $3) printf "LOW STOCK: critical spare \"%s\" — %d on hand, minimum %d\n", $1, $2, $3; }
+  ' "{{spare_parts_csv}}"
+variables:
+  spare_parts_csv:
+    default: "./critical-spare-parts.csv"
+    description: "CSV with header row, columns: part_name,qty_on_hand,min_qty — limited to parts flagged critical for equipment uptime, not general MRO stock."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Scoped to critical maintenance spares tied to specific equipment
+  (bearings, belts, sensors for machines on the floor), not general
+  warehouse/retail inventory — see inventory category's low-stock-alert
+  for that. Export critical-spare-parts.csv from your CMMS spare parts
+  module.

package/jobs/manufacturing/first-pass-yield-report.yaml

@@ -0,0 +1,37 @@
+id: first-pass-yield-report
+version: 1
+name: First-Pass Yield Report
+description: >
+  Calculates yesterday's first-pass yield (units that passed inspection
+  without rework) per production line and flags any line below target.
+  Use this if rework has ever been quietly absorbed as "normal" until
+  someone finally rolled up the numbers and saw how much it was costing.
+category: manufacturing
+tags: [manufacturing, quality, yield, production]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{fpy_target_pct}} '
+    NR==1 {next}
+    {
+      total[$1] += $2;
+      passed[$1] += $3;
+    }
+    END {
+      for (line in total) {
+        fpy = (passed[line] / total[line]) * 100;
+        status = (fpy < target) ? "BELOW TARGET" : "OK";
+        printf "%s: line %s — %.1f%% first-pass yield (%d of %d units), target %d%%\n", status, line, fpy, passed[line], total[line], target;
+      }
+    }
+  ' "{{production_log_csv}}"
+variables:
+  production_log_csv:
+    default: "./production-yield-log.csv"
+    description: "CSV with header row, columns: line_id,units_produced,units_passed_first_time — one row per shift/day for the reporting window."
+  fpy_target_pct:
+    default: 95
+    description: Minimum acceptable first-pass yield percentage per line.
+compatible_agents: [generic, claude, codex]
+notes: Export production-yield-log.csv from your MES's inspection/rework records before each run — a unit only counts as "passed" if it needed no rework or re-inspection.

package/jobs/manufacturing/lot-traceability-audit.yaml

@@ -0,0 +1,37 @@
+id: lot-traceability-audit
+version: 1
+name: Lot Traceability Audit
+description: >
+  Spot-checks that finished-goods lots have complete genealogy back to
+  their raw material lots and process records. Use this if a recall has
+  ever turned into a scramble because a lot's traceability records had
+  gaps nobody caught until they were needed under pressure.
+category: manufacturing
+tags: [manufacturing, traceability, quality, compliance, lots]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the list of finished-goods lots produced in the last
+  {{lookback_days}} days from {{traceability_system}}. For a sample of
+  {{sample_size}} lots (or all of them if fewer), verify each has:
+  1. A linked raw material lot / component lot record.
+  2. A linked process record (line, operator, date, key process
+     parameters).
+  3. A linked QC/inspection record with a disposition (pass/hold/reject).
+
+  Report any lot missing one of these links as a traceability gap, with
+  the lot ID and which link is missing. Summarize overall: lots checked,
+  lots with complete genealogy, lots with gaps.
+variables:
+  traceability_system:
+    default: "your MES/QMS lot genealogy records"
+    description: System of record for lot genealogy and production/QC linkage.
+  lookback_days:
+    default: 30
+    description: How many days back to pull finished-goods lots from.
+  sample_size:
+    default: 20
+    description: Number of lots to spot-check per run (use a full audit periodically instead of every run for large volumes).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: This is a spot-check, not a full recall-readiness audit — schedule a complete review of all lots on a longer cadence (e.g. quarterly) separately.

package/jobs/manufacturing/non-conformance-report-backlog-check.yaml

@@ -0,0 +1,34 @@
+id: non-conformance-report-backlog-check
+version: 1
+name: Non-Conformance Report Backlog Check
+description: >
+  Counts open non-conformance reports (NCRs) that have gone past their
+  disposition deadline without a root cause or corrective action logged.
+  Use this if an NCR has ever sat open for months with the nonconforming
+  material still floating around because nobody was tracking the
+  disposition clock.
+category: manufacturing
+tags: [manufacturing, quality, ncr, corrective-action, compliance]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $2 == "open" {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      if (due_ts < today) { overdue++; printf "OVERDUE: NCR %s (\"%s\") past disposition deadline of %s\n", $1, $4, $3 }
+      else open_count++;
+    }
+    END {
+      printf "Summary: %d NCR(s) open and on track, %d overdue past disposition deadline\n", open_count+0, overdue+0;
+    }
+  ' "{{ncr_log_csv}}"
+variables:
+  ncr_log_csv:
+    default: "./ncr-log.csv"
+    description: "CSV with header row, columns: ncr_id,status (open/closed),disposition_due_date(YYYY-MM-DD),description."
+compatible_agents: [generic, claude, codex]
+notes: Export ncr-log.csv from your QMS's non-conformance module before each run — this checks the disposition clock, it doesn't evaluate root cause quality.

package/jobs/manufacturing/oee-efficiency-check.yaml

@@ -0,0 +1,37 @@
+id: oee-efficiency-check
+version: 1
+name: OEE Efficiency Check
+description: >
+  Calculates Overall Equipment Effectiveness (availability x performance x
+  quality) for a line from a production log and flags it when it drops
+  below target. Use this if a line has ever "felt slow" for weeks before
+  anyone put a single number on how much effectiveness it was actually
+  losing.
+category: manufacturing
+tags: [manufacturing, oee, efficiency, production]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{oee_target_pct}} '
+    NR==1 {next}
+    {
+      planned=$2; runtime=$3; ideal_rate=$4; total_count=$5; good_count=$6;
+      availability = runtime / planned;
+      performance = (ideal_rate > 0) ? (total_count / (runtime * ideal_rate)) : 0;
+      if (performance > 1) performance = 1;
+      quality = (total_count > 0) ? (good_count / total_count) : 0;
+      oee = availability * performance * quality * 100;
+      status = (oee < target) ? "BELOW TARGET" : "OK";
+      printf "%s: line %s — OEE %.1f%% (avail %.0f%%, perf %.0f%%, qual %.0f%%), target %d%%\n", status, $1, oee, availability*100, performance*100, quality*100, target;
+    }
+  ' "{{oee_log_csv}}"
+variables:
+  oee_log_csv:
+    default: "./oee-log.csv"
+    description: "CSV with header row, columns: line_id,planned_minutes,runtime_minutes,ideal_units_per_minute,total_units,good_units — one row per line/day."
+  oee_target_pct:
+    default: 85
+    description: Minimum acceptable OEE percentage per line (world-class benchmark is often ~85%; adjust to your baseline).
+compatible_agents: [generic, claude, codex]
+notes: Export oee-log.csv from your MES's downtime and count records — this is a standard availability x performance x quality OEE calculation, not a substitute for the line-level downtime-cause detail in production-line-downtime-watch.

package/jobs/manufacturing/osha-recordable-incident-audit.yaml

@@ -0,0 +1,37 @@
+id: osha-recordable-incident-audit
+version: 1
+name: OSHA Recordable Incident Log Audit
+description: >
+  Checks the incident log for recordable injuries that haven't been
+  logged on the OSHA 300 form within the required window. Use this if a
+  recordable incident has ever slipped past the logging deadline because
+  the person who handled the report forgot to also update the 300 log.
+category: manufacturing
+tags: [manufacturing, safety, osha, compliance]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v deadline={{logging_deadline_days}} '
+    NR==1 {next}
+    $3 == "yes" && $4 == "no" {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline inc_ts; close(cmd);
+      days_since = int((today - inc_ts) / 86400);
+      if (days_since >= deadline) printf "OVERDUE: incident %s (%s) is recordable and unlogged, %d days since it happened (deadline %d days)\n", $1, $2, days_since, deadline;
+      else printf "PENDING: incident %s (%s) recordable and unlogged, %d days left to log\n", $1, $2, (deadline - days_since);
+    }
+  ' "{{incident_log_csv}}"
+variables:
+  incident_log_csv:
+    default: "./incident-log.csv"
+    description: "CSV with header row, columns: incident_id,incident_date(YYYY-MM-DD),recordable(yes/no),logged_on_300(yes/no)."
+  logging_deadline_days:
+    default: 7
+    description: Days allowed to record a qualifying incident on the OSHA 300 log before it's flagged overdue.
+compatible_agents: [generic, claude, codex]
+notes: >
+  This checks logging timeliness against a configurable window you set —
+  confirm current OSHA recordkeeping deadlines with your safety officer
+  or counsel, this job doesn't determine recordability itself.

package/jobs/manufacturing/production-schedule-adherence-check.yaml

@@ -0,0 +1,35 @@
+id: production-schedule-adherence-check
+version: 1
+name: Production Schedule Adherence Check
+description: >
+  Compares actual output against the planned production schedule and
+  explains any meaningful variance. Use this if a schedule slip has ever
+  gone unexplained until it was too late to recover the shift, because
+  nobody compared plan vs. actual until the week was already over.
+category: manufacturing
+tags: [manufacturing, production-planning, schedule, variance]
+schedule: "0 6 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull yesterday's planned vs. actual production output per line from
+  {{data_source}}. For any line where actual output missed plan by more
+  than {{variance_threshold_pct}}%:
+  1. Report the planned quantity, actual quantity, and variance.
+  2. Check downtime/quality logs for that line for the same period and
+     note any likely cause (downtime event, quality hold, changeover,
+     staffing).
+  3. If no clear cause is found in the logs, flag it as "unexplained
+     variance" for a supervisor to look into.
+
+  Summarize lines on plan, lines behind with an identified cause, and
+  lines with unexplained variance.
+variables:
+  data_source:
+    default: "your MES/ERP production schedule and output records"
+    description: System of record for planned schedule, actual output, and downtime/quality logs.
+  variance_threshold_pct:
+    default: 10
+    description: Percentage variance from plan that triggers a variance investigation.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Complements production-line-downtime-watch and quality-defect-rate-check by tying variance back to a likely cause instead of just reporting the stoppage or defect rate in isolation.