@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/restaurant/gift-card-liability-check.yaml

@@ -0,0 +1,45 @@
+id: gift-card-liability-check
+version: 1
+name: Gift Card Liability Reconciliation
+description: >
+  Reconciles total outstanding gift card balance (liability) against
+  cards sold minus cards redeemed for the period, and flags a mismatch
+  worth investigating. Use this if you've ever had to guess at your
+  gift card liability for the books instead of actually reconciling it.
+category: restaurant
+tags: [restaurant, gift-cards, finance, reconciliation]
+schedule: "0 9 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  sold="{{gift_cards_sold_usd}}";
+  redeemed="{{gift_cards_redeemed_usd}}";
+  prior="{{prior_period_liability_usd}}";
+  ledger="{{current_ledger_balance_usd}}";
+  tolerance="{{variance_tolerance_usd}}";
+  expected=$(awk -v p="$prior" -v s="$sold" -v r="$redeemed" 'BEGIN{printf "%.2f", p+s-r}');
+  diff=$(awk -v e="$expected" -v l="$ledger" 'BEGIN{d=e-l; if (d<0) d=-d; printf "%.2f", d}');
+  if awk -v d="$diff" -v t="$tolerance" 'BEGIN{exit !(d > t)}'; then
+    echo "MISMATCH: expected liability \$$expected, ledger shows \$$ledger (diff \$$diff)";
+    exit 1;
+  else
+    echo "OK: gift card liability reconciles within tolerance (\$$diff diff)";
+  fi
+variables:
+  gift_cards_sold_usd:
+    default: 0
+    description: Total value of gift cards sold during the period.
+  gift_cards_redeemed_usd:
+    default: 0
+    description: Total value of gift cards redeemed during the period.
+  prior_period_liability_usd:
+    default: 0
+    description: Outstanding gift card liability carried over from the prior period.
+  current_ledger_balance_usd:
+    default: 0
+    description: Current outstanding gift card balance as recorded in your accounting ledger.
+  variance_tolerance_usd:
+    default: 25
+    description: Dollar variance allowed before the reconciliation is flagged as a mismatch.
+compatible_agents: [generic, claude, codex]
+notes: This reconciles aggregate liability for the books, not individual card expiry — pair with a per-card expiry check if your state allows gift cards to expire.

package/jobs/restaurant/kitchen-ticket-time-watch.yaml

@@ -0,0 +1,38 @@
+id: kitchen-ticket-time-watch
+version: 1
+name: Kitchen Ticket Time Watch
+description: >
+  Reviews kitchen display system ticket times (fire to plate-up) and
+  flags stations or dayparts running consistently slower than target.
+  Use this if slow ticket times have ever driven complaints or comps
+  before anyone traced it back to a specific station falling behind.
+category: restaurant
+tags: [restaurant, kitchen, kds, speed-of-service]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull ticket time data from {{kds_system}} for the past
+  {{lookback_days}} days, including station, item, fire time, and
+  plate-up time.
+  1. Calculate average ticket time overall and by station.
+  2. Flag any station averaging above {{target_minutes}} minutes, and
+     note whether the slowness is concentrated at specific dayparts
+     (peak lunch/dinner rushes vs. slow periods).
+  3. Identify the specific menu items driving the slowest tickets at
+     each flagged station.
+  4. Suggest one concrete fix per flagged station — additional prep,
+     station staffing, or menu item batching — without recommending
+     cutting a dish outright unless it's clearly the only lever.
+variables:
+  kds_system:
+    default: "your kitchen display system"
+    description: Name of the KDS (e.g. "Toast KDS", "QSR Automations", "a manual ticket-time log").
+  lookback_days:
+    default: 14
+    description: Window of ticket data to analyze.
+  target_minutes:
+    default: 15
+    description: Target average ticket time in minutes before a station is flagged as running slow.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only speed-of-service analysis — pair with kitchen leadership before making staffing changes based on the findings.

package/jobs/restaurant/liquor-pour-cost-variance-check.yaml

