Files
claudetools/.claude/standards/syncro/time-entry-protocol.md
Mike Swanson dd0ef45645 feat: implement agent-os standards system and feature planning tools
- 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>
2026-05-16 12:59:49 -07:00

63 lines
3.1 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: time-entry-protocol
description: Always use timer_entry flow for billing; ask minutes and labor type before logging any time; never assume defaults
applies-to: syncro
---
# Syncro Time Entry Protocol
## Always ask before logging time
Before logging any time entry, ask the user:
1. How many minutes?
2. 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:
```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.