opencode-knowledge-work 0.0.0-stage → 0.1.1

package/content/small-business/skills/small-business-inventory-planner/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: inventory-planner
+description: >
+  Works out what to reorder and when, from what is actually selling: pulls
+  sales history and stock on hand from Shopify, Square, NetSuite, or an
+  uploaded CSV, computes 7-day and 28-day sales velocity per item, projects a
+  conservative stockout date for each, sizes a 60-day reorder quantity, and
+  drafts the purchase orders and vendor emails to cover it. Flags the money
+  sitting still too — overstock, dead stock, and zero-velocity items, reported
+  as slow movers to clear rather than things to buy more of. Seasonality is
+  applied where the history supports it and named where it does not. Nothing
+  is ordered and no vendor is emailed without approval. Reach for this
+  whenever stock comes up — "what do I need to reorder," "am I going to run
+  out," "what should I order this month," "we keep running out of filters,"
+  "how much cash is sitting in the warehouse," "what is not moving," or "draft
+  a PO for my supplier."
+allowed-tools: Read, WebFetch
+---
+
+# Inventory Planner
+
+Buy what sells, before it runs out, and stop buying what doesn't.
+
+Stock is cash the owner already spent. Two things go wrong: running out of the item customers came for, and sitting on a pallet of something nobody wants. Both are visible in the sales history well before they become a problem, which is what this skill reads for.
+
+## Step 1 — Get sales and stock
+
+**Preferred:** Shopify for sales and inventory levels. Square and NetSuite work the same way.
+
+**Fallback, fully supported:** a CSV of sales history plus a stock-on-hand count. Two files, or one with both. This path works with zero connectors and gives the same output. Many businesses count on a clipboard, and that is a legitimate input.
+
+You need, per item: SKU, name, units sold by date, current stock on hand, unit cost, unit price, vendor, and lead time if known. Missing lead time is asked for once and remembered — see `reference/data_sources.md`.
+
+**Say what the count is as of.** A stock figure two weeks old produces a stockout date two weeks wrong.
+
+## Step 2 — Compute velocity, both windows
+
+For every item, compute:
+
+- **7-day velocity** — units per day over the last week. Catches what is happening now.
+- **28-day velocity** — units per day over four weeks. The stable baseline.
+
+Both matter, and disagreement between them is information. An item selling three times its 28-day rate this week is either trending or had one bulk order, and those need different responses. `reference/velocity_and_reorder.md` covers how to tell them apart.
+
+Exclude one-off distortions from the baseline where you can identify them: a single wholesale order, a returned batch, a stockout period where the item could not sell. **A period of zero sales because there was no stock is not zero demand**, and treating it as such is how an item gets under-ordered forever.
+
+## Step 3 — Project stockout dates, conservatively
+
+Stockout date is stock on hand divided by the daily velocity you trust least — the higher of the two windows. Being early is cheap; being late loses the sale.
+
+Then compare against lead time. The number that matters is not when it runs out, it is whether there is still time to order:
+
+- **Past the point of no return** — lead time exceeds days of cover. Already going to stock out. Say so plainly.
+- **Order now** — cover is within lead time plus a safety buffer.
+- **Order soon** — comfortable, but on the next cycle.
+- **Fine** — no action.
+
+**Never state a stockout date for an item with no reliable velocity.** New items with two weeks of history and items whose sales were interrupted get flagged as "not enough history," by name.
+
+## Step 4 — Size the reorder
+
+Default target is **60 days of cover plus the lead time**, sized on the **28-day rate** — not on the faster of the two. The stock has to last from the day it lands until the next order lands, so leaving the lead time out runs the item short by exactly that many days every cycle. Then adjust for pack size, minimum order quantity, and what is already on order.
+
+The two rates do different jobs and both get named on the line: the higher one says when it runs out, the 28-day one says how much to buy. Sizing a 60-day order off a one-week spike is how cash ends up in a pallet.
+
+Never size a reorder without subtracting inbound stock. Double-ordering a slow item is how a business ends up with three years of it.
+
+Round to the vendor's pack size and say which direction you rounded. Show the dollar cost of every recommendation — the owner is deciding about cash, not units.
+
+## Step 5 — Handle the items that are not moving
+
+Zero-velocity and very slow items are a separate list with a separate purpose. **They are never reorder candidates.**
+
+- **Zero velocity** — no units in 28 days. Report as a slow mover with the cash tied up in it. **Never compute days of cover for these** — nothing is selling, so nothing is running out, and the number is either an error or nonsense. The one exception is an item inside a season the owner has named, which goes on a dated watch list instead of the clear-out list.
+- **Overstock** — more than 120 days of cover. Report the excess units and the dollars.
+- **Dead stock** — no movement in 90 days. Suggest clearing, bundling, or discounting.
+
+Total the cash sitting in these. That figure is usually the most surprising number in the whole report and often the most useful one.
+
+## Step 6 — Apply seasonality only where history supports it
+
+With at least a year of history, compare the coming period against the same period last year and adjust.
+
+**With less than a year, say so and do not adjust.** A seasonal multiplier invented from nine months of data is a guess wearing a suit. Ask the owner instead — they know their season better than a short history does. `reference/seasonality.md` covers both paths.
+
+## Step 7 — Present the buy list
+
+Lead with the total dollar amount and the count of items about to stock out. Then: order now, order soon, slow movers, and anything with too little history to judge.
+
+Every line carries the numbers behind it — velocity, days of cover, lead time, quantity, cost. An owner who can see the reasoning approves in a minute; one who cannot rebuilds the whole thing by hand.
+
+Render the buy list as an HTML artifact using the house artifact style (`../../shared/artifact-style.md`): a stockout table sorted by stockout date with mono tabular-nums numerals, urgency status pills (order now / order soon / fine / past the point of no return), a reorder panel with quantities and dollar totals, and a slow-movers section with the cash tied up in it. The chat summary stays — the artifact is the full picture, not the only one.
+
+## Step 8 — Draft POs and vendor emails, with approval
+
+Purchase orders commit money and vendor emails go out under the owner's name, so both wait for an explicit yes.
+
+State the vendor, the line items, and the total before asking. Draft the vendor email in the owner's voice per [the shared voice profile](../../shared/voice-profile.md). **If no profile exists yet, follow that file's "When there is no sample" instruction** — ask for three emails they have already sent a supplier. If they would rather not, write the email plain and neutral and say it is not in their voice. Never invent a personality for someone's vendor relationship.
+
+With Google Calendar connected, offer a recurring block for the restock decision — this works far better as a rhythm than as a fire drill. Keep the approved PO document here — this skill owns it. With QuickBooks or NetSuite connected, hand `ap-processor` the coded memo for each one (vendor, PO number, total, expected date, and the account, class, and job), so the bill three-way-matches against a real record when it arrives. `ap-processor` reads POs; it does not create them.
+
+## Closing offer
+
+Close with one line on what was decided — the total buy and the items about to run out. Then offer the most relevant next step with its exact trigger phrase: "reorder" (`/restock`) when the owner wants the POs drafted and sent end to end. Up to two more from the router's table, such as "cash forecast" (`cash-flow-snapshot`) or "pay the bills" (`/pay-the-bills`). Three offers at most, and never repeat one the owner already declined this session.
+
+## What not to do
+
+- **Do not invent a velocity, a lead time, or a stockout date.** Too little history is reported by SKU, not smoothed over.
+- **Do not treat an out-of-stock period as zero demand.** It is suppressed demand and it biases everything downstream.
+- **Do not recommend reordering a zero-velocity item.** No sales means stop buying, not buy more.
+- **Do not size a reorder without subtracting what is already inbound.**
+- **Do not apply seasonality without a year of history.** Ask the owner instead.
+- **Do not send a PO or a vendor email without approval.** Both spend money or spend goodwill.
+- **Do not report units without dollars.** The owner thinks in cash.
+
+## Reference files
+
+- `reference/data_sources.md` — Shopify, Square, NetSuite, and the CSV path, with required fields
+- `reference/velocity_and_reorder.md` — the 7/28-day math, distortion handling, and reorder sizing
+- `reference/seasonality.md` — when to adjust, when to ask, and how to say which you did
+- `reference/po_drafting.md` — purchase order structure and vendor email drafting
+- `reference/gotchas.md` — the mistakes that stock out a bestseller or bury cash in a pallet
+
+## Using a tool that isn't listed
+
+The connectors named in this skill are the tested paths, not a wall. If the owner wants this flow to use a tool that isn't connected or listed, offer `build-connector` — it checks the connector directory first and connects through Zapier otherwise, never hand-building against a raw API. Once the connection exists, the tool joins this skill like any other optional connector, under the same approval gates.