@@ -0,0 +1,34 @@
+id: liquor-pour-cost-variance-check
+version: 1
+name: Liquor Pour Cost Variance Check
+description: >
+  Compares each bottle's theoretical usage (from drinks sold) against
+  actual bottle depletion from inventory counts, and flags bottles
+  showing a variance that points to over-pouring, spillage, or theft.
+  Use this if the bar's overall liquor cost percentage looks fine but
+  you suspect a specific bottle is walking off faster than it's rung up.
+category: restaurant
+tags: [restaurant, bar, liquor-cost, inventory, loss-prevention]
+schedule: "0 7 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_tolerance_pct}}" '
+    NR==1 {next}
+    {
+      if ($2 > 0) {
+        variance_pct = (($3 - $2) / $2) * 100;
+        absvar = (variance_pct < 0) ? -variance_pct : variance_pct;
+        if (absvar > tolerance) printf "POUR VARIANCE: %s — theoretical usage %.1f oz, actual depletion %.1f oz (%.1f%% variance)\n", $1, $2, $3, variance_pct;
+      }
+    }
+  ' "{{pour_cost_csv}}"
+variables:
+  pour_cost_csv:
+    default: "./liquor-pour-cost.csv"
+    description: "CSV with header row, columns: bottle_name,theoretical_usage_oz,actual_depletion_oz — theoretical comes from POS drink sales times recipe pour size, actual from physical bottle counts."
+  variance_tolerance_pct:
+    default: 10
+    description: Percentage variance (either direction) allowed before a bottle is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from food-cost-percentage-watch and menu-item-profitability-check — this drills into per-bottle variance at the bar rather than an overall cost ratio or a food dish's margin.

package/jobs/restaurant/menu-86-frequency-tracker.yaml

@@ -0,0 +1,39 @@
+id: menu-86-frequency-tracker
+version: 1
+name: Menu Item 86 Frequency Tracker
+description: >
+  Reviews how often each menu item gets 86'd (marked sold out) mid-
+  service and flags items that run out repeatedly, which usually points
+  to a par-level or ordering problem rather than one bad night. Use
+  this if the same dish has ever been 86'd three Fridays in a row
+  before anyone connected the dots.
+category: restaurant
+tags: [restaurant, menu, kitchen, ordering, par-levels]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull 86 (sold-out) log entries from {{pos_or_kitchen_log}} for the
+  past {{lookback_days}} days, including item name, time 86'd, and
+  time (if any) it came back available.
+  1. Rank menu items by number of times 86'd in the window.
+  2. For each item 86'd more than {{repeat_threshold}} times, note the
+     typical time of day/day of week it runs out, which suggests
+     whether it's a prep-quantity or a purchasing-quantity issue.
+  3. Flag any item that's been 86'd on back-to-back service days —
+     that's a stronger signal than scattered one-offs.
+  4. Suggest a par-level or prep-batch adjustment per repeatedly-86'd
+     item, distinct from a general waste-log review which looks at
+     over-ordering rather than under-ordering.
+variables:
+  pos_or_kitchen_log:
+    default: "your POS 86 list or kitchen display system"
+    description: Where 86'd items get logged (e.g. "Toast 86 list", "a kitchen whiteboard log transcribed daily").
+  lookback_days:
+    default: 30
+    description: Window of 86-log history to analyze.
+  repeat_threshold:
+    default: 3
+    description: Minimum number of times an item must be 86'd in the window to be called out individually.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Complements inventory-waste-log-review — that job catches over-ordering (waste), this one catches under-ordering (running out).

package/jobs/restaurant/menu-item-profitability-check.yaml

@@ -0,0 +1,33 @@
+id: menu-item-profitability-check
+version: 1
+name: Menu Item Profitability Check
+description: >
+  Compares each menu item's plate cost against its menu price and flags
+  items whose contribution margin has dropped below target. Use this if
+  an ingredient cost has ever crept up on a specific dish until it was
+  quietly losing money on every order, unlike the overall food-cost
+  percentage which only shows the average.
+category: restaurant
+tags: [restaurant, menu-engineering, margin, food-cost]
+schedule: "0 8 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v target="{{min_margin_pct}}" '
+    NR==1 {next}
+    {
+      if ($3 > 0) {
+        margin_pct = (($3 - $2) / $3) * 100;
+        if (margin_pct < target) printf "LOW MARGIN: %s — plate cost $%.2f, price $%.2f, margin %.1f%% (target %.0f%%)\n", $1, $2, $3, margin_pct, target;
+      }
+    }
+  ' "{{menu_cost_csv}}"
+variables:
+  menu_cost_csv:
+    default: "./menu-item-costs.csv"
+    description: "CSV with header row, columns: item_name,plate_cost_usd,menu_price_usd — one row per active menu item."
+  min_margin_pct:
+    default: 65
+    description: Minimum acceptable contribution margin percentage before an item is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Rebuild menu-item-costs.csv whenever a recipe or ingredient price changes — this compares per-item margin, not the restaurant-wide average that food-cost-percentage-watch checks.

