@wonsukchoi/crondex 0.20.1 → 0.22.0

package/jobs/sales/contract-renewal-opportunity-tracker.yaml

@@ -0,0 +1,28 @@
+id: contract-renewal-opportunity-tracker
+version: 1
+name: Contract Renewal Opportunity Tracker
+description: >
+  Flags existing customer contracts approaching their renewal date so
+  account management can start the renewal conversation early. Use this
+  if a contract has ever auto-lapsed or renewed on unfavorable terms
+  because nobody flagged it until it was almost too late.
+category: sales
+tags: [sales, renewals, contracts, account-management]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_name, owner, contract_value, renewal_date from contracts where status = 'active' and renewal_date < now() + interval '{{warn_days}} days' order by renewal_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the contracts/CRM database.
+  warn_days:
+    default: 60
+    description: Days before renewal_date to start flagging a contract for renewal outreach.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `contracts` table with `status`, `renewal_date`, `owner`, and
+  `contract_value` columns — adjust to your schema. Distinct from
+  `quote-expiry-reminder` (pre-sale quotes that haven't been signed yet);
+  this tracks signed, active customer contracts nearing their renewal date.

package/jobs/sales/discount-approval-pending-check.yaml

@@ -0,0 +1,31 @@
+id: discount-approval-pending-check
+version: 1
+name: Discount Approval Pending Check
+description: >
+  Flags deals with a discount above your standard threshold that are
+  still waiting on manager approval, especially ones that have been
+  sitting for a while. Use this if a rep has ever quoted a customer a
+  deep discount and the deal stalled for days waiting on an approval
+  nobody knew was pending.
+category: sales
+tags: [sales, discounts, approvals, deal-desk]
+schedule: "0 */4 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, owner, discount_pct, approval_requested_at from deals where discount_pct >= {{discount_threshold_pct}} and approval_status = 'pending' and approval_requested_at < now() - interval '{{stale_hours}} hours' order by approval_requested_at;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+  discount_threshold_pct:
+    default: 15
+    description: Discount percent that requires manager approval in your process.
+  stale_hours:
+    default: 24
+    description: Hours an approval request can sit pending before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `deals` table with `discount_pct`, `approval_status`, and
+  `approval_requested_at` columns from a deal-desk/CPQ approval workflow
+  — adjust field names to match your process.

package/jobs/sales/forecast-submission-compliance-check.yaml

@@ -0,0 +1,42 @@
+id: forecast-submission-compliance-check
+version: 1
+name: Forecast Submission Compliance Check
+description: >
+  Compares your active rep roster against submitted forecast records for
+  the current period and flags anyone who hasn't submitted yet. Use this
+  if sales leadership has ever walked into a forecast review meeting only
+  to find out half the team never actually submitted numbers.
+category: sales
+tags: [sales, forecasting, compliance, sales-ops]
+schedule: "0 9 * * 5"
+timezone: "UTC"
+runner: shell
+command: >
+  period="{{current_period}}";
+  if [ -z "$period" ]; then period=$(date +%G-W%V); fi;
+  awk -F',' -v period="$period" '
+    NR==FNR { if (FNR>1) reps[$1]=1; next }
+    FNR==1 { next }
+    $2 == period { submitted[$1]=1 }
+    END {
+      for (r in reps) {
+        if (!(r in submitted)) print "MISSING FORECAST: " r " has not submitted for " period;
+      }
+    }
+  ' "{{reps_csv_path}}" "{{forecasts_csv_path}}"
+variables:
+  reps_csv_path:
+    default: "./active-reps.csv"
+    description: "Path to a CSV with header row and column: rep_name — one row per active rep expected to submit a forecast."
+  forecasts_csv_path:
+    default: "./forecast-submissions.csv"
+    description: "Path to a CSV with header row and columns: rep_name,period,submitted_at — one row per submitted forecast."
+  current_period:
+    default: ""
+    description: 'The period identifier to check submissions against (e.g. ISO week or "2026-Q3"). Leave blank to default to the current ISO week (YYYY-Www) — override if your forecasts CSV uses a different period format.'
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain both CSVs yourself (export active-reps.csv from your HRIS
+  or CRM user list, and forecast-submissions.csv from wherever forecasts
+  are logged) — the `current_period` value must match how periods are
+  written in forecast-submissions.csv exactly.

package/jobs/sales/multi-year-renewal-escalation-tracker.yaml

@@ -0,0 +1,31 @@
+id: multi-year-renewal-escalation-tracker
+version: 1
+name: Multi-Year Renewal Escalation Tracker
+description: >
+  Flags multi-year contracts approaching their next contract-year
+  anniversary, where a pre-agreed price escalation kicks in, so the
+  customer gets notice before the higher invoice arrives. Use this if a
+  customer has ever been surprised by a built-in price increase on a
+  multi-year deal because nobody sent the required notice ahead of the
+  anniversary date.
+category: sales
+tags: [sales, renewals, multi-year, pricing, account-management]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_name, owner, escalation_pct, next_anniversary_date from multi_year_contracts where next_anniversary_date < now() + interval '{{notice_days}} days' order by next_anniversary_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the contracts/CRM database.
+  notice_days:
+    default: 45
+    description: Days of advance notice required before a contract's next anniversary/escalation date.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `multi_year_contracts` table with `next_anniversary_date` and
+  `escalation_pct` columns tracking the pre-agreed annual price increase
+  — adjust to your schema. Distinct from `contract-renewal-opportunity-tracker`,
+  which covers the end-of-term renewal decision rather than an in-term
+  contractual price step-up.

package/jobs/sales/pipeline-hygiene-audit.yaml

@@ -0,0 +1,26 @@
+id: pipeline-hygiene-audit
+version: 1
+name: Pipeline Hygiene Audit
+description: >
+  Finds open deals missing basic required fields, like an amount, a close
+  date, or a next step, so forecasts and reports aren't quietly built on
+  bad data. Use this if a forecast has ever been wrong because half the
+  pipeline had blank fields nobody was checking for.
+category: sales
+tags: [sales, pipeline, data-quality, crm-hygiene]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, owner, stage, (case when amount is null then 'missing amount' end) || (case when close_date is null then ' missing close_date' end) || (case when next_step is null or next_step = '' then ' missing next_step' end) as issues from deals where stage not in ('closed_won','closed_lost') and (amount is null or close_date is null or next_step is null or next_step = '');"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `deals` table with `amount`, `close_date`, and `next_step`
+  columns — adjust the query and the required-field list to what your
+  team actually treats as mandatory. Distinct from `stale-deal-nudge`
+  (which flags deals with no recent activity) — this flags deals with
+  incomplete data regardless of how recently they were touched.

package/jobs/sales/poc-trial-conversion-tracker.yaml

@@ -0,0 +1,29 @@
+id: poc-trial-conversion-tracker
+version: 1
+name: Sales-Led POC Conversion Tracker
+description: >
+  Flags sales-assisted proof-of-concept (POC) engagements approaching or
+  past their end date with no closed-won or closed-lost outcome recorded.
+  Use this if an enterprise POC has ever quietly run past its agreed end
+  date with no clear owner pushing toward a decision.
+category: sales
+tags: [sales, poc, enterprise, conversion]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select account_name, owner, poc_end_date, stage from pocs where stage = 'in_progress' and poc_end_date < now() + interval '{{lookahead_days}} days' order by poc_end_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database (a `pocs` table or equivalent stage on `deals`).
+  lookahead_days:
+    default: 7
+    description: How many days ahead (or past, if negative logic is added) to flag a POC nearing its end date.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `pocs` table (or a `deals` table filtered to a POC stage) with
+  `poc_end_date` and `stage` columns — adjust to your CRM's schema. This
+  is a sales-assisted enterprise POC tracked in the CRM by a rep, distinct
+  from growth's `trial-expiring-nudge`, which tracks self-serve product
+  trials nearing expiration.

package/jobs/sales/referral-followup-tracker.yaml

@@ -0,0 +1,40 @@
+id: referral-followup-tracker
+version: 1
+name: Referral Follow-Up Tracker
+description: >
+  Flags customer referrals that were asked for or given, and haven't had a
+  logged follow-up after a set number of days. Use this if a happy
+  customer has ever offered a referral introduction and it fell through
+  the cracks because nobody owned the follow-up.
+category: sales
+tags: [sales, referrals, advocacy, follow-up]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v wait_days="{{wait_days}}" '
+    NR==1 {next}
+    $5 == "yes" {next}
+    {
+      customer=$1; referred_contact=$2; requested_date=$3; owner=$4;
+      cmd = "date -d \"" requested_date "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" requested_date "\" +%s 2>/dev/null";
+      cmd | getline req_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days = (now_epoch - req_epoch) / 86400;
+      if (days >= wait_days) {
+        printf "NEEDS FOLLOW-UP: %s referred %s (owner: %s) — %d day(s) since requested\n", customer, referred_contact, owner, days;
+      }
+    }
+  ' "{{referrals_csv_path}}"
+variables:
+  referrals_csv_path:
+    default: "./referrals.csv"
+    description: "Path to a CSV with columns: customer_name,referred_contact,requested_date,owner,followed_up (yes/no; requested_date is YYYY-MM-DD)."
+  wait_days:
+    default: 5
+    description: Days after a referral is logged before it's flagged as overdue for a follow-up.
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain referrals.csv yourself (log it when a customer offers or
+  makes an introduction, mark followed_up=yes once the owner reaches out)
+  — doesn't integrate with any CRM directly.

package/jobs/sales/territory-coverage-gap-check.yaml

@@ -0,0 +1,43 @@
+id: territory-coverage-gap-check
+version: 1
+name: Territory Coverage Gap Check
+description: >
+  Flags target accounts that have no assigned rep, or have an assigned
+  rep but no logged activity in a long time. Use this if an account has
+  ever gone completely unworked for months simply because it fell between
+  territory reassignments and nobody noticed the gap.
+category: sales
+tags: [sales, territory, account-coverage, ops]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v stale_days="{{stale_days}}" '
+    NR==1 {next}
+    {
+      account=$1; rep=$2; last_activity=$3;
+      if (rep == "" ) {
+        printf "UNASSIGNED: %s has no assigned rep\n", account;
+        next;
+      }
+      cmd = "date -d \"" last_activity "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" last_activity "\" +%s 2>/dev/null";
+      cmd | getline last_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days = (now_epoch - last_epoch) / 86400;
+      if (days >= stale_days) {
+        printf "NO ACTIVITY: %s (rep: %s) — %d day(s) since last activity\n", account, rep, days;
+      }
+    }
+  ' "{{accounts_csv_path}}"
+variables:
+  accounts_csv_path:
+    default: "./target-accounts.csv"
+    description: "Path to a CSV with columns: account_name,assigned_rep,last_activity_date (YYYY-MM-DD; assigned_rep blank if unowned)."
+  stale_days:
+    default: 45
+    description: Days without logged activity on an assigned account before it's flagged as a coverage gap.
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain target-accounts.csv yourself (or export it from your CRM's
+  account list) — this is a coverage/ownership check, not a deal-level
+  staleness check (see `stale-deal-nudge` for that).

package/jobs/spa/appointment-no-show-tracker.yaml

@@ -0,0 +1,46 @@
+id: appointment-no-show-tracker
+version: 1
+name: Appointment No-Show & Late-Cancel Tracker
+description: >
+  Flags clients who no-showed or cancelled late in the past window so front
+  desk can follow up or apply a policy. Use this if a chair or treatment
+  room has ever sat empty because a client skipped without warning and
+  nobody noticed the pattern until it kept happening.
+category: spa
+tags: [spa, appointments, no-show, front-desk]
+schedule: "0 18 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{lookback_days}}" -v threshold="{{repeat_threshold}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline appt_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (now_epoch - appt_epoch) / 86400;
+      if (diff_days >= 0 && diff_days <= days && ($3 == "no-show" || $3 == "late-cancel")) {
+        count[$1]++;
+        printf "FLAGGED: %s — %s on %s\n", $1, $3, $2;
+      }
+    }
+    END {
+      for (client in count) {
+        if (count[client] >= threshold) {
+          printf "REPEAT OFFENDER: %s — %d no-show/late-cancel(s) in last %d days\n", client, count[client], days;
+        }
+      }
+    }
+  ' "{{appointments_csv_path}}"
+variables:
+  appointments_csv_path:
+    default: "./appointments.csv"
+    description: "Path to a CSV with columns: client_name,appointment_date (YYYY-MM-DD),status (no-show,late-cancel,completed,etc)."
+  lookback_days:
+    default: 30
+    description: How many days back to scan for no-shows and late cancels.
+  repeat_threshold:
+    default: 2
+    description: Number of no-show/late-cancel incidents in the lookback window before flagging a client as a repeat offender.
+compatible_agents: [generic, claude, codex]
+notes: Repeat offenders are good candidates for a deposit-required or confirm-by-text policy before their next booking.

