azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(memory): consolidate scattered feedback/project/reference files

Browse Source 
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.
This commit is contained in:
Mike Swanson
2026-06-01 16:25:45 -07:00
parent 19b69c52ad
commit d676a9a03b
75 changed files with 1473 additions and 1324 deletions
Download Patch File Download Diff File Expand all files Collapse all files

40
.claude/memory/feedback_syncro_appointment_owner.md
View File

@@ -1,40 +0,0 @@
---
name: Syncro — confirm appointment owner explicitly when creating tickets with appointments
description: When creating Syncro tickets that include an appointment, always ask "who is the appointment owner?" before posting. Don't auto-default to the ticket's assigned tech, and distinguish owner from additional attendees.
type: feedback
---
**Rule:** When creating a Syncro ticket that includes an appointment (Onsite, Remote, Phone Call, etc.), explicitly **ask the user who the appointment owner is** in the preview phase. Do not assume the appointment owner equals the ticket's assigned tech, and do not silently add other techs as attendees.
**Why:** The appointment owner is the person whose calendar the appointment lands on as the primary entry — they are the one accountable for being there. Additional `user_ids` in the appointment payload only add the entry to other techs' calendars as secondary/visible items, which clutters their schedule and creates ambiguity about who is actually on the hook for the visit. Howard caught this on 2026-05-08 after a ticket creation where I added the assigned tech to `user_ids` without confirming whether they should be the owner versus an attendee.
**How to apply:**
In the ticket creation preview (Step 3 of the ticket creation workflow), present the appointment block with the OWNER as a separate, explicit field — not buried as an inferred default. Example preview format:
```
APPOINTMENT
-----------
Type: Onsite
Owner: <ASK USER — who's calendar should this be on?>
Additional attendees: (optional, leave blank unless explicitly added)
Start: <start_at>
End: <end_at>
Location: <blank or override>
```
In the API payload, the appointment owner is the FIRST or PRIMARY entry in `user_ids`. Confirm:
- The owner is the person actually attending the appointment (or the lead tech if multiple).
- If the user wants ONLY the owner with no co-attendees, `user_ids` should contain ONE id only.
- If the user wants additional attendees (e.g., "Mike will join remote, Howard onsite"), add them only after explicit confirmation in the preview.
**What NOT to do:**
- Do NOT auto-add the ticket's `user_id` (assigned tech) as the appointment owner without asking.
- Do NOT add additional attendees to `user_ids` without explicit user direction.
- Do NOT treat appointment owner as a passive inheritance from the ticket — surface it as an active confirmation field in the preview.
**Trigger context:**
Howard created the Kittle Design ticket (#32263) on 2026-05-08 for an 11:30 AM onsite to set up Joshua. I auto-added Howard's `user_id` to the appointment's `user_ids` array without confirming whether Howard was the owner or just an attendee. Howard flagged: "when setting up an appointment confirm the appointment owner — don't just add additional attendees." Save as a rule for syncro ticket creation.