Mike Swanson
dd0ef45645
- Split CODING_GUIDELINES.md into 19 indexed standards files under .claude/standards/ - 9 from CODING_GUIDELINES (conventions, powershell, security, api, git, gururmm) - 10 from session log tribal knowledge (syncro, ssh, gitea, python, client, gururmm) - Add .claude/standards/index.yml for cheap relevance-based lookup - Add /inject-standards command: load targeted standards per task instead of full guidelines - Add /shape-spec command: pre-implementation spec for GuruRMM features (plan.md, shape.md, references.md, standards.md) with mandatory out-of-scope gate - Add docs/tech-stack.md and docs/mission.md for ClaudeTools API - Add projects/msp-tools/guru-rmm/docs/tech-stack.md and mission.md for GuruRMM - Update CLAUDE.md commands table with /inject-standards and /shape-spec Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
3.1 KiB
name, description, applies-to
| name | description | applies-to |
|---|---|---|
| time-entry-protocol | Always use timer_entry flow for billing; ask minutes and labor type before logging any time; never assume defaults | syncro |
Syncro Time Entry Protocol
Always ask before logging time
Before logging any time entry, ask the user:
- How many minutes?
- What labor type? (onsite, remote, emergency, warranty, project, etc.)
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.
The required flow
All time-bearing work must use timer_entry → charge_timer_entry, not bare add_line_item. This is a hard rule.
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
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 bare add_line_item is acceptable
Only for non-time items:
- Hardware/parts
- Flat-fee services with no labor component
- Software licenses
Even warranty or free labor must use timer_entry with billable: false. The only exception is cancelled tickets where no work was performed.
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:
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.