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

sync: auto-sync from HOWARD-HOME at 2026-04-23 21:12:42

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-04-23 21:12:42
This commit is contained in:
Howard Enos
2026-04-23 21:12:43 -07:00
parent 6ec260c023
commit 6e2d99bd23
3 changed files with 43 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.claude/memory/MEMORY.md
View File

@@ -25,6 +25,7 @@
- [365 Remediation Tool](feedback_365_remediation_tool.md) - Always means Graph API app fabb3421, not CIPP
- [Ollama Tier-0 Routing](feedback_ollama_tier0_routing.md) - Route drafts/summaries/classifications through Ollama (qwen3:14b). Mike designed ClaudeTools this way — not optional.
- [Syncro Emergency Billing](feedback_syncro_emergency_billing.md) — Emergency = 1.5× multiplier, not additive. Branch by `customer.prepay_hours`: no-prepaid → `26184` at actual hrs; prepaid → `26118` at hrs×1.5. Never stack. Always set `price_retail`.
- [Identity precedence](feedback_identity_precedence.md) — Trust `.claude/identity.json` over the system-reminder `userEmail` hint when they disagree (shared-login machines).
## Machine
- [ACG-5070 Workstation Setup](reference_workstation_setup.md) - Windows 11 Pro clean install 2026-03-30, replaced CachyOS. All tools installed.

11
.claude/memory/feedback_identity_precedence.md Normal file
View File

@@ -0,0 +1,11 @@
---
name: identity.json beats userEmail hint
description: When .claude/identity.json and system-reminder userEmail disagree, trust identity.json — it's the per-machine source of truth
type: feedback
---
When the system-reminder context claims `userEmail = mike@azcomputerguru.com` but `.claude/identity.json` says `howard`, trust identity.json. The userEmail comes from global Claude Code config (Mike set up the login on both machines under his account); identity.json is the per-machine, gitignored file that records who actually sits at this keyboard.
**Why:** On 2026-04-23 I addressed Howard as "Mike" because the claudeMd/userEmail context said so. Howard corrected me. The CLAUDE.md onboarding flow explicitly defines identity.json as the authoritative local identity.
**How to apply:** At every session start, read `.claude/identity.json` FIRST (as CLAUDE.md step 1 requires) and greet from that file's `full_name`. Ignore the `# userEmail` context block for greeting purposes. If identity.json is missing, follow the first-machine bootstrap flow in CLAUDE.md — don't fall back to userEmail.

44
clients/cascades-tucson/docs/migration/share-access-matrix-2026-04-23.md
View File