package/jobs/restaurant/pos-end-of-day-reconciliation-check.yaml

@@ -0,0 +1,31 @@
+id: pos-end-of-day-reconciliation-check
+version: 1
+name: POS End-of-Day Reconciliation Check
+description: >
+  Compares the POS system's expected cash-drawer total against what was
+  actually counted at close and flags any shift over the acceptable
+  variance. Use this if a drawer has ever come up short (or suspiciously
+  over) and nobody traced it back to which shift it happened on.
+category: restaurant
+tags: [restaurant, pos, cash-handling, reconciliation]
+schedule: "0 6 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_tolerance_usd}}" '
+    NR==1 {next}
+    {
+      diff = $4 - $3;
+      absdiff = (diff < 0) ? -diff : diff;
+      if (absdiff > tolerance) printf "VARIANCE: %s shift %s — expected $%.2f, counted $%.2f (diff $%.2f)\n", $1, $2, $3, $4, diff;
+    }
+  ' "{{eod_close_csv}}"
+variables:
+  eod_close_csv:
+    default: "./eod-close-log.csv"
+    description: "CSV with header row, columns: close_date,shift_name,pos_expected_usd,counted_usd — one row per drawer close."
+  variance_tolerance_usd:
+    default: 10
+    description: Dollar variance (either direction) allowed before a shift close is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Export the close log from your POS's end-of-day/drawer-count report — this only compares totals, it doesn't investigate the cause of a variance.

package/jobs/restaurant/table-turnover-rate-tracker.yaml

@@ -0,0 +1,36 @@
+id: table-turnover-rate-tracker
+version: 1
+name: Table Turnover Rate Tracker
+description: >
+  Analyzes seating and table-clear timestamps to calculate average
+  table turnover time by section, day, and shift, and flags where
+  tables are sitting occupied well past the typical dining window. Use
+  this if you suspect one section or server is quietly slowing down
+  the whole dining room's throughput on busy nights.
+category: restaurant
+tags: [restaurant, front-of-house, tables, throughput]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull seated and table-cleared timestamps from {{pos_or_reservation_system}}
+  for the past {{lookback_days}} days.
+  1. Calculate average table turnover time (seated to cleared) overall,
+     then broken down by section, day of week, and shift (lunch/dinner).
+  2. Flag any section or shift where average turnover time is
+     meaningfully above the overall average, and estimate the covers
+     lost to the slowdown based on typical table demand at that time.
+  3. Note any pattern tied to a specific server or table size, if that
+     data is available, without naming individuals punitively — this is
+     for staffing/floor-plan decisions, not performance write-ups.
+  4. Recommend one concrete adjustment (seating flow, bussing staffing,
+     course pacing) for the slowest-flagged segment.
+variables:
+  pos_or_reservation_system:
+    default: "your POS or table-management system"
+    description: System that logs seat and clear timestamps (e.g. "Toast", "OpenTable", "SevenRooms").
+  lookback_days:
+    default: 14
+    description: Window of turnover data to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only analysis for floor-plan and staffing decisions — do not use this to single out individual servers without corroborating context.

package/jobs/restaurant/waitlist-conversion-check.yaml