package/content/small-business/skills/small-business-inventory-planner/reference/data_sources.md

@@ -0,0 +1,94 @@
+# Data Sources
+
+Where sales and stock come from, and what has to be in the data before any of the math is trustworthy.
+
+---
+
+## Required fields
+
+Everything downstream depends on these. Anything missing gets asked for once and remembered.
+
+| Field | Needed for | If missing |
+|---|---|---|
+| SKU or item ID | Everything | Cannot proceed for that item |
+| Item name | The report being readable | Use the SKU and say the name is missing |
+| Units sold, by date | Velocity | No velocity, no stockout date. Flag the item |
+| Stock on hand | Days of cover | Flag; velocity alone cannot tell you when it runs out |
+| As-of date for the count | Accuracy of everything | Ask. A stale count is the most common silent error here |
+| Unit cost | Dollar figures on the buy list | Report units only for that item and say why |
+| Unit price | Overstock cash and margin context | Optional, useful |
+| Vendor | PO drafting | Group as "vendor unknown" and ask |
+| Lead time | Whether there is still time to order | Ask once per vendor and remember |
+| Units on order | Not double-ordering | Ask. This one is worth chasing — it causes real over-buying |
+| Pack size / MOQ | Realistic quantities | Round to whole units and note it was not applied |
+
+---
+
+## Shopify
+
+The preferred source. Pull:
+
+- Orders with line items over the lookback window, at least 90 days, 400 days if seasonality is in scope
+- Inventory levels per variant per location (`get-inventory-levels` takes one `productId` per call; loop the products the run needs — `../../../shared/connector-call-shapes.md`)
+- Product and variant records for cost, price, and vendor
+
+Watch for:
+
+- **Multi-location inventory.** Total across locations only if the owner sells from one pool. Otherwise stockouts are per location and a total hides them.
+- **Variants.** Velocity belongs at the variant level. A shirt that sells fine in medium and never in XL looks healthy at the product level.
+- **Cancelled and refunded orders.** Exclude them from units sold.
+- **Bundles and kits.** A bundle sale consumes component stock. If the store uses bundles, ask how components are tracked before trusting the numbers.
+
+## Square
+
+Same shape, different names. Sales come from transactions, stock from the item catalog inventory counts. Square inventory tracking is often partially enabled — check which items actually have counts before treating a zero as a zero.
+
+## NetSuite
+
+The ERP path for the top end. Item records carry cost, preferred vendor, lead time, and reorder points already set by someone. **Use the existing reorder points as context, not as truth** — they are frequently years stale, and pointing out where the computed number diverges from the stored one is genuinely useful.
+
+---
+
+## The CSV path
+
+A fully supported first-class mode. Two files or one.
+
+**Sales history file**, one row per sale or per item-day:
+
+```
+sku, date, units_sold
+```
+
+**Stock file:**
+
+```
+sku, name, on_hand, unit_cost, vendor, lead_time_days, on_order
+```
+
+Accept whatever column names came out of their system and map them. Report the mapping back so the owner can catch a wrong guess before it becomes a purchase order.
+
+**Ask for the as-of date of the stock count.** It is almost never in the file, and it is the difference between a stockout date that is right and one that is two weeks late.
+
+---
+
+## Data quality checks before any math
+
+Run these and report what they find:
+
+1. **Negative stock.** Real in most systems, and it means the count is wrong. Flag it.
+2. **Items with sales and no stock record**, or stock and no sales record.
+3. **Duplicate SKUs** with different names.
+4. **A history window shorter than 28 days** — say so; the 28-day velocity will not be reliable.
+5. **Zero-sales stretches** that coincide with zero stock. These are stockouts, not demand. See `velocity_and_reorder.md`.
+
+---
+
+## Worked example
+
+Okonkwo Mechanical stocks common parts on the trucks and in the shop. No Shopify — Ray exported two CSVs from his supply-house portal and counted the shop shelf on a Saturday.
+
+- 84 SKUs, 120 days of usage history
+- Stock count as of 3/15, confirmed with Ray
+- Lead times missing for all of them; Ray gave two by vendor: Ferguson 3 days, Watsco 10 days
+- 6 SKUs had usage but no stock line — parts pulled straight to jobs, never shelved. Excluded and reported
+- 2 negative counts flagged, both compressors, both recounted

