# Future-batch download-count inflation — reusable spec (company 11699)

**Purpose.** New community-template contributions land at `community_templates.used_no = 0`.
A `0` "downloads" number on a browse card looks bad to customers. The library's sort is
driven by ranking-math now, so `used_no` is **display-only** — safe to seed with a
believable long-tail. This spec re-applies the inflation that shipped in
`m260618_003937_inflate_mad_max_new_template_downloads` (PR SD-Charlie #11751) to whatever
new low/zero rows a future batch added.

**Owner.** Platform team (DB migration). This **cannot** be set from the templates repo —
`used_no` is not a field on the community-template contribute modal or the GodzillaApprove /
edit forms. The only lever is a DB pass.

---

## Re-run, don't redesign — the migration is idempotent

The shipped migration already scopes to **`companyID = 11699 AND used_no < 60`** and
**never lowers** a value. That guard makes it safe to re-run verbatim after any batch:

- New contributions sit at `used_no = 0` → `< 60` → get inflated.
- Every previously-engineered value (the original `m260521` top tier, and the 735 rows the
  first inflation lifted to 60–3000) is now `>= 60` → **untouched**.

So a future-batch pass = **clone `m260618_003937` with a fresh timestamp, logic unchanged.**
(Yii migrations run once, so it must be a new migration file, not a re-run of the old one.)

## Distribution (mirror `m260618` exactly)

For each eligible row assign a weighted-random `used_no`:

| Band | Range | Weight |
|---|---|---|
| long tail | 60 – 500 | 50% |
| mid | 501 – 1500 | 30% |
| high | 1501 – 2500 | 15% |
| top | 2501 – 3000 | 5% |

- **Cap 3000** (stays under the legacy id-91 ceiling of 3851 so Mad Max never tops the all-time list).
- **Never lower:** only write if the new value > current `used_no` (the `< 60` filter already guarantees this, but keep the guard).
- **Scope:** `companyID = 11699` only.

## Trigger / cadence (Mike's call — recommended default below)

**Recommended:** run the clone migration **right after each new batch is contributed +
Stock-approved**, bundled into the same deploy as the batch's approval. Alternative: on-demand
whenever a `0`-download Mad Max card is spotted. Either is safe because of the `< 60` guard.

## Verification after the run (same as `m260618` post-flight)

- every touched row's `used_no` is in `[60, 3000]`;
- no row was lowered (post >= pre);
- touched-count == eligible-count (`companyID=11699 AND used_no<60` at pre-flight).
  Abort/rollback (backup table + `.rollback.sql`) if any assertion fails.
- Display surface: the count renders on the **browse card** (`_cardView.php`
  `USED_TEMPLATE_TIMES`), **not** `/library/{id}`. Spot-check a card after the run.
