# Status — 2026-04-19 (wizard legacy-alignment refinement) — ARCHIVED

> **⚠️ ARCHIVED snapshot.** For current state, see [../../roadmap.md](../../roadmap.md).

> Follow-up to [2026-04-18b.md](2026-04-18b.md). Small session: reviewed the legacy
> wizard (`facturation.targo.ca/.../client_wizard`), realized the initial
> preset model fought the real workflow, refactored.

## What changed this session

### Wizard presets — now additive, not replacing
The first pass of RESIDENTIAL_PRESETS replaced the cart. That conflicts with
how the shop actually sells: a typical residential deal is **Installation
Internet + Installation Téléphonie + Installation Télé + Ajout WiFi** — four
presses that stack.

Legacy audit (`docs/legacy-wizard/account_wizard.php`) confirmed the model:
the PHP wizard has no "presets" at all — it has 4 independent sections with
checkboxes. Adding Internet adds lines; adding Phone adds more lines; the
combo rebate (legacy RAB2X/RAB3X/RAB4X, IDs 556/557/558) is computed
automatically from the count of distinct combo-eligible service types.

**Our presets are now building blocks:**
- `preset_internet_install` — service_type `internet`, combo_eligible
- `preset_phone_install` — service_type `phone`, combo_eligible
- `preset_tv_install` — service_type `tv`, combo_eligible
- `preset_wifi_addon` — service_type `addon`, NOT combo_eligible (ajout seul)

Each press **appends** its items. Item codes are deduped so double-clicking
a preset is idempotent (no accidental doubles).

### Auto combo rebate
`recomputeComboRebate()` in [apps/ops/src/composables/useWizardCatalog.js](apps/ops/src/composables/useWizardCatalog.js):
- Counts distinct `service_type`s across recurring + combo_eligible items.
- 2 services → Rabais combo 2 services (-5$/mois)
- 3 services → Rabais combo 3 services (-10$/mois)
- 4+ services → Rabais combo 4 services (-15$/mois)
- Under 2 → removes the rebate line automatically.

Tune amounts in `apps/ops/src/data/wizard-constants.js → COMBO_REBATES`.

Driven by `watch(orderItems, recomputeComboRebate, { deep: true })`. The
function is **idempotent** — compares `rate`, `item_name`, `contract_months`
against the existing rebate line before mutating, so the deep watch can't
spiral into an infinite loop.

### Ad-hoc items still work
Per the "one simple way + ad-hoc onetime" directive: presets get the
common composition in one click, but the catalog picker + "+ Ajouter un
item" row are unchanged, so an agent can still add a router, an install
fee, or any catalog item on top.

## Files touched this session
```
apps/ops/src/data/wizard-constants.js                 presets reshaped + COMBO_REBATES
apps/ops/src/composables/useWizardCatalog.js          applyPreset additive + recomputeComboRebate
docs/legacy-wizard/                                   legacy PHP wizard copy for reference
docs/STATUS_2026-04-19.md                             this file
memory/project_contract_acceptance.md                 Wizard integration section
```

## Deployed
Ops app rebuilt and deployed 2026-04-19 ~08:25 EDT.
Live bundle: `index.9ca1cb6e.js`. Hard-reload to pick up.

## Verification checklist (please run when you're back)
1. Open a customer → Soumissions → "+ Nouvelle soumission".
2. Press **Installation Internet** → 1 line Internet 500 + 1 line frais (0$, regular 75$).
3. Press **Installation Téléphonie** → appends tel line. **Rabais combo 2 services (-5$/mois)** should appear automatically.
4. Press **Installation Télé** → appends IPTV line. Rebate upgrades to **3 services (-10$/mois)**.
5. Press **Ajout WiFi** → router line appended but rebate stays at 3 services (WiFi is not combo_eligible).
6. Remove Télé → rebate downgrades to 2 services (-5$).
7. Publish with JWT acceptance → Quotation created + Service Contract created + SMS sent.

If the rebate gets "stuck" or duplicates appear, screenshot the cart and
send — the idempotency check may need tightening.

## Known follow-ups (deliberately deferred)
- Rebate amounts are hard-coded in `COMBO_REBATES`. Should eventually read
  from legacy item IDs 556/557/558 (or their ERPNext equivalents once migrated).
- `combo_eligible` is currently a preset-level flag. If ad-hoc catalog items
  should participate in combo counting, the catalog model needs a
  `combo_ready` column (legacy has one).
- Commercial flow still piggybacks on acceptance-method toggle. A proper
  `contract_type` toggle in the wizard would decouple the two.