@@ -0,0 +1,37 @@
+id: waitlist-conversion-check
+version: 1
+name: Waitlist-to-Seated Conversion Check
+description: >
+  Analyzes waitlist app data to see what share of people who joined the
+  waitlist actually got seated versus walked away, and whether quoted
+  wait times matched reality. Use this if you suspect an overly
+  optimistic quoted wait time is quietly driving guests to leave before
+  their table is ready.
+category: restaurant
+tags: [restaurant, front-of-house, waitlist, guest-experience]
+schedule: "0 11 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull waitlist entries from {{waitlist_app}} for the past
+  {{lookback_days}} days, including join time, quoted wait, actual seated
+  time (or abandoned/no-show status), and party size.
+  1. Calculate overall waitlist-to-seated conversion rate and the
+     abandonment rate (left before being seated).
+  2. Compare quoted wait time to actual wait time — flag any pattern
+     where actual wait consistently runs longer than quoted, which
+     likely drives abandonment.
+  3. Break down conversion rate by day of week, time slot, and party
+     size — flag the weakest-converting segments.
+  4. Recommend whether quoted wait times need adjusting for the
+     flagged segments, or whether a text-notification/callback flow
+     would reduce walk-aways.
+variables:
+  waitlist_app:
+    default: "your waitlist/reservation app"
+    description: Name of the waitlist system (e.g. "Yelp Waitlist", "NoWait", "Toast Tables").
+  lookback_days:
+    default: 30
+    description: Window of waitlist history to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only analysis — any change to quoted-wait logic or staffing is a floor-management decision for a human to make.

package/jobs/retail/cash-office-deposit-variance-check.yaml

@@ -0,0 +1,34 @@
+id: cash-office-deposit-variance-check
+version: 1
+name: Cash Office Deposit Variance Check
+description: >
+  Compares the bank deposit slip amount against the store's total
+  reported cash sales for the day and flags a mismatch. Use this if a
+  bank deposit has ever come up short of what the registers reported for
+  days before anyone in accounting reconciled it back to a specific
+  store.
+category: retail
+tags: [retail, cash, deposit, reconciliation]
+schedule: "0 10 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{tolerance_usd}}" '
+    NR==1 {next}
+    {
+      diff = $2 - $3;
+      abs_diff = (diff < 0) ? -diff : diff;
+      if (abs_diff > tolerance) {
+        printf "DEPOSIT VARIANCE: store %s — reported cash $%.2f, bank deposit $%.2f (diff $%.2f)\n", $1, $2, $3, diff;
+      }
+    }
+  ' "{{deposit_log_csv}}"
+variables:
+  deposit_log_csv:
+    default: "./cash-deposit-log.csv"
+    description: "CSV with header row, columns: store_id,pos_reported_cash_total,bank_deposit_amount — one row per store per deposit day."
+  tolerance_usd:
+    default: 10.00
+    description: Acceptable variance in dollars between reported cash and the actual bank deposit before flagging.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `pos-till-reconciliation-check` (per-register count at close) — this checks the far end of the process, the actual bank deposit against total reported store cash.

package/jobs/retail/competitor-price-monitoring-check.yaml

@@ -0,0 +1,42 @@
+id: competitor-price-monitoring-check
+version: 1
+name: Competitor Price Monitoring Check
+description: >
+  Reviews a nearby competitor's weekly ad/flyer or in-store price shots
+  against your own shelf prices for a shortlist of high-traffic items.
+  Use this if you've ever found out you were losing foot traffic to a
+  competitor's price on a staple item only because a customer mentioned
+  it at the register.
+category: retail
+tags: [retail, pricing, competitor, monitoring]
+schedule: "0 9 * * 5"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare the competitor's current weekly ad/flyer or in-store price
+  photos ({{competitor_source_path}}) against our own shelf prices
+  ({{our_price_list_csv}}) for the tracked item list.
+  1. For each tracked item, find the competitor's current price if it
+     appears in the source material.
+  2. Flag any item where the competitor's price is at least
+     ${{diff_threshold_usd}} cheaper than ours.
+  3. Note any item the competitor doesn't appear to be carrying anymore
+     versus one you simply couldn't find a price for.
+  4. Summarize as a short list ranked by dollar gap, for the store
+     manager to decide on a price-match or promo response this week.
+variables:
+  competitor_source_path:
+    default: "./competitor-flyers/"
+    description: Folder of this week's competitor flyer scans or in-store price photos.
+  our_price_list_csv:
+    default: "./tracked-items-price-list.csv"
+    description: "CSV with columns: sku,item_name,our_price — the shortlist of high-traffic items being watched."
+  diff_threshold_usd:
+    default: 1.00
+    description: Minimum price gap in dollars worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Physical-store competitor price checks off flyers/photos, distinct from
+  ecommerce's `competitor-price-watch`, which scrapes a competitor's live
+  product page URL per SKU — there's no comparable URL for a
+  brick-and-mortar competitor's shelf price. See duplicates-allowlist.js.