package/content/small-business/skills/small-business-inventory-planner/reference/gotchas.md

@@ -0,0 +1,153 @@
+# Gotchas
+
+The mistakes that stock out a bestseller or bury cash in a pallet. Inventory errors are slow and expensive — they show up as a missed sale or a shelf nobody touches for two years.
+
+---
+
+## Gotcha: counting a stockout as zero demand
+
+**Why it matters:** This is the most damaging error in the whole skill, and it is self-reinforcing. The item ran out because it sells. The zero-sales days drag the velocity down. The next order is smaller. It runs out sooner. Repeat.
+
+### Bad
+
+```
+Merv 11 filter: 12 units sold in 28 days = 0.43/day. Slow mover, no reorder.
+```
+(the shelf was empty for 20 of those 28 days)
+
+### Good
+
+```
+Merv 11 filter: 12 units in the 8 days it was actually in stock = 1.5/day.
+Out of stock 20 of the last 28 days — that is suppressed demand, not slow sales.
+Planning on 1.5/day.
+```
+
+---
+
+## Gotcha: ordering into a one-week spike
+
+**Why it matters:** A single bulk order makes an ordinary item look like a runaway for exactly seven days. Sixty days of cover sized off that number is a pallet the owner paid for and will look at for a year.
+
+### Bad
+
+7-day velocity 5.8/day vs 28-day 0.4/day. Size 60 days at 5.8/day.
+
+### Good
+
+```
+7-day rate is 14x the 28-day rate. Looking at the orders: one sale of 40 units
+on the 9th. That is a job, not a trend. Sizing on the 28-day rate and noting
+it in case that customer comes back.
+```
+
+---
+
+## Gotcha: recommending a reorder for a zero-velocity item
+
+**Why it matters:** Zero sales in 28 days means stop buying. A reorder point set years ago in the ERP will happily say otherwise, and following it converts working capital into shelf decoration.
+
+### Bad
+
+NetSuite reorder point says 24, on hand is 6, so order 18.
+
+### Good
+
+```
+Zero units sold in 28 days. The stored reorder point says 24 — that is stale.
+Not a reorder. Six units, USD 340 tied up. Worth clearing.
+```
+
+---
+
+## Gotcha: forgetting what is already on order
+
+**Why it matters:** Two orders for the same item three weeks apart is the classic double-buy, and it usually happens right after a stockout scare when the owner is paying attention.
+
+### Bad
+
+On hand 38, target 258, order 240.
+
+### Good
+
+```
+On hand 38, 160 already inbound from the 3/2 order, target 258 total.
+That leaves 60 — 2 cases of 40, so 80 units. If that inbound number is
+wrong tell me, it changes this.
+```
+
+---
+
+## Gotcha: a stock count with no as-of date
+
+**Why it matters:** Everything downstream is stock divided by velocity. A two-week-old count on a fast mover produces a stockout date that has already passed.
+
+### Bad
+
+Take the uploaded count at face value and project from today.
+
+### Good
+
+Ask when it was counted. If the count is from the 1st and today is the 15th, either net out two weeks of sales or ask for a fresh count on the fast movers, and say which you did.
+
+---
+
+## Gotcha: seasonality invented from partial history
+
+**Why it matters:** A multiplier computed from nine months looks exactly like one computed from three years. It gets used to buy real stock, and nobody can tell later which kind it was.
+
+### Bad
+
+```
+June factor: 1.6x (computed)
+```
+(from 120 days of data that do not include a June)
+
+### Good
+
+```
+120 days of history — no June in there, so I cannot compute a season.
+You know this better than the data does. Roughly how much heavier is June?
+```
+
+---
+
+## Gotcha: velocity at the product level instead of the variant
+
+**Why it matters:** A product that sells well in one size and never in another looks healthy in aggregate. The good size stocks out while the bad size accumulates, and the product-level number shows neither.
+
+### Bad
+
+Filter, 20x25: 4.1/day, 38 on hand, healthy.
+
+### Good
+
+Split by variant. The 1-inch is running out in four days; the 4-inch has nine months of cover. Two different problems, one product line.
+
+---
+
+## Gotcha: reporting units without dollars
+
+**Why it matters:** Owners decide about cash. "Order 240 filters" is not a decision they can make; "USD 888" is.
+
+### Bad
+
+A buy list of quantities with no cost column.
+
+### Good
+
+Every line costed, every vendor subtotaled, and the total stated before the approval question.
+
+---
+
+## Gotcha: quietly accepting a vendor substitution
+
+**Why it matters:** A different part number goes onto a customer's equipment. That is the owner's call and sometimes a warranty question, never a shipping detail.
+
+### Bad
+
+Vendor swaps a compatible capacitor, order updated, nothing said.
+
+### Good
+
+Report the substitution, the part numbers both ways, and the effect on cover if the owner rejects it. Then let them decide.