package/jobs/spa/gift-card-expiry-check.yaml

@@ -0,0 +1,35 @@
+id: gift-card-expiry-check
+version: 1
+name: Gift Card Expiry Check
+description: >
+  Scans your gift card ledger for cards approaching their expiration date
+  with a remaining balance. Use this if a client has ever held an unused
+  gift card that quietly expired, turning a goodwill purchase into a
+  complaint at checkout.
+category: spa
+tags: [spa, gift-cards, retention, front-desk]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $3 > 0 {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline exp_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (exp_epoch - now_epoch) / 86400;
+      if (diff_days <= days && diff_days >= 0) {
+        printf "GIFT CARD EXPIRING: %s — balance $%.2f, expires %s (%d days)\n", $1, $3, $2, diff_days;
+      }
+    }
+  ' "{{gift_cards_csv_path}}"
+variables:
+  gift_cards_csv_path:
+    default: "./gift-cards.csv"
+    description: "Path to a CSV with columns: card_code_or_holder,expiry_date (YYYY-MM-DD),remaining_balance."
+  warn_days_before:
+    default: 30
+    description: How many days before expiry to start warning, so the holder can be reminded to redeem it.
+compatible_agents: [generic, claude, codex]
+notes: Check local law before letting balances actually expire — many states restrict or ban gift card expiration, so this may need to become a "reminder only" job.