package/jobs/retail/damaged-merchandise-writeoff-tracker.yaml

@@ -0,0 +1,41 @@
+id: damaged-merchandise-writeoff-tracker
+version: 1
+name: Damaged Merchandise Write-Off Tracker
+description: >
+  Reviews logged damaged/defective merchandise write-offs for patterns
+  worth a closer look — a single SKU with a recurring damage reason, or
+  one store writing off well above the chain average. Use this if
+  write-offs have ever just gotten rubber-stamped monthly instead of
+  getting checked for a root cause (bad packaging, a rough receiving
+  process, or something less innocent).
+category: retail
+tags: [retail, damage, write-off, loss-prevention]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review this period's damaged merchandise write-off log
+  ({{writeoff_log_path}}) across stores.
+  1. Identify any SKU that recurs as a write-off reason more than
+     {{recurring_sku_threshold}} times — that points at a packaging or
+     handling issue worth escalating to the vendor or receiving process,
+     not just re-approving the write-off.
+  2. Flag any store whose total write-off dollar amount is more than
+     {{store_outlier_multiplier}}x the average store in the file.
+  3. Separate write-offs with a documented cause (damaged in transit,
+     customer damage, expired) from those marked "unknown" — a high rate
+     of "unknown" is itself worth flagging.
+  4. Summarize findings in a short list a loss-prevention or merchandising
+     manager could act on.
+variables:
+  writeoff_log_path:
+    default: "./damaged-merchandise-writeoffs.csv"
+    description: "CSV with columns: store_id,sku,writeoff_amount,reason — one row per write-off in the period."
+  recurring_sku_threshold:
+    default: 3
+    description: Number of times a SKU must recur as a write-off before flagging a possible systemic cause.
+  store_outlier_multiplier:
+    default: 2
+    description: How many times the average store's write-off total counts as an outlier worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Judging what counts as a meaningful pattern versus normal variance across stores and reasons needs an agent, not a fixed threshold script.

package/jobs/retail/employee-discount-abuse-check.yaml

@@ -0,0 +1,39 @@
+id: employee-discount-abuse-check
+version: 1
+name: Employee Discount Abuse Check
+description: >
+  Reviews employee discount usage for patterns that look like abuse —
+  unusually high dollar volume, discounts applied to gift cards, or
+  discounts rung up under an employee's number when they weren't
+  scheduled to work. Use this if employee-discount abuse has ever quietly
+  eaten margin for months because each transaction looked fine in
+  isolation.
+category: retail
+tags: [retail, employee-discount, fraud, loss-prevention]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review this period's employee discount transaction log
+  ({{discount_log_path}}) against the shift schedule
+  ({{schedule_csv_path}}).
+  1. Flag any employee whose total discounted purchase volume for the
+     period exceeds ${{monthly_volume_threshold_usd}}.
+  2. Flag any discount applied to a gift card purchase — most policies
+     disallow this.
+  3. Cross-reference discount timestamps against the schedule and flag
+     any discount rung up on a day the employee wasn't scheduled to work
+     (a common sign of a shared or misused employee number).
+  4. Summarize flagged employees with the specific reason for each flag.
+variables:
+  discount_log_path:
+    default: "./employee-discount-log.csv"
+    description: "CSV with columns: employee_id,transaction_date,amount,item_type,discount_pct."
+  schedule_csv_path:
+    default: "./employee-schedule.csv"
+    description: CSV of scheduled shifts to cross-reference against discount timestamps.
+  monthly_volume_threshold_usd:
+    default: 500
+    description: Total discounted purchase volume per employee in the period that triggers a flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: A flag is a prompt for HR/loss prevention review, not an accusation — cross-referencing two data sources and judging intent needs an agent, not a fixed script.

