Files
claudetools/.claude/memory/feedback_syncro_workflow.md
Mike Swanson 0c000109dc chore(memory): consolidate scattered feedback/project/reference files
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.
2026-06-01 16:25:45 -07:00

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.
type
feedback

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: omit contact_id from the body entirely. Don't fetch contacts via GET /customers/{id} and pick one.
  • PUT /tickets/{id}: send only fields you're changing. NEVER include contact_id/contact_name/contact_email, even matching the existing value — PUT can re-apply.
  • Billing/invoices: same rule. Drop contact_id if it shows up in any payload.
  • Verify after writes: GET /tickets/{id}.ticket.contact_id should be null. 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.