package/jobs/spa/license-renewal-tracker.yaml

@@ -0,0 +1,35 @@
+id: license-renewal-tracker
+version: 1
+name: Esthetician/Cosmetologist License Renewal Tracker
+description: >
+  Warns before a staff member's state license, certification, or
+  continuing-education deadline lapses. Use this if a technician has ever
+  shown up ready to work a shift, only to discover their license expired
+  last month and they can't legally touch a client.
+category: spa
+tags: [spa, licensing, compliance, staff]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline exp_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (exp_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "LICENSE EXPIRING: %s (%s) — expires %s (%d days)\n", $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{licenses_csv_path}}"
+variables:
+  licenses_csv_path:
+    default: "./staff-licenses.csv"
+    description: "Path to a CSV with columns: staff_name,license_type,expiry_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 30
+    description: How many days before expiry to start warning, leaving time to complete renewal or CE hours.
+compatible_agents: [generic, claude, codex]
+notes: A lapsed license can be a licensing-board violation for both the technician and the business, so warn early enough to complete any required CE hours.

package/jobs/spa/membership-unused-session-expiry-check.yaml

@@ -0,0 +1,35 @@
+id: membership-unused-session-expiry-check
+version: 1
+name: Membership/Package Unused-Session Expiry Check
+description: >
+  Flags members or package holders whose prepaid sessions or membership
+  credits are about to expire unused. Use this if a client has ever paid
+  for a monthly facial membership, banked three unused visits, and let
+  them evaporate because nobody reminded them to book.
+category: spa
+tags: [spa, membership, churn, retention]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $4 > 0 {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline exp_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (exp_epoch - now_epoch) / 86400;
+      if (diff_days <= days && diff_days >= 0) {
+        printf "CREDITS EXPIRING: %s — %d unused credit(s), expires %s (%d days)\n", $1, $4, $3, diff_days;
+      }
+    }
+  ' "{{memberships_csv_path}}"
+variables:
+  memberships_csv_path:
+    default: "./memberships.csv"
+    description: "Path to a CSV with columns: member_name,plan_name,credit_expiry_date (YYYY-MM-DD),unused_credits."
+  warn_days_before:
+    default: 10
+    description: How many days before credit expiry to start warning, while there's still time to book.
+compatible_agents: [generic, claude, codex]
+notes: A member who repeatedly lets credits expire unused is a churn risk — treat this as a retention nudge, not just a "use it or lose it" notice.