package/jobs/retail/layaway-special-order-pickup-tracker.yaml

@@ -0,0 +1,33 @@
+id: layaway-special-order-pickup-tracker
+version: 1
+name: Layaway & Special Order Pickup Tracker
+description: >
+  Flags layaway and special-order items that have been ready for pickup
+  past a set number of days. Use this if a paid-for special order has
+  ever sat in the back room for weeks because nobody was tracking pickup
+  age, only whether the item had arrived.
+category: retail
+tags: [retail, layaway, special-order, customer-service]
+schedule: "0 9 * * 2"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{overdue_days_threshold}} '
+    NR==1 {next}
+    $4 == "ready" {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline ready_ts; close(cmd);
+      days_waiting = int((today - ready_ts) / 86400);
+      if (days_waiting >= warn) printf "OVERDUE PICKUP: order %s for %s ready %d days (since %s)\n", $1, $2, days_waiting, $3;
+    }
+  ' "{{orders_csv}}"
+variables:
+  orders_csv:
+    default: "./layaway-special-orders.csv"
+    description: "CSV with header row, columns: order_id,customer_name,ready_date(YYYY-MM-DD),status(pending/ready/picked-up)."
+  overdue_days_threshold:
+    default: 14
+    description: Days an order can sit marked "ready" before it counts as overdue for pickup.
+compatible_agents: [generic, claude, codex]
+notes: A long-overdue pickup is worth a courtesy call before it becomes a restocking/refund headache or a customer dispute.

package/jobs/retail/loyalty-enrollment-redemption-rate-tracker.yaml

@@ -0,0 +1,37 @@
+id: loyalty-enrollment-redemption-rate-tracker
+version: 1
+name: Loyalty Enrollment & Redemption Rate Tracker
+description: >
+  Tracks new loyalty program enrollments and reward redemptions against
+  targets, not just whether individual points are about to expire. Use
+  this if enrollment has ever quietly stalled, or redemption has ever
+  dropped off a cliff, for months before anyone looked at the trend.
+category: retail
+tags: [retail, loyalty, customers, rewards, metrics]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v enroll_target="{{monthly_enrollment_target}}" -v redeem_floor="{{redemption_rate_floor_pct}}" '
+    NR==1 {next}
+    { enrolled += $2; redeemed += $3; eligible += $4 }
+    END {
+      redeem_pct = (eligible > 0) ? (redeemed / eligible) * 100 : 0;
+      printf "New enrollments this period: %d (target %d)\n", enrolled, enroll_target;
+      if (enrolled < enroll_target) printf "BELOW TARGET: enrollment %d short of target %d\n", enroll_target - enrolled, enroll_target;
+      printf "Redemption rate: %.1f%% (%d redeemed of %d eligible)\n", redeem_pct, redeemed, eligible;
+      if (redeem_pct < redeem_floor) printf "LOW REDEMPTION: %.1f%% is below the %.1f%% floor\n", redeem_pct, redeem_floor;
+    }
+  ' "{{loyalty_activity_csv}}"
+variables:
+  loyalty_activity_csv:
+    default: "./loyalty-activity.csv"
+    description: "CSV with header row, columns: store_id,new_enrollments,points_redeemed,points_eligible_for_redemption — one row per store or period."
+  monthly_enrollment_target:
+    default: 100
+    description: Target number of new loyalty enrollments for the period across the file.
+  redemption_rate_floor_pct:
+    default: 20
+    description: Minimum acceptable redemption rate (redeemed / eligible) before flagging.
+compatible_agents: [generic, claude, codex]
+notes: Complements `loyalty-points-expiry-reminder` (individual point expiry) by tracking program health as an aggregate trend — enrollment growth and redemption engagement, not per-customer expiry.

package/jobs/retail/markdown-execution-audit-check.yaml

