fix(syncro): resolve billing SSOT — add_line_item is normal, timers outlier-only

Task 3/3a of the harness-optimization spec. Mike confirmed normal billing uses
add_line_item; timers stay available only for explicit outlier requests, never the
normal loop. Rewrote time-entry-protocol.md to defer to the /syncro command (SSOT for
billing mechanics) and state timers are outlier-only; aligned the command's two
absolute "no timers" lines. Contradiction removed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

.claude/standards/syncro/time-entry-protocol.md

@@ -1,62 +1,44 @@
 ---
 name: time-entry-protocol
-description: Always use timer_entry flow for billing; ask minutes and labor type before logging any time; never assume defaults
+description: Normal Syncro billing uses add_line_item per the /syncro command; timers are an outlier path used only when Mike explicitly requests one; always confirm minutes + labor type before logging.
 applies-to: syncro
 ---
 
 # Syncro Time Entry Protocol
 
-## Always ask before logging time
+## Source of truth
 
-Before logging any time entry, ask the user:
-1. How many minutes?
-2. What labor type? (onsite, remote, emergency, warranty, project, etc.)
+The `/syncro` command (`.claude/commands/syncro.md`) is the SINGLE source of truth for
+the billing mechanics — product IDs, rates, emergency and prepaid handling, the
+line-item + invoice flow. Do not duplicate or contradict it here. This standard states
+only the cross-cutting discipline.
 
-Never assume a default. Never round up or fill in a number. Billing errors are client-facing, hard to reverse, and affect prepaid block balances. An incorrect time entry requires Winter (billing) to manually reverse it.
+## Normal billing = add_line_item
 
-## The required flow
+Routine labor bills directly via `POST /tickets/{id}/add_line_item` (see the /syncro
+command for the exact payload, product IDs, and `price_retail` rules). This is the
+standard, expected path for all normal billing. (Confirmed by Mike, 2026-06-08.)
 
-All time-bearing work must use `timer_entry → charge_timer_entry`, not bare `add_line_item`. This is a hard rule.
+## Timers are an OUTLIER — not the billing loop
 
-```
-1. POST /tickets/{id}/timer_entry     — create the time record
-2. POST /tickets/{id}/charge_timer_entry   — generate the line item from the timer
-3. Verify line item: GET /tickets/{id} → check price_retail on the new line item
-4. If price_retail is wrong: PUT /tickets/{id}/line_items/{item_id} to patch it
-5. POST /invoices                     — roll line item onto invoice
-6. PUT /tickets/{id}                  — set status to Invoiced
-```
+`timer_entry → charge_timer_entry` is NOT part of normal billing. Use it ONLY when Mike
+explicitly asks for a timer on a specific job. The capability stays available, but it is
+never the default and routine labor is never routed through it.
 
-The `add_line_item` endpoint bypasses Syncro's time-tracking table entirely. Using it for labor means hours appear in the invoice but not in time-tracking reports (hours per client, technician productivity, average resolution time, prepay burn rate). After the 2026-04-30 audit, 31 closed tickets had 00:00:00 in time tracking because bare `add_line_item` was used for all of them.
+When a timer IS explicitly requested:
+1. `POST /tickets/{id}/timer_entry` → 2. `POST /tickets/{id}/charge_timer_entry` →
+   verify the generated line item's `price_retail` (patch via `update_line_item` if wrong).
+- `billable: false` is silently ignored by the API on `timer_entry` — for warranty/free,
+  verify in the GUI that the charged line landed at $0 and patch if not.
 
-## When bare add_line_item is acceptable
+## Always confirm before logging (either path)
 
-Only for non-time items:
-- Hardware/parts
-- Flat-fee services with no labor component
-- Software licenses
+Before logging any time, confirm: (1) how many minutes, (2) what labor type — onsite /
+remote / emergency / warranty / project. Never assume a default or round up. Billing
+errors are client-facing, hard to reverse, and affect prepaid block balances (Winter has
+to reverse them manually).
 
-Even warranty or free labor must use `timer_entry` with `billable: false`. The only exception is cancelled tickets where no work was performed.
+## Prepaid
 
-## Labor type reference
-
-| Situation | Product | Note |
-|-----------|---------|-------|
-| Standard onsite | `26118` Onsite Business | At `hours × $175` |
-| Emergency/after-hours | `26184` Emergency or After Hours | Full rate, no quantity multiplier |
-| Prepaid project labor | `9269129` Prepaid Project Labor | At `$0/hr`; debits from prepay block |
-| Warranty | Any labor product | `billable: false` on timer_entry |
-
-## Prepaid customers
-
-Before applying any rate, verify `prepay_hours` on the customer record:
-```bash
-curl -s "https://computerguru.syncromsp.com/api/v1/customers/${CUSTOMER_ID}?api_key=${API_KEY}" \
-  | jq '.customer.prepay_hours'
-```
-
-If `prepay_hours > 0`, use the prepaid product at `$0/hr` and verify the balance debits correctly after the invoice posts (Syncro may not debit until the invoice is paid in the GUI — flag for Winter if uncertain).
-
-## Note on billable: false
-
-The Syncro API ignores `billable: false` on `timer_entry` calls silently — the entry is created but the billing flag has no effect through the API. If a warranty/free entry is needed, create the timer entry, then verify through the GUI that the line item generated by `charge_timer_entry` is at $0. Patch with `update_line_item` if it came in at a non-zero rate.
+Check `prepay_hours` on the customer before billing — the /syncro command holds the
+authoritative prepaid + emergency rules.