package/jobs/spa/product-chemical-expiry-check.yaml

@@ -0,0 +1,35 @@
+id: product-chemical-expiry-check
+version: 1
+name: Product & Chemical Expiry Check
+description: >
+  Flags skincare products, dye lots, wax, and other chemical inventory
+  approaching their expiration or period-after-opening date. Use this if
+  an esthetician or colorist has ever applied a product past its safe-use
+  date because the expiry label was never checked against today's date.
+category: spa
+tags: [spa, inventory, expiry, safety, chemicals]
+schedule: "0 6 * * 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 exp_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (exp_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "EXPIRING/EXPIRED: %s (lot %s) — expires %s (%d days)\n", $1, $3, $2, diff_days;
+      }
+    }
+  ' "{{product_expiry_csv_path}}"
+variables:
+  product_expiry_csv_path:
+    default: "./product-expiry.csv"
+    description: "Path to a CSV with columns: product_name,expiry_or_pao_date (YYYY-MM-DD),lot_number."
+  warn_days_before:
+    default: 14
+    description: How many days before expiry to start warning, so stock can be used up or pulled before it goes bad.
+compatible_agents: [generic, claude, codex]
+notes: Applying an expired chemical (peel, dye, wax) can cause skin reactions — pull flagged items from active use immediately, don't just discount and sell through.

