Compressed memory store 104 -> 71 files via four passes: - Syncro: 19 scattered feedback_syncro_* files merged into 3 rule files (api/billing/workflow) + an on-demand feedback_syncro_history.md for incident detail, quotes, and tech/product ID tables. - Four near-duplicate merges: Howard paste-safety, Pluto build server, Howard backend deferral, IX server access (ssh+tailscale). - Per-cluster rule/state/history split applied to GuruConnect (2->1), Dataforth (3->2), Cascades (7->3), GuruRMM (13->3). - New reference_resource_map.md: single auto-loaded cheatsheet for "do I have access to X and how do I connect from this machine?" - MEMORY.md rewritten to match the new layout. Health: broken backlinks 8->7, overlap clusters 12->5, orphans 17->0.
3.8 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| Syncro workflow rules — preview comments, appointment ownership/dates, blank contact | Process and etiquette rules for Syncro work — always preview comments before posting, verify appointment day-of-week before creating, ask who the appointment owner is, leave the contact field blank by default for all customers. |
|
Rules only. Incident detail and ticket numbers live in feedback_syncro_history — read on-demand. API mechanics: feedback_syncro_api. Billing rules: feedback_syncro_billing.
1. ALWAYS preview comments before posting — no exceptions
Show the full comment text and wait for explicit confirmation before posting any comment to a Syncro ticket. No exceptions — not billing, not resolution notes, not client-facing, not internal/hidden notes.
Apply: draft → show as a formatted block → "Good to post?" → wait for yes → only then POST. Also ALWAYS ask for minutes + labor type before logging time — never assume a default.
Once posted, comments can't be deleted via API (manual GUI cleanup required). See also feedback_syncro_api §2 (no idempotency).
2. Verify appointment day-of-week before creating
Print the weekday and confirm it matches intent before posting:
py -c "import datetime; d=datetime.date(2026,5,24); print(d.strftime('%A %Y-%m-%d'))"
# Sunday 2026-05-24
Catch: always show Day YYYY-MM-DD (e.g. "Saturday 2026-05-23") in the preview — never just the numeric date.
3. Ask explicitly who the appointment owner is
When creating a ticket with an appointment (Onsite, Remote, Phone Call, etc.), explicitly ask who the appointment owner is in the preview. Do NOT default to the ticket's assigned tech; do NOT silently add other techs as attendees.
The owner is whose calendar the appointment lands on as the primary entry — they are accountable for being there. Additional user_ids only add the entry as secondary items on other techs' calendars (clutter + ambiguity).
Preview format:
APPOINTMENT
-----------
Type: Onsite
Owner: <ASK USER — whose calendar?>
Additional attendees: (optional, blank unless explicitly added)
Start: <start_at>
End: <end_at>
API payload: owner is the FIRST entry in user_ids. If only the owner, user_ids has ONE id. Additional attendees only after explicit confirmation.
Don't: auto-add the ticket's user_id as owner without asking; add attendees without direction; treat owner as passive inheritance.
4. Leave the contact field BLANK by default
When creating or billing tickets, leave contact_id / contact_name / contact_email blank ("Not Assigned") by default for any customer. Only set a contact when the user explicitly says to.
Blank contact lets Syncro apply company-level email defaults, routing notifications to the right people. Setting a specific contact overrides those and may push to a secondary email, bypassing the customer's intended distribution.
Apply:
POST /tickets: omitcontact_idfrom the body entirely. Don't fetch contacts viaGET /customers/{id}and pick one.PUT /tickets/{id}: send only fields you're changing. NEVER includecontact_id/contact_name/contact_email, even matching the existing value — PUT can re-apply.- Billing/invoices: same rule. Drop
contact_idif it shows up in any payload. - Verify after writes:
GET /tickets/{id}→.ticket.contact_idshould benull. If set, blank it:PUT /tickets/{id}with{"contact_id": null}.
Watch for Syncro's auto-default: the contact picker often pre-selects the first-alphabetical or most-recently-used contact (Cascades' Meredith Kuhn is the canonical bad-default — see feedback_syncro_history). The rule applies the same way: ignore the pre-selection, leave null.