package/content/small-business/skills/small-business-inventory-planner/reference/po_drafting.md

@@ -0,0 +1,92 @@
+# PO Drafting and Vendor Emails
+
+Turning an approved buy list into documents, and the gate in front of both.
+
+---
+
+## The gate
+
+A purchase order commits the owner's money and a vendor email goes out under their name. Neither happens without an explicit yes.
+
+State before asking:
+
+> Ferguson: 8 items, 640 units, USD 4,180. Watsco: 3 items, USD 2,290.
+> Total USD 6,470 across two POs. Draft them?
+
+**The dollar total goes before the question.** The owner is deciding about cash, and units alone do not tell them what they need to know.
+
+Approve per vendor, not per buy list. An owner may want the Ferguson order today and the Watsco one next week, and forcing an all-or-nothing yes gets a no.
+
+---
+
+## Purchase order structure
+
+One PO per vendor. Standard contents:
+
+- PO number, following the owner's existing numbering if they have one — ask rather than starting a new series
+- Date, and the requested delivery date based on lead time
+- Ship-to and bill-to
+- Line items: SKU, description, quantity, pack or unit of measure, unit price, extended price
+- Subtotal, expected freight, total
+- The owner's terms, payment method, and contact
+
+**Use the last known price per item and say when it is from.** A price from four months ago is fine to work with; a price presented as current when it is not sets up a variance argument later. When there is no known price, leave it blank rather than guessing — the vendor will price it.
+
+---
+
+## Vendor email
+
+Read the shared voice profile at `../../../shared/voice-profile.md` before writing. These go out under the owner's name to people they have real relationships with, and a message that sounds like software damages that.
+
+Keep it short. The useful content is:
+
+- What is being ordered, or a reference to the attached PO
+- When they need it by, and why if the timing is tight
+- Any question — availability, a substitution, a price check
+- How the owner wants confirmation
+
+What to avoid: apologizing for ordering, over-explaining, and any pleasantry the owner would not actually write.
+
+**A price question is worth including when the last known price is stale.** Asking "is this still USD 14.80 a case?" costs one line and prevents the variance that `ap-processor` would otherwise flag when the bill arrives.
+
+---
+
+## Substitutions and backorders
+
+When a vendor comes back with a substitution or a partial:
+
+- Recompute days of cover on what is actually coming, not what was ordered
+- Report the gap and whether it changes the stockout date
+- Never accept a substitution on the owner's behalf. A different part number is a decision about what goes on a customer's job
+
+---
+
+## Handoff to AP
+
+When QuickBooks or NetSuite is connected, approved POs go into the ledger so `ap-processor` can run the three-way match when the bill arrives. That closes the loop: what was ordered, what showed up, what was billed.
+
+When they are not connected, keep the POs as files and tell the owner they are the matching record. A PO nobody can find later is a PO that cannot catch an overbilling.
+
+---
+
+## Calendar rhythm
+
+With Google Calendar connected, offer a recurring block for the restock review — weekly or biweekly, depending on lead times.
+
+This works far better as a rhythm than as an emergency. An owner who looks at the buy list every Tuesday for twenty minutes rarely stocks out. One who looks when a customer asks for something already has the problem.
+
+Offer once. If they decline, do not ask again.
+
+---
+
+## Worked example
+
+Ray's June order, after approval.
+
+**PO 2041 — Ferguson Supply**, requested 6/12
+- 240 ea, Merv 11 filter 20x25x1, USD 3.70 ea, USD 888.00
+- 24 ea, 45/5 capacitor, USD 11.40 ea, USD 273.60
+- 6 ea, contactor 2-pole 30A, USD 18.90 ea, USD 113.40
+- Subtotal USD 1,275.00, freight per usual terms
+
+Email drafted to Ray's rep, three sentences, asking whether the filter price still holds and confirming the Thursday delivery. Held for Ray's approval before sending.