@@ -213,8 +213,7 @@ Agency placeholders ("Reliable Agency 1/2") are **not** being created as account
These names show up on Synology but are not in John's current employee list. They'll be disabled when we retire the Synology file-share role:
- **Stephanie Devin** — "Accounting Assist", no longer in CSV. Confirm departed.
- **Amber M Lee, Ann Dery, Anna Pitzlin, Britney Thompson, Haris Durut, Monica RamirezRossette, Nela Durut-Azizi** — all former employees.
- **Amber M Lee, Ann Dery, Anna Pitzlin, Britney Thompson, Haris Durut, Monica RamirezRossette, Nela Durut-Azizi, Stephanie Devin** — all former employees.
- **Tamra Johnson** (old alias — now `Tamra Matthews`)
- **CasAdmin201** — prior-MSP admin account. Confirm with Meredith before deletion.
- **Role accounts** — `Accounting`, `Dining Manager`, `Front Desk`, `mcnurse`, `memcarenurse`, `Memcare Receptionist`, `Nurse Tower`. These are shared logins that violate HIPAA unique-user-identification requirement. Replaced by the named-person accounts above.
@@ -257,7 +256,6 @@ Tick each when answered:
- [ ] **Shelby Trozzi** — OK with the narrower scope (no admin-full), keeping her as MC Director?
- [ ] **Matt Brooks** — primary department: Maintenance or Resident Services (MC Receptionist)?
- [ ] **Christine Nyanzunda** — Management as read-only OK, or does she need write?
- [ ] **Stephanie Devin** — confirm no longer employed (so we disable her Synology account)
- [ ] **`Activities` folder** — confirm contents are Life Enrichment only (so we create CS-SERVER `LifeEnrichment` share with just LE team RW)
- [ ] **`pacs` folder** — Howard verified 2026-04-23 it's empty on Synology. **Do we create a Clinical shared folder on CS-SERVER at all?** If clinical staff use ALIS for everything, retire the concept entirely (and strip Clinical from everyone's access lines above). If there's a future need, we create an empty `Clinical-PHI` share with the access list already proposed.
- [ ] **`web` folder** — confirm we can retire entirely (DSM web station, not a business share)
@@ -270,7 +268,26 @@ Tick each when answered:
- **Create three new shares on CS-SERVER** — `LifeEnrichment`, `ALdocs`, `WebDocs` at `D:\Shares\<name>`. Populate NTFS per this doc.
- **Map the new shares** — LE workstations are net-new mappings (no drives today). Script the drive maps via GPO or logon script once per-user interviews close.
- **Receptionist share — machine+user GPO/logon-script mapping** — drive letter (likely `S:`) should only map when the machine is a Tower reception PC (currently `RECEPTIONIST-PC`, and any future Tower-desk stations) AND the user is in a Tower receptionist role group. MC receptionist PC and Sales workstations must NOT get the drive auto-mapped even if the user also logs in elsewhere.
- **Retarget Synology Drive Client sync path** from `D:\Shares\Main` to `D:\Shares\Synology\` before Phase 4 share cutover.
## Transition from Synology Drive Client to SMB mapped drives
**Current state.** The Synology NAS (`cascadesDS`) two-way syncs its shares to CS-SERVER at `D:\Shares\Main\` via a Synology Drive Client running on CS-SERVER. That sync stays in place until Phase 4 cutover. Separately, some user workstations also have Synology Drive Client installed locally, pulling a cached copy of the shares to each PC — that's how those users access Management / SalesDept / Server / Public today.
**Goal.** Replace each user's local Synology Drive Client with a standard SMB mapped drive (e.g. `\\CS-SERVER\Management`, backed by `D:\Shares\Main\Management`). Because CS-SERVER's copy is kept current by the NAS-side sync, users see the same files via the mapped drive as they did via Synology Drive Client — no data move, just a different access path.
**Prerequisite.** NTFS permissions on each `D:\Shares\Main\<share>` folder must match this access matrix **before** drives are mapped on a user's PC. Otherwise users will see the folder but hit access-denied on files.
**Rollout per user:**
1. Create / populate that user's `SG-*-RW` group memberships per this matrix.
2. Map their drives via GPO Preferences (or logon script) based on those group memberships.
3. Have the user sign in, open each mapped drive, confirm read-and-write works where expected.
4. Uninstall Synology Drive Client from the PC. Delete the local cached folder once confirmed empty of unsynced changes.
5. Log the change in the session log for that day.
**At Phase 4 cutover** the sync direction breaks: CS-SERVER becomes authoritative, the Synology moves to read-only, then to a backup target. Mapped drives already point at CS-SERVER so no user-side change is needed at cutover.
**Do not retarget the CS-SERVER Synology Drive Client sync path.** It stays at `D:\Shares\Main\` for the duration. An earlier version of this doc proposed moving it to `D:\Shares\Synology\` — that plan is scrapped because it would break the current user-side Synology Drive Client sync for the users still on it.
## Next step — per-user interviews
@@ -290,8 +307,9 @@ For Howard's reference during setup. Reviewers can skip this section.
Two path conventions on CS-SERVER's D: drive:
- **`D:\Shares\Synology\<name>\`** — two-way synced with cascadesDS via Synology Drive Client. Use this for any share that needs to exist on both the Synology NAS and CS-SERVER during the Phase 4 overlap window: Management, SalesDept, Server, Public, homes, and any others Meredith wants kept in sync.
- **`D:\Shares\<name>\`** — CS-SERVER-local only, no Synology sync. Use this for shares that don't exist on Synology today or don't need a Synology copy: Culinary, IT, Receptionist, directoryshare.
- **`D:\Shares\Main\<name>\`** — two-way synced with cascadesDS via Synology Drive Client running on CS-SERVER. Use this for any share that needs to exist on both the Synology NAS and CS-SERVER during the Phase 4 overlap window: Management, SalesDept, Server, Public, and any others Meredith wants kept in sync. **This is the existing sync target — do not retarget.**
- **`D:\Shares\<name>\`** — CS-SERVER-local only, no Synology sync. Use this for shares that don't exist on Synology today or don't need a Synology copy: Culinary, IT, Receptionist, directoryshare, LifeEnrichment, ALdocs, WebDocs.
- **`D:\Homes\<username>\`** — per-user folder-redirection share. Exposed as `\\CS-SERVER\homes`. Not under either shares tree; not Synology-synced.
SMB share names stay flat (`\\CS-SERVER\Management`, `\\CS-SERVER\Culinary`) — users never see the path difference. Only the NTFS path under the hood changes.
@@ -299,11 +317,11 @@ Shares to create/update on CS-SERVER at this path convention:
| SMB share | CS-SERVER path | Synced with Synology? |
|---|---|---|
| Management | `D:\Shares\Synology\Management` | yes |
| SalesDept | `D:\Shares\Synology\SalesDept` | yes |
| Server | `D:\Shares\Synology\Server` | yes |
| Public | `D:\Shares\Synology\Public` | yes |
| homes | `D:\Shares\Synology\homes` | yes |
| Management | `D:\Shares\Main\Management` | yes |
| SalesDept | `D:\Shares\Main\SalesDept` | yes |
| Server | `D:\Shares\Main\Server` | yes |
| Public | `D:\Shares\Main\Public` | yes |
| homes | `D:\Homes` | **no** (local, folder-redirection target) |
| LifeEnrichment | `D:\Shares\LifeEnrichment` | **no** (CS-SERVER local, new) |
| ALdocs | `D:\Shares\ALdocs` | **no** (CS-SERVER local, new) |
| WebDocs | `D:\Shares\WebDocs` | **no** (CS-SERVER local, new) |
@@ -314,9 +332,9 @@ Shares to create/update on CS-SERVER at this path convention:
| IT | `D:\Shares\IT` | **no** |
| Sandra Fish Archive | `D:\Shares\Archive\Former-Director-Sandra-Fish` | **no** — Meredith-only, archived |
The existing Synology Drive Client sync target on CS-SERVER today is `D:\Shares\Main` (per `docs/servers/cs-server.md`) — that will be retargeted to `D:\Shares\Synology\` before Phase 4 NTFS permissions go on, so the path convention matches this doc.
The existing Synology Drive Client sync target on CS-SERVER is `D:\Shares\Main\` (per `docs/servers/cs-server.md`). **It stays there for the duration of the Phase 4 overlap.** An earlier draft of this doc proposed retargeting to `D:\Shares\Synology\` — that plan is scrapped; users currently rely on `D:\Shares\Main\` and a retarget would break their sync.
`scripts/phase2-file-shares.ps1` will need its `$DestRoot` + per-share `Path` values updated to match.
`scripts/phase2-file-shares.ps1` will need its `$DestRoot` + per-share `Path` values updated to match (`D:\Shares\Main\<name>` for synced shares, `D:\Shares\<name>` for local-only).
---