Odoo-Modules/docs/superpowers/EXECUTE-technician-service-booking.md

KICKOFF BRIEF — Implement "Technician Service Booking & Auto-Quote" (hands-off)

You are a fresh Claude Code session. Implement this feature end-to-end, autonomously, from the plans below. The design is already locked through brainstorming — do NOT re-design or re-brainstorm. Build it.

---

1. Mission

Replace the raw fusion.technician.task booking modal with a polished OWL "Book a Service" wizard that: captures the client (incl. brand-new clients inline), books the technician task, prices the call-out from an editable rate table, and auto-creates a draft repair Sale Order — with correct, consistent timezone handling. Works in dark + light.

2. Read these first, in order

1. K:\Github\Odoo-Modules\CLAUDE.md (repo Odoo-19 rules) + the global K:\Github\CLAUDE.md.
2. Spec: docs/superpowers/specs/2026-06-03-technician-service-booking-design.md
3. Plan 1 (do first): docs/superpowers/plans/2026-06-03-service-rates-foundation-plan.md
4. Plan 2 (do second): docs/superpowers/plans/2026-06-03-service-booking-wizard-plan.md
5. UI source of truth (port its markup/CSS): docs/superpowers/mockups/technician-booking-wizard.html

The plans are bite-sized (TDD, exact files, full code). They are the authority — follow them task-by-task. The spec/mockup are context.

3. Method

• Use the superpowers:subagent-driven-development skill (the plan headers require it). One task at a time; write test → implement → verify → commit per task with the messages in the plan.
• Order: Plan 1 fully, then Plan 2 (Plan 2 consumes Plan 1's fusion.service.rate).
• Before writing any model/view/OWL code, obey repo rule #1: read the real reference from Docker first (docker exec odoo-modsdev-app cat … or, for the Enterprise classes, read the on-disk source) — never code Odoo APIs from memory. The plans flag the specific signatures to confirm (_get_local_tz, _compute_datetimes, _calculate_travel_time, real task field names like in_store/client_name/address_lat, the crm.tag vs sale.order tag model).

4. Branch

git -C K:\Github\Odoo-Modules checkout main
git -C K:\Github\Odoo-Modules checkout -b claude/technician-service-booking

Create it off main — NOT off claude/fusion-schedule-audit-fixes (that branch has unrelated calendar-sync fixes). The spec/plans/mockup are already on disk under docs/superpowers/; keep them.

5. Hard constraints (do not violate)

• Odoo 19 idioms (from CLAUDE.md): declarative models.Constraint / models.Index (never _sql_constraints); group_ids not groups_id; HTTP routes type="jsonrpc"; backend OWL uses standalone rpc() from @web/core/network/rpc (not useService("rpc")), client action static props = ["*"]; dark mode = branch on $o-webclient-color-scheme at SCSS compile time and register the SCSS in both web.assets_backend and web.assets_web_dark; new fields use the x_fc_ prefix; Canadian English; any message_post(body=…) HTML wrapped in Markup().
• Enterprise-only: fusion_claims pulls ai → it cannot install on local Community (odoo-modsdev). Do not attempt -d modsdev -u fusion_claims. (fusion_tasks alone may install locally — the tz-fix test in Plan 2 Task 1 can be tried there; everything else is clone-only.)
• The design is LOCKED — implement exactly §6 below; don't add scope or re-open decisions.

6. Locked design (build exactly this)

• Time: 12-hour AM/PM entry on the wizard (custom control — Odoo's native widget is 24h). Fix the fusion_tasks tz bug: the _inverse_datetime_* methods must use self._get_local_tz() (same resolver as _compute_datetimes), not self.env.user.tz.
• Client: inline new-client (name / phone / email / address) on the page; no forced SO (relax fusion_claims _check_order_link to a no-op); find-or-create the res.partner on save (match by email then phone).
• View: a full OWL client action wizard (complete design freedom), ported from the mockup, dark + light.
• Pricing → SO: pick service type → call-out fee → auto draft repair sale.order with the call-out line + auto per-km line for Rush/After-Hours (qty = travel_distance_km × 2, $0.70/km). On-screen estimate is UI-only (labour/parts added later as actuals). Tag the SO (x_fc_is_service_repair + a "Service Repair" tag).
• Rates are an editable table — fusion.service.rate with a Service Rates menu. The card only seeds it (noupdate=1). Pricing is read from this table, never hardcoded.
• Rate card seed: Standard call $95 / Rush $120 / After-Hours $140; Lift & Elevating $160 / Rush $185 / After-Hours $205 (the $185/$205 are suggested fills — seed them but they're confirm-pending; leave a code comment). Labour: on-site $85, in-shop $75 (reuse existing LABOR product), lift $110. Per-km $0.70 ×2-way. Delivery/setup: local $35 / outside $60 / rush $60+km / lift-chair $120 / bed $120 / stairlift $300 / removal $300. In-shop = no call-out, labour @ $75.
• Module split: the tz fix goes in fusion_tasks; everything else (rate model, products, menu, resolver, SO builder, action_book_from_wizard, controller, OWL wizard, SCSS, entry point) goes in fusion_claims.

7. Verification (you probably can't reach the Enterprise clone — handle both cases)

• Always do (no Odoo needed): after each Python file, run python -m py_compile <file> and python -m pyflakes <file> (or docker exec odoo-modsdev-app python3 -m pyflakes …). Fix every warning you introduce. This is your local gate.
• Full tests + smoke require a Westin Enterprise clone. A one-command harness already exists: scripts/verify_service_booking.sh (runs on the odoo-westin host: clones the DB, the orphaned-tax-FK cleanup, stages the branch, -u + tests, PASS/FAIL; --deploy ships on green).
  • If you have access to odoo-westin: push the branch, then run that script (verify-only first).
  • If you do not: finish all code, ensure py_compile/pyflakes are clean, commit the branch task-by-task, and clearly report "clone-verification pending — run scripts/verify_service_booking.sh on odoo-westin." Do not fake a green test.
• Never deploy to prod yourself. Leave --deploy to the human.

8. Definition of done

• Branch claude/technician-service-booking off main.
• Plan 1 + Plan 2 implemented, committed task-by-task with the plans' commit messages.
• py_compile + pyflakes clean on every touched .py.
• OWL wizard renders the mockup layout in both light and dark bundles.
• Either clone-verified GREEN via the script, or branch committed + verification explicitly flagged pending (with the exact command to run).
• A short final report: what was built, files changed, how to verify + deploy (scripts/verify_service_booking.sh), and the one open business item (confirm Lift Rush/After-Hours $185/$205).

9. Don't

• Don't test on odoo-modsdev (Community — fusion_claims won't install).
• Don't re-brainstorm or change the design in §6.
• Don't hardcode prices (they live in fusion.service.rate).
• Don't deploy to prod or run --deploy — hand that to the human.
• Don't change the suggested $185/$205 silently — keep them, flag them confirm-pending.

---

Optional: launch it headless

# from the repo root, on a machine with this checkout:
claude -p "$(cat docs/superpowers/EXECUTE-technician-service-booking.md)" --permission-mode acceptEdits

…or just paste this file into a fresh Claude Code session and say "go".