package/jobs/spa/retail-product-low-stock-check.yaml

@@ -0,0 +1,26 @@
+id: retail-product-low-stock-check
+version: 1
+name: Retail Product Low-Stock Check
+description: >
+  Scans your retail/backbar inventory log and flags skincare, haircare, or
+  nail products at or below reorder point. Use this if a stylist or
+  esthetician has ever reached for a product mid-service and found the
+  shelf empty because nobody was watching the count.
+category: spa
+tags: [spa, retail, inventory, restock]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    $2 <= $3 {
+      printf "LOW STOCK: %s — %d on hand, reorder point %d\n", $1, $2, $3;
+    }
+  ' "{{inventory_csv_path}}"
+variables:
+  inventory_csv_path:
+    default: "./retail-inventory.csv"
+    description: "Path to a CSV with columns: product_name,quantity_on_hand,reorder_point."
+compatible_agents: [generic, claude, codex]
+notes: Pair the reorder point with your supplier's typical lead time so you never hit zero mid-service.

package/jobs/spa/safety-inspection-due-reminder.yaml

@@ -0,0 +1,33 @@
+id: safety-inspection-due-reminder
+version: 1
+name: Health & Safety Inspection Due Reminder
+description: >
+  Warns before a health department, board-of-cosmetology, or fire/safety
+  inspection is expected, based on your jurisdiction's typical interval.
+  Use this if an inspector has ever shown up to a treatment room that
+  wasn't ready because nobody was tracking when the last inspection
+  happened.
+category: spa
+tags: [spa, compliance, inspection, safety]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  last_ts=$(date -d "{{last_inspection_date}}" +%s 2>/dev/null || date -jf "%Y-%m-%d" "{{last_inspection_date}}" +%s);
+  days_since=$(( (today - last_ts) / 86400 ));
+  days_left=$(( {{typical_interval_days}} - days_since ));
+  if [ "$days_left" -le "{{warn_days}}" ]; then echo "WARNING: next inspection likely due within $days_left days (last was {{last_inspection_date}})"; exit 1;
+  else echo "OK: next inspection likely due in about $days_left days"; fi
+variables:
+  last_inspection_date:
+    default: "2026-01-01"
+    description: Date of the last health/safety/board inspection (YYYY-MM-DD).
+  typical_interval_days:
+    default: 365
+    description: Typical number of days between inspections in your jurisdiction.
+  warn_days:
+    default: 21
+    description: Days before the estimated next inspection to start warning.
+compatible_agents: [generic, claude, codex]
+notes: This is an estimate based on your jurisdiction's typical cadence, not a confirmed scheduled date — most boards don't publish inspection dates in advance.

package/jobs/telecom/circuit-outage-detection.yaml