@@ -0,0 +1,29 @@
+id: markdown-execution-audit-check
+version: 1
+name: Markdown Execution Audit Check
+description: >
+  Confirms that approved markdowns were actually applied at the register,
+  not just flagged as candidates. Use this if a markdown has ever been
+  approved on paper but never keyed into the POS, so the item kept
+  ringing at full price for weeks while it sat on the clearance rack.
+category: retail
+tags: [retail, markdown, pricing, audit]
+schedule: "0 8 * * 2"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      approved = $2; pos_current = $3;
+      if (approved != pos_current) {
+        printf "NOT APPLIED: SKU %s — approved markdown price $%s, POS still shows $%s\n", $1, approved, pos_current;
+      }
+    }
+  ' "{{markdown_approvals_csv}}"
+variables:
+  markdown_approvals_csv:
+    default: "./markdown-approvals.csv"
+    description: "CSV with header row, columns: sku,approved_markdown_price,pos_current_price — one row per approved markdown."
+compatible_agents: [generic, claude, codex]
+notes: Complements `markdown-aging-inventory-check` (flags candidates for markdown) by auditing the other end — whether an already-approved markdown was actually executed at the register.

package/jobs/retail/planogram-compliance-audit-check.yaml

@@ -0,0 +1,36 @@
+id: planogram-compliance-audit-check
+version: 1
+name: Planogram Compliance Audit Check
+description: >
+  Reviews a store's shelf/floor photos against the current planogram and
+  flags sections that are out of compliance. Use this if a reset has ever
+  quietly drifted out of plan for weeks — wrong facings, missing
+  end-caps, product in the wrong bay — before a district visit caught it.
+category: retail
+tags: [retail, planogram, merchandising, compliance]
+schedule: "0 8 * * 3"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare this week's shelf photos ({{shelf_photos_path}}) against the
+  current planogram document ({{planogram_doc_path}}) for store
+  {{store_id}}.
+  1. Go section by section and note any bay where product placement,
+     facing count, or signage doesn't match the planogram.
+  2. Flag missing or expired promotional signage separately from pure
+     placement drift.
+  3. Rank findings by sections that drive the most revenue first (per the
+     planogram's priority notes, if included).
+  4. Produce a short punch list a store associate could act on today.
+variables:
+  shelf_photos_path:
+    default: "./planogram-photos/"
+    description: Folder or path containing this cycle's shelf/section photos for the store.
+  planogram_doc_path:
+    default: "./current-planogram.pdf"
+    description: Path to the current approved planogram document or image set.
+  store_id:
+    default: "store-001"
+    description: Identifier for the store being audited.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Needs visual comparison and judgment about what counts as meaningful drift versus a shopper-caused mess — not a fit for a fixed script.

package/jobs/retail/pos-void-refund-anomaly-tracker.yaml

@@ -0,0 +1,42 @@
+id: pos-void-refund-anomaly-tracker
+version: 1
+name: POS Void & Refund Anomaly Tracker
+description: >
+  Flags cashiers or registers with an unusually high rate of transaction
+  voids and refunds instead of treating each one as an isolated event.
+  Use this if register-level fraud or sweethearting has ever gone
+  unnoticed for months because void/refund activity was never rolled up
+  per employee.
+category: retail
+tags: [retail, pos, fraud, loss-prevention]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v void_pct_max="{{void_rate_threshold_pct}}" '
+    NR==1 {next}
+    {
+      employee[$1] += 1;
+      total[$1] += 1;
+      if ($2 == "void" || $2 == "refund") flagged[$1] += 1;
+    }
+    END {
+      for (e in total) {
+        if (total[e] > 0) {
+          pct = (flagged[e] / total[e]) * 100;
+          if (pct >= void_pct_max) {
+            printf "HIGH VOID/REFUND RATE: %s — %.1f%% of %d transactions (%d void/refund)\n", e, pct, total[e], flagged[e];
+          }
+        }
+      }
+    }
+  ' "{{transactions_csv_path}}"
+variables:
+  transactions_csv_path:
+    default: "./pos-transactions.csv"
+    description: "Path to a CSV with columns: employee_id,transaction_type (sale/void/refund) — one row per transaction in the period."
+  void_rate_threshold_pct:
+    default: 8
+    description: Percentage of an employee's transactions that are voids/refunds before flagging for review.
+compatible_agents: [generic, claude, codex]
+notes: A flag is a prompt for a manager to review video/receipts, not proof of wrongdoing — some roles (returns desk) will legitimately run higher.