package/content/small-business/skills/small-business-inventory-planner/reference/seasonality.md

@@ -0,0 +1,112 @@
+# Seasonality
+
+When to adjust for the season, when to ask instead, and how to say which you did.
+
+---
+
+## The threshold
+
+**Adjust only with at least 400 days of history.** That gives a full year plus enough overlap to compare the same weeks year over year.
+
+With less than that, do not compute a multiplier. Ask the owner.
+
+The reason is simple: a seasonal factor derived from nine months of data is arithmetic performed on an assumption. It comes out looking like a real number — "1.6x for June" — and it will be used to buy real stock. The owner already knows their season better than that number does, and asking takes one line.
+
+---
+
+## With a year or more
+
+Compare the upcoming planning window against the same calendar window last year, per item or per category.
+
+```
+seasonal_factor = units_sold(same window, last year) ÷ units_sold(trailing 28d, last year)
+```
+
+Apply the factor to the sizing velocity (the 28-day rate), and to the stockout velocity when projecting into the season. Cap it — anything above 3x or below 0.3x gets shown to the owner rather than applied silently, because factors that extreme usually mean a promotion, a stockout, or a one-time event in last year's data rather than a real season.
+
+Prefer **category-level factors** for items with thin individual history. A single SKU's year-ago numbers are noisy; the category's are not.
+
+**Check for a stockout in last year's comparison window.** If the item was out of stock last June, last June's units understate demand, and the factor built from them will under-order this June. Say so instead of applying it.
+
+---
+
+## Without a year
+
+Say what you have and ask one question:
+
+> I have 120 days of history, so I cannot see your season in the data. You are heading into summer — do filters and capacitors move differently for you then? Give me a rough multiple and I will size the order to it. Otherwise I will plan on the current rate and we adjust as it moves.
+
+Then use whatever they say and **label the buy list with where the number came from**:
+
+> Sized at 1.8x current velocity per your estimate, not from history.
+
+That label is what lets the owner recalibrate next quarter. An unlabeled adjusted number is indistinguishable from a computed one six weeks later.
+
+---
+
+## When the owner names an end to the season
+
+A season has two dates and the second one does the damage. Sizing 60 days of stock at the busy rate, six weeks before the busy period ends, buys a month of stock for a month that will not happen — and it stays on the shelf until next year at the old cost.
+
+**When the owner names an end date, cap the order at the days left in the season.** Do not cap silently:
+
+```
+days_left       = season_end_date − expected_arrival_date
+target_uncapped = (60 + lead_time_days) × sizing_velocity
+target_capped   = days_left × sizing_velocity
+```
+
+Show both numbers and say which one is being ordered:
+
+> Ray says the AC season winds down at the end of August — 47 days after this
+> order lands, not 60. At 7.0/day with 20 on hand, that's 309 units, so 8 cases:
+> USD 1,184. The uncapped number would have been 11 cases at USD 1,628 — the extra
+> three cases would sit until next May.
+
+The owner overrides this whenever they want to. Some items are worth carrying over — a filter keeps fine and the price only goes up. Others do not, and a slow tail into the off-season is exactly where the cash gets stuck. **Their call, made with both numbers in front of them.**
+
+Carrying a few days of tail past the end date is fine when the owner asks for it — say the sentence, do not add it silently.
+
+Where the season ends before the stock could even land, do not order at all. Say so plainly and put the item on the watch list for next season with the decide-by date already on it.
+
+---
+
+## Known-event adjustments
+
+Seasonality is not only the calendar. Ask about, and record:
+
+- A big job, contract, or event coming up that will draw down stock
+- A promotion or sale planned
+- A vendor price increase announced, which sometimes justifies buying early
+- A vendor shutdown — many suppliers close for a stretch and lead times double around it
+
+These are one-time adjustments, applied to specific items, and always labeled as owner-supplied rather than computed.
+
+---
+
+## Reporting the adjustment
+
+Every seasonally adjusted line shows both numbers:
+
+```
+Compressor, 3-ton                SKU CMP-3T
+  Current velocity   0.4/day (28d)
+  Seasonal           1.9x — June ran 1.9x the spring rate last year
+  Sizing at          0.76/day
+  On hand            11 units, 14 days of cover at the seasonal rate
+  Status             ORDER NOW
+```
+
+Showing the unadjusted rate next to the adjusted one is what makes the adjustment reviewable. An owner who thinks 1.9x is too hot can say so before the PO goes out.
+
+---
+
+## Worked example
+
+Ray's shop, planning into June.
+
+- 120 days of history only. No computed factors.
+- Asked Ray directly. His answer: "Filters and capacitors go crazy the first hot week. Compressors maybe double. Everything else is the same."
+- Applied 2.0x to filters, capacitors, and compressors on Ray's estimate. Everything else planned at the current 28-day rate.
+- Buy list labeled: three categories sized on Ray's seasonal estimate, the rest on trailing velocity.
+- Noted for next year: with a full year of history by next spring, these factors can be computed and checked against what he guessed.