@@ -0,0 +1,38 @@
+id: circuit-outage-detection
+version: 1
+name: Circuit Outage Detection
+description: >
+  Pings each monitored circuit endpoint and flags any that are down.
+  Use this if a customer circuit has ever gone dark and nobody on your
+  team noticed until the customer called in.
+category: telecom
+tags: [telecom, outage, monitoring, circuits]
+schedule: "*/5 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  down=0;
+  while IFS=',' read -r circuit_id endpoint _rest; do
+    [ "$circuit_id" = "circuit_id" ] && continue;
+    [ -z "$endpoint" ] && continue;
+    if ! ping -c "{{ping_count}}" -W "{{ping_timeout_sec}}" "$endpoint" >/dev/null 2>&1; then
+      echo "DOWN: circuit $circuit_id ($endpoint) is not responding";
+      down=1;
+    fi;
+  done < "{{circuits_csv_path}}";
+  if [ "$down" -eq 0 ]; then echo "OK: all monitored circuits responding"; else exit 1; fi
+variables:
+  circuits_csv_path:
+    default: "./circuits.csv"
+    description: "Path to a CSV with columns: circuit_id,endpoint (IP or hostname to ping)."
+  ping_count:
+    default: 2
+    description: Number of ping probes per circuit before declaring it down.
+  ping_timeout_sec:
+    default: 3
+    description: Timeout in seconds per ping probe.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Uses ICMP ping as a cheap reachability check — swap in an SNMP or NMS API
+  poll if your circuits are behind firewalls that block ICMP. Read-only,
+  no state changes.

package/jobs/telecom/circuit-provisioning-order-aging.yaml

@@ -0,0 +1,36 @@
+id: circuit-provisioning-order-aging
+version: 1
+name: Circuit Provisioning Order Aging Check
+description: >
+  Flags circuit orders that were placed but never activated within a
+  target number of days. Use this if a provisioning order has ever sat
+  in limbo for weeks because the install date fell through the cracks
+  between sales, the carrier, and the field tech.
+category: telecom
+tags: [telecom, provisioning, circuits, orders]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v max_days="{{max_days_to_activate}}" '
+    NR==1 {next}
+    $3 != "" {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline order_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      age_days = (now_epoch - order_epoch) / 86400;
+      if (age_days >= max_days) {
+        printf "AGING ORDER: %s ordered %s (%d days ago), still not activated\n", $1, $2, age_days;
+      }
+    }
+  ' "{{orders_csv_path}}"
+variables:
+  orders_csv_path:
+    default: "./provisioning-orders.csv"
+    description: "Path to a CSV with columns: order_id,order_date (YYYY-MM-DD),activated_date (blank if not yet activated)."
+  max_days_to_activate:
+    default: 21
+    description: Days after order date to flag as aging if still not activated.
+compatible_agents: [generic, claude, codex]
+notes: Assumes order/activation dates are updated in the CSV from your provisioning ticketing system.

package/jobs/telecom/cpe-firmware-update-tracker.yaml

@@ -0,0 +1,45 @@
+id: cpe-firmware-update-tracker
+version: 1
+name: CPE Firmware/Warranty Update Tracker
+description: >
+  Checks deployed customer-premises equipment against current firmware
+  versions and warranty expiry dates, flagging anything out of date or
+  soon out of warranty. Use this if a modem or router has ever been
+  running years-old firmware with a known vulnerability because nobody
+  was tracking the fleet's patch level.
+category: telecom
+tags: [telecom, cpe, firmware, warranty]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target_fw="{{target_firmware_version}}" -v warn_days="{{warranty_warn_days}}" '
+    NR==1 {next}
+    {
+      device=$1; fw=$2; warranty_end=$3;
+      if (fw != target_fw) {
+        printf "OUTDATED FIRMWARE: %s running %s, target is %s\n", device, fw, target_fw;
+      }
+      if (warranty_end != "") {
+        cmd = "date -d \"" warranty_end "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" warranty_end "\" +%s 2>/dev/null";
+        cmd | getline end_epoch; close(cmd);
+        "date +%s" | getline now_epoch; close("date +%s");
+        diff_days = (end_epoch - now_epoch) / 86400;
+        if (diff_days <= warn_days) {
+          printf "WARRANTY EXPIRING: %s warranty ends %s (%d days)\n", device, warranty_end, diff_days;
+        }
+      }
+    }
+  ' "{{cpe_inventory_csv_path}}"
+variables:
+  cpe_inventory_csv_path:
+    default: "./cpe-inventory.csv"
+    description: "Path to a CSV with columns: device_id,firmware_version,warranty_end_date (YYYY-MM-DD, blank if unknown)."
+  target_firmware_version:
+    default: "1.0.0"
+    description: The firmware version the fleet should be running.
+  warranty_warn_days:
+    default: 30
+    description: Days before warranty expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Assumes CPE inventory is exported from your provisioning/asset system into the CSV before this runs.